[Top] [All Lists]

Re: Bounce/System Notification Address Verification

2005-06-28 21:21:51

At 08:24 -0400 on 06/28/2005, Bruce Lilly wrote about Re: Bounce/System Notification Address Verification:

On Tue June 28 2005 01:42, Robert A. Rosenberg wrote:

 At 16:34 -0400 on 06/27/2005, Keith Moore wrote about Re:
 Bounce/System Notification Address Verification:

 >Wrong.  There is no prohibition that I'm aware of against using <> for
 >other purposes, and there are some standards that specifically require
 >using <> - e.g. MDNs and responses from mail robots, neither of
 >which are constrained to exactly one recipient.

 OTOH: There is no requirement that the generator of these responses
 (when presented with a request/need to sent such a message to more
 than one recipient) create a single copy of the message as opposed to
 one personally addressed copy per recipient.

You are correct that there is no *requirement*, but sending an MDN to
multiple recipients is explicitly permitted and in fact may be specified
by the sender; RFC 3798:

   mdn-request-header = "Disposition-Notification-To" ":"
             mailbox *("," mailbox)

N.B. multiple MDN recipients may be specified.

Rejecting what is explicitly permitted is probably not a good idea unless
there is some ancillary information or some overriding consideration.

I am not rejecting anything. All I am suggesting is that when more than one recipient is to be used for the message, to generate a separate copy for each recipient (with only that recipient listed as the "To") so there are separate copies (as would occur with multi-recipient [messages where each recipient is in a different domain] at the MTA stage ).

Administratively rejecting specific permitted, useful, non-harmful
information that users have explicitly requested is probably not sound

 Creating multiple copies 
 preserves the "Only One Recipient for a 'Mail From <>' message" rule.

Where exactly is that "rule" specified?

OK - Not a Rule but only the usual occurrence with <> messages such as "can not deliver" messages. If those functions that generate multi-recipient messages with a <> from would just create a separate copy for each recipient it would make SPAM detection (of <> messages) much easier since any attempt to deliver such a multi-recipient <> message would be trappable without needing to bother asking if it was possibly a legitimate message or SPAM.

<Prev in Thread] Current Thread [Next in Thread>