Dave Crocker wrote:
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.
The case that an alias can be an address behind another MX is rather
obscure, maybe it simply didn't work with old sendmails (I'm guessing).
The language in the architecture draft represents both my own view and
the view that I believe represents a pretty strong community ROUGH
consensus.
The "bounces to" concept is IMHO a minority view. Or at least it's not
more popular, because it indirectly allows forgeries.
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 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.
It is essential that notifications be able to go to addresses that
have no observable relationship with From or Sender.
No problem with that from my POV (obviously I'm no Sender-ID fan).
RfC 2476 3.2 says:
[...]
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.
Yes, I used RfC 2476 because I found your "bounces to" in a chapter
about MSAs (the 2476bis "last call" just started, but there are no
changes in 3.2 or 6.1).
The text certainly does say that MailFrom COULD contain a source
identification string, but not that it MUST or even that it SHOULD.
STD 10 is somewhat clearer than the remark in 2476:
| The first host in the <reverse-path> should be the host sending
| this command.
[...together with section 3.2 about 251 and 551...]
The succesful attempt to kill source routes crippled the original
idea of "reverse path", and now the spammers abuse this loophole.
It used to be a feature for forwarders, but today the majority of
mail is spam, something the author of RfC 1123 didn't foresee 16
years ago (so it's not his fault, OTOH it's also not my fault ;-)
Note that it is explicitly obsoleted by RFC2821.
That's one of the IETF mysteries I still don't understand. In the
case of "bounces to" vs. "reverse path" it's probably irrelevant,
nobody wants to reintroduce "source routes" (but it was discussed
on the SPF mailing list, with the result that SRS is less trouble).
the historical reference is useful.
The 1123 (STD 3) reference 5.3.6 (a) and (b) was also interesting,
but it didn't help with "bounces to" vs. "reverse path". 2821 says
"originator":
| Such a transaction consists of a series of commands to specify the
| originator and destination of the mail and transmission of the
| message content (including any headers or other structure) itself.
Whatever an "originator" is, it's not an arbitrary "bounces to".
the language that says what to actually DO with this string is
clear and straightforward: it is a notifications address.
Sure, but as "originator" I can't specify whatever I like, it's an
address for error reports. Some error between the origin and the
recipient as specified in (one of) the original RCPT TO. Even if
I'd prefer to get my error messages somewhere else, the problem is
not between "somewhere else" and RCPT TO, it's between MAIL FROM
and RCPT TO.
If I'd think that ICANN should solve my mail problems, then I'm
still _not_ free to say "bounces to ICANN". That's a feature,
you can't replace the "originator" by an arbitrary "bounces to".
we can see that the intention of this field matches exactly what
the architecture document says it is for.
No, I don't see it, it makes no sense for me. In very strange
cases it might be interesting that I send RCPT TO:<you> with a
forged MAIL FROM:<user(_at_)dcrocker>. maybe because we try to find an
obscure bug with your new address. But normally that's not okay,
if the "originator" was me then it wasn't a user(_at_)dcrocker(_dot_)
'still considered as the_ responsible source in... the "mail-arch"
draft'? I do not understand this reference. Please clarify.
For the cases "mailing list" (6.2.6) and "resent-*" (6.2.2) you
have the normal (my POV) "mediating source" as 2821-From. That's
5.3.6 (b) "redistribution" in RfC 1123.
[RfC 3834]
seems to me to be in 100% agreement with the language of the
architecture draft.
Yes, IIRC RfC 3834 doesn't explicitly say that "Mail From" must be
the "originator". It's IMHO an implicit assumption, chapter 4 in
3834 enumerates all other possibilities as bad ideas, because they
are not necessarily the "originator". Actually RfC 3834 is lost
if even the "Mail From" is some arbitrary "bounces to" or forged.
An autoresponder can't detect this situation, so that would be a
hopeless case (ignoring some SPF- or BATV-tricks).
[MX-quote found at the end of 6 just before 6.1]
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.
RfC 1123 explains why source routes were not more "state of the art"
(1989), because MX was a much better idea. The quoted part of your
text is also about MX. And all is fine as long as there is only
one MX between sender and recipient. But if the recipient forwards
his mail to _another_ MX keeping the original MAIL FROM it breaks,
in that case the MAIL FROM is not more the responsible party.
It's a special case, because normally it makes no sense to send mail
via MX 1 to MX 2 (in another organization), after the 1st 251 or 551
the sender could update his address book and use the new address.
251 and 551 were (IMHO) meant as temporary workarounds, not as a
permanent forwarding solution. Of course the recipient is free to
do whatever he wants with his mail, but if that includes forwarding
to another MX he should make sure that it's not normal to keep the
old "Mail From" instead of using his own "Mail From".
Any problem between MX 1 and MX 2 is something where the original
sender can't help, and he's not necessarily interested in any error
messages caused by this kind of "forwarding to 3rd parties". The
same situation as for mailing lists or other "redistributions" (you
use the term "mediating source").
it's not allowed by STD 10
[...]
I am not understanding what it is that you believe is not allowed.
The "mediating source" would at least add his FQDN to the "reverse
path", and so the "Mail From" would be always different from the
original "Mail From", and indicate the last responsible party. Any
bounce from MX 2 would go via MX 1 to the sender. That was a reason
for MX 1 to avoid these bounces (in a STD 10 world). Later without
real reverse paths the responsibility of MX 1 was much smaller.
if the two sides are in the same messaging environment, then they
do not need a gateway.
Then you probably consider mail and net news as different "message
environments". If I had my own LAN with SMTP, 127.* IPs, and funny
TLDs, then my gateway to the Internet better replaces funny addresses
(incl. Mail From) by something with a meaning in the Internet. If I
decide that ICANN isn't good enough and use some alternate DNS (in
addition to ICANN's DNS) my MTAs should make sure that they don't
use alternate addresses while talking to Internet MTAs. Gateways
_must_ use addresses understood on the relevant side of the gateway,
normally there's no "may choose to use a new address".
Recognizing that gateways operate at the MUA level
[...]
is an explicit goal for the architecture document.
Okay, apparently you define "MUA level" as "something above SMTP",
and that has nothing to do with (ab)using ordinary MUAs as gateways.
In that sense you'd probably say that a "Web proxy" operates at the
"browser level". I've no better idea without inventing a new term
like "mail application" (and that's ugly).
Real forgery problems are due to a lack of authentication
techniques, not debates about actual semantics.
I'm not sure, this semantical difference explains why SPF is no
part of CSV or vice versa, and when I heard about SPF the first
time I actually thought that somebody has implemented RMX. With
your "bounces to" concept RMX would be unthinkable or at least
an obscure idea. And with a literal "Mail From" concept RMX is
the most natural fix of SMTP after it lost its reverse paths.
P.S.: For unknown reasons your mail didn't make it from IMC to
GMaNe yet, therefore I've added a CC: