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