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: 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
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html