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