> Technical support at chek.com says that: "LSMTP reportedly violates > RFC822 standard by terminating lines in the header and body with only > LF. As such, Qmail will reject the mail with status 451, with the > error body pointing to a site explaining the problem." RFC821 defines the message body as follows: "The receiver treats the lines following the [DATA] command as mail data from the sender. This command causes the mail data from this command to be appended to the mail data buffer. The mail data may contain any of the 128 ASCII character codes." Last I checked, LF was one of the 128 ASCII character codes. It is permissible to have LF characters in the message text. I would not recommend sending messages with LF characters, but such messages are valid and must be accepted. The correct processing when encountering LF in the message text is to keep looking for CRLF because LF alone does not terminate a line of text. It is incorrect to reject the message on the assumption that this LF was meant to terminate the line and there will not be a CRLF later on. There is in fact a CRLF later on. > Bare LFs are strictly forbidden by the IETF document > "draft-ietf-drums-msg-fmt-09.txt". This supersedes RFC822 in > defining the valid format for mail sent via SMTP. I might as well reveal that I am the real President-elect of the USA (most of you did not read the fine print on the back side of the ballot when punching, and ended up voting for me even though the arrow was pointing at another name), and that I plan to veto any bills that would make proposed standard drafts override established Internet standards. I also plan to reinstate the capital punishment for people who confuse RFC821 and 822. I joined the drums working group when it started in 1995. Within a few months, it had stabilised at around 50-200 inflammatory messages a day, mostly assertions and counter-assertions on the intellect or character of Dan Bernstein. I am not talking about 5 liners here but about long, detailed technical messages. I found myself literally spending hours a day reading and answering drums mail, and came to the conclusion that this group was never going to reach "rough consensus," at least not in its current form. I signed off, having better uses for my time. Five years later, they still do not have a standard. When and if they do have a standard, it will be based on the opinions of people who had the stamina to put up with flame wars for 5 years and whose employers did not mind. The university where I used to work would not have minded if I had spent 1-2h a day "contributing to the development of the next generation of e-mail protocols," but in the commercial world time is money and endeavours like drums are better described as "black-hole, geological scale projects with no enforceable deadlines, no progress reports and no deliverables other than evaporated manpower." A private chat with the product manager for (say) Exchange is the preferred way to settle compatibility issues, because it produces the quick results demanded by customers. People who gave up and left drums may or may not agree with the changes drums would require and may or may not implement them. Sorry but today's customers couldn't care less whether their e-mail server follows the Aref Sea! They want to know whether it works with Exchange, Lotus Notes, and so forth. Either way, there is going to be a huge installed base of pre-drums-standard servers, and drums-standard servers had better be able to interoperate. Incompatible changes like the rejection of plain LF aren't going to be popular. There is probably a popular mail client out there that generates plain LF in the message body, its users probably have no ability to change that, and you aren't going to make it disappear by dumping all these messages on the floor at web mail companies #7298, #18212 and #21152. And if you do decide to dump a message on the floor, the correct way to do this is a 5xx error code, which does not ask the other server to try again later. The stray LF in the message is unlikely to vanish spontaneously the next time the message is sent, so you are just wasting resources and bandwidth with a 451 error. Eric