Alessandro,There is still a status quo between the two different camps; one that believes in a policy framework and one that doesn't. It really has nothing to do with technical issues because they all has been already worked out. But rather an unwillingness to even acknowledge policy existence.
That approach has not worked and it was predictable because it was always a fallacy to believe that strict policies were limited to certain use cases and certain domains. It provided a flawed rationale and basis to allow DKIM resigning by ignoring policy with the acceptability of a limited damage.
The DKIM RFC6376 preferred method of looking up the signer domain has simply failed to materialize in the market place. And even if it did, it would still not address the filtering of the obvious protocol expected faults resulting from legacy mail operations and adapting spoofers. In other words, via policy, if you raise the "expectation bar":
Does this domain send any mail? Does this domain always sign its own mail? Does it allow others to sign freely? Does it allow authorized resigners?The first two could be ignorant spammers who don't have a clue about new 5321/5322 methods. Its getting by with a legacy SMTP mode of operation. The last two helps to deal with those spammers that may adapt and try to "fake" out the receivers with unchecked DKIM signatures.
These and other similar questions are real DKIM situations the signer domain trust model can not answer. You can only get this info from the author. Even if the signer domain was used, it would need to still reflect the author domains intent and authorization for resigning.
None is this is new. Many documents were produced. But we didn't have the full IETF DKIM project leaders support and endorsement to finish up ADSP. Levine refused to fix/update ADSP despite all the interest to do so. It was an unfortunate mistake for the DKIM WG chairs and Ads to allow this lack of ADSP engineering leadership situation to occur. The chairs and ADs were clearly aware there was a concern and also the threat of appeal.
Anyway, the available solution is still very simple. Given all the work already explored, DMARC needs an ATPS extension. ATPS piggy back off the ADSP record. We can just update ATPS to piggy back of the DMARC record. I already started this using my idsg.net DMARC record:
_dmarc TXT ("v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-rua@xxxxxxxx;"; )
The atps=y tag tells the compliant DMARC+ATPS receiver to do an
authorized third party signature check against the DKIM-Signature "d="
signer domain. I have an _atps record for ietf.org:
pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ( "v=atps01; d=ietf.org;" )So in theory, when ietf.org breaks and resigns my isdg.net list submissions, any download DMARC+ATPS receivers can see that isdg.net authorizes ietf.org to resign list mail from isdg.net. I already began to modify our WCADSP Wizard web site for DMARC:
http://winserver.com/public/wcdmarc
It is pretty much done with the backend scripts updated to create
DMARC records. I am just playing/cleaning the FORM UI, single sourcing
it for mobile/tablet UI.
Of course, it all means nothing without further support for ATPS. It provides an OUT for YAHOO and AOL to get a resigner whitelist using ATPS records. If they can support this simple extension to DMARC, then we would be headed in the right direction for all parties. Even if the certain LIST operators continues to refuse to support policy, at the very least, the download receivers would be able to handle it better by checking for the list signer domain authorization.
Without the support, you can see the attached dmarc-gmail-warning.png image where the GMAIL mail reader (via my iPAD) shows a warning for the unauthorized 3rd party signature DMARC failure. A simple ATPS TXT lookup for:
base32(sha1("ietf.org"))._atps.isdg.net
would of addressed this problem.
---
HLS
On 5/16/2014 9:48 AM, Alessandro Vesely wrote:
On Thu 15/May/2014 17:13:05 +0200 Dave Crocker wrote:
2. There is nothing that requires mailing lists to make adjustment. Arguably, it is better for mailing lists NOT to make adjustments, so that those affected users can consider the efficacy of their current account.I'm disappointed. I know p=reject, like dkim=discardable before it, was meant to be used by domains that "don't have individual human users". I cannot help comparing it to SPF's -all. In fact, DMARC's overview[1] suggests that the monitoring step be followed by policy adjustment. Looking at DMARC reports, one can guess whether an authentication failure originates from abuse or from a possibly forwarded mailing list post. Setting a strict policy would kill both. OTOH DMARC is perfectly useless with p=none. What does it take to set up a "human" domain, then? It's way harder than a web site. Several organizations give up working out their own way to configuring a mail server. Google do an excellent job at filtering. Besides marking as spam and email authentication, they deploy literally hundreds of signals, whose relative importance is dynamic and determined on complex algorithms[2], which are definitely beyond the reach of an average company with a smallish IT dept. Now, being forced to outsource email has obvious privacy issues. I want to ask whether the onset of giant, all-monitoring, central email plants is part of "the basic design assumptions of Internet email". If not, we ought to consider putting the restoring of a well-defined, simple email functionality among the Internet 2020 goals. Can DMARC generalization be regarded as a spontaneous move in that direction? It requires adjustments in mailing lists and other niches such as WSJ send-an-article and gmail sending. But what are the alternatives? Ale [1] How Senders Deploy DMARC in 5-Easy Steps, bottom section in http://www.dmarc.org/overview.html [2] summary of a talk with Sri Somanchi on Gmail's Anti-Spam Team http://www.campaignmonitor.com/blog/post/4196/gmail-focus-on-engagement
Attachment:
dmarc-gmail-warning.png
Description: PNG image
