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