[ietf-dkim] New canonicalizations
John R. Levine
johnl at iecc.com
Mon May 16 06:00:52 PDT 2011
> 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.
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
More information about the ietf-dkim