SM wrote:
At 05:17 18-06-2008, 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. Perhaps it would be a good idea someday to
collect experience and advice into an implmentation guide, but other
than that, it's not our problem. Agreed?
There is an implementation note about signing all end-user visible
header fields. The topic of multiple From headers came up during a
discussion about a DK implementation. It was suggested not to sign
such messages. If I recall correctly, the test was also done in the
DKIM implementation. At the verification stage, it's better to do a
sanity check on the headers before verifying the signature and flag
non-conformant messages.
+1.
My theory is that if throw more information (DKIM signature) about the
client, the lower your false positives in rejection when it comes to
these growing 2822 sanity checks issues.
DKIM naturally promotes sanity checks by its very nature with its
declaration of the binding headers (h=).
More and more, I'm battling operators about new strict 2822
implementations issues with legacy systems that have not caught up.
i.e., missing date: headers. Just the other day, we saw a report where
the operator saw a rejection that said:
Reason: A transaction failure was reported by remote server:
"550 5.6.0 Invalid header found (see RFC2822 section 3.6)"
And then asked:
What does this mean? What needs to happen in order for
my recipient to receive this mail?
That has to be one of the first times I actually seen a RFC2822 based
"Invalid Header" rejection report.
Good or bad, DKIM will help strengthen this fast sanity check behavior.
--
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