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.
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]> wrote: > On Apr 5, 2013, at 9:25 AM, Benny Pedersen <[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] > 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)
