Subject: Working group last call on protocol document set

From: Steve Hole <[email-masked]>
Date: Tue, 6 Nov 2001 12:04:39 -0700

At this time I would like to issue a working group last call on the 
collection of three protocol documents:

 draft-ietf-msgtrk-smtpext-03.txt
 draft-ietf-msgtrk-trkstat-03.txt
 draft-ietf-msgtrk-mtqp-03.txt

All comments should be delivered to the list.

I would like to thanks our authors Eric Allman and Tony Hansen for their 
wonderful work in putting these documents together for us.

If no comments are received within two weeks, I will recommend their 
progress to the IESG.

Cheers.
---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

---

From: Gregory Neil Shapiro <[email-masked]>
Date: Tue, 6 Nov 2001 12:57:12 -0800

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.

Subject: Comments on draft-ietf-msgtrk-mtqp-03.txt
From: Gregory Neil Shapiro <[email-masked]>
To: [email-masked]
Date: Sat, 4 Aug 2001 01:47:34 -0700

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-masked] 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,

Subject: Re: Comments on draft-ietf-msgtrk-mtqp-03.txt
From: Tony Hansen <[email-masked]>
To: [email-masked]
Date: Sat, 04 Aug 2001 14:07:05 -0400

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-masked] 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

Subject: Late comments on the msgtrk documents
From: Philip Hazel <[email-masked]>
To: <[email-masked]>
Date: Sat, 11 Aug 2001 20:11:08 +0100 (BST)

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-masked]      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.

---------------------------------------------------------------------