Closed Bug 220225 Opened 21 years ago Closed 18 years ago

Can't retrieve POP mail with combination of COMCAST and antivirus software

Categories

(MailNews Core :: Networking: POP, defect)

Product:
MailNews Core
Component:
Networking: POP
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: robertlaferla, Assigned: sspitzer)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(8 files)

POP3 failure to retrieve messages
5.05 KB, text/plain
Details
Both tcpdump ascii and NSPR_LOG_MODULES=POP3:5 logs of pop3 hang
22.27 KB, application/x-compressed-tar
Details
a message that seems to cause the "get new mail" process to stall
8.57 KB, text/plain
Details
A POP3:5 Mozilla log.
4.91 KB, text/plain
Details
a network traffic trace that corresponds to the POP3 Mozilla log.
8.91 KB, text/plain
Details
a screenshot of the pop3 traffic as viewed in vim
44.00 KB, image/png
Details
Mozilla and TCP traces with and without Norton AntiVirus enabled
18.38 KB, application/x-zip-compressed
Details
File that may be causing the hang
2.51 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030718
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030923

Starting with the nightly build from 9/23/2003 and continuing with the 9/24/2003
build, I can no longer retrieve my e-mail from mail.comcast.net.  I have only
tested it with this one POP server so I don't know how widespread the issue is.
 HOWEVER, I am able to retrieve e-mail with an older version of Mozilla
(2003071814) so it's not the POP server.  Some code was checked in that broke
the build.



Reproducible: Always

Steps to Reproduce:
1.  Open Messenger.
2.  Try to retrieve POP mail from mail.comcast.net
3.
This is a work around that I have find to get it to work will comcast e-mail. Go
to the site and use the web based e-mail and clear all the folders of e-mail
then it will work in mozilla. This will happen again after a while and yhou will
have to do the same thing to get it to work again. This is only a work around
till they can get it fixed. 
How about backing out the code that caused this major REGRESSION bug?  In the
intermin, the developer could use that time to do more unit testing of his or
her changes.

does not block Mozilla development

> How about backing out the code that caused this major REGRESSION bug?

and which code would that be?  a lot of code changed between 7/18 and 9/24
Severity: blocker → critical
Keywords: regression
Summary: Can't retrieve POP mail! → Can't retrieve comcast POP mail!
The problem started with nightly build from 9/23/2003.  I seem to remember
seeing some code that was checked in to deal with the password dialog for POP. 
That's where I'd look first.





Robert, I guess you think of the workaround in bug 219162, but there indeed many
other too. Do you get an error message and if yes, which?

You could help to narrow the cause down if you try getting mail with e.g. 20030915.

Also a communications log could help finding the cause. See 
http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#pop how to create.
Lowering severity - this problem can't be that important since the reporter
didn't answer any  question for weeks.

Also I can't confirm this problem when loging in a test account on the server
with or without SSL (see bug 202575, comment #45).
Severity: critical → normal
No.  It is important.   I have been out of the country for a family emergency. 
I have been using web-based e-mail in the interim.  I just returned last night.

Here is the log information that you requested.

0[2344f8]: Entering NET_ProcessPop3 52
0[2344f8]: POP3: Entering state: 1
0[2344f8]: POP3: Entering state: 2
0[2344f8]: POP3: Entering state: 4
0[2344f8]: RECV: +OK (sccrpxc04) Maillennium POP3/PROXY server #297
0[2344f8]: POP3: Entering state: 29
0[2344f8]: SEND: AUTH

0[2344f8]: Entering NET_ProcessPop3 32
0[2344f8]: POP3: Entering state: 3
0[2344f8]: RECV: -ERR authorization not enabled
0[2344f8]: POP3: Entering state: 30
0[2344f8]: POP3: Entering state: 31
0[2344f8]: SEND: CAPA

0[2344f8]: Entering NET_ProcessPop3 29
0[2344f8]: POP3: Entering state: 3
0[2344f8]: RECV: +OK Capability list follows
0[2344f8]: POP3: Entering state: 32
0[2344f8]: Entering NET_ProcessPop3 14
0[2344f8]: POP3: Entering state: 32
0[2344f8]: RECV: EXPIRE NEVER
0[2344f8]: POP3: Entering state: 32
0[2344f8]: Entering NET_ProcessPop3 90
0[2344f8]: POP3: Entering state: 32
0[2344f8]: RECV: IMPLEMENTATION Maillennium/PROXY V04.61c++ [12-Jun-03]
cpu_sparc.os_solaris_bsd.comp_gnu
0[2344f8]: POP3: Entering state: 32
0[2344f8]: Entering NET_ProcessPop3 15
0[2344f8]: POP3: Entering state: 32
0[2344f8]: RECV: LOGIN-DELAY 0
0[2344f8]: POP3: Entering state: 32
0[2344f8]: Entering NET_ProcessPop3 12
0[2344f8]: POP3: Entering state: 32
0[2344f8]: RECV: PIPELINING
0[2344f8]: POP3: Entering state: 32
0[2344f8]: Entering NET_ProcessPop3 12
0[2344f8]: POP3: Entering state: 32
0[2344f8]: RECV: RESP-CODES
0[2344f8]: POP3: Entering state: 32
0[2344f8]: Entering NET_ProcessPop3 6
0[2344f8]: POP3: Entering state: 32
0[2344f8]: RECV: STLS
0[2344f8]: POP3: Entering state: 32
0[2344f8]: Entering NET_ProcessPop3 5
0[2344f8]: POP3: Entering state: 32
0[2344f8]: RECV: TOP
0[2344f8]: POP3: Entering state: 32
0[2344f8]: Entering NET_ProcessPop3 6
0[2344f8]: POP3: Entering state: 32
0[2344f8]: RECV: UIDL
0[2344f8]: POP3: Entering state: 32
0[2344f8]: Entering NET_ProcessPop3 6
0[2344f8]: POP3: Entering state: 32
0[2344f8]: RECV: USER
0[2344f8]: POP3: Entering state: 32
0[2344f8]: Entering NET_ProcessPop3 3
0[2344f8]: POP3: Entering state: 32
0[2344f8]: RECV: .
0[2344f8]: POP3: Entering state: 33
0[2344f8]: POP3: Entering state: 5
0[2344f8]: SEND: USER myusername

0[2344f8]: Entering NET_ProcessPop3 5
0[2344f8]: POP3: Entering state: 3
0[2344f8]: RECV: +OK
0[2344f8]: POP3: Entering state: 34
0[2344f8]: POP3: Entering state: 6
0[2344f8]: Logging suppressed for this command (it probably contained
authentication information)
0[2344f8]: Entering NET_ProcessPop3 11
0[2344f8]: POP3: Entering state: 3
0[2344f8]: RECV: +OK ready
0[2344f8]: POP3: Entering state: 34
0[2344f8]: POP3: Entering state: 7
0[2344f8]: SEND: STAT

0[2344f8]: Entering NET_ProcessPop3 13
0[2344f8]: POP3: Entering state: 3
0[2344f8]: RECV: +OK 9 93796
0[2344f8]: POP3: Entering state: 8
0[2344f8]: POP3: Entering state: 9
0[2344f8]: SEND: LIST

0[2344f8]: Entering NET_ProcessPop3 100
0[2344f8]: POP3: Entering state: 3
0[2344f8]: RECV: +OK 9 messages (93796)
0[2344f8]: POP3: Entering state: 10
0[2344f8]: RECV: 1 486
0[2344f8]: POP3: Entering state: 10
0[2344f8]: RECV: 2 4615
0[2344f8]: POP3: Entering state: 10
0[2344f8]: RECV: 3 4578
0[2344f8]: POP3: Entering state: 10
0[2344f8]: RECV: 4 3006
0[2344f8]: POP3: Entering state: 10
0[2344f8]: RECV: 5 1929
0[2344f8]: POP3: Entering state: 10
0[2344f8]: RECV: 6 3006
0[2344f8]: POP3: Entering state: 10
0[2344f8]: RECV: 7 37416
0[2344f8]: POP3: Entering state: 10
0[2344f8]: RECV: 8 37416
0[2344f8]: POP3: Entering state: 10
0[2344f8]: RECV: 9 1344
0[2344f8]: POP3: Entering state: 10
0[2344f8]: RECV: .
0[2344f8]: POP3: Entering state: 11
0[2344f8]: SEND: UIDL

0[2344f8]: Entering NET_ProcessPop3 360
0[2344f8]: POP3: Entering state: 3
0[2344f8]: RECV: +OK 9 messages (93796)
0[2344f8]: POP3: Entering state: 12
0[2344f8]: RECV: 1   20031022190542s1400eg2bee000i3t
0[2344f8]: POP3: Entering state: 12
0[2344f8]: RECV: 2   20031022191337s1300fkj69e000i3u
0[2344f8]: POP3: Entering state: 12
0[2344f8]: RECV: 3   20031022193612r12000qdute000i3v
0[2344f8]: POP3: Entering state: 12
0[2344f8]: RECV: 4   20031022194811s11009nr3ie000i41
0[2344f8]: POP3: Entering state: 12
0[2344f8]: RECV: 5   20031022194903s13001lb4je000i42
0[2344f8]: POP3: Entering state: 12
0[2344f8]: RECV: 6   20031022194903s14004087pe000i43
0[2344f8]: POP3: Entering state: 12
0[2344f8]: RECV: 7   20031022221408r1100o02afe000i48
0[2344f8]: POP3: Entering state: 12
0[2344f8]: RECV: 8   20031022222044s11000ejc8e000i49
0[2344f8]: POP3: Entering state: 12
0[2344f8]: RECV: 9   20031022234751r1400922pue000i4f
0[2344f8]: POP3: Entering state: 12
0[2344f8]: RECV: .
0[2344f8]: POP3: Entering state: 15
0[2344f8]: POP3: Entering state: 22
0[2344f8]: SEND: QUIT

0[2344f8]: Entering NET_ProcessPop3 17
0[2344f8]: POP3: Entering state: 3
0[2344f8]: RECV: +OK comcast.net
0[2344f8]: POP3: Entering state: 41
0[2344f8]: POP3: Entering state: 23
0[2344f8]: POP3: Entering state: 25
This problem still exists in the latest build 2003102204.  BTW - I tried
enabling secure authorization but it said that the server does not support it.

I also tried hitting the "Get Msgs" button again but then I get this message dialog:

"The folder is being processed.  Please wait until processing is complete to get
messages."


And what's the problem you have?

The log (please always create an attachment for such things) shows that
everything is fine. No message has been retreived because Mozilla sees no new mail.
The UIDLs listed have been compared to the UIDLs in the popstate.dat in your
profile. This popstate.dat keeps the UIDL of mails that have been downloaded but
kept on the server.
If you want to download them again, close Mozilla, delete the popstate.dat and
get mails again.
It is not downloading e-mail even though the biff window reports 16 new
messages.  I also logged into my web-based mail and there were 16 messages
waiting for me.

I am using Norton Internet Security/Antivirus.  Could this be an issue?


Yes, your Norton tool can be a issue. Just try it without.

Did biff and webmail show 16 mails around the time you created the log? As you
can see the log shows 9 messages. And what does you popstate.dat say - are these
UIDLs listed there?
Robert: can you retreive messages if you click on the get-new-mail button?
It is working now.  It appears to be some sort of issue with Norton Anti-virus.
 The strange thing is in the past it worked with an older version of Mozilla
(9/22) but not with newer versions (until a several days ago.)  I think the bug
should be closed out.  If I see it again, we can revisit it but everything seems
to be working fine now.

ok.  I thought you might have been seeing bug 221165 (I think it also started
around 9/23), which would be consistent with your POP3 log.

I'll mark this WORKSFORME for now.  If you see the bug again, you can REOPEN it.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
I am seeing this problem again with build #2003120709.  I examined my e-mail on
the comcast server and there was nothing out of the ordinary.  I had 30 messages
waiting for me to download.  I tried disabling/enabling Norton Antivirus to no
avail.  I added an environment variable to enable POP mail logging but I only
get a 0 length file.  I did noticed that Mozilla reported "Building inbox
summary..." or something like that prior to prompting me for my password to
login in to the POP server.  Lastly, I tried rebooting and it still does not work.

The main question I have is why the 0 length log file?  

NSPR_LOG_FILE=C:\mypath\mylogfile.log  (and C:\mypath exists)
NSPR_LOG_MODULES=POP:5
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
and it Mozilla reports "Retrieving message 1 out of 30" before it just stops. 
It never retrieves even the first message.  I will try deleting that first
message on the server to see if it changes anything.

I looked at the messages on the server again.  There were 1-2 spam messages with
all sorts of strange characters in the subject line.  I deleted them.  I also
moved all my INBOX messages to a temporary folder.  I am now able to retrieve
e-mail.

However, what is the problem?  I don't know how the POP protocol / Mozilla works
but does it first request a list of headers before retrieving the message
bodies?  If so, perhaps, it is choking on the bad headers??
 
NSPR_LOG_MODULES=POP:5
                 ^^^   POP3

> and it Mozilla reports "Retrieving message 1 out of 30" before it just stops. 

then it looks like this is a different problem than what you reported originally...

> all sorts of strange characters in the subject line.  I deleted them.  I also
> moved all my INBOX messages to a temporary folder.  I am now able to retrieve
> e-mail.

if you are no longer able to reproduce the problem, there's not much that can be
done for Mozilla.

either way, this bug seems to be WORKSFORME again.
I'm still interested in your problem (may it be a new or not), Robert. But
having a log of this newly hang is mandatory. As Andrew wrote the var must be
set to "POP3:5".

If you can't reproduce the problem right now after deleting/moving the mails,
just let the logging be activated and wait till it happens again.
Okay.  I'll monitor it.  I suspect it has something to do with non-ASCII
characters in various mail headers that spammers are using.  It could possibly
even be a new DoS denial of service tactic because that's the net effect of the
problem.  Then again, it could simply be a non-standard POP3 server that Comcast
is using.  We'll see...





    
    

    
  
It is happening again.  I updated my environment variable.  That sure was a
stupid typo.  I've added the log as an attachment to this bug.


    
    

    
  
Thanks for the log, Robert. It stops abrupt before receiving only one line of
the mail. So I don't think the hang is caused by illegal characters confusing
Mozilla.

From the log it looks like the server doesn't send anything after his "+OK"
answer to our "RETR 1" request. The reason why I don't simply say "it's the
server" is, that such an error would affect any user of this server and thus
well known.

Are you able to check this mail account with any other mail client like Outlook,
The Bat, Eudora or something like that?

    
    

    
  
I think I'm seeing this, too.  Increasingly.
I have mozilla 1.6 on both WinXP and RH Linux 9.  
It happens only on WinXP, and only with POP3.
Linux is ok, and WinXP is ok with IMAP.
I'll attach a tarball of both a windump log and a set NSPR_LOG_MODULES=POP3:5
log.


    
    

    
  
Oh, and my mail server isn't comcast, it's pair.com.
(Yeah, comcast is my cable provider, but I don't use their mail servers.)

    
  

        Attachment #140656 -
        Attachment mime type: application/x-compressed → application/x-compressed-tar

    
    

    
  
Erm Elizabeth, your logs don't read as your problem is the same. Bug 224900
looks more like your one.

    
    

    
  
I believe I am seeing this same problem (or something very similar).  Using
Netscape 7.1 or Mozilla 1.6 on Windows XP, I see basically the same symptoms as
Robert La Ferla:

1) Mozilla starts to retrieve new messages using POP.  I might see status
messages like "Retrieving message 1/5", then 2/5, etc. but the progression stops
before Mozilla gets to 5/5.

2) After that, I can view messages that have been downloaded but clicking "Get
Msgs" causes a dialog to be displayed that reads "This folder is being
processed. Please wait until processing is complete to get messages."

The POP server is mail.comcast.net.  I can "fix" the problem my using Comcast's
webmail interface to delete the message that could not be downloaded (just
deleting that one message, restarting Mozilla, and retrieving messages again
fixes the problem entirely).

I am going to capture a POP3 trace and attach it to this bug.  I will also
attach one of the offending messages now.

    
    

    
  


  
Here is an example of a message that causes the get new messages stall.  One
thing to notice is that it is an ugly spam message.  Even more interesting is
the two Date: headers and this message:

X-Comment: Sending client does not conform to RFC822 minimum requirements
X-Comment: Date has been added by Maillennium

Maybe Maillennium (Comcast's SMTP server?) is confused and adds a second date. 
Still, the client should not stall.  I have about 10 messages very similar to
this one saved that all caused the same problem in Mozilla.  It happens a
couple of times each day for me lately; I used to see the problem once a week
or so but it has gotten worse lately due to the increase in these particular
spam messages.

    
    

    
  

      
      
      
      

        Attached file
          
        A POP3:5 Mozilla log.
        — 
      

    


  

    
    

    
  
Note that the network traffic trace (attachment 142910 [details]) contains another example
of a problematic message.

    
    

    
  
Confirming bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  


  
One more interesting thing: the original header lines of the message do not
have CRs on them (they only have LFs; if I remember correctly in both POP and
SMTP every line is supposed to end with a CR LF pair).	This screenshot shows
the lines that are wrong (vim shows the CRs as ^M so look for lines that do not
end in ^M).

    
    

    
  
Please assign this bug to a developer.  With the overabundance of SPAM mail
today, it is increasingly difficult for Comcast users to justify using Mozilla
mail.  If you want all Comcast users to dump Mozilla, ignore this bug.  This was
originally reported in December of last year and I seem to remember reporting a
similar bug even earlier than that.
Severity: normal → critical

    
    

    
  
Errata to my last comment:  This bug started in September of last year.



    
    

    
  
Robert, a bug doesn't has to be assigned to someone before something happens.
As I wrote earlier, this problem is interesting, but I don't have *the* idea
what can be done.

But after some experiences in the last days, here are two new things you (and
Mark) can try.
1. At least Robert has Norton running. Just disabling isn't enough, please see
bug 224900, comment #25 and bug 234315, comment #17 about this. I know, the
problem here looks different, but I wanna go sure it isn't Norton (or another
AV). So please kill the processes of all those programs before downloading.
2. I've a 1.6 build with enhanced debug informations available on
http://www.eyrich-net.org/tests/mozilla-i686-pc-cygwin_dbg.zip. If 1. doesn't
work, please download and unpack this archive and use that Mozilla for creating
a comm log. The archive is just a zip, no install necessary - just put it in
some different folder and run it after closing your normal Mozilla (including
Quick Launch).

If both doesn't help, the next option would be a tcpdump/windump log that we
hadn't already for this bugs issue.

    
    

    
  
The problem absolutely definitely occurs when there is SPAM mail in the incoming
queue.  To manually correct the problem, you must log into the Comcast web mail
client and delete all SPAM from your queue.  Even if you do this, if you already
attempted to download the mail using Mozilla, you will need to exit and restart
Mozilla or you will get the message again.


    
    

    
  
I am running Norton AntiVirus 2003 version 9.05.15 on Windows XP Service Pack 1.
I was experiencing this bug this morning due to another SPAM message almost
exactly like Attachment 142908 [details], so I tried disabling Norton AV's AutoProtect and
Email Scanning features.  After I restarted Mozilla and tried to download my
Comcast POP mail with Norton AV disabled, all messages downloaded without any
problem!

So at least for me, this problem seems to be caused by an interaction between
Mozilla and Norton AV.  I am not yet willing to assign all of the blame to one
piece of software or another.  Unfortunately, I did not capture the network
traffic or Mozilla POP log this time.  I reenabled Norton AV and plan to capture
various TCP and Mozilla POP traffic logs both with the antivirus package enabled
and with it disabled.  Maybe that will tell us what Norton is doing to the
stream that causes problems.

Robert, if you are running an AntiVirus package please try disabling it
temporarily and see if that has any effect.

    
    

    
  
I meant to say I will capture logs the next time I encounter this problem.

    
    

    
  
Mark, I don't want to put all the blame on the AV too. But in the last days it
has proven that the various AV are mostly the cause for this kind of trouble.
And it's no interaction with the AV, it's the AV. If this software is proxying
the communication, there's no way for the mail client to download when the proxy
stops working.

But I look forward to your further experiences. If Mozilla is to blame even
partly, I'll try to fix it.

    
    

    
  


  
Here are Mozilla POP3:5 and TCP traces both with Norton AntiVirus enabled and
then disabled (in the "disabled" traces, I omitted some irrelevant parts of the
logs).	I used http://www.eyrich-net.org/tests/mozilla-i686-pc-cygwin_dbg.zip
for both sessions.

I am not an expert at reading the Mozilla POP3 logs, but this snippet makes me
think that Norton AV causes the message contents to never be delivered to
Mozilla (the 5 bytes received are enough for the +OK line only and nothing
more):

0[9a3e68]: SEND: RETR 1
0[9a3e68]: Entering NET_ProcessPop3 5
0[9a3e68]: POP3: Entering state: 3
0[9a3e68]: ReadNextLine(), get more data. m_startPos: 0
0[9a3e68]: numBytesToCopy: 5
0[9a3e68]: numBytesCopied: 5, strlen(): 5
0[9a3e68]: RECV: +OK
0[9a3e68]: POP3: Entering state: 19
0[9a3e68]: Opening message stream: MSG_IncorporateBegin
0[9a3e68]: Done opening message stream!
0[9a3e68]: ReadNextLine(), get more data. m_startPos: 0
0[9a3e68]: numBytesToCopy: 0
0[9a3e68]: !endOfLine, numBytesToCopy <= 0 and !m_numBytesInBuffer
0[9a3e68]: RECV: (null)

(and that is the end of the log).  With Norton AV disabled, things look good
(many more than 5 bytes received):

0[9a3e68]: SEND: RETR 1
0[9a3e68]: Entering NET_ProcessPop3 1460
0[9a3e68]: POP3: Entering state: 3
0[9a3e68]: ReadNextLine(), get more data. m_startPos: 0
0[9a3e68]: numBytesToCopy: 1460
0[9a3e68]: numBytesCopied: 1460, strlen(): 1460
0[9a3e68]: RECV: +OK
0[9a3e68]: POP3: Entering state: 19
0[9a3e68]: Opening message stream: MSG_IncorporateBegin
0[9a3e68]: Done opening message stream!
0[9a3e68]: RECV: Date: Mon, 15 Mar 2004 17:56:40 +0000 (GMT)
0[9a3e68]: RECV: X-Comment: Sending client does not conform to RFC822 minimum
requirements
0[9a3e68]: RECV: X-Comment: Date has been added by Maillennium
0[9a3e68]: RECV: Received: from sehv-2-cb-108.lino.sympatico.ca
([142.217.93.108]
...

    
    

    
  
Thanks for the logs, Mark.
And you're right, NAV sitts between the network socket and Mozilla and only
delivers the data it wants to it.

The question is, why doesn't it send the mail through?
The "tcp traces" you included show the message has some lines (wrongly) with \n
and some normal with \r\n. Although I'd expect NAV sends at least the first
lines (which have correct line endings), it seems to choke right at the start.

I'm thinking about to disable the recognition of \n as line endings in Mozilla
itself because it also causes not few problems. But I think the mail client is
allowed to do that (at least if it throws an alert and allows to read the
following mails). But a proxying application failing silently? :(

So I'm sorry, from Mozillas side there doesn't seem to be a way around this problem.

    
    

    
  
I think the problem with Comcast's email has to do with previous attbi.com email
accounts.  I had indeed noticed that, as described before it was only certain
email's that causes mozilla to choke and fail to download any emails.  Outlook,
on the other hand will download all emails just fine, except for any spam mail
that were forwarded to my attbi.com.  When there were 22 emails on the server,
Outlook gives message that 22 out of 22 were downloaded but only 16 showed up in
my inbox (6 were comcast spam-I was able to see using webmail).  Additionally,
Outlook gives an error message saying the server responded with message "?" or
"????????" or something similar and meaningless to me.  I have since put a stop
to forwarding my attbi.com emails to my comcast.net account and have yet to
encounter any problems.  You can halt forwarding of attbi.com emails here:
http://faq.comcast.net/faq/answer.jsp?name=17799&cat=Email&subcategory=1

Can someone confirm this fix?

Brian Reyes

    
    

    
  
Update:
I'm still receiving attbi.com emails (haven't yet sent tech support additional
requested info),  but this has allowed me to further test my theory that
attbi.com emails cause Mozilla to choke.  Every time that Mozilla stops
downloading emails, if I can delete all my attbi.com (which are usually only
spam anyways) Mozilla begans to function properly again.  Sometimes Mozilla can
download attbi.com emails, but when Mozilla fails it seem to be the fault of an
attbi.com.

Brian

PS I did not specify earlier (comment #45) that many Comcast/Mozilla users may
be experiencing this same problem since all attbi.com users became Comcast users
a year ago

    
    

    
  
Brian, whatever causes Mozilla to choke, forwarded email or not, it shouldn't.
The question is, is the server sending out trash that must cause a conform
client to choke, or is it a bug in Mozilla.

Without having at least a normal log from Mozilla I can't say anything. Better
would be one from my build (see comment #38). And in a supporting role a
tcpdump/windup log.

    
    

    
  
I did some experimenting with various Windows operating systems and various
email clients.  I found a common thread that surprised me.  First of all let me
explain my setup for Mozilla mail.  I use version 1.6 of Mozilla and I leave the
mail on the server for 5 days.  I found that the operating system did not make a
difference and the email client did not make a difference as long as I did not
leave the email on the server for a given number of days.  (I forgot to check
what would happen if I just said leave the mail on the server indefinitely.)

What surprised me was that it made a difference for the particular version of
McAfee VirusScan that I was using.  Version 8.0, their latest version, breaks
Mozilla but did not break Eudora, when I set the POP mail account to leave the
mail on the server fox X number of days.  As soon as removed version 8.0 and
went back to 7.0 or 6.0 I no longer got the RETR error messages and all my
emails downloaded quickly and smoothly.

As to who is at fault I can not say.  I can not entirely fault McAfee because I
read that Norton users had similar problems, but obviously the combination of
Mozilla, McAfee 8.0, and temporarily leaving mail on the POP server has conflicts.

    
    

    
  
Well, it might be that 8.0 has some problems than its predecessors because it
tries to be more restrictive or so.
More interesting is why one client has a problem with the AV Tool and another
don't. The problems I've seen until now are that a AV fakes server responses or
steals data comming from the network.

But not having any 3rd party logs to view at it's otiose to think what could
make the difference.

    
    

    
  


  
I'm seeing this problem with the newest versions of everything

This message may be the one that was hanging mozilla.  It also may be a
different one, but it vanished entirely once it got downloaded into mozilla
(how did I get it into mozilla if I'm seeing this problem?  more on that later)

I'm using norton antivirus, but it is marked as Disabled (don't know if that
actually disables it)
Using comcast
Saw in:
mozilla 1.7.2
mozilla 1.8a2
mozilla 2004081709
thunderbird 0.7.3

None of these could pop it off.

HOWEVER, I set the nighty to download just the headers, and that worked!
I downloaded my real mail successfully, but when it came to download the 2
suspect messages by clicking the "here" to download the messageok:
1 message downloaded, then vanished.
1 message refused to download when clicking on the "here", then I exited
mozilla and re-entered, and fiddled with pop settings, and it downloaded
somehow (sorry didn't get the process down exactly.)

Anyway, if it happens again, I'll take better care to check it out.

    
    

    
  
I also see the behavior in bug 240969

    
    

    
  
With respect to disabling Norton Antivirus (NAV), here is what I do:  whenever I
see Mozilla 1.7x hang while downloading my Comcast POP email, I exit Mozilla,
open NAV and uncheck "Scan Incoming Email" in the settings, and then restart
Mozilla to download the email.  Then I reenable the Scan Incoming Email feature
in NAV.  I am currently using Norton Antivirus (NAV) 2004 Professional and I
believe this is a bug in that product (but since it apparently does not affect
all email clients, Symantec may never fix it).
Product: MailNews → Core

    
    

    
  
Summarizing Robert - worked for suite 20030922 build, didn't work for 20030923 - a checkin range of roughly http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2003-09-23+08%3A00%3A00&maxdate=2003-09-24+12%3A00%3A00&cvsroot=%2Fcvsroot

Robert is idle all of November 03 and then comment 14 "I am seeing this problem again with build #2003120709". last item regarding robert's data is comment 40.  I don't think Robert ever says he went back and checked that 20030922 still worked, which would have confirmed the regression idea.

As for Mark Smith, "I stopped using Norton AntiVirus a couple of years ago and switched to ZoneAlarm's security suite (and I do not believe I have seen this problem since)".

STM this is headed to INVALID, caused by Norton, unless Robert chimes in.
Summary: Can't retrieve comcast POP mail! → Can't retrieve POP mail with combination of COMCAST and antivirus software

    
    

    
  
Kaiser Ken: "A newer version of McAfee in combination with Mozilla updates seems to
have cleared up my problems."

if you have a problem check:
http://kb.mozillazine.org/Thunderbird_:_FAQs_:_Anti-virus_Software
http://kb.mozillazine.org/Disappearing_mail
URL: http://kb.mozillazine.org/Thunderbird...
Status: NEW → RESOLVED
Closed: 21 years ago → 18 years ago
Resolution: --- → INVALID
Product: Core → MailNews Core

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: