On Oct 14, 2005, at 2:06 PM, Dave Crocker wrote:
I agree with this point. What's important to me, though, is that
we be able to tell the difference between a failed signature
(because the body was changed) and a bogus signature (something
signed with the wrong key, or something made to look like a sig
that's not).
This is the sort of goal that seems entirely reasonable, but might
not be. It's worth exploring exactly how much sophistication and
subtlety is needed, for the functionality DKIM is seeking to provide.
As I understand it, the goal is to determine a domain that is
willing to assert responsibility for the message.
That's a positive goal. It only applies if the signature
validates. If validation fails, for any reason, then we do not
have an accountable domain.
It sounds as if the distinction you want to draw is useful for some
sort of additional goal:
The signature header may include both a body hash and perhaps even a
future salty RCPT TO hash. Failure to validate the hash in the first
case would be useful when attempting to understand the cause. This
would have greater significances during the first few years of
deployment. Extending this mechanism as a means to mitigate some
other checks for example, may be made easier when following this
approach.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org