On Thu January 27 2005 17:03, Frank Ellermann wrote:
Permitting the MailFrom address to be entirely different than
RFC2822.From or RFC2822.Sender also reflects real-world use
Yes, but that's no problem, only Sender-ID fans hate this idea. As long
as there is no Sender: I'd consider the mailbox in the Return-Path: as
some kind of default "sender". If a Sender: mailbox is specified, and
it's different from both 2821- and 2822-From I'd be confused, but still
no problem, maybe a mailing list / BATV / SRS / ... caused this effect.
The From header field specifies the message author(s) in a mailbox-list.
The Sender header field mailbox specifies the person who placed the
message into the transport process. The argument to the SMTP MAIL FROM
command is a return mailbox for transport problem notification. The
three are supposed to serve distinct purposes. Trouble arises when
those purposes are muddled by poor design or implementation. For example:
Automated delivery failure (delay, etc.) notifications are supposed
to go to the return mailbox. That mailbox needs to be set appropriately
by list expanders so that delivery failure notices go to the list
maintainer (who may be able to actually do something useful with a failure
notice) rather than to individual contributors. Many mailing list
contributors have been annoyed by poorly-designed MDAs that send
vacation-like messages to the mailbox(es) in the From field rather
than to the return mailbox, when such poorly-designed MDAs are used
by clueless persons who have failed to make exclusions for mailing list
messages.
Some list expanders inappropriately alter the message header Sender field,
which is clearly an originator field, not a transport trace field.
The 2821-From is the responsible address in case of trouble, the Sender:
address is never used in error reports or any other kind of reply.
The mailbox specified in the Sender field may be useful to recipients
for responses in some circumstances, just as may be the case for any
of the address fields, and as discussed in detail on the ietf-822 list
a few months ago (but of course that list apparently isn't concerned
with mail architecture :-/).