Re: I-D ACTION:draft-ietf-msgtrk-trkstat-01.txt
Eric Allman <[email protected]> Thu, 05 Apr 2001 17:21:22 -0700
| Newsgroups | gmane.ietf.msgtrk |
|---|---|
| Message-ID | <[email protected]> |
: From: Chris Newman <[email protected]> : Date: Wed, 28 Mar 2001 17:08:27 -0800 : Message tracking is intended for use as a "last resort" mecha- : nism. Normally, Delivery Status Notifications (DSNs) [RFC-DSN- : SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN] would : provide the primary delivery status. Only if no response from : either of these mechanisms would Message Tracking be used. : : The last sentence needs a verb. Fixed. : A Message Tracking Status Notification (MTSN) is intended to : be returned as the body of a Message Tracking request [DRAFT-MTRK- : MTQP]. The actual body MUST be a multipart/related [RFC-RELATED] : with type of "tracking-status"; each subpart MUST be type "mes- : sage/tracking-status" as described herein. : : The multipart/related type parameter takes a media type, so: : : ... The actual body MUST be a multipart/related [RFC-RELATED] : with type parameter of message/tracking-status. Fixed. : ... That body consists of one or more "fields" for- : matted to according to the ABNF of RFC 822 headers "fields" (see : [RFC-MSGFMT]). : : headers -> header Fixed. : The body of a message/tracking-status is modeled after : [RFC-DSN-STAT]. That body consists of one or more "fields" for- : matted to according to the ABNF of RFC 822 headers "fields" (see : [RFC-MSGFMT]). The per-message fields appear first, followed by : a blank line. Following the per-message fields are one or more : groups of per-recipient fields. Each group of per-recipient : fields is preceded by a blank line. Formally, the syntax of the : message/tracking-status content is as follows: : : I'd be inclined to add something like: : : Note that there will be a blank line between the final per-recipient field : and the MIME boundary, since one CRLF is necessary to terminate the field, : and a second is necessary to introduce the MIME boundary. Agreed. : delivered The message has been successfully delivered to : the final recipient. This includes "delivery" : to a mailing list exploder. It does not indi- : cate that the message has been read. No further : information is available; in particular, the : tracking agent SHOULD NOT attempt further "down- : stream" tracking requests. : : expanded The message has been successfully delivered to : the recipient address as specified by the : sender, and forwarded by the Reporting-MTA : beyond that destination to multiple additional : recipient addresses. However, these additional : addresses are not trackable, and the tracking : agent SHOULD NOT attempt further "downstream" : tracking requests. : ... : The tracking algorithms MUST NOT allow tracking through : list expansions. When a message is delivered to a list, a : tracking request MUST respond with an "expanded" tracking status : and MUST NOT display the contents of the list. : : I'm unclear under what conditions to use "delivered" or "expanded" for : mailing lists or aliases. Please fix. This wording was taken nearly as is from 1894, and the intent was to keep things fairly parallel to that spec. I'm open to suggestions. Anyone? : ---- : 3.5. Interaction Between MTAs and LDAs : : A message that has been delivered to an LDA that under- : stands message tracking (in particular, an LDA ... : : You need to associate "LDA" with the expansion of the acronym in section : 3.3.5. Either expand it once here as well, or use the acronym in 3.3.5. I'm expanding it in 3.5. : A note on my security consideration suggestion for the SMTPEXT document, a : reference to the security considerations section in this document would : suffice. Already dealt with, as indicated in my previous message. Do you still think a cross-reference is warranted? : - Chris Thanks for the comments. eric