Ferhat Doruk writes...
>After some our client's Bare LF problem, I used fixcr according to DJB's
>suggestion and I started qmail-smtpd process by using a command like this:
I'd suggest instead you simply patch Qmail.
Below is an article I never got around to posting, it has a patch that
should work. I guess I never posted it becuase there seems to be
some kind of unwritten rule that if qmail does something unusual or
unexpected, it's because the RFC says to do it that way. And if the
RFC says to do it some other way, the way Qmail is doing it is actually
better.
-------
Qmail advertises itself as supporting 8BITMIME. In no sense whatsoever
does it support 8BITMIME (well, other than printing 8BITMIME as a
response to a EHLO).
# telnet qmail.org smtp
Trying 192.203.178.37...
Connected to qmail.org.
Escape character is '^]'.
220 ns.crynwr.com NO UCE ESMTP
EHLO erehwon.org
250-ns.crynwr.com NO UCE
250-PIPELINING
250 8BITMIME
According to RFC 1652,
A server which supports the 8-bit MIME transport service extension
shall preserve all bits in each octet passed using the DATA command.
Qmail will not pass, let alone preserve the bits of bare LF's in the DATA
phase. It detects them as "stray new lines", and bombs out in the middle
of message collection and closes the connection. This termination before
quit violates section 4.1.1 of RFC 821 and was responsible for a near
catastrophe last week which when a NT server (which consider a dropped
onnection an invitation to immediatly retry the failed message about
.2 secs later, charming) started a mailing list delivery run to our
server. This interaction resulted in several million failed messages
delivery attempts over a span of several days.
Since Qmail doesn't contain any code to check for the 8BITMIME message
type indicator (which looks like this on a MAIL FROM command)
MAIL FROM:<[EMAIL PROTECTED]> BODY=8BITMIME
it will also silently transform CRLF pairs into the local \n, also a
violation of RFC 1652 for BODY=8BITMIME messages.
Qmail is not RFC 822 compliant either, although it's reasonable for the
MTA to restructure bare LF's according to local end-of-line conventions,
bare LF's are perfectly _legal_ in the message body and the MTA can't
refuse to process messages that contain them, like Qmail does as
described above.
>From the RFC 822 BNF...
text = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.
Note that some measure of RFC 822 compliance can be achieved by simply
commenting a few lines in qmail-smtpd.c, like...
switch(state) {
case 0:
/* if (ch == '\n') straynewline(); */
if (ch == '\r') { state = 4; continue; }
break;
case 1: /* \r\n */
/* if (ch == '\n') straynewline(); */
if (ch == '.') { state = 2; continue; }
if (ch == '\r') { state = 4; continue; }
state = 0;
break;
case 2: /* \r\n + . */
/* if (ch == '\n') straynewline(); */
if (ch == '\r') { state = 3; continue; }
state = 0;
break;
case 3: /* \r\n + .\r */
if (ch == '\n') return;
put(".");
put("\r");
if (ch == '\r') { state = 4; continue; }
state = 0;
break;
case 4: /* + \r */
if (ch == '\n') { state = 1; break; }
if (ch != '\r') { put("\r"); state = 0; }
}
If Qmail wants to detect people terminating lines with bare LF's, it
needs to do that before it gets to the DATA phase.
It's somewhat amusing to note in the author's page at
ftp://koobera.math.uic.edu/www/docs/smtplf.html
"Even if this slight message corruption is acceptable for the
end users, it is dangerous behavior, since LF dot LF can legitimately
appear in the middle of a binary mail message."
that qmail won't permit a "legitimate" LF dot LF in a message either!
Qmail's MIME behavior also results in some undesirable auto-conversion
when it is in a message delivery chain,
mua -> sendmail --> qmail --> sendmail
since qmail is promising to the upstream sendmail that it will
keep the 8BITMIME intact, when in fact it does a "just send 8" to
the next sendmail which will cause it to auto-convert when it
detects the incoming 8 bit data.
--
Aaron Nabil
