Here's maybe a better way to frame the question: Should we empower ourselves
to label a DKIM implementation that doesn't do format enforcement as (a)
non-compliant, or (b) low-security/low-quality?
The latter. Hey, we agree. I think I always said SHOULD rather than
MUST.
The DKIM spec is a peculiar combination of instructions on how to produce
a technically valid signature along with a great deal of non-normative
advice, some of which is good (sign all the visible headers) and some of
which is not so good (tell MUAs to highlight the signed parts.) If I were
redoing it, I think I would go through all the advice and either turn it
into a SHOULD if it tells you how to do more robust signing and
verification, or get rid of it. If you recall my snarky message to Dave a
few days ago, I actually do think we should get rid of that stuff.
There are already a zillion ways to produce a technically valid but
useless signature, so I'm not concerned about yet another one. I'd just
like to give people who want to do useful signing and verification the
best shot at it we can. Keep in mind the "as if" rule, which says that
your code can do whatever you want so long as the results are the same as
if you followed the spec. So if the spec says you SHOULD NOT sign or
verify messages that have extra headers that MUAs are likely to render
inconsistently, it would be entirely valid to have a validation prepass
that ensured that the DKIM module never saw those messages at all.
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