----- Original Message -----
From: "Ned Freed" <ned(_dot_)freed(_at_)mrochek(_dot_)com>
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.
That sounds a rare edge case. It is certainly not the norm. But even then,
for this case, does it remove the EOL (regardless of type) of the line so
that two or more subsequent data lines become one? Because if it doesn't I
think.Thomas's suggestion still applies
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.)
Most system comply with RFC x822/x821. Thank God. :-) Most systems will
send out compliant CRLF delimited DATA. But then again, I had no reason to
sit down to look for broken mail senders because our Receiver and post mail
processors will handle any format. This is basically Postel's principal:
Conservative with what you send out, liberal on what you receive. I think
most systems behave in this manner.
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.
I'm speaking in terms of a black box DKIM function generator for the signer
and verifier, that independent of any varying EOL formatted feed, it would
be able to produce the same result. I believe that is it possible.
Of course, there will be rare exception to the rule with the extremely rare
highly broken edge cases, which is probably problematic for other things as
well, especially if they are joining DATA lines. I'm sure they will be see
the problems once they attempt to implement DKIM.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html