----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Michael Thomas" <[EMAIL PROTECTED]> Cc: "Mark Delany" <[EMAIL PROTECTED]>; <[email protected]> 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. I can attest that would be the case for us. DKIM is not as easy to implement as Crocker believe it is. Software Change is required and the more integrated your system is, the more changes it needs. All signers and verification used a single transformation or a consistent method this would solve the problem and then Crocker would be more correct - Less software changes is requires because now the DKIM Function Generator will be independent of feed type. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
