Dave Crocker wrote:
I am still not understanding how the use of MX records is
important to anything but routing.
That's the point. With source routes, bang paths, whatever,
mail was sent from the originator via the given route to the
recipient. If something didn't work somewhere on this route
the same (reverse) path was used to report the error.
MX simplified this, the originator arranged his part of the
route to his mailout, and he arranged a route from his MX
to his "Mail From" address for potential error messages. All
the recipient needed to know about this part of the route was
an MX for the "Mail From".
Same idea on the other side, the route from the MX to the
mailbox of the recipient is irrelevant for the originator.
All problems reduced to 4 points: originator - mailout - MX -
recipient. At most 6 points for mailout != MX and error
reports. And it's always obvious who is responsible, the
border is defined by the first used MX.
An alias behind the MX of a 3rd party introduces a 3rd party,
and then it's much less obvious who is responsible if something
doesn't work as expected. Maybe the originator wants to know
it if the alias-mailbox at a 3rd party is full. Maybe that's
a privacy issue. Maybe it would be much more interesting for
the forwarder to get this info and disable the alias.
The real problem are of course terabytes of spam with forged
"Mail From" addresses, and your paper apparently ignores this
issue. It also ignores RfC 2476 6.1 and 3.2.
my own assessment of community consensus is that it is the
majority view.
IMHO the majority doesn't like forged "Mail From" addresses.
They want it to be the "originator", and not some "bounces to"
free to be (ab)used for other purposes.
a goal of the architecture document is to try to resolve
exactly these sorts of issues.
Maybe it would be cleaer if you'd also mention some potential
problems and solutions, RfC 3834 chapter 4 among others.
I do not know what it means to 'indirectly allow forgeries'
One simple example, I had four mail providers and corresponding
mailboxes. With two of them I could only send mail while I was
online with the correspoding ISP. That choice depends on the
time of the day, sometimes I'm online with another ISP who does
not offer a smart host for SMTP.
Of course I'd like to use one of my favourite xyzzy addresses
always as both 2821 and 2822-From. Two of the four providers
did not accept it. One forces 2821 = 2822 = my address at this
provider. The other was an MSA implementing RfC 2476 6.1, I
could use my favourite 2822-From, but the 2821-From had to be
my address at this provider.
The other two providers don't care what I use as "Mail From",
they only check RADIUS or SMTP AUTH resp. That's bad. They
allow me to use an arbitrary "bounces to xyzzy", although they
don't know that this could in fact make sense for me (before
SPF tried to close this loophole).
These mail providers follow your "bounces to" doctrine. They
shouldn't, it's gross negligence. I could spam the whole world
claiming "bounces to dcrocker" until they get me.
I'd consider the mailbox in the Return-Path: as some kind of
default "sender".
That would be a mistake.
How do you interpret 2822-From mailbox != 2821-From mailbox
without an explicit Sender:, who sent this stuff ? The MSA
mentioned above (2476 6.1) guaranteed that the 2821-From is
the sender, but it didn't insert a Sender: header (2476 8.1).
Both 2476 6.1 and 8.1 are unfortunately only MSA options.
If there is no rfc2822.sender field, then rfc2822.from is
defined as holding the (virtual) value of sender.
Yes, that's the RfC-theory. But in practice neither my MUA nor
the MSA enforced this, and I rarely added a Sender: manually.
Both 2821- and 2822-From were my addresses (and working), that
should be good enough for a 2822-From with one mailbox address.
I'm still _not_ free to say "bounces to ICANN"
That is why the architecture document states that the
rfc2822.sender specifies the value in rfc2821.mailfrom.
A "Sender: ICANN" added to a "Mail From ICANN" does not help.
I should use an address as 2821-From corresponding to the used
MSA, not an arbitrary "bounces to" of the day (even if it's my
address elsewhere instead of ICANN).
The term "forged" does not make sense, with respect to
rfc2821.mailfrom.
That's a case of DEnglish on my side, how about "abused" ? If I
claim to send mail from ICANN or dcrocker it's mail abuse. And
if I claim to send mail from xyzzy via another mail provider it
is a lie or stupidity (and an SPF-MX would reject it, because I
do not tolerate this kind of abuse, even if it's only me being
stupid).
Mailfrom specifies a recipient address.
For error reports etc., actually it's an _originator_ address.
Where I define "originator" w.r.t the SMTP dialogue, and you
apparently want to define it w.r.t. the user. With my concept
a user with addresses user(_at_)A and user(_at_)B cannot send mail from
user(_at_)A via the MSA of B (and v.v.), with your definition that's
perfectly okay. Oops, that helps, doesn't it ? You define it
from the user's POV, I define it from the mail provider's POV.
having relaying through a second MX, in a sequence, does not
automatically invalidate the original rfc2821.mailfrom.
sometimes, yes, but not always.
I'd draw the line at the organization, of course a secondary MX
can forward mail to another MTA of the same organization incl.
another MX. But if it replaces the RCPT TO by an address with
a completely different set of MXs, then it should also handle
all errors caused by this manipualtion.
In other words it should do something with the MAIL FROM, the
original sender is not more responsible for this "redirection"
(was that one of your terms, or do I confuse it with one of
William's drafts ?)
whether relaying through second MX changes who is really
accountable -- and therefore, possibly, whether the
rfc2821.mailfrom should be changed -- depends on a number of
issues
IIRC your text does not mention "3rd party" (= "user not local"
in STD 10) as one of these issues.
you are suggesting some sort of reverse source route
specification.
That was only a 821 quote. And as long as there are only two
parties we certainly don't need it anymore. Today it's only
relevant when a 3rd party is involved.
common practise is to have the address(s) be simple and
global, rather than relative.
Yes, and if you get "mail from xyzzy", and it's not one of the
IPs in my sender policy, please reject it and don't bounce it.
If I screwed up using the wrong MSA, this MSA will inform me,
and I can fix my error.
you probably consider mail and net news as different
"message environments".
Yes. Similar, but different.
What would you do as news server, if you have to send articles
in a moderated group to the moderator's address ? I'm just
curious, it's a tricky case for RMX and Co. Would you use the
2822-From of the poster with a 2821-From of your news server,
plus a corresponding Sender: ? And if the article already had
(another) Sender:, keep it, drop it, or replace it by X-Sender
or maybe Original-Sender ? Or simply use Resent-* ?
[gateway examples]
It probably falls in the category of "gateway" rather than
"relay" because the semantics of addresses needs translation.
Yes, but your text says only "may choose to use a new address"
in its gateway chapter (6.2.4), not "must" or "probably must".
Bye, Frank
P.S.: this time your article made it from IMC to GMaNe, but my
CC to your Reply-To is delayed, therefore I drop it here.
For GMaNe users an URL for the (apparently) lost article:
<http://www.imc.org/ietf-smtp/mail-archive/msg01423.html>