Re: WSJ/gmail/ML, was a permission to...

On May 5, 2014, at 1:19 AM, Michael Richardson <[email protected]> wrote:

> John Levine <[email protected]> wrote:
> [...]
>> Remember that there are other things that DMARC broke, that do not
>> involve forwarding.  That's what "WSJ/gmail" in the subject line are
>> about.
> 
> Yes, I understand.  I'm not sure that web sites sending on my behalf
> is ultimately distinguishable from spam without some cryptographic route
> through the browser/webserver into my MUA.
> 
> I can imagine such a channel, but I don't think we want to talk about that.
> I think that we should list the various problems that we have discovered and
> it may be that some we can fix, and some we can not.
> 
> Ultimately, in the space of end-to-end SMTP, lists are a form of
> intermediary.  DMARC is a form of BCP38...

Dear Michael,

Cryptography will help secure many things, perhaps none better than SMTP-DANE.  But can a sending domain make request without providing information necessary to avoid exposure of private exchanges by way of insecure DMARC feedback. Talk about a major security hole. 

Email is currently being accepted based on fairly weak validation schemes.  DKIM does not even indicate who sent the message nor is it expected to indicate to whom it was intended.  It seems that when there are strong methods to validate email sources, there should be a way for a DMARC strategy to make authoritative exceptions. DKIM Delegate seems to assume sending domains know which destinations can be trusted to the point of offering a weak signature.  Although it does not leverage DNS it also can not address important use cases and further weakens already weak protections that even failed to exclude invalid header field from producing PASS.  Since DMARC is expecting others to act on their behalf, it should also directly convey which non-aligned domains have been used by their domain's u
 sers.

This communication can be an authorization of validated sources.  The granularity of the authorization can be by domain.  Any further resolution of the source will depend on trusting message handling.  Authorization might include a requirement  an Original Authentication Results header be included, for example.

Regards,
Douglas Oits












_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822