Subject: I-D ACTION:draft-ietf-msgtrk-trkstat-01.txt

From: [email-masked]
Date: Mon, 26 Mar 2001 18:37:38 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Message Tracking Protocol Working Group of the IETF.

	Title		: The Message/Tracking-Status MIME Extension
	Author(s)	: E. Allman
	Filename	: draft-ietf-msgtrk-trkstat-01.txt
	Pages		: 8
	Date		: 23-Mar-01
	
Message  Tracking is expected to be used to determine the sta-
tus of undelivered e-mail upon request.  Tracking is used  in  con-
junction with Delivery Status Notifications [RFC-DSN-SMTP] and Mes-
sage Disposition  Notifications  [RFC-MDN];  generally,  a  message
tracking request will be issued only when a DSN or MDN has not been
received within a reasonable timeout period.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-msgtrk-trkstat-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-msgtrk-trkstat-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-msgtrk-trkstat-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Chris Newman <[email-masked]>
Date: Wed, 28 Mar 2001 17:08:27 -0800

--On Monday, March 26, 2001 18:37 -0500 [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Message Tracking Protocol
> Working Group of the IETF.
>

        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.

        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.

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

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

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

A note on my security consideration suggestion for the SMTPEXT document, a 
reference to the security considerations section in this document would 
suffice.

		- Chris

---

From: Steve Hole <[email-masked]>
Date: Thu, 29 Mar 2001 11:51:28 -0700

> mailing lists or aliases.  Please fix.

Once again, we refer back to the detailed definitions for each of these 
occurrences in the DSN spec.   Delivery to a mailing list gets the 
"expanded" response.   Delivery to a single alias "relays" normally with a
change in the final recipient.   Delivery to multiple-recipient aliases 
are handled in one of three ways, implementation defined.

I don't believe that we want to screw down the multiple-recipient aliases 
choices any tighter, but we could consider it.

I would be inclined to directly reference section 6.2.7, with specific 
changes for any additional or modified status codes used because we are 
referencing along the chain of delivery.   I don't think that there are 
any.

Cheers.
---
Steve Hole
Chief Technology Officer
ACI - MessagingDirect
<mailto:[email-masked]>
Phone: 780-424-4922