> 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