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