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

From: Eric Allman <[email-masked]>
Date: Thu, 05 Apr 2001 17:21:22 -0700

: From:  Chris Newman <[email-masked]>
: 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

---

From: Chris Newman <[email-masked]>
Date: Thu, 05 Apr 2001 17:57:14 -0700

> keep things fairly parallel to that spec.  I'm open to suggestions.

My suggestion is to use "expanded" for _all_ cases where there are multiple 
recipients.  If a user sends to a list and gets a "delivered" notification, 
their assumption will be that the message has been delivered to all list 
recipients.  So any use of "delivered" with a multiple recipients is likely 
to result in a "user astonishment" scenario.  Since those are bad, stick to 
"expanded".

The only caveat would be if a site has a local alias sent to multiple 
recipients, and wishes to conceal the fact the address is a list.  Then 
"delivered" would be OK.

> think a cross-reference is warranted?

A non-normative cross-reference would be nice.  When I'm considering only 
the security implications of a protocol, I look only at the security 
considerations and anything it references.  But the text you added is good 
enough.

		- Chris