Ben Lentz wrote, On 29/10/06 1:26 AM: > However, after providing all this information to Anthony Howe, developer > of milter-spamc he's responded with: >> I'm going to reject this patch on the grounds that I claim the DKIM >> test in SpamAssassin is wrong. RFC 2822 line endings for ALL headers, >> body lines, and the blank line separating the two are CRLF, not LF.
The problem with this line of reasoning, and I believe the reason why we ended up with the practical solution of looking at the line endings of the first lines and using what we find for the rest, is that RFC2822 applies only to the mail as it is sent between computers to an MTA. We found that we could not count on the line endings conforming to RFC2822 at the time that it is sent to SpamAssassin. To quote from RFC2822: This specification is intended as a definition of what message content format is to be passed between systems. Though some message systems locally store messages in this format (which eliminates the need for translation between formats) and others use formats that differ from the one specified in this standard, local storage is outside of the scope of this standard. We ran into problems when we did anything other than decide on what line ending format the message was using and then use that when we add headers. It seems to me that milter-spamc is making the same mistake that we did, which is to assume that it is always ok to add a header in RFC2822 format. As long as it is not acting as a filter of mail in transit to an MTA, then it cannot rely on RFC2822. In practice, we see mail systems that internally use RFC2822 format _except_ for using the newline convention of the local OS, only taking care of that aspect of RFC2822 when the mail is sent out to or received from other MTAs. Absent a standard, all we can do is figure out which newline is being used and do the same with any headers that are added. -- sidney
