Late comments on the msgtrk documents

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.

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