Sounds like there are 3 things to discuss: 1. How to use existing stuff, per Murray's description.
2. What additional set of information should be obtained 3. How a signer can signal the need for #2. The reason for separating 2 and 3 is that having 2 can allow uncoordinated logging, with post hoc reconciliation, if both sides happen to be doing logging. Whereas 3 is the new header fied and is a protocol enhancement -- albeit a small one -- that requires changes to the protocol engines on both sides. A good idea, but also nice to keep out of the critical path, if possible. Just being able to get everyone's loggers to record the right set of information is likely to allow useful diagnostics more quickly. Or perhaps I'm missing how to do this more easily? From Mark's note, I can't quite figure out enough of the diagnostic data specification to do the ABNF for it... All of this should be written into an I-D draft. Probably does not need to go to publication, but it would be good to make sure everyone is on the same page (so to speak) about the details. d/ On 2/24/2010 10:06 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: [email protected] [mailto:ietf-dkim- >> [email protected]] On Behalf Of Michael Thomas >> Sent: Wednesday, February 24, 2010 9:47 AM >> To: Mark Delany >> Cc: IETF DKIM WG >> Subject: Re: [ietf-dkim] Broken signature analysis >> >> But I guess this all rather begs the question about what people intend >> to >> do with those breakage stats and/or analysis. > > I've been using several approaches to solve these problems. > > Basically I have two debugging modes. In the first mode I enable "z=" tags > on signing (or ask the sender to do so) and then wait for a failure; if the > "bh" matches then "z=" will contain enough information to identify the > problem, otherwise you have to move to the second mode. OpenDKIM can be > compiled to make some attempt to figure out what changed in this case by > using the library equivalent of "agrep" (approximate grep) to try to find > similar header fields in the "z=" block and what the receiver actually got. > > In the second mode, I enable debugging flags on both ends of the connection > that save the canonicalized header and body, and then collect and "diff" to > see what changed (or spot canonicalization errors). This can be automated, > but the data collection part is tough because it requires co-operation of > both ends. The "r=" (reporting address) tag that the WG chose not to pursue > has been extremely useful here. > > And in terms of general deployment statistics and observations about overall > success, OpenDKIM has a statistics mode that we will be encouraging people to > enable and report back to us periodically, and we will relay data from > willing participants to the working group once the WG gets to that point. > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
