[ietf-dkim] New canonicalizations

[John R. Levine]

> Thus the following two forms
>
>  Content-type: text/plain; charset=us-ascii (Plain text)
>  Content-type: text/plain; charset="us-ascii"
>
> are completely equivalent
>
> but they are not DKIM-wise equivalent.

I'm sorry, but this is just so wrong.

Helpful software can modify mail in a million ways that don't affect the 
way that a message renders.  If the contents of a message are in fact 
ASCII, these are also equivalent to the headers above:

  Content-type: text/plain; charset=UTF-8 (a superset of ASCII)
  Content-type: text/plain; charset="ISO-8859-2" (another superset of ASCII)
  Content-type: text/enriched; charset="windows-1252" (if there are no enriched codes)

The point of relaxed canonicalization was to deal with the kind of small 
changes that dusty copies of sendmail make, not to handle every possible 
message mutation that more or less renders the same.  In retrospect, it 
probably would have been better only to provide simple and tell people 
more firmly to do the signing after and the checking before any local 
modification.  The idea that an MUA can sign if an MTA doesn't is clever, 
but if anyone's doing that, it's news to me.

Perhaps Murray has data that says whether relaxed verifies much more 
often than simple does.

Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly