At 09:58 28-04-10, Alessandro Vesely wrote: >Do you have specific examples? Could a "mellowed" canonicalization >cope with them?
There is a MTA that was doing changes to the message headers after a message has been signed. The implementation made allowances for changes after signing such as the addition of extra spaces. There's also the case where the user name part can get quoted. Or you can see a change due to the Content-Transfer-Encoding. Some of these changes can be addressed with "relaxed" canonicalization. Some of them may require a configuration change at the verifier's end. The diversity of the email environment is such that you cannot come up with a "mellowed" canonicalization to cope with every possible change. >Replay attacks? Spam is also happening. As an email user, I'm not >overly worried about spoofed signatures: They are not legally binding, >and I trust human recipients are able to distinguish fake messages in >case they occur. I'm not easing spammers' job by signing mail, even >though I'd use weaker signatures for increased resiliency. In facts, >the backscatter I get is not signed. I would be concerned if my DKIM signatures are re-purposed. Once that gets done, my DKIM signature is of no value except for you to direct my messages to the bit bucket. >The reason I'm also reluctant to recommend it is because restrictive >acceptance policies may discard such messages, as John mentioned. The >same concern also applies to possible weaker canonicalizations: would >receivers be tempted to rule them out? I think receivers should trust >the signing policies that senders devise for the messages they send. Receivers seem to be happy with "relaxed". If DKIM becomes common and there is abuse in that area, receivers might rule it out or adapt their filters accordingly. A well-known company had a broken signing policy a few days before Christmas. That caused messages from that company to be rejected. The receiver wanted to accept the message as it was a notice to confirm an order. The receiver decided not to trust the signing policy and allow the message through. >It is true that by the 80%-20% criterion DKIM may work without l=0. >However, it breaks mailing list traffic and MIME-conformant forwarding >(compare that to SPF.) Do we aim at 100%? I don't expect 100%. Regards, -sm _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
