Hector Santos wrote:
very useful document to have for reference.
IMHO it is not, its 2821.MailFrom concept is different from
STD 10 and RfC 2476:
? Ultimately the simple basis for deciding what address needs
? to be in the RFC2821.MailFrom is to determine what address
? needs to be informed about transmission-level problems (and,
? possibly, successes.
That's not true, "Mail From" is exactly what the name says,
it's no arbitrary "Bounces To". The quote is taken from the
MSA section, and in RfC 2476 6.1 "enforced submission rights"
"Mail From" is the authenticated source. RfC 2476 3.2 says:
! If an MSA is not able to determine a return path to the
! submitting user, from a valid MAIL FROM, a valid source IP
! address, or based on authenticated identity, then the MSA
! SHOULD immediately reject the message.
It's the Return-Path, as specified in STD 10, not some obscure
"Bounces-To".
? The MDA records the RFC2821.MailFrom address into an RFC2822
? header field named Return-Path.
It's not only "named" so, it really _was_ the Return-Path in
STD 10 and 11, as the name says. And it's still considered as
_the_ responsible source in say RfC 3834 or in the "mail-arch"
draft for some important cases of mediators like mailing lists
or resent mail.
The "Return-Path" quote was taken from the MTA section, IMHO it
should be moved to the MDA section. The MDA section contains
HELO, that could be removed. Or it needs an explanation, when
does an MDA say HELO ?
! The primary "routing" mechanism for Internet mail is the DNS
! MX record [RFC1035]. It is an advertisement, by a recipient
! domain, of hosts that are able to relay mail to it, within
! the portion of the Internet served by this instance of the
! DNS.
Yes, and based on this simple observation it's clear that mail
sent to _another_ (3rd party) MX is a special case, where using
the original unmodified "Mail From" is far from "natural". In
fact it's not allowed by STD 10, and it's the reason for codes
251 and 551.
? The agent responsible for gatewaying the message may choose
? to specify a new address to receive handling notices.
Generally it's not only a "may" for a gateway, but a "should".
The only case where keeping the original "Mail From" could make
sense is when original sender and recipient are in the same
"messaging environment" (aka net), e.g. moderated newsgroups.
IMHO gateway considerations should not be a part of the MUA
section. MUAs (ab)used as gateways are normally very bad news.
? The agent responsible for submission to an alias address will
? usually retain the original address to receive handling
? notifications. The benefit of retaining the original
? MailFrom value is to ensure that the origination-side agent
? knows of that there has been a delivery problem. On the
? other hand, the responsibility for the problem usually lies
? with the recipient, since the Alias mechanism is strictly
? under the recipient's control.
There's no "benefit of retaining the original MailFrom", and it
was never allowed by STD 10, the forwarding host was added to
the reverse path. That's the single point of failure in 2821,
and why we have a problem with forged "Mail From" addresses
today, plus attempts to fix it like RMX. SPF, domain keys, etc.
Bye, Frank