On Oct 8, 2010, at 10:36 AM, Charles Lindsey wrote:
On Thu, 07 Oct 2010 17:09:14 +0100, Michael Thomas <mike(_at_)mtcc(_dot_)com>
I'm with Steve on this one. Forcing implementations of DKIM to
determine whether a message is compliant is a pretty high bar. ...
How can you claim it is a "high bar" when clearly it isn't.? All that the
implementor of a verifier has to do is:
1: Construct a list of all the RFC5322 headers which can occur at most
once. FYI, that is Orig-Date, From, Sender, Reply-To, To, Cc, Bcc,
Nessage-ID, In-Reply-To and References. For good measure, add the
once-only headers defined in all the other RFCs that you can locate (which
would give you, for a start, MIME-Version, Content-Type and
2. Your implementation already needs to scan all the headers in order to
identify the ones it needs to hash in order to verify the signature. It is
a pretty trivial addition to count the occurrences of each one mentioned
in the "h=" tag as part of your scan, and to check whether any of the ones
in the list have occured twice.
If you think that that's all it means to comply with 5322 then you should
go and read 5322 again. Line lengths. Bare CRs or LFs. ABNF from atoms
on up. Timestamp format. Message-ID format. Address structure in any
of To, From, Cc, Reply-To and so on. Similarly for all the Resent-* variants
of those. And that's before you get to the really ugly obsolete header formats.
I'm not aware of existing code that does all that - and if it were found or
written, it would reject mail that's successfully delivered today.
If one were to add the "MUST" mentioned upthread then
a DKIM validator would be _required_ to implement all that checking
and to decline to validate mail that would commonly be delivered.
If you want to talk about adding some minimal header checking to
DKIM then go right ahead, it seems like a reasonable thing to discuss
- but take it to a new thread, rather than this one, as it's an entirely
different thing than requiring all DKIM validators to also be 5322
NOTE WELL: This list operates according to