Per Murray's request, here's just the changes to take out the verifier message editing
Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ---------- Forwarded message ---------- I wish I could say this is ready to ship, but it's not. It's still full of language in which a verifier creates an edited version of the message, and a few other lies. Here's the fixes, most of which I think I sent in last time. Assuming we agree that the verifier does not, in fact, create an edited message, none of them should be contentious: 3.4.5, first INFORMATIVE IMPLEMENTATION NOTE, last sentence: delete "or remove text that appears after the specified content length" since verifiers do not produce an edited message. 3.5, d= and i= tags: references to RFC3490 should be RFC5890. The reference to ToASCII() should go, or else in both places say IDNs are represented as A-labels. 3.5, l= tag, INFORMATIVE IMPLEMENTATION WARNING, remove "or remove text that appears after the specified content length" since verifiers don't produce an edited message. 3.5, z= tag, remove paragraph "Header fields with characters requiring conversion (perhaps from legacy MTAs that are not [RFC5322] compliant) SHOULD be converted as described in MIME Part Three [RFC2047]." DKIM only applies to RFC5322 compliant messages, RFC2047 only describes conversions for some, not all, of the fields that can be copied in a z= header, and as soon as the EAI RFCs come out, which is likely to be soon, this advice will be wrong anyway. 6.1.3, next to last paragraph, remove "by truncating the message at the indicated body length" since verifiers do not create an edited message. 6.1.3, remove the INFORMATIVE IMPLEMENTATION NOTE at the end, which is entirely about creating the edited message that verifiers don't create. 6.3, remove next to last pp, "The verifier MAY treat unsigned header fields with extreme skepticism, including marking them as untrusted or even deleting them before display to the end user." That's both because the verifier doesn't create an edited message, and because verifiers don't treat any field with any degree of scepticism. They take what they get. 6.3, last sentence: "should be rendered" -> "should be treated" There's other stuff I would remove or fix if we had unlimited time, but these are the important ones. Regards, John Levine, jo...@iecc.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