"Signers SHOULD take reasonable steps to ensure
that the messages they're signing are valid according to [RFC 5322,
etc]." Leaving the definition of "reasonable" out allows flexibility. It
may be waffly, but I like the approach in this case.
This is OK, but it misses the scenario where a bad guy takes an existing
signed message and prepends another Subject: or From: header. It's more
effective to address this in the verifier.
3. It'd be reasonable for the DKIM spec to remind verifiers that
signers aren't supposed to sign stuff like this, so they might
consider that when deciding what to do with it after verification.
It'd be reasonable to remind them of this particular case. But
I think that all ought to be informative text.
I don't feel strongly about how normative we make the language, but I do
think it would be a good idea to encourage verifiers not to say the
signature is valid on a message with extra headers, even if it
mechanically verifies. This catches both the sloppy signer and the
hostile intermediary.
FWIW, my DKIM verifier has for several weeks rejected anything which has
an extra of any of these headers:
From Sender Subject Date To Cc MIME-Version Content-Type
Content-Transfer-Encoding
I haven't collected detailed statistics, but I can report that nothing
horrible has happened. It's Mail::DKIM, the changes are about eight
lines. Anyone else wants it, just ask.
Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet
for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html