> 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, [email protected], 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
