CRLF in headers sneaking through qmail-smtpd

[Network Administration]

This is kind of strange.

I'm the Net Admin for Alyrica Networks, an Oregon-based ISP. Some time after we switched from Sendmail to Qmail with Maildir, I began recieving complaints about Outlook Express POP3 "sticking" on messages: a user with 10 messages in their mailbox would download 4, and then hang and time out while downloading the 5th. The problem could only be resolved in each case by deleting the message that "stuck", in this case that 5th message. If the 5th message were not deleted, the user would never be able to retrieve the rest of their mail.

After looking into the problem, I discovered that some copies of OE would have problems like this, and some would not. Identical versions of Outlook Express on different computers would act differently: One would hang, and another would work but place headers in the message body.

Remember, this problem was rare. Only some clients, and only some messages. We would get maybe 1-2 calls a month about this issue.

After looking into the problem, I found that the offending messages were those which had intact \r\n in their headers, _on_the_server_. In other words, messages were getting through qmail-smtpd without having \r\n replaced with \n.

When the MTA went to download these messages, the \r\n was replaced with \r\r\n (part of the normal Unix -> PC conversion process, but in this case run amok due to the extra \r). When OE sees \r\r\n, it thinks "End of headers" and puts everything following into the message body.

I suspect that the mail agents generating these messages are leading the headers with a \r\n\r\n, but I have been unable to prove it. In any case, I'm left wondering if anyone else is having similar problems. This problem is rare, and even when it occurs it only hangs some versions of OE. Any suggestions?

Joseph

[Network Administration]

Please, any help on this issue would be appreciated!
----- Original Message -----
From: Network Administration
To: ***@list.cr.yp.to
Sent: Friday, November 14, 2003 11:54 AM
Subject: CRLF in headers sneaking through qmail-smtpd



This is kind of strange.

I'm the Net Admin for Alyrica Networks, an Oregon-based ISP. Some time after we switched from Sendmail to Qmail with Maildir, I began recieving complaints about Outlook Express POP3 "sticking" on messages: a user with 10 messages in their mailbox would download 4, and then hang and time out while downloading the 5th. The problem could only be resolved in each case by deleting the message that "stuck", in this case that 5th message. If the 5th message were not deleted, the user would never be able to retrieve the rest of their mail.

After looking into the problem, I discovered that some copies of OE would have problems like this, and some would not. Identical versions of Outlook Express on different computers would act differently: One would hang, and another would work but place headers in the message body.

Remember, this problem was rare. Only some clients, and only some messages. We would get maybe 1-2 calls a month about this issue.

After looking into the problem, I found that the offending messages were those which had intact \r\n in their headers, _on_the_server_. In other words, messages were getting through qmail-smtpd without having \r\n replaced with \n.

When the MTA went to download these messages, the \r\n was replaced with \r\r\n (part of the normal Unix -> PC conversion process, but in this case run amok due to the extra \r). When OE sees \r\r\n, it thinks "End of headers" and puts everything following into the message body.

I suspect that the mail agents generating these messages are leading the headers with a \r\n\r\n, but I have been unable to prove it. In any case, I'm left wondering if anyone else is having similar problems. This problem is rare, and even when it occurs it only hangs some versions of OE. Any suggestions?

Joseph

[Clyde Wildes]

Joseph,

I am having the exact same problem, but do not know the root cause. I have
had three instances in the past week where I have had to delete e-mails from
a customer server pop-box because their e-mail clients looped during
download. It happened with Outlook and Eudora clients. Please let me know if
you find anything.

Clyde


_____

From: Network Administration [mailto:***@alyrica.net]
Sent: Tuesday, November 18, 2003 8:15 AM
To: ***@list.cr.yp.to
Subject: Bizarre CRLF killing Outlook Express


Please, any help on this issue would be appreciated!

----- Original Message -----
From: Network <mailto:***@alyrica.net> Administration
To: ***@list.cr.yp.to
Sent: Friday, November 14, 2003 11:54 AM
Subject: CRLF in headers sneaking through qmail-smtpd


This is kind of strange.

I'm the Net Admin for Alyrica Networks, an Oregon-based ISP. Some time
after we switched from Sendmail to Qmail with Maildir, I began recieving
complaints about Outlook Express POP3 "sticking" on messages: a user with 10
messages in their mailbox would download 4, and then hang and time out while
downloading the 5th. The problem could only be resolved in each case by
deleting the message that "stuck", in this case that 5th message. If the
5th message were not deleted, the user would never be able to retrieve the
rest of their mail.

After looking into the problem, I discovered that some copies of OE would
have problems like this, and some would not. Identical versions of Outlook
Express on different computers would act differently: One would hang, and
another would work but place headers in the message body.

Remember, this problem was rare. Only some clients, and only some messages.
We would get maybe 1-2 calls a month about this issue.

After looking into the problem, I found that the offending messages were
those which had intact \r\n in their headers, _on_the_server_. In other
words, messages were getting through qmail-smtpd without having \r\n
replaced with \n.

When the MTA went to download these messages, the \r\n was replaced with
\r\r\n (part of the normal Unix -> PC conversion process, but in this case
run amok due to the extra \r). When OE sees \r\r\n, it thinks "End of
headers" and puts everything following into the message body.

I suspect that the mail agents generating these messages are leading the
headers with a \r\n\r\n, but I have been unable to prove it. In any case,
I'm left wondering if anyone else is having similar problems. This problem
is rare, and even when it occurs it only hangs some versions of OE. Any
suggestions?

Joseph

[Carl Haddick]

I have seen this for years.

Post by Network Administration
Please, any help on this issue would be appreciated!
----- Original Message -----
From: Network Administration
Sent: Friday, November 14, 2003 11:54 AM
Subject: CRLF in headers sneaking through qmail-smtpd
This is kind of strange.
I'm the Net Admin for Alyrica Networks, an Oregon-based ISP. Some time after we switched from Sendmail to Qmail with Maildir, I began recieving complaints about Outlook Express POP3 "sticking" on messages: a user with 10 messages in their mailbox would download 4, and then hang and time out while downloading the 5th. The problem could only be resolved in each case by deleting the message that "stuck", in this case that 5th message. If the 5th message were not deleted, the user would never be able to retrieve the rest of their mail.

I once found a MS Knowledge Base article that said any message exceeding
12K, message plus headers, could cause this situation. There was also a
specific problem noted with a Sun mail server.

According to the now-gone MS KB article, Outlook would not recognize
that it had the end of a message and wait forever for more. Since more
would never come, you would get the 'pop3 server has stopped responding
error'.

When I first saw this, I thought it was my pop3 server's fault
(ipop3d). However, a different computer running a similar version of
Outlook would download the mail just fine. Subsequent upgrades of
ipop3d did not relieve the problem.

The problem seemed to lessen when I switched to qmail, my theory being the
extra blank line qmail-pop3d adds at the end of each email message helps
Outlook recognize end of message.

I'm convinced the problem happens with any pop3 server, and I've heard
Microsoft users say messages can get stuck on their servers.

At the risk of encouraging off-topic discussion, it would be very, very
nice to know why qmail is getting blamed for what seems to be an Outlook
problem.

I have also seen Norton's local mail proxy (virus scanner) cause this -
stick on message x every time, take out the 127.0.0.1 mail server
setting, and download the mail without difficulty.

Best regards, comments appreciated,

Carl

[Andrew Hamilton]

----- Original Message -----
From: "Carl Haddick" <***@glade.net>
To: <***@list.cr.yp.to>
Sent: Tuesday, November 18, 2003 4:55 PM
Subject: Re: Bizarre CRLF killing Outlook Express

Post by Carl Haddick
I have seen this for years.

Post by Network Administration
Please, any help on this issue would be appreciated!
----- Original Message -----
From: Network Administration
Sent: Friday, November 14, 2003 11:54 AM
Subject: CRLF in headers sneaking through qmail-smtpd
This is kind of strange.
I'm the Net Admin for Alyrica Networks, an Oregon-based ISP. Some

time after we switched from Sendmail to Qmail with Maildir, I began
recieving complaints about Outlook Express POP3 "sticking" on messages: a
user with 10 messages in their mailbox would download 4, and then hang and
time out while downloading the 5th. The problem could only be resolved in
each case by deleting the message that "stuck", in this case that 5th
message. If the 5th message were not deleted, the user would never be able
to retrieve the rest of their mail.

Post by Carl Haddick
I once found a MS Knowledge Base article that said any message exceeding
12K, message plus headers, could cause this situation. There was also a
specific problem noted with a Sun mail server.

Yes, this was a common problem a few years ago when we used Sendmail, but
mostly to Eudora users. It turned out that Eudora would insert an extra
blank line when trying to download new messages (I don't quite remember
exactly where it would insert it, it was a problem that we dealt with about
4 1/2 years ago -- sorry), and for some reason this would goose the client
into thinking that the server had stalled. In order to remedy the problem,
we would have to delete the poplock, and also delete the message that the
download stalled at. I also observed OE behaving similarly a few years ago,
but in the last couple of years I haven't seen it happen. Attachments will
occasionally cause OE to to time out, too.

andrew :)

Andrew Hamilton
Systems Administrator
Powercalling.Net
*Phone: [phone]
*Fax: [phone]
*Email: ***@powercalling.net

[Network Administration]

First off, I'm comforted by the fact that there are others seeing the same
problem! Now that I know it's an issue, I'm all the more interesed in
tracking it down. I'll probably start dumping raw tcp traffic to port 25 in
order to debug the problem. When a user is affected with something like
this, it seems to happen about once a week. The reason is that it us
usually the same originating organization that is generating problem
messages, over and over.

A few points are in order:

1) Let me remind people that this is a reproducible problem. I have a few
messages, which, if placed in a user's maildir, will cause their OE to hang.
2) I don't know why /r/r/n is causing OE to hang, but I can see that it is
causing it to misinterpret end-of-headers and I'm guessing that this is
somehow related (it could be as simple as some copies of OE rebelling at not
thinking they are recieving "From", "To", or "Subject" headers).
3) Although some may blame the problem on OE's reaction to /r/r/n, it isn't
OE's fault (nor the pop3 agent's fault) that a text file on a unix server
contains /r/n. In any case, it doesn't matter who is at fault. I intend to
fix the problem. That's my job. ;)
4) The only agent that I have definitely found to be causing the problem is:

X-Mailer: Kana 6.nkpfccBcn{tkec0pgv

I think Kana is spamming software, and the gibberish is to "fool" people
trying to filter them out. In any case, Yahoo! personals were also causing
problems awhile back.

Wish me luck.

Joseph

[Carl Haddick]

On Wed, Nov 19, 2003 at 08:52:28AM -0800, Network Administration wrote:
<snip>

Post by Network Administration
1) Let me remind people that this is a reproducible problem. I have a few
messages, which, if placed in a user's maildir, will cause their OE to hang.

Wow, that's great news! Is there any way you could send me an example of
a message that will hang Outlook Express? If so, I would like to write
a filter to call out of .qmail to fix the offending character sequence.

Because of those on this list struggling along with Outlook Express,
please send the messages straight to me: ***@glade.net (that would be
better than the address I've subscribed to this list, ***@glade.net).

I will happily post the solutions I write to a web site where any who
are interested my download them and review my methods. I'll probably
write solutions in Python and C.

Best regards,

Carl

[Network Administration]

OK, significant progress has been made! I finally figured out what is causing this. Actually, I was able to capture a "faulty" message on the wire, and look at it both before and after qmail-smtpd got to it.

To begin with, I started tcpdumping all port 25 traffic on my mail server. About 18 hours (and 155mb) later, I got a call from one of my customers: his mail program was sticking. I had something in my net!

I immediately took the offending messages (there were two of them) out of his maildir and saved them. Then, by using strings found in the messages, I located the messages in the tcpdump file (in their raw packet format). By examining the IP headers in their raw form, I saw that the protocol code (0x06) was followed by a two-byte checksum and then the source and destination IP addresses (four bytes each). I converted my server's IP to hex, and used that to find the IP of the "bad" (sending) servers in dotted-decimal form.

After that, I simply told tcpdump to re-parse the binary capture file, sorting out all communications with those servers and storing them in seperate binary files.

Finally, I ran the binary files through Ethereal. If anyone wants to look at the files, they are online; the .txt file is the maildir file, and the .dat is raw packet data. The URLs are:

Bad message #1 [Raw tcpdump] [Maildir file]
Bad message #2 [Raw tcpdump] [Maildir file]

OK, so the analysis was not too difficult. The bottom line is that the sticking messages are sent with each line terminated by \r\r\n (0D0D0A) instead of \r\n (0D0A). The "mail from:" and "rcpt to:" commands are terminated with \r\n, but the body ("data" segment) is not. Technically, I don't think this violates RFC (comments, anyone?)

For example:

220 tiberius.alyrica.net ESMTP\r\n
HELO cetta.net\r\n
250 tiberius.alyrica.net\r\n
MAIL FROM:<***@cetta.net>\r\n
250 ok\r\n
RCPT TO:***@deleted_for_privacy\r\n
250 ok\r\n
DATA\r\n
354 go ahead\r\n
From: Jon R. <***@cetta.net>\r\r\n
To: <***@igosaab.com>\r\r\n
blah blah blah...\r\r\n

In any case, the \r\r\n is converted to \r\n by qmail-smtp and the message is saved on the server in the maildir. When someone reads the message (POP3), \r\n becomes \r\r\n again, and Outlook Express dies.

So, where do we want to go from here? I think we need to answer three questions:

1) Does any of this behavior violate RFC?

2) If not, the problem still needs to be solved. How? (NO, I cannot tell my customers not to change mail clients!)

3) Anyone want to make a patch for this? Or suggest what program ought to be patched?

Cheers (and happy thanksgiving!)

Joseph



From: Network Administration
To: ***@list.cr.yp.to
Sent: Friday, November 14, 2003 11:54 AM
Subject: CRLF in headers sneaking through qmail-smtpd



This is kind of strange.

I'm the Net Admin for Alyrica Networks, an Oregon-based ISP. Some time after we switched from Sendmail to Qmail with Maildir, I began recieving complaints about Outlook Express POP3 "sticking" on messages: a user with 10 messages in their mailbox would download 4, and then hang and time out while downloading the 5th. The problem could only be resolved in each case by deleting the message that "stuck", in this case that 5th message. If the 5th message were not deleted, the user would never be able to retrieve the rest of their mail.

After looking into the problem, I discovered that some copies of OE would have problems like this, and some would not. Identical versions of Outlook Express on different computers would act differently: One would hang, and another would work but place headers in the message body.

Remember, this problem was rare. Only some clients, and only some messages. We would get maybe 1-2 calls a month about this issue.

After looking into the problem, I found that the offending messages were those which had intact \r\n in their headers, _on_the_server_. In other words, messages were getting through qmail-smtpd without having \r\n replaced with \n.

When the MTA went to download these messages, the \r\n was replaced with \r\r\n (part of the normal Unix -> PC conversion process, but in this case run amok due to the extra \r). When OE sees \r\r\n, it thinks "End of headers" and puts everything following into the message body.

I suspect that the mail agents generating these messages are leading the headers with a \r\n\r\n, but I have been unable to prove it. In any case, I'm left wondering if anyone else is having similar problems. This problem is rare, and even when it occurs it only hangs some versions of OE. Any suggestions?

Joseph

[Richard Lyons]

Post by Network Administration
1) Does any of this behavior violate RFC?

No.

Post by Network Administration
2) If not, the problem still needs to be solved. How? (NO, I cannot
tell my customers not to change mail clients!)

What mail clients fail? I was able to put your messages into
a mailstore and successfully downloaded them with OE6. As
a POP client only needs to check for CRLF.CRLF to determine
the end of the message, and since that's supplied by the POP
server, the message content shouldn't matter. Have you tried
tcpdumping a POP session to verify that the client hangs
after the server indicates EOM?

Post by Network Administration
3) Anyone want to make a patch for this? Or suggest what program ought to be patched?

Put

| tr -d '\012' | safecat Maildir/tmp Maildir/new

in your customers .qmail. This may break some mail.

Rick.

[Richard Lyons]

Post by Richard Lyons
| tr -d '\012' | safecat Maildir/tmp Maildir/new

s/2/5/

Rick

[Charles Cazabon]

Post by Network Administration
OK, so the analysis was not too difficult. The bottom line is that the
sticking messages are sent with each line terminated by \r\r\n (0D0D0A)
instead of \r\n (0D0A). The "mail from:" and "rcpt to:" commands are
terminated with \r\n, but the body ("data" segment) is not. Technically, I
don't think this violates RFC (comments, anyone?)

It does, actually, violate RFC2821 -- see the second paragraph of section
2.3.7:

In addition, the appearance of "bare" "CR" or "LF" characters in text
(i.e., either without the other) has a long history of causing
problems in mail implementations and applications that use the mail
system as a tool. SMTP client implementations MUST NOT transmit
these characters except when they are intended as line terminators
and then MUST, as indicated above, transmit them only as a <CRLF>
sequence.

"\r\r\n" is a forbidden bare CR followed by a legitimate CRLF pair.

Post by Network Administration
In any case, the \r\r\n is converted to \r\n by qmail-smtp and the message
is saved on the server in the maildir. When someone reads the message
(POP3), \r\n becomes \r\r\n again, and Outlook Express dies.

And is therefore an OE bug. Report it to Microsoft.

Post by Network Administration
1) Does any of this behavior violate RFC?

Yes; see above.

Post by Network Administration
3) Anyone want to make a patch for this? Or suggest what program ought to be patched?

OE should be fixed. Don't break qmail.

Charles

[Richard Archer]

Post by Charles Cazabon
OE should be fixed. Don't break qmail.

So Charles... do you support any systems with real live
users who get to choose their own MUA?

Because while your preferred option would work well in
Utopia, unfortunately I live in the real world and this
incompatibility between Outlook and qmail regularly costs
me real money.

...R.

[Charles Cazabon]

Post by Charles Cazabon
OE should be fixed. Don't break qmail.

So Charles... do you support any systems with real live users who get to
choose their own MUA?

Yes. But I make them live with the consequences of their decisions.

Because while your preferred option would work well in Utopia, unfortunately
I live in the real world and this incompatibility between Outlook and qmail
regularly costs me real money.

There are better solutions.

I regularly see administrators waste thousands of dollars of time and
equipment to "save a valuable customer" from which they might earn fifty bucks
a month.

If you have clients running known-broken software generating known-broken
messages, run ofmipd for them and fix the messages the right way. It's easier
than "fixing" qmail-smtpd, which isn't broken in the first place. But this
should only be a stopgap measure -- the evidence here is clear and
irrefutable; if someone paying for Windows "licenses" can't get Microsoft to
fix this bug given this evidence, what, exactly, is the point of purchasing
this commercial crapware in the first place?

Charles

[Jason Haar]

Post by Charles Cazabon
if someone paying for Windows "licenses" can't get Microsoft to
fix this bug given this evidence, what, exactly, is the point of purchasing
this commercial crapware in the first place?

..because Outlook Express *isn't* commercial software - it comes with
the OS and is explicitly not supported by Microsoft (same as IE).

Don't you love the user-base they have created over the years. They can
now say, "use our software, but we don't support it".

Say... sounds like Open Source ;-)

Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: [phone] Fax: [phone]
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

[James Craig Burley]

Post by Jason Haar
Don't you love the user-base they have created over the years. They can
now say, "use our software, but we don't support it".
Say... sounds like Open Source ;-)

Well, yeah, except for the part where they say "if you make a copy, or
change it, or reverse-engineer it, or benchmark and discuss its
performance with anyone else, we'll sue you and your little dog too".

Looking at it from MS' point of view, though: why should they "fix" OE
to work with other Internet software? It's the rest of the Internet
that's broken -- especially by using open standards and, in many case,
free or open-source sofware that implements them -- so they're just
making a reasonable effort to provide software that works in that
environment, an environment that is antagonistic towards seamless,
integrated solutions like those offered by MS.

Once MS gets everyone (or a sufficiently high % of everyone) to switch
over to the One True Microsoft Way of networking (whatever that is
these days -- .NET?), this whole vendor-interoperability fad, which is
only a recent phenomenon (starting sometime in the 1980s), will just
go away.

Then we can all stop spending so much time and energy discussing
interoperability, trying to design for it, worrying about the extent
to which we've achieved it, fretting over those who make components
that *mostly*, but don't entirely, "fit in" with how everyone else
does things, and so on.

(Again, that may be MS' point of view. It certainly isn't mine; in my
view, monoliths and monocultures don't scale up and survive well
enough to warrant any serious consideration as the basis for a
worldwide communications and computing infrastructure.)

[Scott Gifford]

Jason Haar <***@trimble.co.nz> writes:

[...]

They can now say, "use our software, but we don't support it".
Say... sounds like Open Source ;-)

Except that nobody will fix the bug...

---ScottG.

[Matthias Andree]

Post by Jason Haar

Post by Charles Cazabon
if someone paying for Windows "licenses" can't get Microsoft to
fix this bug given this evidence, what, exactly, is the point of purchasing
this commercial crapware in the first place?

..because Outlook Express *isn't* commercial software - it comes with
the OS and is explicitly not supported by Microsoft (same as IE).

Microsoft created the impression that IE was an intrinsic part of the
OS, did they exempt OE from that statement? Do they print "CONTAINS
BROKEN AND UNSUPPORTED SOFTWARE PACKAGES OUTLOOK EXPRESS" on their
boxes? Or does the US law protect gazillion-dollar craporations from
liabilities?

Post by Jason Haar
Don't you love the user-base they have created over the years. They can
now say, "use our software, but we don't support it".
Say... sounds like Open Source ;-)

If I made 100 ppm of Microsoft's wins, I'd probably also stop supporting
my software because spending all the money would be so much more fun.
:-P

SCNR.

[Carl Haddick]

Post by Charles Cazabon
should only be a stopgap measure -- the evidence here is clear and
irrefutable; if someone paying for Windows "licenses" can't get Microsoft to
fix this bug given this evidence, what, exactly, is the point of purchasing
this commercial crapware in the first place?
Charles

Please don't kill this thread, because every time a crapware user can't
download from a qmail-based system, qmail gets a black eye.

Please also keep CRLF in the subject line - it will help to keep track
in my flood of email.

However, I don't think the problem is CRLF related. I use maildirs, and
qmail-local seems to store only newlines, not crlf pairs, in maildirs.

Yesterday I had two subscribers that had trouble downloading email. The
first one cured her own problem (by deleting the message directly out of
her maildir) with a mailwasher-like facility we have. I got to see the
other email, which carried its body as a single line html file.

That line was about 10,700 characters long. As I understand, mail
messages are supposed to be constrained to 'relatively short' lines of
998 characters or less. However, it wasn't the length that was the
problem - after the closing </html> tag, there were approximately 1,000
space characters (0x20) and about 2,000 nulls. The nulls were the
killer, and the message downloaded fine after I truncated them off the
line.

Nulls, of course, are not acceptable in email, either the 7 bit or 8 bit
variety.

I have also occasionally seen email with the header line 'X-1: X-1:
X-1: X-1:...' out to around 500,000 characters, followed by the moronic
statement 'this message is not spam'. OE wouldn't download those,
either.

I don't care to chase phantoms, such as the 'x-1' lockup. It would be
nice, though, to include a .qmail filter that would limit the number of
MS OE problems. Dropping nulls would be a good idea, along with
anything else that causes common problems.

I don't use crapware. I don't like crapware. I like it even less when
crapware harms the acceptance of robust software.

It would be nice if an answer to this problem were found in the qmail
community. A google search for 'pop3 server has not responded' comes up
with a number of references, but no answers.

Trying to fit in with all the other lemmings,

Carl

[Juan Hernandez]

Post by Carl Haddick
I don't use crapware. I don't like crapware. I like it even less when
crapware harms the acceptance of robust software.

Wise words...

Juan

[Charles Cazabon]

Post by Carl Haddick

Post by Charles Cazabon
should only be a stopgap measure -- the evidence here is clear and
irrefutable; if someone paying for Windows "licenses" can't get Microsoft to
fix this bug given this evidence, what, exactly, is the point of purchasing
this commercial crapware in the first place?

Please don't kill this thread, because every time a crapware user can't
download from a qmail-based system, qmail gets a black eye.

I don't necessarily agree with your conclusion, but there's no such thing as
"killing a thread" here. If someone has something to contribute, they send a
message -- if no one contributes, the thread is still there in the archives
for all to see...

Post by Carl Haddick
Please also keep CRLF in the subject line - it will help to keep track
in my flood of email.

Consider using extension addresses and multiple maildirs to make this easier
for you; or you can use a filtering MDA at your end and have it sort messages
based on the Mailing-List: header field.

Post by Carl Haddick
However, I don't think the problem is CRLF related. I use maildirs, and
qmail-local seems to store only newlines, not crlf pairs, in maildirs.

qmail stores all messages using Unix line-end convention -- as do other Unix
MTAs. Doesn't matter whether you're storing your messages in Maildir, mbox,
or feeding them to a qmail-command program.

Post by Carl Haddick
Yesterday I had two subscribers that had trouble downloading email. [snip
first]
other email, which carried its body as a single line html file.
That line was about 10,700 characters long. As I understand, mail
messages are supposed to be constrained to 'relatively short' lines of
998 characters or less. However, it wasn't the length that was the
problem - after the closing </html> tag, there were approximately 1,000
space characters (0x20) and about 2,000 nulls. The nulls were the
killer, and the message downloaded fine after I truncated them off the
line.
Nulls, of course, are not acceptable in email, either the 7 bit or 8 bit
variety.

Can you provide a reference for this, please? RFC2821 says otherwise.

Post by Carl Haddick
X-1: X-1:...' out to around 500,000 characters, followed by the moronic
statement 'this message is not spam'. OE wouldn't download those,
either.

That's an OE-specific problem.

Post by Carl Haddick
I don't care to chase phantoms, such as the 'x-1' lockup. It would be
nice, though, to include a .qmail filter that would limit the number of
MS OE problems. Dropping nulls would be a good idea, along with
anything else that causes common problems.

You're talking about silently corrupting messages to placate one buggy MUA.
That's not a good idea for interoperability. If OE gives you such problems,
why not simply stop using and supporting it? Switch to just about any other
MUA and you won't have these problems.

Charles

[Carl Haddick]

[snip]

Post by Charles Cazabon

Post by Carl Haddick
Please don't kill this thread, because every time a crapware user can't
download from a qmail-based system, qmail gets a black eye.

I don't necessarily agree with your conclusion, but there's no such thing as
"killing a thread" here. If someone has something to contribute, they send a
message -- if no one contributes, the thread is still there in the archives
for all to see...

Apologies - it's just that I believe this off-topic discussion could
lead to greater acceptance of qmail.

[snip]

Post by Charles Cazabon

Post by Carl Haddick
Nulls, of course, are not acceptable in email, either the 7 bit or 8 bit
variety.

Can you provide a reference for this, please? RFC2821 says otherwise.

You may be right. I have not read all the RFCs or kept up with which
ones supercede. However, RFC 2045 (Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies ) states:

"7bit data" refers to data that is all represented as relatively short
lines with 998 octets or less between CRLF line separation sequences
[RFC-821std10(-> 2821prop)]. No octets with decimal values greater than
127 are allowed and neither are NULs (octets with decimal value 0). CR
(decimal value 13) and LF (decimal value 10) octets only occur as part
of CRLF line separation sequences.

Further, from RFC 2045:

"8bit data" refers to data that is all represented as relatively short
lines with 998 octets or less between CRLF line separation sequences
[RFC-821std10(-> 2821prop)]), but octets with decimal values greater
than 127 may be used. As with "7bit data" CR and LF octets only occur
as part of CRLF line separation sequences and no NULs are allowed.

The third data type, binary, allows all values and I believe CRLF has
no special meaning, nor is there a requirement for pairing of CR and
LF - and this kind of data isn't going to work, unencoded, in mail.

RFC 2821 says that line limits may be imposed by servers, and I don't
think there is any prohibition of nuls ('The transmission of NULs
(US-ASCII value 0) is problematic in Internet mail').

However, RFC 2821 is about SMTP, not about MIME encoding.

Post by Charles Cazabon

Post by Carl Haddick
X-1: X-1:...' out to around 500,000 characters, followed by the moronic
statement 'this message is not spam'. OE wouldn't download those,
either.

That's an OE-specific problem.

Yes. Agreed.

Post by Charles Cazabon

Post by Carl Haddick
I don't care to chase phantoms, such as the 'x-1' lockup. It would be
nice, though, to include a .qmail filter that would limit the number of
MS OE problems. Dropping nulls would be a good idea, along with
anything else that causes common problems.

You're talking about silently corrupting messages to placate one buggy MUA.
That's not a good idea for interoperability. If OE gives you such problems,
why not simply stop using and supporting it? Switch to just about any other
MUA and you won't have these problems.

Again, agreed. I have already solved this problem for myself - I don't
run any MS software. However, members of the unwashed masses may clamor
for the replacement of qmail if OE won't download email from it. Most
of those will be happier if they experience the same problems (and,
likely, many more) in a pure Microsoft environment. Time is short,
my ability to educate is limited, and I would like to avoid
undocumented, unmaintainable mail systems - qmail works well for me.

Forgive me, but if I can transparently 'corrupt' certain messages to
accomodate a large, uneducated majority of email users, I'm ready to dig
in. I just don't want to violate standards in the process, or further
corrupt the world at large.

By the way, feel free to rip my arguments to shreds. I appreciate
criticism, particularly from someone with credentials and experience.

Regards,

Carl

Post by Charles Cazabon
Charles
--
---------------------------------------------------------------------------
GPL'ed software available at: http://www.qcc.ca/~charlesc/software/
Read http://www.qcc.ca/~charlesc/writings/12-steps-to-qmail-list-bliss.html
---------------------------------------------------------------------------

[Chris Wilkes]

Post by Carl Haddick
Again, agreed. I have already solved this problem for myself - I don't
run any MS software. However, members of the unwashed masses may clamor
for the replacement of qmail if OE won't download email from it. Most
of those will be happier if they experience the same problems (and,
likely, many more) in a pure Microsoft environment. Time is short,
my ability to educate is limited, and I would like to avoid
undocumented, unmaintainable mail systems - qmail works well for me.

Does Exchange "fix" these emails for use by OE clients?

Chris

[Ken Meyer]

Post by Charles Cazabon
You're talking about silently corrupting messages to placate one buggy MUA.
That's not a good idea for interoperability. If OE gives you such problems,
why not simply stop using and supporting it? Switch to just about any other
MUA and you won't have these problems.
Charles

This sounds great in theory. In the real world, however, OE is the defacto standard. While I can fully understand not trying to support every MUA out there, OE needs to be supported. I say this even though I, personally, detest OE. Fact is, most of my users use it. It doesn't help to go around saying, "We support the standard, you don't" when it costs customers. It doesn't help to say, "Your program is non-compliant" when their program is the most widely used, approaching a monopoly status. The typical user would be saying, "what standard?" To them, OE is the standard. Even if they are wrong, that won't be much solace when you lose their business.

Ken

[gary]

Post by Ken Meyer

Post by Charles Cazabon
You're talking about silently corrupting messages to placate one buggy
MUA. That's not a good idea for interoperability. If OE gives you
such problems, why not simply stop using and supporting it? Switch to
just about any other MUA and you won't have these problems.

This sounds great in theory. In the real world, however, OE is the defacto
standard. While I can fully understand not trying to support every MUA out
there, OE needs to be supported.

<snip>

Why support OE when M$ is not even supporting it... their future
development on it has stopped.. they announced it awhile back. My user
experience is different from yours... i.e. OE is not the most widely used.

[Ken Meyer]

Post by Carl Haddick

Post by Ken Meyer

Post by Charles Cazabon
You're talking about silently corrupting messages to placate one buggy
MUA. That's not a good idea for interoperability. If OE gives you
such problems, why not simply stop using and supporting it? Switch to
just about any other MUA and you won't have these problems.

This sounds great in theory. In the real world, however, OE is the defacto
standard. While I can fully understand not trying to support every MUA out
there, OE needs to be supported.

<snip>
Why support OE when M$ is not even supporting it... their future
development on it has stopped.. they announced it awhile back. My user
experience is different from yours... i.e. OE is not the most widely used.

What do you find is the most widely used, and what environment are you
working in? Among Windows users, I only know of one person who uses
anything other than OE - and I know a lot of Windows users.

Among non-windows users, OE is rare; but these are people who are
looking for a Microsoft Free computer, generally; they predominately use
Linux or Apple, generally with Mozilla or Evolution with Linux, or
Apple's standard MUA.

Ken

[gary]

Post by Ken Meyer

Post by Carl Haddick

Post by Ken Meyer

Post by Charles Cazabon
You're talking about silently corrupting messages to placate one buggy
MUA. That's not a good idea for interoperability. If OE gives you
such problems, why not simply stop using and supporting it? Switch to
just about any other MUA and you won't have these problems.

This sounds great in theory. In the real world, however, OE is the
defacto standard. While I can fully understand not trying to support
every MUA out there, OE needs to be supported.

<snip>
Why support OE when M$ is not even supporting it... their future
development on it has stopped.. they announced it awhile back. My user
experience is different from yours... i.e. OE is not the most widely used.

What do you find is the most widely used, and what environment are you
working in?

I do work (service) in Linux, Unix, and Windows (XP, W2K, W98)
environments.

Post by Ken Meyer
Among Windows users, I only know of one person who uses
anything other than OE - and I know a lot of Windows users.

Of those offices I support, and of those who use Windows network
environments/desktops, my experience has been that Outlook is used more
than any other, almost 2 to 1, Some professional offices use Outlook
exclusively. Eudora and The Bat are also popular, as well as Becky.

Post by Ken Meyer
Among non-windows users, OE is rare; but these are people who are
looking for a Microsoft Free computer, generally;

It is hard to use OE in a non-windows environment <g> I am relating my
MUA Windows observations, based not on individuals, or from an ISP
standpoint, but rather from professional office environments..

Post by Ken Meyer
they predominately use Linux or Apple, generally with Mozilla or
Evolution with Linux, or Apple's standard MUA.

agreed... Kmail is also popular.. Most like GUI MUAs. Personally, nothing
beats the functionality of Mutt, but that's another story <g> .

[Richard Letts]

Post by gary

Post by Ken Meyer

Post by gary
Why support OE when M$ is not even supporting it... their future
development on it has stopped.. they announced it awhile back. My user
experience is different from yours... i.e. OE is not the most widely used.

What do you find is the most widely used, and what environment are you
working in?

I do work (service) in Linux, Unix, and Windows (XP, W2K, W98)
environments.

Post by Ken Meyer
Among Windows users, I only know of one person who uses
anything other than OE - and I know a lot of Windows users.

Of those offices I support, and of those who use Windows network
environments/desktops, my experience has been that Outlook is used more
than any other, almost 2 to 1, Some professional offices use Outlook
exclusively. Eudora and The Bat are also popular, as well as Becky.

Outlook Express != Outlook. One is 'free' [excluding support costs] the
other comes with Office.

My wife uses Outlook on her machines, mostly because that is what she uses
at work. (qmail+spamassassin files possible spam in a folder on courier
IMAP for her and she is very happy.)

At work the supported MUA is (licensed) Eudora (with its own builtin spam
scoring); some people use netscape or outlook, but they are on their own
and if you get virused then it was your own stupid fault.

Pegasus mail for windows would have been my other choice for a MUA -- I
quite liked it and it uses mbox format files to store its mail in, so I
could share [mail]folders between pine and my desktop.

/RjL

[Richard Lyons]

Post by Ken Meyer
This sounds great in theory. In the real world, however, OE is the
defacto standard. While I can fully understand not trying to support
every MUA out there, OE needs to be supported.

OE is supported. Depending on your metric, qmail is the second
or third most used mail server on the planet. If there were
serious interoperability issues, they would have been discovered
long ago, and perhaps even fixed. The sporadic reporting of issues
in this respect either means that the bug is hard to trigger and
unlikely to affect the bulk of users before they are forced to
upgrade their MUA, or it's a local problem. Sucks to be the
person with the local problem, but without adequate diagnosis,
there's not much anybody else can do.

Rick.

[Jonathan de Boyne Pollard]

KM> In the real world, however, OE is the defacto standard.

False.

Moreover, in my experience, Outlook is far more preferred (by both individuals
and organisations) than Outlook Express.

[Ken Meyer]

Post by Jonathan de Boyne Pollard
KM> In the real world, however, OE is the defacto standard.
False.
Moreover, in my experience, Outlook is far more preferred (by both individuals
and organisations) than Outlook Express.

To be honest, I didn't realize there was a difference. Shows how long I
have been out of the MS world. ;^)

I hereby officially retract my statement.

Ken

[Richard Lyons]

Post by Carl Haddick
However, I don't think the problem is CRLF related.

Agreed. I was unable to duplicate Joseph's problem with
OE5 or OE6 using the supplied messages.

Post by Carl Haddick
That line was about 10,700 characters long.

I've seen this before, with Mdaemon. The customer used us
as store and forward; when their mail server got a single
line of more than 8K it would overflow a buffer and crash,
with the result that qmail would keep retrying until it
bounced the message.

Rick.

[Jonathan de Boyne Pollard]

RA> unfortunately I live in the real world

If the following is truly your analysis of the situation, you do not. Your
analysis does not match the real world.

RA> this incompatibility between Outlook and qmail

This is not an incompatibility between Outlook (or Outlook Express, with which
you are confusing it) and "qmail" at all. It is an incompatibility between
Outlook Express and the MUA that originally generated the message. As
demonstrated with examples only two messages ago in this very thread, the
message data that Outlook Express sees are the same message data that the SMTP
Relay client sent to "qmail"'s SMTP Relay server in the first place, which are
presumably the message data that the originating MUA actually created.
"qmail" is transparent, inasmuch as the same message data (plus some trace
headers) come out of its POP3 server as went in to its SMTP Relay server, and
is thus irrelevant to the problem.

RA> regularly costs me real money.

Then complain to the authors of either or both of the _actual_ softwares that
are incompatible with each other here. Complain to Microsoft about its MUA
and ask for your money back, for example. Find out what the MUA at the other
end is, and complain to the company that it was bought from and ask for money
back from it, too.

[Richard Archer]

Post by Jonathan de Boyne Pollard
RA> unfortunately I live in the real world
If the following is truly your analysis of the situation, you do not. Your
analysis does not match the real world.

Trust you to resurrect another dead thread. Don't you have anything better
to do than trawl through the list archives trying to stir up trouble from
weeks-old threads?

As for your inciteful comments, I can envisage three possible solutions
to this problem:

1. Patch or wrap qmail so these screwy messages are fixed on the fly.

2. Switch to another MTA which fixes these screwy messages.

3. Have every single person in the world use a Jonathan de Boyne
Pollard and Charles Cazabon approved MUA.

You might like to push for option 3 (who knows, maybe you can charge
royalties??). I know a couple of sysadmins who went with option 2 years
back and I'm starting to wish I'd done the same.

...R.

[Jeremy Kitchen]

On Wed, 2003-12-10 at 00:18, Richard Archer wrote:
[snip whining]

Post by Richard Archer
As for your inciteful comments, I can envisage three possible solutions
1. Patch or wrap qmail so these screwy messages are fixed on the fly.
2. Switch to another MTA which fixes these screwy messages.
3. Have every single person in the world use a Jonathan de Boyne
Pollard and Charles Cazabon approved MUA.
You might like to push for option 3 (who knows, maybe you can charge
royalties??). I know a couple of sysadmins who went with option 2 years
back and I'm starting to wish I'd done the same.

You simply cannot blame qmail for this problem.

Whine all you want, but you discrediting qmail because it doesn't `fix'
this MUA brokenness is ignorant.

-Jeremy
--
Jeremy Kitchen
Systems Administrator
***@inter7.com
Kitchen @ #qmail on EFNet - Join the party!
.....................
Inter7 Internet Technologies, Inc.
www.inter7.com
866.528.3530 toll free
847.492.0470 int'l
847.492.0632 fax
GNUPG key ID: 93BDD6CE

[Busynet]

Post by Jeremy Kitchen
Whine all you want, but you discrediting qmail because it doesn't `fix'
this MUA brokenness is ignorant.

Nobody is discrediting QMail, they're just sick of the narrow mindedness
that permeates this list.

What's ignorant is preaching that the entire world should immediately fix
every broken piece of Microsoft garbage on their computer, since the
standards are cast in stone. The only thing greater than the rudeness
level on this non-support list is the arrogance. You morons think that
demanding MS, and everyone else, fix the crap they sell is going to
accomplish one goddamned thing? Does the term piss up a rope mean
anything to you.

If you had any REAL experience in the REAL world dealing with broken
fill-in-the-blank applications, you'd know that it's not about fixing
anything.
The only way to survive in the MS world is to find a way AROUND the
problem, whatever it may be. Anyone who thinks they're going to persuade
Bill Gates and his band of crayola wielding GUI gamers, I mean 'programmers'
to repair the miserable sewage they peddle to unsuspecting beta testers is
utterly delusional.

To the person or persons who contributed the CRLF patch, thank you. God
forbid anyone should admit that you found a problem, regardless of where the
blame lies, and fixed it. Good job. Qmail et al may be right, but that
doesn't
mean squat to the dozen or so customers that call me every month wanting to
know yet again why their email is frozen. Obviously, as a little guy ISP, I
should
tell them to contact Bill Gates directly, since it's his problem. I'll be
out of
business of course, as they'll all dump me in a heartbeat, but at least I'll
have the
satisfaction of knowing that QMail is right, and maybe the geniuses on this
list will
even give me a pat on the back for sticking to their principles. Here's
another cliche
for ya...heads stuck in the sand.

later,
Bob

[Dave Sill]

I can't resist...

Post by Busynet
What's ignorant is preaching that the entire world should immediately fix
every broken piece of Microsoft garbage on their computer, since the
standards are cast in stone. The only thing greater than the rudeness
level on this non-support list is the arrogance. You morons think that
demanding MS, and everyone else, fix the crap they sell is going to
accomplish one goddamned thing? Does the term piss up a rope mean
anything to you.

Is it better to accomodate broken software or to encourage people to
use better software? Why should we all bend over and take it from MS,
even if resistance is futile? Should rape victims ``just relax and try
to enjoy it''?

Post by Busynet
If you had any REAL experience in the REAL world dealing with broken
fill-in-the-blank applications, you'd know that it's not about fixing
anything.
The only way to survive in the MS world is to find a way AROUND the
problem, whatever it may be.

One way around the MS problem is to refuse to accommodate their
junk. If you're in a position to do that, why not do it? If you're not
in a position to do that, why complain to those who are?

Post by Busynet
Anyone who thinks they're going to persuade Bill Gates and his band
of crayola wielding GUI gamers, I mean 'programmers' to repair the
miserable sewage they peddle to unsuspecting beta testers is utterly
delusional.

I don't refuse to apply MS-specific workarounds in an futile attempt
to get MS to fix their bugs, I do it to (1) keep my working software
working, and (2) encourage people to switch away from broken MS
apps. Whether or not MS ever wakes up and smells the coffee is
unimportant. They dominate today, but their days are clearly
numbered.

Post by Busynet
To the person or persons who contributed the CRLF patch, thank you.
God forbid anyone should admit that you found a problem, regardless
of where the blame lies, and fixed it. Good job.

Yeah, let's just install a zillion patches to work around a zillion
bugs in everyone else's apps. That'll surely result in a reliable
infrastructure.

Post by Busynet
Qmail et al may be right, but that doesn't mean squat to the dozen or
so customers that call me every month wanting to know yet again why
their email is frozen. Obviously, as a little guy ISP, I should tell
them to contact Bill Gates directly, since it's his problem. I'll be
out of business of course, as they'll all dump me in a heartbeat, but
at least I'll have the satisfaction of knowing that QMail is right,
and maybe the geniuses on this list will even give me a pat on the
back for sticking to their principles. Here's another cliche for
ya...heads stuck in the sand.

Yeah, you're right, it's much better to do whatever it takes to
silently "make things work" than to explain that user should switch to
a less buggy app. So what if your users never find out how buggy their
apps are? So what if they don't realize how much work their buggy apps
make for you, and how much that raises your fees? Let them think MS
apps are golden and ISPs are a dime a dozen. See how quickly they drop
you for an ISP that's $2/mo cheaper.

-Dave

[Carl Haddick]

Post by Busynet
What's ignorant is preaching that the entire world should immediately fix
every broken piece of Microsoft garbage on their computer, since the
standards are cast in stone. The only thing greater than the rudeness
level on this non-support list is the arrogance. You morons think that
demanding MS, and everyone else, fix the crap they sell is going to
accomplish one goddamned thing? Does the term piss up a rope mean
anything to you.

Thank you so much for your insight, but I'm not getting a clear picture
of this 'piss up a rope' business.

Please accept my apologies if this is in the archives - I looked, but
just couldn't find it. A Google search for 'piss up a rope' uncovered
examples of usage, but did not yield complete documentation or history
of the practice.

I'm very interested, though, because this is the second time I've been
told to piss up a rope.

I remember the first instance as if it were yesterday. I was 19, and my
1967 Ford pickup had blown a head gasket just outside of some forsaken
place in Oklahoma. A nice, but apparently very busy man named Bubba
told me to piss up a rope when I asked to use the telephone in the
double-wide trailer from which he and his sister, Cousin Tiny, sold
cigarettes at a really wonderful discount.

Of course, Cousin Tiny was anything but petite, and local rumor held
that she was either Bubba's aunt by marriage or his niece, depending on
where you started following their family tree. I'm sure they would have
had time to be more detailed in their suggestions if I had caught them
at a more opportune moment. Running a business like that probably has
its share of stress.

Thank you once again for the time you took forming your reply, and
setting aside your priorties to illuminate the problems we've been
discussing here.

Have a very nice day,

Carl

[Mat Kovach]

Post by Busynet

Post by Jeremy Kitchen
Whine all you want, but you discrediting qmail because it doesn't `fix'
this MUA brokenness is ignorant.

Nobody is discrediting QMail, they're just sick of the narrow mindedness
that permeates this list.

Educating your users and customers is short sighted? Interesting.

Post by Busynet
What's ignorant is preaching that the entire world should immediately fix
every broken piece of Microsoft garbage on their computer, since the
standards are cast in stone. The only thing greater than the rudeness
level on this non-support list is the arrogance. You morons think that
demanding MS, and everyone else, fix the crap they sell is going to
accomplish one goddamned thing? Does the term piss up a rope mean
anything to you.

Does it to you? Patching software over and over again to accomodate
people that choose to disgard the standards leads to buggy software.
If you modify a square hole to accept a round peg you then break it
for people that have a square peg (or have a very good chance at
doing so).

Post by Busynet
If you had any REAL experience in the REAL world dealing with broken
fill-in-the-blank applications, you'd know that it's not about fixing
anything.

I have explained to many of my customers that using a Microsoft MUA
can lean to many problems, including virus attacks, incompatibility,
and keeping Outlook patched. I provide them with many reliable and
less buggy alternatives and have never lost a customer due to the
conversation. A few have huffed a bit but the majority of the time
the customer is happy as the problem has been solved.

Post by Busynet
The only way to survive in the MS world is to find a way AROUND the
problem, whatever it may be. Anyone who thinks they're going to persuade
Bill Gates and his band of crayola wielding GUI gamers, I mean 'programmers'
to repair the miserable sewage they peddle to unsuspecting beta testers is
utterly delusional.

I'm sure many of the programming would be happy for Microsoft to
provide them the means to fix their software. There are several ways
around the problem, you simply desire to get the round peg in the
square hole.

Post by Busynet
To the person or persons who contributed the CRLF patch, thank you. God
forbid anyone should admit that you found a problem, regardless of where the
blame lies, and fixed it. Good job. Qmail et al may be right, but that
doesn't mean squat to the dozen or so customers that call me every
month wanting to know yet again why their email is frozen.

And you haven't taken the time to explain to your customer what the
problem is an provide them with alternatives to fix the problem?

Post by Busynet
Obviously, as a little guy ISP, I should tell them to contact Bill
Gates directly, since it's his problem. I'll be out of business of
course, as they'll all dump me in a heartbeat, but at least I'll
have the satisfaction of knowing that QMail is right, and maybe the
geniuses on this list will even give me a pat on the back for
sticking to their principles. Here's another cliche for ya...heads
stuck in the sand.

You should take the time to provide support for you customers. There
are many ``work arounds'' that you simply don't wish to provide to
your customers. Maybe you should consider the way you provide support
before you discuss how people on this list provide support.

Just my thoughts,

Mat

[Network Administration]

There have been a lot of comments on this. Let me address them.

1: Ok, so the offending senders are violating RFC (Thanks, Charles...
RFC2821, section 2.3.7). Therefore, further discussions of whether OE is to
blame are not necessary. We need to reject these "illegal" messages so that
the bad boys are forced to clean their SMTP clients.

2: It doesn't matter, but I'm guessing that this "bug" may spring from an
odd quirk resulting from Cygwin dos/unix conversions:
http://www.google.com/search?q=cygwin+%5Cr%5Cr%5Cn&btnG=Google+Search&hl=en&ie=ISO-8859-1


3:The best solution seems to 550 reject the message as being invalid. Most
of these "problem" messages are spam, anyway.
The question is how to detect that a message is bad. No, we can't scan
for the appearance of /r/r/n (such as > | tr -d '\015' | safecat Maildir/tmp
Maildir/new), because binary email attachments may legally contain that
code. I plan instead on analyzing the Subject: and other headers and seeing
how they are terminated. If they are terminated with /r/r/n, I'll just give
a nasty message to the sender and drop (log) the message. Expect a solution
in the next week or two.

4: Someone was wondering what versions of OE are hanging:
- I have a customer with 6.00.2800.1123 on Windows (98?) that is
hanging on /r/r/n messages.
- My Windows 2000 workstation uses the exact same OE version
(6.00.2800.1123) and does NOT hang, even when known-bad messages are fed to
it. It DOES misinterpret the end-of-headers, however: the Subject: line and
other headers may appear in the body.
- I have another customer using an earlier (I think) version of 6.00 on
Windows 2000, and he IS experiencing the problem.

5: The problem (the one I'm dealing with, I'm not precluding others) has
nothing to do with long messages.

6: Almost all of us di$like Micro$oft to some extent. I am forced to deal
with OE whether I like it or not, however. Therefore, I'm choosing to
reject illegal SMTP and leave it at that for the moment. As I said, expect
a fix of some sort (to be implemented from .qmail delivery files) in the
next two weeks.


c0d3runn3r

[Carl Haddick]

Post by Network Administration
There have been a lot of comments on this. Let me address them.
1: Ok, so the offending senders are violating RFC (Thanks, Charles...
RFC2821, section 2.3.7). Therefore, further discussions of whether OE is to
blame are not necessary. We need to reject these "illegal" messages so that
the bad boys are forced to clean their SMTP clients.
2: It doesn't matter, but I'm guessing that this "bug" may spring from an
http://www.google.com/search?q=cygwin+%5Cr%5Cr%5Cn&btnG=Google+Search&hl=en&ie=ISO-8859-1

I may be experiencing different problems than some of you, but I do not
believe the problem could possibly be with \r\r\n sequences in the SMTP
dialog.

That's because the line endings in the user's queue are all plain
newlines, and that's what's being converted and delivered via
qmail-pop3d.

There is a precedent for mutating messages on the server - in CHANGES in
qmail-1.03, 'qmail-pop3d now appends an extra blank line to every
message, for compatibility with popper. some clients can't deal with the
right thing, unfortunately. tnx FPL.'

When we migrated to qmail, the incidence of 'pop3 server has not
responded' complaints dropped. In fact, we went for at least a week
without seeing any of them, and I thought at the time the extra blank
line had fixed the problem.

I have seen the 'pop3 server has not responded' error with both Outlook
and Outlook Express for _years_ including those dark and uninspired
years during which I ran sendmail. I have seen the problem with
Netscape 3, but not later versions.

It is not a problem with server response. Telnetting to 110 will always
'retr' the messages far faster than OE or Outlook.

I get a separate email notification on each virused email message
quarantined, as well as the usual qmail administrative messages. After
a long weekend, that can be 85,000 messages. I usually categorize and
weed them on the server before downloading, but fetchmail will always,
without fail, download massive mail loads. Outlook/Outlook Express will
not - and we can't count on Microsoft to fix the problem.

I have a friend who runs some kind of MS IIS server. He has the same
problems at the same frequency I have. It is a client-side problem,
that I think may be related to a MIME issue.

In the past (it's gone now), there was a Microsoft Knowledge Base entry
that said that the problem could happen with any message that exceeded
12K, counting both body and headers, but was more common with longer
messages. I once found an MSN FAQ that addressed the problem,
suggesting MSN customers should set an inbox rule to delete without
downloading any message longer than 1 meg.

This MS knowledge base entry documents a problem with OE for Solaris:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q186272

Virgin.net says the problem happens if a message is too long, or has
been corrupted in transit (mail.virgin.net identifies itself as an
InterMail pop3 server):

http://www.virgin.net/customers/helpme/email/outlook4/18.html

At mcmsys.com, the problem must happen often enough for it to be a
standard gripe on their tech support web form:

http://www.mcmsys.com/ohr.html

So, anyway, I guess that's about all I have to contribute at this
point. I would like to write a script that will scan email and fix
whatever Outlook/Outlook Express doesn't like, but I'm not sure exactly
what to scan for.

Regards, all, and thanks for all your input,

Carl

Post by Network Administration
3:The best solution seems to 550 reject the message as being invalid. Most
of these "problem" messages are spam, anyway.
The question is how to detect that a message is bad. No, we can't scan
for the appearance of /r/r/n (such as > | tr -d '\015' | safecat Maildir/tmp
Maildir/new), because binary email attachments may legally contain that
code. I plan instead on analyzing the Subject: and other headers and seeing
how they are terminated. If they are terminated with /r/r/n, I'll just give
a nasty message to the sender and drop (log) the message. Expect a solution
in the next week or two.
- I have a customer with 6.00.2800.1123 on Windows (98?) that is
hanging on /r/r/n messages.
- My Windows 2000 workstation uses the exact same OE version
(6.00.2800.1123) and does NOT hang, even when known-bad messages are fed to
it. It DOES misinterpret the end-of-headers, however: the Subject: line and
other headers may appear in the body.
- I have another customer using an earlier (I think) version of 6.00 on
Windows 2000, and he IS experiencing the problem.
5: The problem (the one I'm dealing with, I'm not precluding others) has
nothing to do with long messages.
6: Almost all of us di$like Micro$oft to some extent. I am forced to deal
with OE whether I like it or not, however. Therefore, I'm choosing to
reject illegal SMTP and leave it at that for the moment. As I said, expect
a fix of some sort (to be implemented from .qmail delivery files) in the
next two weeks.
c0d3runn3r

[Network Administration]

OK, rant and scream. I just hacked qmail-smtpd to reject illegal
unaccompanied carriage returns. Specifically, the sending of a message
containing 0D0D is rejcted with an error.

I compiled qmail-smtpd with the new code and it seems to be doing it's
job. If after looking at the patch, more experienced individuals have
concerns, let me know. I'm using the new code as of yesterday AM without
problems.

Below follows the patch for qmail-smtpd 1.03

Joseph

---- cut below this line ----

51c51
<
---

void err_crcr() { out("451 Your SMTP client is badly tweaked. Your

message contains an illegal CRCR sequence (instead of a legal CRLF).\r\n");
flush(); _exit(1); }
348c348,350
< if (ch != '\r') { put("\r"); state = 0; }
---

if (ch == '\r') err_crcr();
put ("\r");
state = 0;

[Network Administration]

There has been NO comment on this since I sent it out. Has anyone else
besides myself tried the patch? Do you like it? It's working beautifully
over here...

Joseph



----- Original Message -----
From: "Network Administration" <***@alyrica.net>
To: <***@list.cr.yp.to>
Sent: Friday, December 05, 2003 9:25 AM
Subject: The patch: Bizarre CRLF killing Outlook Express

Post by Network Administration
OK, rant and scream. I just hacked qmail-smtpd to reject illegal
unaccompanied carriage returns. Specifically, the sending of a message
containing 0D0D is rejcted with an error.
I compiled qmail-smtpd with the new code and it seems to be doing it's
job. If after looking at the patch, more experienced individuals have
concerns, let me know. I'm using the new code as of yesterday AM without
problems.
Below follows the patch for qmail-smtpd 1.03
Joseph
---- cut below this line ----
51c51
<
---

void err_crcr() { out("451 Your SMTP client is badly tweaked. Your

message contains an illegal CRCR sequence (instead of a legal

CRLF).\r\n");

Post by Network Administration
flush(); _exit(1); }
348c348,350
< if (ch != '\r') { put("\r"); state = 0; }
---

if (ch == '\r') err_crcr();
put ("\r");
state = 0;

[Richard Lyons]

Post by Network Administration
There has been NO comment on this since I sent it out. Has anyone else
besides myself tried the patch? Do you like it? It's working beautifully
over here...

For servers with a reasonable amount of traffic, the collateral
damage may be too high. RFC or not, we receive mail with multiple
consecutive CRs in the message body, typically HTML, PDF and RTF
documents.

Rick.

[Matthias Andree]

Post by Network Administration
I suspect that the mail agents generating these messages are leading
the headers with a \r\n\r\n, but I have been unable to prove it. In
any case, I'm left wondering if anyone else is having similar
problems. This problem is rare, and even when it occurs it only
hangs some versions of OE. Any suggestions?

Identify the senders of these broken \r\r\n mails and have them fix
their software. Optionally and more aggressively, you can try to use one
of the qmail filters that wrap around or replace qmail-queue to refuse
mail with bare \r (that's \r not followed by \n) and have the sender
deal with the issue.

[Richard Lyons]

Post by Network Administration
When the MTA went to download these messages, the \r\n was replaced
with \r\r\n (part of the normal Unix -> PC conversion process, but in
this case run amok due to the extra \r). When OE sees \r\r\n, it
thinks "End of headers" and puts everything following into the message
body.

I don't see how this is causing your timeout errors. I do recall
a bug from several years ago where OE would miss the POP3 message
terminator if the ".CRLF" from "CRLF.CRLF" was sent in a separate
packet. A quick poke around the net didn't lead me to that bug
report, but I did stumble across this:

http://support.microsoft.com/?kbid=813518

As an outside chance, you might also consider the MTU of your
customers connections.

Do you know which agents are adding the CR to the headers?

Rick.

[Carl Haddick]

Post by Richard Lyons
http://support.microsoft.com/?kbid=813518
As an outside chance, you might also consider the MTU of your
customers connections.

I'm pretty sure this can be ruled out, and I'm pretty sure the situation
has nothing to do with an actual timeout. Outlook Express expects a
message to continue when there is no more message. The pop3 server
waits patiently. Meanwhile, OE whines that the pop3 server has not
responded.

I have seen this personally with ipop3d (a couple of versions) and
qmail-pop3d. From the FAQs I see around the net, I suspect it happens
with every server on the net.

I acknowledge this is off-topic for qmail, because the problem lies with
Outlook Express. However, this will give a qmail installation a black
eye, and for that reason I would really like to know why this happens.

Many ISPs just document that a mail block can occur when a message is
too big. In six years of using fetchmail and other Linux hosted mail
retrieval methods I have never even once seen this problem outside of
early Netscape (under Windows) and MS OE mail clients.

I get a notification from qmail-scanner on every virus detected. On a
heavy day, I get 30,000 messages. Usually I get a count of how many
virus warnings are in my queue, which I then just 'rm' out of my maildir
before downloading. However, if I choose to download 30K messages, they
will always, without exception, zip right down to my box - which I keep
clean of Microsoft products.

Anyway, apologies for the off-topic nature of this discussion, but I
would like to be able to defend my decision to use qmail.

Regards, all,

Carl

[Network Administration]

No, you don't. Binary messages are sent through use of the BDAT command.,
not SMTP DATA. My patch only affects the use of multiple CRs in messages,
_not_ binary attachments.

Hence binary attachments containing the CRCR sequence do not pose a
problem.

Joseph

Post by Richard Lyons
For servers with a reasonable amount of traffic, the collateral
damage may be too high. RFC or not, we receive mail with multiple
consecutive CRs in the message body, typically HTML, PDF and RTF
documents.
Rick.

[Charles Cazabon]

Network Administration <***@alyrica.net> wrote:
[snip]
Your message was top-posted and therefore unreadable. Please configure your
MUA to quote correctly before sending messages to mailing lists.
I've corrected your quoting for this reply, but will ignore further top-posted
messages.

If you are using and must continue to use an MS MUA (Outhouse or Outhouse
Express), these free add-on packages can apparently fix them for you:
http://home.in.tum.de/~jain/software/oe-quotefix/
http://home.in.tum.de/~jain/software/outlook-quotefix/

Post by Network Administration

For servers with a reasonable amount of traffic, the collateral damage may
be too high. RFC or not, we receive mail with multiple consecutive CRs in
the message body, typically HTML, PDF and RTF documents.

No, you don't. Binary messages are sent through use of the BDAT command.,
not SMTP DATA. My patch only affects the use of multiple CRs in messages,
_not_ binary attachments.

There /is/ no "BDAT" command in SMTP, and there is no distinction between
"binary attachment" and "message". To SMTP, there are two parts to a message,
the envelope (sent with the MAIL FROM: and RCPT TO: commands), and the message
body or content (i.e. everything else), sent with the DATA command.

Post by Network Administration
Hence binary attachments containing the CRCR sequence do not pose a
problem.

An "attachment" is just part of the message body as far as an MTA is
concerned. Hint: read about the brutal stupidity of "8BITMIME" and the
sensible alternative known as "just send 8".

Charles

[Robert James Kaes]

Post by Charles Cazabon
An "attachment" is just part of the message body as far as an MTA is
concerned. Hint: read about the brutal stupidity of "8BITMIME" and the
sensible alternative known as "just send 8".

Charles, do you have any quick links for information about those two
topics. I did a bit of a search on Google, but got lost in the sea of
pages.

Thank you for your time.
-- Robert

[Charles Cazabon]

Post by Robert James Kaes

Post by Charles Cazabon
An "attachment" is just part of the message body as far as an MTA is
concerned. Hint: read about the brutal stupidity of "8BITMIME" and the
sensible alternative known as "just send 8".

Charles, do you have any quick links for information about those two
topics. I did a bit of a search on Google, but got lost in the sea of
pages.

One set of thoughts on the horrors of 8BITMIME:
http://www.zmailer.org/mhalist/1995/msg00210.html

You can look at other sources, like DRUMS list archives, if you can find them
-- but the basic problem of 8BITMIME is that it means MTAs have to parse and
possibly re-encode every message they handle. Broken, broken, broken. Don't
go there. We have seen the future of ESMTP 8BITMIME and similar propositions,
and It Is Excrement.

Charles

[Richard Lyons]

Post by Charles Cazabon
http://www.zmailer.org/mhalist/1995/msg00210.html

Interesting read, thanks. As qmail has the same issues as
pointed out in the post, are there any widely deployed MTAs
that don't support js8? Are there any MUAs that are incapable
of QP or B64 and require 8BITMIME?

Rick.

[Network Administration]

Post by Charles Cazabon
There /is/ no "BDAT" command in SMTP, and there is no distinction between
"binary attachment" and "message". To SMTP, there are two parts to a message,

OK, I guess you're right. The same idea applies, however. Binary
attachments can be sent as quoted-printable, which escapes carriage return
sequences. For example, a binary file like this:

0D0D 0D0D 0D0A 0A0A 0A0A 0A0A

Would encode like this:

------=_NextPart_000_018E_01C3C32E.02EA3040
Content-Type: application/octet-stream;
name="crlf.dat"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="crlf.dat"
=0D=0D=0D=0D
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=

Post by Charles Cazabon
For servers with a reasonable amount of traffic, the collateral
damage may be too high. RFC or not, we receive mail with multiple
consecutive CRs in the message body, typically HTML, PDF and RTF
documents.

Joseph

[Richard Lyons]

Post by Network Administration
OK, I guess you're right. The same idea applies, however. Binary
attachments can be sent as quoted-printable, which escapes carriage return

In theory. Practice is somewhat different.
# dumpbytes 1071474953.32399.bne005m.server-mail.com|grep 0d.0d
000d30 75 72 69 65 72 20 4e 65 77 3b 7d 7d 0d 0d 7b 5c urier New;}}..{\
000dc0 65 73 7d 0d 7b 5c 76 65 72 6e 31 7d 7d 0d 0d 5c es}.{\vern1}}..\

IIRC, the original OE problem was caused by messages that had
CRLF in the headers (as well as the body). The FP hit rate of
your patch could be reduced by limiting the CRCR check to just
headers (if you care about possibly rejecting valid email).

Rick.

[Network Administration]

Post by Richard Lyons
# dumpbytes 1071474953.32399.bne005m.server-mail.com|grep 0d.0d
000d30 75 72 69 65 72 20 4e 65 77 3b 7d 7d 0d 0d 7b 5c urier New;}}..{\
000dc0 65 73 7d 0d 7b 5c 76 65 72 6e 31 7d 7d 0d 0d 5c es}.{\vern1}}..\

How was that RTF attachment coded? Not quoted-printable!

Joseph