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
