On Apr 5, 2013, at 12:35 PM, Murray Kucherawy <[email protected]> wrote: > 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.
Dear Murray, When we first talked, the speed of the hash function demonstrated it did not impose a burden. Importantly, hashing ensured consistent label size regardless of domains being authorized. Response size issues created due to domain sizes authorized could lead to nasty troubleshooting complexities. In addition, by having only one hashing method, the range of cacheable queries created via abuse is constrained to a single set. Use of the hash also increases the number of authorizations that can be held in DNS cache. If DMARC were to include a tag indicating use of the ATPS extension, DMARC could signal whether there might be a benefit in checking ATPS records. The inability of DMARC to work in conjunction with various forums or third-party services remains a difficult scaling problem that ironically DMARC was specifically attempting to address. Since as you said, the code has already been written which offers a method to permit this type of extension. Perhaps now would be a good time to reconsider this extension albeit with a few minor changes. Use only one hashing method and don't require changes to DKIM. Add use of ATPS signaling into DMARC instead. DMARC is where there is a problem needing to be addressed. As such, it make sense to place this signaling into the DMARC records. Placing ATPS signaling into DKIM signatures creates a significant if not impossible adoption barrier. Regards, Douglas Otis > -MSK > > From: Douglas Otis <[email protected]> > Date: Fri, 5 Apr 2013 11:54:46 -0700 > To: Steve Atkins <[email protected]> > Cc: "[email protected]" <[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. > > 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) > _______________________________________________ > 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)
