ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Working Group Last Call on 4871bis

2011-04-12 20:04:59
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.

3.6.2.1, 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.

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