On Apr 17, 2014, at 11:18 AM, Martin Rex <mrex(_at_)sap(_dot_)com> wrote:
MUAs which are not implementing the rfc822/2822/5322 "on behalf of"
semantics of a message that carries both From: and Sender: header
fields ought to be FIXED. Standards that build on rfc822/2822/5322
and do not respect "on behalf of" semantics of messages with
both "Sender:" and "From:" also need to be FIXED.
Dear Martin,
Merging Sender and From header fields by MUAs offers no protection when actual
sources of messages remain unknown. ESPs would rather see various
authorization schemes than actually offering a means to authenticate their
domain responsible for introducing the message. When there is phishing or
spoofing detected, those introducing messages into the public mail stream must
respond by removing access, but they would rather push the problem onto their
recipients.
John Klensin has already indicated TLS has a problem at authenticating sending
MTAs, the clients. We now have
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane. The next step should
be to permit DANE verification of the sending MTA and allow SMTP to become
fully federated.
In the meantime, there is a way for From header field domains to publish a list
of third-party services employed by their users. This can be done in the form
of hash labels that can even be secured using DNSSEC. This information could
then be used to permit meaningful policy exceptions where each provider is
expected to act responsibly.
The actions of a few ESPs should not result in such meaningless reaction.
Regards,
Douglas Otis