> -----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
