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.
184.108.40.206, Namespace: remove INFORMATIVE OPERATIONAL NOTE about wildcards,
because the first sentence is just plain false.
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.
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet
Please consider the environment before reading this e-mail. http://jl.ly
NOTE WELL: This list operates according to