----- Original Message ----- From: "Ned Freed" <[EMAIL PROTECTED]>
>> 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
