The hashing in the original proposal was determined (correctly, in my view) to be unnecessary complexity. The additional "atpsh" tag is included only for compatibility with the original scheme, and doesn't have to be used.
The "atps" tag itself was added because the default is to attempt, via a DNS query, to confirm a relationship whenever the "d=" doesn't match the From: domain. Where there is no such relationship claimed, unnecessary load on the DNS would be created. I don't have any plans to reopen those issues absent evidence to the contrary. Anyone who feels differently is free to give it a try. But more importantly, the third party signature extensions proposed have seen approximately zero adoption since they were published as an RFC more than a year ago, and implemented more than two years ago even before the aforementioned tagging was added. I think this whole topic is a dead end. -MSK From: Douglas Otis <[email protected]<mailto:[email protected]>> Date: Fri, 5 Apr 2013 11:54:46 -0700 To: Steve Atkins <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [dmarc-discuss] Gmail Authentication-Results header Dear Steve, There was a draft written that intended to specifically address the third-party problem as related to DMARC. This draft was subsequently modified and then published as http://tools.ietf.org/html/rfc6541<https://urldefense.proofpoint.com/v1/url?u=http://tools.ietf.org/html/rfc6541&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=aZ0xRzXh0AB20HBCmRph%2Bg%3D%3D%0A&m=3eFXdFc5SOdk7bw2PzXiups%2Fh%2F0lMVD1OBLWPsTtzPY%3D%0A&s=1e692c3f8782a813e6ce60a2f967c588078e164ebb6c8599b31f2f0b883e7dd1>. The intent of the original draft was completely lost with inclusion of "atps" and "atpsh" modifications to the DKIM signature. The intent was to offer authorization of third-party domains without authorized domains needing to modify their DKIM operation. The change that was made will never scale nor was it needed. There is no reason to offer alternative hashing schemes that only ensure consistent label sizes. Changes to the hash algorithm inhibits sharing of those domains considered safe to authorize in a way that permitted If linkedin wanted to implement ATSP, use of ATSP should be signaled in their DMARC record and NOT depend on changes made by every mailing list that happens to be using DKIM. In fact, the original draft offered authorization tags that permitted other types of source verification methods. Over time, this might include use of STARTTLS Certs, for example. Perhaps Murray would be interested in creating an alternative version of ATPS sans the additional tags, or perhaps simply allow these tags to default using DMARC information in a way that still permitted the desired authorization. In the end, the DKIM signature would still indicate who permitted any spoofing. DMARC feedback paths could be used to signal spoofing problems with their authorization which could be rapidly withdrawn. Regards, Douglas Otis On Apr 5, 2013, at 9:47 AM, Steve Atkins <[email protected]<mailto:[email protected]>> wrote: On Apr 5, 2013, at 9:25 AM, Benny Pedersen <[email protected]<mailto:[email protected]>> wrote: Al Iverson skrev den 2013-04-05 18:13: Sure, I could be totally wrong. But I might not be. the bug is that dmarc should not be used with deep scanning on dmarc, it should trust maillist server dmarc record, The mailing list server's DMARC record, if it has one, is entirely irrelevant. if it does not whats the point of dmarc then ? that sayed, its still not working with dkim, and spf forwards if google does not trust maillist servers as trusted forwarders :( i cant get dkim pass back here, but it works as designed on postfix / apache maillists, fix the real problem first The primary problem is people who add inappropriate DMARC records to domains that should not have them (due to their usage patterns being contrary to the DMARC assertion). That in itself isn't a problem for the email ecosystem at large, as it'll just lead to problems for their users. But it leads to the secondary problem of mail administrators who implement DMARC in a half-hearted manner and attempt to work around the primary problem by picking and choosing which DMARC records to pay attention to, and when, opening up a broad enough attack surface as to make p=REJECT not reliable enough to be useful, especially for smaller domains that weren't special-cased previously and aren't being correctly special-cased now. It's possible my experience with ADSP is colouring my take on this, but I did have higher hopes for DMARC. Cheers, Steve _______________________________________________ dmarc-discuss mailing list [email protected]<mailto:[email protected]> http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html) _______________________________________________ dmarc-discuss mailing list [email protected]<mailto:[email protected]> http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
_______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
