You'v already answered your own question. The client/end-user mail reader
is adding "Sender:" header to the email, that is not a proper behavior,
the sender should be added by sending MUA or MTA. Your example does not
really illustrate that behavior of Outlook since "Sender:" header is
already part of the message having been added by ietf maillist remailer.
Two points there: first, MUAs can add Sender: headers - there's nothing in
the standard to stop them doing so, and as the intention of this header is
to reflect the case where envelope MAIL FROM does not match content From: it
is preferable for an MUA to add such a header where appropriate; second,
when I said that Outlook might add Sender: when appropriate I was reporting
something I've been told, not something I've observed (I suppose I should
have made that clear) and although I would prefer it to add Sender: where
appropriate it may be that it actually has your prefered behaviour (not add
Sender: even when appropriate).
In addition your example illustrates yet again what I said since less
sophisticated users (read 99% of users) who use outlook only see one
"From:" and one "To:" headers which are part of the header/body of the
email but you do not see the "MAIL FROM" and "RCPT TO" email used during
transmission and these are really the ones used for actual delivery.
The question for RMX (or the Vixie proposal, which is equivalent so far as I
can see) is not what an end-user sees (whether that's an unsophisticated
user or a sophisticated one) but what the MTA carrying out the check sees.
It sees the envelope MAIL-FROM which is the only thing it can check (an MTA
can't examine the content, it may be encrypted with a key the MTA doesn't
have, it may not conform to any standard the MTA knows about, and so on. It
can prefix the content with a Received From: header, since that doesn't
require understanding the existing content, but it can't reliably do
anything else to the content and in principle it shouldn't try.
<snip>
This leaves MAIL FROM to be used for RMX validation and
this is what all current RMX-like drafts propose. But as you quite well
illustrated the MAIL FROM is not even seen by end-users and it means
spammer can use one domain for MAIL-FROM (which would random domain
without any RMX record) and use another domain for "From:" and most users
will still consider email as having come from the listed "From:" address.
And as for the "Sender:" header, spammers quite often set that as well.
However, it doesn't mater whether MAIL-FROM is seen by end users. All these
RMX and RMX-like proposals offer is assurance that the MAIL-FROM: header was
not invalid for the MTA from which the mail was received, and so far as I
know they have never purported to do any more than that. They provide a
hop-by-hop check, in effect, not a source to destination check.
However this is a defect of the RMX approach, and verification of the
original source would be much more useful. I have stated my preference for
a cryptographic often enough. A new DNS record specifying a key would be
much nicer, and there's no need for certificates or TTPs. It doesn't
require any more change to existing standards than Vixie's proposal does,
provided that one doesn't expect it to carry across list expanders or other
functions that change the envelope MAIL_FROM without some intelligent
processing by the expander, since conformant transmitters could carry the
signature as part of the helo/oleh.
Tom
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg