On May 5, 2014, at 1:19 AM, Michael Richardson
<mcr+ietf(_at_)sandelman(_dot_)ca> wrote:
John Levine <johnl(_at_)taugh(_dot_)com> 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 users.
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
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822