On Feb 24, 2010, at 8:54 AM, Mark Delany wrote:
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
figuring out why something broke are slim to none. With z=, your
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
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,
The form we used is kinda ugly as
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).
Neat. A nice way of fingerprinting.
I'm guessing that the verifier typically won't particularly care why it failed,
certainly not to the extent they'll want to expend much effort to characterize
The signer will already have (or be able to regenerate) a byte accurate
copy of what was sent, if they care to diagnose things. If the verifier
simply returns a copy of what they received back to the signer, is
that adequate for any forensics needed, or does more metadata need
to be sent along with the message?
NOTE WELL: This list operates according to