----- Original Message -----
From: <ned+dkim(_at_)mauve(_dot_)mrochek(_dot_)com>
To: "Michael Thomas" <mike(_at_)mtcc(_dot_)com>
Cc: "Mark Delany" <MarkD+dkim(_at_)yahoo-inc(_dot_)com>;
<ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Friday, July 14, 2006 9:34 PM
Subject: Re: [ietf-dkim] More on naked CR canonicalization
Like it or not, you are not going to be able to define a canonicalization
that
can tolerate all the cases and possible transformations. My best advice is
not
to try. Signing messages that are syntactically invalid is going to be
unreliable and the only solution is to stop creating such messages.
That might be more easily said than done. I think the issue is more about
"easy of use" vs. "required processing." For legacy reasons, the "simple"
method is not going to be as easy to support.
Thomas is theoretically correct, for canonicalization purposes, all bare CR
and LF eol delimiters should be corrected to CRLF pairs. This would
theoretically resolve the problem and it will reduce integrated framework
implementation issues.
Actually, it solves the problem neither in theory nor in practice: What happens
when one of these messages hits a machine that simply drops the offending bare
CRs? Such systems do exist - I've encountered them. (This is apparently done
because there also machines that emit bare CRs in SMTP responses which, if
treated as CRLFs, cause the SMTP command-response alignment to go awry. I
personally advocate using different rules for the handling of bare CRs and LFs
in commands, responses, and data, but that's not how some folks implement
things.)
In any case, I could live with a rule that says to canonicalize bare CRs and
LFs to CRLFS as part of the canonicalization process, but let's please not
pretend that this will solve all the problems with how bare CRs and LFs
interact with DKIM.
Ned
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html