SM wrote:
This is not related to ADSP.
I believe the OP knew that.
At 14:05 18-06-2008, Hector Santos wrote:
But more importantly, consider that DKIM binding *instructs* you what
headers must be present. Therefore, this is going to be one of the top
strong "sanity checks" to optimized DKIM processors. Why bother to
waste time recalculation the SHA265 hash when it may not even have all
its ingredients. If DKIM h= has from:to:subject:date: and one or more
of these fields are missing - BINGO - instance REJECT without the need
to do hashing - a sanity check and heavily confirmed with a new higher
level of expectations triggered but the presence of this
"DKIM-Signature:" in the message.
Sanity checks are different from which headers should be signed. The
checks may be necessary to prevent MUA quirks. The h= tag defines which
headers are signed. It may include headers that are not present. There
is an informative explanation in the RFC about that.
Well, none of this are sanity checks, so I'm at fault for perpetuating
the errant usage.
Those binds are part of the integrity and verification process - missing
headers yields failed hashing calculations.
So what's the point of doing or even offering or verifying DKIM, if the
whole point of keeping integrity is just a farce?
Anyway, my point is the theory that DKIM won't be used for valid header
checking is not correct because that is the one thing we are looking at
providing small footprint filtering rules that will assist in the long
time issues of better handling missing/bad headers. IOW, it must past
that test first before even considering the next step - hashing.
In the event a process prepends additional existing headers, I guess it
would be up to the implementation of the verifier to make that part of
some feature list. This is probably more true if the appear above any
Received lines.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html