I understand that you, me and Mark have a vested interest in DKIM qua DKIM, but I think we're outliers. What's unclear to me is what mailops and/or ARF-consuming boxen intend to do with this data.
Mike, and you passed on BARF as the name of the WG? Shame! On 02/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
