Ned Freed wrote:
----- 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.)
The problem here is that up until a few years ago, the apps that did this
were compliant with STD11. This is quite a different situation than apps
that are just flagerant protocol scofflaws. RFC 2822's proscription is
probably a good idea since it clarifies something that wasn't entirely clear
in the previous standard, but I think it is quite another thing to design a
protocol which is trying to accommodate the mail universe as
it's currently constituted, not as we wish it were to be. These apps exist
whether we like it or not, and as far as the app owners are concerned they
aren't broken since they manifestly do the job their owners expect.
I also think that whether there are MTA's that reject 2822 non-compliant
messages is a bit of a red herring: they'd do that with or without the help
of DKIM. The fact still remains that they are outliers, and while that is
the case, it seems perfectly reasonable for DKIM to be robust.
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.
Fine, but how else do they interact? That's the only thing in my code
that cares
about this subject.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html