At 09:47 24-02-10, Michael Thomas wrote:
>The thing that I'm skeptical about is that an automaton can be programmed
>to do this sort of analysis with any sort of accuracy. We're talking about
>a potential flood of reports coming in, I assume, so I doubt we're all going
>to be putting out job reqs for "DKIM Signature Breakage Analysis Engineer".
>There were far too many breakages even with tools and hunches that were very
>difficult to figure out, and even then there were lots of mysteries.

I guess that it is all about determining whether the number of 
reports points to a significant problem.  Murray mentioned the z= tag 
( http://mipassoc.org/pipermail/ietf-dkim/2010q1/012988.html ).  It's 
useful to catch obvious causes of DKIM verification failures.  I 
agree that there is too much breakage for automated analysis.

>But I guess this all rather begs the question about what people intend to
>do with those breakage stats and/or analysis.

Personally, it is useful to fix bugs and improve the implementation.

At 08:54 24-02-10, Mark Delany wrote:
>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.

I recall seeing the header for DomainKeys.

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

Do you have any documentation for that?  As a non-WG comment, I doubt 
that the before and after capture would catch the useful cases due to 
rewrites and other changes done in some environments.

Regards,
-sm 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Reply via email to