http://bugzilla.spamassassin.org/show_bug.cgi?id=4068
------- Additional Comments From [EMAIL PROTECTED] 2005-01-10 16:11 ------- I'm familiar with the different line termination character sequences that UNIX and Windows platforms use to create files. However, these RFCs only specify how messages should be formed when being transmitted between platforms and not how they are stored on any specific platform. I haven't used or tested against as many e-mail clients/servers as you probably have but of the stuff that I have tested (Windows - MS Outlook Express and Thunderbird as MUAs, Debian Linux - UNIX mail to send messages, Thunderbird as MUA, exim4 as MTA, and UW pop/imap server to manage mailboxes), they always include CRLFs at the end of lines when they send/receive messages (at the SMTP, POP3, and IMAP4 protocol levels). (I intercepted messages using the ethereal packet sniffer to confirm the presences of CRLFs.) In terms of a real world example, I created a setup where I intercepted messages between e-mail clients and POP3/IMAP3 servers, passed the messages to SpamAssassin, and retransmitted the resulting messages that SpamAssassin generated. I found two problems: 1- I noticed that the modified messages were missing CRLFs on the lines that SpamAssassin added. The message parser that I wrote to examine messages broke because the parser is strictly compliant with the RFCs (on the assumption that "bad" message senders would be sloppy in terms of message syntax). 2- When a message contained spam and SpamAssassin tagged and modified this message, SpamAssassin added a closing MIME boundary delimiter without a CRLF. When a POP3 client (MS Outlook Express and Thunderbird) received this modified message, the client would wait indefinitely (or until its timer expired) for the missing closing CRLF to specify the end of the RETR reply even if the RETR reply's end-of-date sequence had already been transmitted after the message. --- I think that the "add CRLFs only if a message already contains a null line with CRLFs between message header and body or a CRLF is already present at the end of a message (when there is no message body)" suggestion make sense. If CRLFs exist, it probably means that a message is in transit between MUA and MTA or between MTA and MTA (being handled according to the RFCs using SMTP, POP3, or IMAP4 rules) or being copied as a file on Windows platforms. In this case, SpamAssassin should terminate the lines that it adds with CRLFs. If LFs exist, then the message is being copied as a file on UNIX platforms. In this case, SpamAssassin should terminate the lines that it adds with LFs. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
