Re: Working group last call on protocol document set
Gregory Neil Shapiro <[email protected]> Tue, 6 Nov 2001 12:57:12 -0800
| Newsgroups | gmane.ietf.msgtrk |
|---|---|
| Message-ID | <[email protected]> |
--WPJla7Cb6r Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit steve.hole> At this time I would like to issue a working group last call on steve.hole> the collection of three protocol documents: steve.hole> draft-ietf-msgtrk-mtqp-03.txt We need a new revision of the -mtqp- document from Tony first as there are issues from Philip Hazel and myself which haven't been taken into account in the -03 version. I've attached them below. --WPJla7Cb6r Content-Type: multipart/digest; boundary="VYn9l6j2m/" Content-Transfer-Encoding: 7bit This is a digest, 3 messages, MIME encapsulation. --VYn9l6j2m/ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Gregory Neil Shapiro <[email protected]> Sender: [email protected] To: [email protected] Subject: Comments on draft-ietf-msgtrk-mtqp-03.txt Date: Sat, 4 Aug 2001 01:47:34 -0700 Message-ID: <[email protected]> 2. Basic Operation The second paragraph describes how to determine tracking host to contact. How about a host like this: gshapiro.net IN SRV mtqp tracking.gshapiro.net IN MX 10 smtp.gshapiro.net IN MX 20 smtp.sendmail.com In other words, a dedicated tracking server for gshapiro.net and two MX records. When an SMTP message is sent, smtp.gshapiro.net happens to be unavailable so the message goes to smtp.sendmail.com. If an MTQP client then tries to track the message, it will use tracking.gshapiro.net (due to the SRV record). However, tracking.gshapiro.net doesn't know about the message yet (still in smtp.sendmail.com's queue). The lookup fails. Also, it's not clear from the paragraph that if SRV records do not exist, do you only use the first MX returned or all of them in MX preference order? If I may suggest the following change: When an MTQP client wishes to make use of the message tracking service, it establishes a TCP connection with the server host. To find the server host, the MTQP client first does an MX lookup for the server host using DNS MX records, as specified in [RFC-DNS] and revised by [RFC-HOSTS]. If no MX records are found, the MTQP client then does an A record lookup for the server host. If MX records are found, for each MX record (in MX preference order -- lowest to highest), an SRV lookup on the MX host name using DNS SRV records, with a service name of "mtqp". (See the "Usage rules" section in [RFC-SRV] for details.) If a SRV host is found, the MTQP client uses that host for tracking. Otherwise, it uses the MX host name for tracking. Finally, the host either the SRV host (if found) or the MX host is contacted using MTQP. This process is repeated for each of the MX records until an MTQP lookup succeeds (i.e., tracking status is returned). With this new text, the DNS records might look something like: gshapiro.net IN MX 10 smtp.gshapiro.net IN MX 20 smtp.sendmail.com smtp.gshapiro.net IN A 10.254.153.10 smtp.sendmail.com IN A 192.168.10.43 IN SRV mtqp tracking.sendmail.com tracking.sendmail.com IN A 192.168.10.45 In which case, a message sent to [email protected] would be tracked by first contacting smtp.gshapiro.net with MTQP and if no tracking information is available at that host (or it can not be contacted), then continue by contacting tracking.sendmail.com with MTQP. An example, such as the one I have given should be added to the draft. --- 3. Initialization and Option Response Example 5 should probably use "VND." as Option2 and Option3 are not valid (only STARTTLS is). A suggested replacement: Example #5 (options available): S: +OK+/MTQP MTQP server ready S: starttls S: Vnd.vendor.Option2 with parameters S: Vnd.vendor.Option3 with a very long S: list of parameters S: . --- 10. IANA Considerations Vendor-specific options MUST be registered with IANA? I thought the whole point of vendor options was like that of 'X' ESMTP extensions: RFC 2821 Simple Mail Transfer Protocol April 2001 2.2.2 Definition and Registration of Extensions In addition, any EHLO keyword value starting with an upper or lower case "X" refers to a local SMTP service extension used exclusively through bilateral agreement. Keywords beginning with "X" MUST NOT be used in a registered service extension. Conversely, keyword values presented in the EHLO response that do not begin with "X" MUST correspond to a standard, standards-track, or IESG-approved experimental SMTP service extension registered with IANA. A conforming server MUST NOT offer non-"X"-prefixed keyword values that are not described in a registered extension. If that is the case, then they should not be registered with IANA. Perhaps we want to steal some of the above text for this document. --- 12. Protocol Syntax Move opt-text up as it is used by comment-command first (before temp-response). The response-info ABNF is incorrect. The parens are not balanced. --- Spelling fixes: @@ -197 +197 @@ -parseable, case-insensitive response information giving more data about +parsable, case-insensitive response information giving more data about @@ -249 +249 @@ -Which option is picked is an adminstrative decision and is not further +Which option is picked is an administrative decision and is not further @@ -667 +667 @@ - System port number XXXX - TBA by IANA + System port number XXXX - TBD by IANA @@ -693 +693 @@ -begin with "vnd." MUST be registered with IANA on a Firt Come First +begin with "vnd." MUST be registered with IANA on a First Come First @@ -721 +721 @@ - Both the STMP client and server must check the result of the TLS + Both the SMTP client and server must check the result of the TLS @@ -725 +725 @@ -was achieved is made locally, is implementation-dependant, and is beyond +was achieved is made locally, is implementation-dependent, and is beyond @@ -825 +825 @@ -13. Acknowledgements +13. Acknowledgments @@ -925 +925 @@ -assist in its implmentation may be prepared, copied, published and dis- +assist in its implementation may be prepared, copied, published and dis- @@ -930 +930 @@ -references to the Internet Society or other Internet organisations, +references to the Internet Society or other Internet organizations, --VYn9l6j2m/ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Tony Hansen <[email protected]> Sender: [email protected] To: [email protected] Subject: Re: Comments on draft-ietf-msgtrk-mtqp-03.txt Date: Sat, 04 Aug 2001 14:07:05 -0400 Message-ID: <[email protected]> See comments below. Tony Gregory Neil Shapiro wrote: > > 2. Basic Operation > > The second paragraph describes how to determine tracking host to contact. > How about a host like this: > > gshapiro.net IN SRV mtqp tracking.gshapiro.net > IN MX 10 smtp.gshapiro.net > IN MX 20 smtp.sendmail.com > > In other words, a dedicated tracking server for gshapiro.net and two MX > records. When an SMTP message is sent, smtp.gshapiro.net happens to be > unavailable so the message goes to smtp.sendmail.com. If an MTQP client > then tries to track the message, it will use tracking.gshapiro.net (due to > the SRV record). However, tracking.gshapiro.net doesn't know about the > message yet (still in smtp.sendmail.com's queue). The lookup fails. > > Also, it's not clear from the paragraph that if SRV records do not exist, > do you only use the first MX returned or all of them in MX preference > order? > > If I may suggest the following change: > > When an MTQP client wishes to make use of the message tracking > service, it establishes a TCP connection with the server host. To > find the server host, the MTQP client first does an MX lookup for the > server host using DNS MX records, as specified in [RFC-DNS] and > revised by [RFC-HOSTS]. If no MX records are found, the MTQP client > then does an A record lookup for the server host. If MX records are > found, for each MX record (in MX preference order -- lowest to > highest), an SRV lookup on the MX host name using DNS SRV records, > with a service name of "mtqp". (See the "Usage rules" section in > [RFC-SRV] for details.) If a SRV host is found, the MTQP client uses > that host for tracking. Otherwise, it uses the MX host name for > tracking. Finally, the host either the SRV host (if found) or the MX > host is contacted using MTQP. This process is repeated for each of > the MX records until an MTQP lookup succeeds (i.e., tracking status is > returned). > > With this new text, the DNS records might look something like: > > gshapiro.net IN MX 10 smtp.gshapiro.net > IN MX 20 smtp.sendmail.com > > smtp.gshapiro.net IN A 10.254.153.10 > > smtp.sendmail.com IN A 192.168.10.43 > IN SRV mtqp tracking.sendmail.com > > tracking.sendmail.com IN A 192.168.10.45 > > In which case, a message sent to [email protected] would be tracked by > first contacting smtp.gshapiro.net with MTQP and if no tracking information > is available at that host (or it can not be contacted), then continue by > contacting tracking.sendmail.com with MTQP. > > An example, such as the one I have given should be added to the draft. I don't know how common this usage of MX records is, but it is valid. I'm okay with this change. Anyone else? > --- > > 3. Initialization and Option Response > > Example 5 should probably use "VND." as Option2 and Option3 are not valid > (only STARTTLS is). A suggested replacement: > > Example #5 (options available): > S: +OK+/MTQP MTQP server ready > S: starttls > S: Vnd.vendor.Option2 with parameters > S: Vnd.vendor.Option3 with a very long > S: list of parameters > S: . sure > --- > > 10. IANA Considerations > > Vendor-specific options MUST be registered with IANA? I thought the whole > point of vendor options was like that of 'X' ESMTP extensions: > > RFC 2821 Simple Mail Transfer Protocol April 2001 > 2.2.2 Definition and Registration of Extensions > > In addition, any EHLO keyword value starting with an upper or lower > case "X" refers to a local SMTP service extension used exclusively > through bilateral agreement. Keywords beginning with "X" MUST NOT be > used in a registered service extension. Conversely, keyword values > presented in the EHLO response that do not begin with "X" MUST > correspond to a standard, standards-track, or IESG-approved > experimental SMTP service extension registered with IANA. A > conforming server MUST NOT offer non-"X"-prefixed keyword values that > are not described in a registered extension. > > If that is the case, then they should not be registered with IANA. Perhaps > we want to steal some of the above text for this document. I meant to say that the vendor name must be registered, as is done with MIME content types. Another option is to go the java route and use a reversed domain name: vnd.com.example.option1 This avoids the IANA registration issue entirely, under the assumption that only the owners of a domain would use their domain. > --- > > 12. Protocol Syntax > > Move opt-text up as it is used by comment-command first (before > temp-response). > > The response-info ABNF is incorrect. The parens are not balanced. ok > --- > > Spelling fixes: > > @@ -197 +197 @@ > -parseable, case-insensitive response information giving more data about > +parsable, case-insensitive response information giving more data about > @@ -249 +249 @@ > -Which option is picked is an adminstrative decision and is not further > +Which option is picked is an administrative decision and is not further > @@ -667 +667 @@ > - System port number XXXX - TBA by IANA > + System port number XXXX - TBD by IANA > @@ -693 +693 @@ > -begin with "vnd." MUST be registered with IANA on a Firt Come First > +begin with "vnd." MUST be registered with IANA on a First Come First > @@ -721 +721 @@ > - Both the STMP client and server must check the result of the TLS > + Both the SMTP client and server must check the result of the TLS > @@ -725 +725 @@ > -was achieved is made locally, is implementation-dependant, and is beyond > +was achieved is made locally, is implementation-dependent, and is beyond > @@ -825 +825 @@ > -13. Acknowledgements > +13. Acknowledgments > @@ -925 +925 @@ > -assist in its implmentation may be prepared, copied, published and dis- > +assist in its implementation may be prepared, copied, published and dis- > @@ -930 +930 @@ > -references to the Internet Society or other Internet organisations, > +references to the Internet Society or other Internet organizations, ok --VYn9l6j2m/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Philip Hazel <[email protected]> Sender: [email protected] To: <[email protected]> Subject: Late comments on the msgtrk documents Date: Sat, 11 Aug 2001 20:11:08 +0100 (BST) Message-ID: <[email protected]> Folks, I am coming very late to this working group, and I know how annoying it can be when someone piles in late with a zillion comments, so please ignore me if you feel I am out of line. I should also point out that I'm on record as not being very enthusiastic about any of the message tracking mechanisms, so these comments come from the point of view of a sceptic. (And as the author of Exim, I can see that at least one feature of the msgtrk system is close to "impossible" to implement.) Below are comments on draft-ietf-msgtrk-smtpext-03 [SMTPEXT], draft-ietf-msgtrk-trkstat-03 [TRKSTAT], and draft-ietf-msgtrk-mtqp-03 [MTQP]. Regards, Philip -- Philip Hazel University of Cambridge Computing Service, [email protected] Cambridge, England. Phone: +44 1223 334714. --------------------------------------------------------------------- Comments on [SMTPEXT] Section 3, paragraph labelled (4): (a) This paragraph talks about the "MAIL FROM command". In fact, all other RFCs about SMTP call it the "MAIL command". This change is needed throughout the document. (b) The second sentence reads "In addition, the ENVID and ORCPT parameters (as defined in RFC 1891 sections 5.4 and 5.2 respectively) MUST be supported, with extensions as described below." This implies that both these parameters are for the MAIL command, but ORCPT is actually a parameter of the RCPT command. Also, I can't see any extensions for the ORCPT command in the rest of the document. Suggested rewording: In addition, the ENVID parameter of the MAIL command (as defined in RFC 1891 section 5.4) MUST be supported, with extensions as described below. The ORCPT parameter of the RCPT command (as defined in RFC 1891 section 5.2) MUST also be supported. Section 3, paragraph labelled (5): This paragraph is talking about the length of the MAIL command, and says "Note that a further extension of 614 characters for the OCRPT and ENVID parameters is required..." This can't be right, because ORCPT is not a parameter of MAIL. Section 4.1: The first sentence reads "Any sender wishing to track a message must...". I think it would be clearer to say "Any sender wishing to request the retention of data for subsequent tracking of a message must...". A few paragraphs down there is "B is stored in tracking databases of compliant MTAs..." I suggest a change to "compliant receiver MTAs" to contrast with the start of the paragraph, which covers the sender. Section 4.2: The last paragraph reads: Any resubmissions of this message into the message trans- mission system MUST assign a new ENVID. In this context, "resubmission" includes forwarding or resending a message from a user agent, but does not include MTA-level aliasing or forward- ing where the message does not leave and re-enter the message transmission system. What does this mean in the context of an MTA aliasing that turns one incoming address into two outgoing addresses, causing two different copies of the message to be sent to two different MTAs? Does each copy retain the ENVID? (This is probably answered by the following section, but perhaps some words here might help the reader the first time through, and emphasize the point about one-to-one redirection.) Section 4.3: The second and third paragraphs had me somewhat confused. I *think* I now know what is meant, but I may be wrong. If aliasing, forwarding, or other redirection of messages to a single recipient occurs, then the MTA SHOULD treat this as an ordinary hop-to-hop transfer and forward the MTRK=, ENVID=, and ORCPT= values; these values MUST NOT be modified. "redirection of messages to a single recipient" can be read in one of two ways: (a) A single envelope recipient (possibly one among many) is redirected to a new single recipient, and that copy of the message is what we are talking about. OR (b) A message contains only a single (incoming) envelope recipient, and this paragraph covers just that case. I think it must be (a) that is intended. Is this wording better? If aliasing, forwarding, or other redirection of a recipient occurs, and the result of the redirection is exactly one new recipient, the MTA SHOULD treat this as... [This begs the question of the very common case where somebody who is temporarily somewhere else sets up a .forward file that saves messages in their local mailbox, and also forwards them to a single forwarding address. Does this count as "one-to-one" redirection, or not? I suppose it has to be not.] The next paragraph reads thus: MTAs MUST NOT copy MTRK certifiers when relaying a message to multiple recipients. An MTA MAY designate one recipient in a multi-recipient alias as the "primary" recipient to which track- ing requests shall be forwarded; other addresses SHALL NOT receive tracking certifiers. MTAs MUST NOT forward MTRK certi- fiers when doing mailing list expansion. Does "relaying a message to multiple recipients" mean that the message envelope contains more than one recipient, and the MTA is passing it on, or does it mean that a single envelope recipient is expanded to more than one address, and these are passed on? I think the latter is intended, in which case perhaps some wording that mirrors the previous paragraph might be clearer: MTAs MUST NOT copy MTRK certifiers when a recipient is aliased, forwarded, or otherwise redirected and the redirection results in more than one new recipient. However, an MTA MAY designate one of the new recipients as the "primary" recipient... [My case of "save in mailbox and forward" mentioned above is probably an example of where the forward address should be "primary", I suppose.] Section 5.2: (Minor comment.) I felt it might be helpful to add a final paragraph along these lines: Therefore, implementors are encouraged to provide mechanisms by which site administrators can choose between these alternatives. Section 6: [RFC_SMTP] should refer to 2821, not 821 --------------------------------------------------------------------- Comments on [TRKSTAT] References to RFC 822 should refer to 2822 instead. Section 3.3.2 REQUIRES the final-recipient field. I know that many administrators do not want to expose the results of redirection or other address rewriting. I suspect, therefore, that this field will be of very little use in practice. Section 3.3.5 (Remote-MTA field): What if several MTAs have been tried, and the message is delayed because all are unreachable? Should this field be omitted, or should one MTA be chosen at random? Section 3.3.7 (Will-Retry-Until field) is hard for at least one MTA (Exim) to implement (because of the way its retrying is designed). By making this field REQUIRED, this specification assumes a certain kind of retry implementation. --------------------------------------------------------------------- Comments on [MTQP] I think we fixed this at the mini-BOF, but all references to "A records" should be to "address records" so as to include AAAA (or A6 if that refuses to die). Section 2.4 The last sentence reads "An MTQP server MAY limit the number of commands or total connection time to prevent denial of service attacks." It may be worth pointing out that severely limiting the number of *unrecognized* commands defends against attacks that are implemented by subverting unsuspecting programs to send data to arbitrary ports. In such cases, the input usually contains a number of unrecognized commands. There's a specific new attack of this form which can be used against SMTP - it's not yet published, I think, which is why I'm being a bit vague here. The potential for damage is much greater with SMTP than with MTRK, of course. Section 7 (QUIT command): This says "The client may close the session from its end immediately after issuing this command." This was the subject of some heated debate somewhere (can't remember exactly where) in the case of SMTP. The conclusion was, if I recall correctly, that this was a safe thing to do on a Unix system, because of the way that TCP/IP stacks work in Unix. On some other systems, it was alleged, doing this would crash the system, because closing the session wipes out all knowledge of the call, and the incoming response to QUIT on a now-non-existent connection, causes trouble. (Unix, of course, keeps the session hanging around for a bit, in CLOSE_WAIT state.) I have never used Windows or MacOS (believe it or not), let alone programmed for either of them, so I don't know the details of this. However, it seems to me that it might be sensible to put some kind of a warning after that sentence, such as "on operating systems where this does not cause problems". The alternative is to remove the sentence altogether. Section 9: The word "cookie" appears without any previous definition. Section 11: Typo in 4th paragraph: for "dependant" read "dependent". Section 14: References to RFCs 821 and 822 should now be to 2821 and 2822. --------------------------------------------------------------------- --VYn9l6j2m/-- --WPJla7Cb6r--