ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] New canonicalizations

2011-05-16 08:04:08
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(_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

<Prev in Thread] Current Thread [Next in Thread>