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 :