Frank,
Thanks for taking the time to pursue such diligent reading and commenting. The
concerns you raise involve issues that were at the core of my motivation for
producing this paper: The community has demonstrated a distinct lack of
cohesion about these points, and we need to fix that.
Even more interesting is that some of the citations you use have not been part
of previous discussions on these topics, so it is good to explore their impact.
? 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
It IS pretty impressive that it took us 20 years to discover that the labeling
of RFC2821.mailfrom was wrong and even its formal definition is ambiguous. In
effect, it refers both to source identity AND to notifications use.
This specific issue has gotten very wide and deep discussion over the last year
or so, in quite a few venues. The language in the architecture draft
represents both my own view and the view that I believe represents a pretty
strong community ROUGH consensus.
Permitting the MailFrom address to be entirely different than RFC2822.From or
RFC2822.Sender also reflects real-world use of the field. It is essential that
notifications be able to go to addresses that have no observable relationship
with From or Sender.
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.
First of all, let's note that the text you are quoting here is in a section of
RFC2821 that is not defining the MailFrom command nor any of its semantics.
Second note that MailFrom is referenced in a LIST of choices. And these
choices pertain to an implication of what IS being specified. Hence, the
paragraph was neither intended nor succeeds at being a normative reference for
RFC2821.MailFrom. The text certainly does say that MailFrom COULD contain a
source identification string, but not that it MUST or even that it SHOULD.
It's the Return-Path, as specified in STD 10, not some obscure
"Bounces-To".
Well, the RFC821 definition of Mail From is:
It gives the reverse-path which can be used to report errors.
Std 10 is RFC821. Note that it is explicitly obsoleted by RFC2821. (The STD
reference is, therefore, out of sync. But that's OK, since the historical
reference is useful.)
We can quibble about the rfc821 reference to reverse-path, but the language
that says what to actually DO with this string is clear and straightforward:
it is a notifications address.
So, even ignoring all normative documents since RFC821, we can see that the
intention of this field matches exactly what the architecture document says it
is for.
? 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.
'still considered as the_ responsible source in... the "mail-arch" draft'?
I do not understand this reference. Please clarify.
As for RFC 3834, it's statement:
The primary purpose of the MAIL FROM address is to serve as the
destination for delivery status messages and other automatic
responses.
seems to me to be in 100% agreement with the language of the architecture
draft. So I do not understand why you think it supports a view that MailFrom
is about authoriship our assertion of source.
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 ?
Good catch. Thanks. Both the MTA and the MDA sections have significant errors
in listing identities that they use. I've moved things around, to fix that.
! 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".
Unfortunately I am not understanding what you mean here. Please say it again,
differently.
At a minimum, I have no idea what relationship and constraints, between MX
usage and MailFrom usage, you are trying to draw.
In
fact it's not allowed by STD 10, and it's the reason for codes
251 and 551.
I am not understanding what it is that you believe is not allowed.
? 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.
Actually, this depends upon how seamlessly the gateway can emulate being a
relay. The goal of a gateway is to provide perfect emulation, to the two email
services it is interconnecting. To each of them, it seeks to appear as an
ideal relay. However gatewaying is needed when there are significant
differences between the service; such differences pretty much always affect
visible mail service semantics. So perfect emulation is not possible. In any
event when the two different email service have reasonably close semantics,
then even the notifications/bounce mechanism can be emulated.
As for the case you cite, if the two sides are in the same messaging
environment, then they do not need a gateway.
IMHO gateway considerations should not be a part of the MUA
section. MUAs (ab)used as gateways are normally very bad news.
The nature of a gateway is that it alters the message. It is not merely part
of the underlying transfer service. Recognizing that gateways operate at the
MUA level (as well as, yes, the MHS level) is an explicit goal for the
architecture document.
? The agent responsible for submission to an alias address will
? often 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
Please cite the text that says that this action is "never allowed".
Anyhow, I am changing "usually" to "often", in order to give more weight to the
"On the other hand" sentence and to avoid the implication that the architecture
document is recommending one over the other, since I do not have a sense of
community consensus on this.
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.
Real forgery problems are due to a lack of authentication techniques, not
debates about actual semantics.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net