234315 - POP3 Receiving hangs persistently on certain type of emails

Status: RESOLVED DUPLICATE of bug 224900

(MailNews Core :: Networking: POP, defect)

Description

[George]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

There is certain types of messages (usually spam) that when mozilla attempts 
to receive them via pop3 .. pop3 receiving hangs. The GUI works ok but you can 
no longer receive pop3 email.

I have identified one of those messages.

I tried to telnet to port 110 and receive that message and 'retr' command 
works ok. Mozilla though doesn't like the message.

My guess is that the mime encoding of the message or something along those 
lines is causing mozilla to keep on waiting delivery of the message even after 
the whole message has been piped through.

I'm attaching on of those messages (it's spam).

I have identified another 3 messages that also cause the same problem.

All in all I get this problem everyday and I must manually (via telnet or 
webmail) delete the 'bad' message before I can continue receiving the rest of 
my email.

Reproducible: Always
Steps to Reproduce:
1. Mail this (attached) email to your pop3 account
2. Try to receive the email via pop3 Mozilla Mail
3. Mozilla waits endlessly (blocked) and rest of messages get stuck in queue

Actual Results:  
Mozilla Mail mail receiving hangs while receiving this message.

Expected Results:  
Receive message and continue receiving the rest of messages.

Comment 1

[George]

Attachment: One of emails that blocks mozilla mail

Comment 2

[Christian Eyrich]

George, we don't inspect the message while receiving. So no mime encoding or
something should cause this problem.

We had a problem with null bytes at the end of some spam messages, but that
should be fixed (bug 223062). The other problem is, that some servers forget to
send the CRLF.CRLF at the end of a message and so we wait and wait ...

At least the last case you can test in telnet. But there may be other problems
too. So I ask you to attach a communications log of a hanging session. See
http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#pop how to create it.

Comment 3

[George]

Attachment: Communication log

This is a communication log as requested.

I had to stop mozilla after a few minutes as it was stuck there receiving one
email endlessly.

Comment 4

[George]

(In reply to comment #3)
> Created an attachment (id=141564)
> Communication log
> This is a communication log as requested.
> I had to stop mozilla after a few minutes as it was stuck there receiving one
> email endlessly.

I forgot to mention that I tried the same session with telneting to port 110 
and the server was sending CRLF.CRLF ok and I could request 'retr 1' again and 
again.
But in mozilla it was just hanging there.

Comment 5

[George]

Attachment: One more mozilla communication log + telnet 110 log of same

And the telnet to port 110 log of the same:

+OK hello from popgate(2.23.13)
user myusername
+OK password required.
pass mypass
+OK maildrop ready, 2 messages (26448 octets) (34120 26214400)
list
+OK 2 messages (26448 octets)
1 679
2 25769
.
retr 1
+OK 681 octets
X-Apparently-To: [e-mail] via 217.12.10.56; Thu, 19 Feb 2004 01:51:38
- 0800
X-YahooFilteredBulk: 62.234.59.110
Return-Path: <[e-mail]>
Received: from 62.234.59.110  (HELO c3eea3b6e.cable.wanadoo.nl) (62.234.59.110)
by mta2-vm3.mail.yahoo.com with SMTP; Thu, 19 Feb 2004 01:51:35 -0800
Date: Thu, 19 Feb 2004 06:23:04 +0000
From: birgit <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail]
Subject: robyn
MIME-Version: 1.0
Content-Type: text/plain; charset=Windows-1251
Content-Transfer-Encoding: 8bit

&#9500;¸&#8804;¾&#8730;� ÷�¢¼�תש ÷� ¾¿¼&#8729;ש&#9632;&#8805; � ÷�
‎ש�&#8730;�ש&#9632;&#8805;; ÷ש��÷&#8730;� ¾¿¼&#8729;ש&#9632;&#8805; �
‎ש�&#8730;�ש&#9632;&#8805;; ¹&#8804;ת¿&#8730;� ¾¿¼&#8729;
, ÷¼ ÷� ‎ש�&#8730;�ש&#9632;&#8805;.



.
retr 1
+OK 681 octets
X-Apparently-To: [e-mail] via 217.12.10.56; Thu, 19 Feb 2004 01:51:38
-
0800
X-YahooFilteredBulk: 62.234.59.110
Return-Path: <[e-mail]>
Received: from 62.234.59.110  (HELO c3eea3b6e.cable.wanadoo.nl) (62.234.59.110)

  by mta2-vm3.mail.yahoo.com with SMTP; Thu, 19 Feb 2004 01:51:35 -0800
Date: Thu, 19 Feb 2004 06:23:04 +0000
From: birgit <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail]
Subject: robyn
MIME-Version: 1.0
Content-Type: text/plain; charset=Windows-1251
Content-Transfer-Encoding: 8bit

&#9500;¸&#8804;¾&#8730;� ÷�¢¼�תש ÷� ¾¿¼&#8729;ש&#9632;&#8805; � ÷�
‎ש�&#8730;�ש&#9632;&#8805;; ÷ש��÷&#8730;� ¾¿¼&#8729;ש&#9632;&#8805; �
‎ש�&#8730;�ש&#9632;&#8805;; ¹&#8804;ת¿&#8730;� ¾¿¼&#8729;
, ÷¼ ÷� ‎ש�&#8730;�ש&#9632;&#8805;.



.
quit
+OK server signing off.


Connection to host lost.

Comment 6

[George]

Attachment: Message that causes above communication log

Attached is one of many messages that causes this problem. And associated log
(with antivirus disabled):

0[283ee0]: Entering NET_ProcessPop3 30
0[283ee0]: POP3: Entering state: 3
0[283ee0]: RECV: -ERR popgate unknown command
0[283ee0]: POP3: Entering state: 38
0[283ee0]: POP3: Entering state: 18
0[283ee0]: SEND: RETR 1

0[283ee0]: Entering NET_ProcessPop3 16
0[283ee0]: POP3: Entering state: 3
0[283ee0]: RECV: +OK 681 octets
0[283ee0]: POP3: Entering state: 19
0[283ee0]: Opening message stream: MSG_IncorporateBegin
0[283ee0]: Done opening message stream!
0[283ee0]: RECV: (null)
0[283ee0]: Entering NET_ProcessPop3 678
0[283ee0]: POP3: Entering state: 19
0[283ee0]: RECV: X-Apparently-To: [e-mail] via 217.12.10.56; Thu, 19
Feb 2004 01:51:38 -0800
0[283ee0]: RECV: X-YahooFilteredBulk: 62.234.59.110
0[283ee0]: RECV: Return-Path: <[e-mail]>
0[283ee0]: RECV: Received: from 62.234.59.110  (HELO
c3eea3b6e.cable.wanadoo.nl) (62.234.59.110)
0[283ee0]: RECV:   by mta2-vm3.mail.yahoo.com with SMTP; Thu, 19 Feb 2004
01:51:35 -0800
0[283ee0]: RECV: Date: Thu, 19 Feb 2004 06:23:04 +0000
0[283ee0]: RECV: From: birgit <[e-mail]>
0[283ee0]: RECV: Message-ID: <[e-mail]>
0[283ee0]: RECV: To: [e-mail]
0[283ee0]: RECV: Subject: robyn
0[283ee0]: RECV: MIME-Version: 1.0
0[283ee0]: RECV: Content-Type: text/plain; charset=Windows-1251
0[283ee0]: RECV: Content-Transfer-Encoding: 8bit
0[283ee0]: RECV: 
0[283ee0]: RECV: Глупые никогда не прощают и не забывают; наивные прощают и
забывают; мудрые прощают, но не забывают.
0[283ee0]: RECV: 
0[283ee0]: RECV: 
0[283ee0]: RECV: (null)

And waits here endlessly ...

Comment 7

[George]

Attachment: Same message as above (repeated as it isn't loading properly in previous attachment)

Comment 8

[Christian Eyrich]

What' that McAfee Timout-Thing in the third log? Do you have a virus scanner
running? Did you already test without it?

Comment 9

[George]

(In reply to comment #8)
> What' that McAfee Timout-Thing in the third log? Do you have a virus scanner
> running? Did you already test without it?

Yes, have a look at comment #6

McAfee kicks in when mozilla doesn't respond as an antivirus failsafe.
I have completely disabled McAfee when producing results of comment #6

Comment 10

[Christian Eyrich]

Sorry, I overread the part in parenthesis in comment #6.

I'm at a loss at the moment. Do you think you can create a log with tcpdump or
compatible packet sniffer? This is to have 1. an independent log and 2.
invisible characters logged.

Comment 11

[George]

(In reply to comment #10)
> Sorry, I overread the part in parenthesis in comment #6.
> 
> I'm at a loss at the moment. Do you think you can create a log with tcpdump or
> compatible packet sniffer? This is to have 1. an independent log and 2.
> invisible characters logged.

As requested I created a new attachment with windump (tcpdump for windows).

I can created more such dumps for other emails that cause the same problem.

Comment 12

[George]

Attachment: TCP Dump

Comment 13

[Christian Eyrich]

Erm, adding -s 0 to the tcpdump/windump arguments would be very helpful, withou
only the first few bytes are catched. Thanks.

Comment 14

[Bob Fillmore]

I am seeing the same problem, on about 10 emails over the last 6 days.
Here is a copy of a message captured with ethereal:

Return-Path: <[e-mail]>
Received: from h226.50.55.139.ip.alltel.net ([139.55.50.226])
          by fep04-mail.bloor.is.net.cable.rogers.com
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with SMTP
          id
<20[e-mail]>;
          Thu, 4 Mar 2004 21:39:32 -0500
X-Message-Info: OWZOaOC57fHPy/lJoEBcgEhLqybcKj7N
Received: from apply-p62.homeown.aol.com ([52.16.247.122]) by
bz1-u59.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824);
	 Fri, 05 Mar 2004 00:34:59 -0200
From: Adam Eaton <[e-mail]>
To: [e-mail]
Subject: elder impunity loamy fluff aden scenic radix saucepan evict accord
relieve expatiate churchwomen backfill deaconess flashback vial beheld marshland
risible genie connie aida wormy tremble exonerate angola contribution 
Date: Thu, 04 Mar 2004 20:34:59 -0600 EST
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="--8083912998498755800"

----8083912998498755800
Content-Type: text/html;
Content-Transfer-Encoding: base64

PEhUTUw+PEhFQUQ+PC9IRUFEPjxCT0RZPjxDRU5URVI+PFRBQkxFIGFsaWduPWNlbnRlciBi
b3JkZXI9MiBjZWxscGFkZGluZz0xNSBzZWxsc3BhY2luZz01PjxUUj4NCiAgICA8VEQgDQpi
Z2NvbG9yPUEwRkZBMD48Rk9OVCANClNJWkU9KzMgZmFjZT1hcmlhbD48Qj48YSBocmVmPSJo
dHRwOi8vd3d3LmNhc2luby1hcmVuYS5jb20vXzQ1NTIyYTU2MTJjZGU3MDYzYzQzYWM4YTNm
NjZmODY5LyI+R2FtYmxlIA0KICAgICAgT25saW5lPzwvYT48L0I+PC9GT05UPjwvVEQ+DQog
IDwvVFI+PC9UQUJMRT4NCjxCUj4NCjxkaXYgYWxpZ249ImNlbnRlciI+PC9kaXY+DQo8ZGl2
IGFsaWduPSJjZW50ZXIiPg0KICA8cD48Zm9udCBzaXplPSIrMSIgZmFjZT0iQVJJQUwiPlJl
Y2VpdmUgdXAgdG8gPEEgDQpIUkVGPSJodHRwOi8vd3d3LmNhc2luby1hcmVuYS5jb20vXzQ1
NTIyYTU2MTJjZGU3MDYzYzQzYWM4YTNmNjZmODY5LyI+PEZPTlQgQ09MT1I9Ymx1ZT48Qj4k
MjUwIA0KICAgIFVTIGluIEJ8T3xOfFV8UyBDSElQUzwvQj48L0ZPTlQ+PC9BPiBqdXN0IGZv
ciBwbGF5aW5nIGhlcmUhITwvZm9udD48L3A+DQogIDxwPjxmb250IHNpemU9IisxIiBmYWNl
PSJBUklBTCI+PEJSPg0KICAgIE9OTFkgMSBEb2xsYXIgZHxlfHB8b3xzfGl8dHwgdG8gYmVn
aW4hISEgPC9mb250PjwvcD4NCjwvZGl2Pg0KPGZvbnQgc2l6ZT0iKzEiPg0KPFRBQkxFIGFs
aWduPWNlbnRlciBib3JkZXI9MiBjZWxscGFkZGluZz0xNSBzZWxsc3BhY2luZz01Pg0KICA8
VFI+DQogICAgPFREIGJnY29sb3I9QTBGRkZGPjxmb250IGZhY2U9IkFSSUFMIj4NCiAgICAg
IDxMST48QSBIUkVGPSJodHRwOi8vd3d3LmNhc2luby1hcmVuYS5jb20vXzQ1NTIyYTU2MTJj
ZGU3MDYzYzQzYWM4YTNmNjZmODY5LyI+SGlnaGVyIA0KICAgICAgICBPZGRzIFBheW91dHMg
JiBQYXkgVGFibGVzPC9BPg0KICAgICAgPExJPkFsbCBuZXcgZ3JhcGhpY3MgYW5kIGFuaW1h
dGlvbnMNCiAgICAgIDxMST5GdWxseSBhdXRvbWF0ZWQgPEEgDQpIUkVGPSJodHRwOi8vd3d3
LmNhc2luby1hcmVuYS5jb20vXzQ1NTIyYTU2MTJjZGU3MDYzYzQzYWM4YTNmNjZmODY5LyI+
UGxheWVyIA0KICAgICAgICBCb251c2VzPC9BPg0KICAgICAgPExJPjEwMCUgTUFUQ0hQTEFZ
PC9mb250PjwvVEQ+DQogIDwvVFI+DQo8L1RBQkxFPg0KPC9mb250Pg0KPFAgYWxpZ249ImNl
bnRlciI+PEZPTlQgc2l6ZT0tMiBjb2xvcj13aGl0ZT4gQmFza2V0YmEgaGZoc3VlaCBjbWNo
YW5jZSBzbXdlaW5zdCANCiAgJm5ic3A7IElzYWJlbGxlIHBpZXJyZSBwdWx2ZXIgYmFydG1h
biBlY2NhbGR3ZSBtYXJra25hcCBjYXJyb2xsIGJyaWRnZXQgY3Jvd25lZCANCiAgZGVpYmxl
ciBzcGFua3kgQXNzaG9sZSBkd2F1cmljYyBrY29ybmV0dCBncmFuaXRlIHNzY2h1bWVyIGJh
c2F5bmUgc3dhaWlzIGhhbnNvbiANCiAgbGVhcmQgZGV3ZXJ0aCBiZWFyZCA8L0ZPTlQ+PEJS
Pg0KICBHZXQgb2ZmIHRoaXMgbGlzdCBieSB3cml0aW5nIHRvIHlhaG9vb2ZmMzYzM0BtYWls
LmNvbQ0KPFAgYWxpZ249ImNlbnRlciI+Jm5ic3A7DQo8UCBhbGlnbj0iY2VudGVyIj4mbmJz
cDsNCjwvQk9EWT48L0hUTUw+ k

----8083912998498755800--

.

Comment 15

[Bob Fillmore]

*** Bug 236724 has been marked as a duplicate of this bug. ***

Comment 16

[George]

Attachment: Windump -o ... as requested

This is windump of tcp 110 while the bad message is being downloaded. Please
note that I had to stop the pop3 downloading and restart it to indicate that
I'm having two attempts to download message with no success.

Comment 17

[Christian Eyrich]

Thanks for the new log, George. It shows a null (\0) right before the
terminating CRLF.CRLF at the message end.
While Mozilla has a patch against null bytes in the mail since bug 223062,
McAfee still suffers from a such a bug. Please see bug 224900, comment #28 and
following.

If you can reproduce this, it's a dupe to that bug.

Comment 18

[George]

*** This bug has been marked as a duplicate of 224900 ***

Comment 19

[George]

(In reply to comment #17)
> Thanks for the new log, George. It shows a null (\0) right before the
> terminating CRLF.CRLF at the message end.
> While Mozilla has a patch against null bytes in the mail since bug 223062,
> McAfee still suffers from a such a bug. Please see bug 224900, comment #28 and
> following.
> 
> If you can reproduce this, it's a dupe to that bug.

Thanks Christian, you are right it's McAffee .. amazingly McAffee still does
it's bugy thing in the background even when deactivated and exited from GUI. So
killing it stopped the problem and I managed to download all 12 problematic
emails that I had saved for testing this problem. So I marked this problem as
dupe and I'm heading onto McAffee :-)

Comment 20

[Bob Fillmore]

Thanks for the McAfee tip... I downgraded from McAfee 8.0 to 7.1 and all is well.
Perhaps Mozilla should have a timeout in this code, with a popup saying the
message is possibly truncated?