On Mon, Oct 17, 2005 at 05:09:01PM -0500, Earl Hood allegedly wrote: [ re body hashes ]
> Even though you still have to wait until after DATA, if you know the > sig will fail (and your rules dictate the message should be rejected), > you can stop any extra processing (which may include non-DKIM stuff) > on the DATA; you just send bytes to /dev/null. Isn't this optimizing the 20 part of 80/20? Already we are routinely seeing 95+% verification success with DK, so at very best you're prematurely optimizing a less than 5% problem. Even then, as I understand it, the failures that most commonly occurred with the early DKIM crew were header failures rather than body failures. So if anything, on the optimization front, one should consider a header hash rather than a body hash. > It also provides benefits in diagnostics, logging, auditing, and > dealing with multiple signatures. On the matter of diagnostics, while a binary indicator saying the cause of a failure is the header vs the content is mildly useful, I think the whole role of diagnostic mechanisms needs to much more comprehensive than this to be useful. It's one of the areas that we started focusing on heavily in DK - what additional diagnostic material can be supplied to help automate and categorize verification failures? I would hazard that comprehensive, automated diagnostics should be available before finalizing canonicalization. Mark. _______________________________________________ ietf-dkim mailing list http://dkim.org
