Dave Crocker wrote:
John Levine wrote:
My theory is that DKIM only applies to valid 2822 messages, and it's not a
substitute for a sanity check for all the screwy things one can send in a
non-conformant message.
+1
huh?
-1, DKIM will be a "Sanity Check" for 2822 headers.
It doesn't matter what's the John's theory is. There are strong
assertions being made with DKIM and there are going to be a lot of
systems that will be adding/correcting and changing headers with/out
DKIM knowledge.
In the last few weeks, we got into "operators" strong feelings regarding
missing fields and corrective actions including rejection.
Interestingly, DKIM can resolve some of this questions.
Consider the fact that 2822 does not require a TO: field. Yet, some
systems will add it - integrity change.
Consider the fact both 822 and 2822 require a DATE:, yet many systems
(or all sizes) don't add it!
Consider the fact that DKIM minimum is "FROM:"
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.
--
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