On October 14, 2005 at 08:25, Jim Fenton wrote: > Very early in the design process for IIM we considered something like > this (I think well before we published the IIM -00 draft). The idea was > that we could make a provisional decision based on the message header > information alone, and then just confirm that the body hash was correct. > > We dropped the idea because it is a little more complex and,
The complexity is neglibible. > apart from > the obvious diagnostic benefit (which we could get other ways), it > wasn't a compelling-enough optimization to be worth the trouble. Once > you're into the DATA stage of the message transmission, you don't have > another opportunity to send feedback to the sending MTA until you have > received the entire message body, and in any case I didn't expect IIM to > be used to reject messages out of hand. 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. Even if out-right rejection is warrented, any further DKIM processing can be stopped. > But I'm willing to revisit that > decision, especially since there is now stronger sending policy that > might make outright rejection a possibility in some cases. It also provides benefits in diagnositics, logging, auditing, and dealing with multiple signatures. --ewh _______________________________________________ ietf-dkim mailing list http://dkim.org
