On Feb 24, 2010, at 5:51 AM, Michael Thomas wrote:
I'm sort of dubious about this. Unless you're using z=, your chances
of
figuring out why something broke are slim to none. With z=, your
chances
of figuring it out are merely slim.
Mike, with far too much experience at that
It got a luke-warm response a few years back, but now that a lot more
people are having to deal with "why did the verify failed", is it
worth re-vivifying the DKIM-Trace stuff, or whatever it was called
back then? We found it very useful for our early days of interop
testing.
The idea is pretty simple: The signer adds a header that characterizes
the content before and after canonicalization. The verifier performs
the same characterization and compares the differences. The
characterizations we used at the time were simple character counts
represented in a relatively compressed form (27 a's, 60 b's, 40LFs,
50spaces, etc)
The form we used is kinda ugly as
http://www.ietf.org/mail-archive/web/ietf/current/msg39488.html
shows, but it was very illuminating as things like mis-match of
white-space counts, or case-conversions, etc, identified what changed
and where it changed (canonicalization vs transit).
Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html