There are really two parts to this: (1) How to do the analysis of what failed, and (2) How to report the failure to the signing domain.
(1) Assuming it's a signature failure and not a body hash failure, analyzing z= gives the best chance of finding the cause. There are going to be a lot of failures that one can't diagnose that way, of course, but z= should help with enough of them to be worth trying. Some tools might help, like something that does an automated comparison of the z= value in a signature with the corresponding header fields and reports any discrepancy. The best thing about this is that z= is already in the spec. (2) I wouldn't give up on the reporting mechanism too quickly due to the potential for abuse. Perhaps the use of the reporting address could be constrained in such a way that abuse gets dropped more easily, since this isn't a general-purpose address that has to deal with all sorts of use cases. So perhaps the messages get dropped if they're not authenticated (maybe use SPF here to drop messages as they're received, and tell admins not to do forwarding on the reporting address). Maybe additionally rate limit by domain. I'm just brainstorming; other ideas? -Jim Michael Thomas wrote: > I'm sort of dubious about this. Unless you're using z=, your chances of > figuring out why something broke are slim to none. With z=, your chances > of figuring it out are merely slim. > > Mike, with far too much experience at that > > On 02/24/2010 02:17 AM, Suresh Ramasubramanian wrote: > >> I support this. The rest of Barry's charter proposal is OK by me. >> >> thanks >> suresh >> >> On Wed, Feb 24, 2010 at 3:27 PM, Franck Martin<[email protected]> wrote: >> >>> Shouldn't we move forward Murray's draft "quickly" that allows to report >>> back broken DKIM signature to the validating domain? >>> >>> This would allow to collect information on why signature gets broken making >>> the DKIM draft stronger. >>> >>> >> >> > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
