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