On 16/May/11 06:15, Murray S. Kucherawy wrote: >> From: On Behalf Of Barry Leiba >> 2. We wanted to cover the vast majority of the cases, though we knew >> there'd always be outlying situations where some mail would get broken >> because what we had didn't *quite* cover some other case. We decided >> to accept that.
However, relaxed header canonicalization is not MIME compatible. In particular, RFC 2045 says Note that the value of a quoted string parameter does not include the quotes. That is, the quotation marks in a quoted-string are not a part of the value of the parameter, but are merely used to delimit that parameter value. In addition, comments are allowed in accordance with RFC 822 rules for structured header fields. 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. Fixing this and a couple more nits, we could claim to cover text/plain, which is still not quite the vast majority of the cases. > I would add that adding a new canonicalization now has an extremely > high cost to the people that want to use it, because signatures > using it will go unverified for a very long time until software > supporting the new canonicalization is widely deployed. Many MTAs still add a Domainkey-Signature. They could stop that, and add a legacy DKIM-Signature along with a one that features the newer canonicalization instead. Setting the pace in this manner can keep DKIM development alive indefinitely. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html