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
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
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
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:
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):
At mcmsys.com, the problem must happen often enough for it to be a
standard gripe on their tech support web form:
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,
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.
Carl Haddick http://www.glade.net
GladeNet Communications alt email: ***@glade.net
200 South Red River (254) 562-6381
Mexia, TX 76667 (877) 373-3882