-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] 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