Re: (DMARC) We've been here before, was Why mailing lists

[Douglas Otis <[e-mail]>]

On Apr 17, 2014, at 11:18 AM, Martin Rex <[e-mail]> 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