Per Murray's request, here's just the changes to take out the verifier
message editing
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
---------- 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, 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