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).
I am still not understanding how the use of MX records is important to anything
but routing.
> 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.
whereas my own assessment of community consensus is that it is the majority
view.
but, then, a goal of the architecture document is to try to resolve exactly
these sorts of issues.
Or at least it's not
more popular, because it indirectly allows forgeries.
I do not know what it means to 'indirectly allow forgeries' or what forgeries
you think rfc2821.mailfrom relates to.
> 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".
That would be a mistake.
If there is no rfc2822.sender field, then rfc2822.from is defined as holding
the (virtual) value of sender.
If a Sender: mailbox is spec> > 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...
If I'd think that ICANN should solve my mail problems, then 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.
> 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>.
The term "forged" does not make sense, with respect to rfc2821.mailfrom.
It is like saying that my use of a recipient address, in To or CC is "forged".
Mailfrom specifies a recipient address.
My use of a particular mailfrom address might not be *authorized* but that is
different from saying it is "forged", since "forged" pertains to claims of (my
own) identity.
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.
having relaying through a second MX, in a sequence, does not automatically
invalidate the original rfc2821.mailfrom. sometimes, yes, but not always.
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, as I said in any earlier message.
>> 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.
you are suggesting some sort of reverse source route specification. common
practise is to have the address(s) be simple and global, rather than relative.
> 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".
Yes.
Similar, but different.
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
....
If I understand you correctly, you are describing environments that use all the
same standard email technology and conventions, but differ is some aspects of
the domain name addressing.
This is, of course, more than simple relaying, but not by much. It probably
falls in the category of "gateway" rather than "relay" because the semantics of
addresses needs translation.
> 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",
Yes. That is exactly the point. User-level is above Transfer-level. Hence
the different diagrams in the architecture document.
and that has nothing to do with (ab)using ordinary MUAs as gateways.
right.
> 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,
The semantics of the two are entirely different.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net