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

Eric Allman <[email protected]> Mon, 18 Jun 2001 20:18:36 -0700
Newsgroups gmane.ietf.msgtrk
Message-ID <[email protected]>
Chris, sorry for the long delay in replying -- I set this aside for
a while, and am just getting back to it.

The problem with using "expanded" for all cases where there are
multiple recipients is that the MTA doesn't necessarily know.  For
example, if the MTA can deliver to a program on behalf of a user,
that program might explode a mailing list.  I believe you see this
in Postfix, and for that matter some message stores (including, I
believe, Exchange) have the property that the MTA delivers to a
real mailbox which is then scanned later by a background process
that does the exploding.

I think this is the same reason that the wording in 1894 is
fairly ambiguous.

eric



============= In Reply To: ===========================================
: From:  Chris Newman <[email protected]>
: Subject:  Re: I-D ACTION:draft-ietf-msgtrk-trkstat-01.txt
: Date:  Thu, 05 Apr 2001 17:57:14 -0700

: --On Thursday, April 5, 2001 17:21 -0700 Eric Allman 
: <[email protected]> wrote:
: > 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?
: 
: 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.
: 
: > Already dealt with, as indicated in my previous message.  Do you still
: > 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
: