Jon Callas wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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?
Completely.
Broken messages should be handled at a different layer.
True, but that different layer may just use DKIM assertions as part of
it's new 2822 checking logic. :-)
For example:
Prior to DKIM (or no DKIM signature), having a missing DATE: might
allow the message to get by with a local policy:
EnableStrict2822-Date No
EnableStrict2822-From Yes
One of the largest conglomerates in the world is sending newsletters
without dates and we recently got blasted when the new strict 2822
options added enabled by default, caused delivery issues. Of course,
the sender was WRONG, but the customer didn't care!! He wanted the
option to ignore the lack of a date.
Now come DKIM.
DKIM offers new inherent rules based on the idea that DKIM asserts 2822
compliance. That means a DATE: and FROM: must exist and the lack of any
has a high weight and confidence that the DKIM domain message was
violated - no need to do any hashing calculations. In short, a message
with a DKIM-Signatures elevates the email 2822 status to one that SHOULD
NOT be violated. If the customer still wants to receive the bad
message, that option will still provided, but he is no longer doing
himself any justice and DKIM domain any justice he is accepts this
broken 2822 message especially one that was expected to be signed
correctly with alterations.
--
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