User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507 I keep getting the above message and having to exit Mozilla and reenter to retrieve my email. It was working okay for months and within the last 6 days started having this problem. I have removed my existing Inbox files and it still happens on the Inbox when I press the "Get Msgs" or "Compact files" buttons. Reproducible: Always Steps to Reproduce: 1.Start program 2.The first sequence of existing email is retrieved 3.When Mozilla goes to retrieve any newly added email from pop, I get message. Actual Results: The above message in the summary file Expected Results: It use to work as expected by periodically retrieving the new email from my pop account.

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

Harry L. Bennett: are you using ATTBI as your mail server?

Yes, I am. Is that the problem?

I suspect this is not a dupe.

I'm seeing this too. It seems to be cross-platform (it at least affects the PC platform...bug #204954 and bug #205683 seem to be for the same problem on Windows platforms).

Altho the error of "this folder is being processed" has a known cause, as seen in the report which this bug putatively duplicated (bug 152675), I have noticed a recent rash in Bugzilla and on the newsgroups of people complaining about this bug who just happened to be accessing mail at attbi.com. I suspect that there is a different cause behind this, in particular because attbi.com is undergoing a switchover to comcast.com (viz. bug 202575). Duping the bug reports over to this one. Changing summary to mention attbi; changing OS.

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

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

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

I have been wrestling with this for a couple of weeks and while I do not have an answer, maybe I have a clue for someone else. I have multiple attbi pop accounts. All work fine except for one of them. I sniffed the traffic and the difference is this: The ones that work properly do this: SEND: XSENDER 1 RECV: -ERR Invalid command; valid commands: DELE, LIST, LAST, NOOP, RETR, RSET, STAT, TOP, UIDL or QUIT The ones that get the error (also would get a permanent busy icon sometimes) did this: SEND: XSENDER 1 RECV: +OK In other words, for some accounts, attbi actually says "ok" for XSENDER and some it does not recognize the command. I was able to work around this by deleting the account (on attbi) and recreating it. (This requires a call to their tech support, as they will not let you recreate an account that has once existed.)

I am seeing this problem too with the 5/19 nightly build. I encounter it frequently and it is preventing me from reading mail. I have quit the application entirely and restart to read mail. I also reported a bug (206314) with the mail application hanging that I think (but cannot prove) may be somehow related.

BTW - I am also using attbi.com. I also get the permanent busy icon sometimes as reported above and in bug #206314. Regarding the switch over to Comcast, the switch does not take place until 6/30/2003. As a result, I would not say that it is related unless someone can prove that it is happening to Outlook or Eudora users accessing mail.attbi.com.

Don't count on this being unrelated to attbi. I suspect it is a bug on both sides. It appears as if attbi is running a pop proxy service, which could mean that userid1 is on attbi's server and userid2 is on comcast's server. % telnet mail.attbi.com 110 Trying 204.127.202.7... Connected to mail.attbi.com. Escape character is '^]'. +OK <29557.1053387203@attbi.com> (sccrpxc11) Maillennium POP3/PROXY server #210 As for some of my pop ids working and some getting this bug, one by one over the weekend they all transitioned to getting either the permanent busy or the "this folder is being processed". I suspect the frontend is hiding transitions on the backend. I cannot speak for outlook/eudora. I did switch to fetchmail to retrieve mail. While it does work, it complains of socket error with the pop server. The same version working towards a "normal" pop server does not complain. I also attempted to mask this bug by installing a pop3 proxy of my own on my local system. This does mask out the sending of XSENDER (my local proxy refuses it) but the bug still persists. I guess XSENDER OK is just the answer you get from the "buggy" attbi pop server.

One other clue I might add. I think this explains the bug on the attbi side. Here is a manual pop3 probe: % telnet mail.attbi.com 110 Trying 216.148.227.71... Connected to mail.attbi.com. Escape character is '^]'. +OK <5307.1053388008@attbi.com> (rwcrpxc11) Maillennium POP3/PROXY server #684 user notmyrealuserid +OK pass notmyrealpasswd +OK ready list +OK 0 messages (0) . quit Connection closed by foreign host If I understand rfc1939 correctly, the response to QUIT should always be +OK or -ERR, not just a socket shutdown.

Tuesday May 20, 2003 9pm EST For what it's worth, the bug has disappeared on my computer this morning for no apparent reason. Perhaps they'll all be gone by June 30, 3003 the official "ATT-Comcast" switchover day?

This now appears to be working correctly. I definitely think it was the attbi.com server that was causing the problem. Thank-you for you work on this problem. Harry

It is still occurring for me. Even if it is a problem with the mail server, Mozilla should handle exceptions more gracefully. I don't understand why it has to rebuild by Inbox summary upon restart either.

still broken for me... FWIW, I did report this yesterday to attbi as a protocol error with their pop server. It is conceivable they could be backing out or fixing the change. Out of my 5 email addresses, the problem creeped in gradually. ...but as someone else said, mailnews should probably handle it gracefully.

Still broken for me ... 3 of 6 accounts

This is repeatable on all six of my mailboxes. Comcast support said that they supported Eudora, but not Mozilla. I accepted their invitation to walk me through a test using Outlook Express. I could draw mail repeatedly without a complaint. Norton POP proxy is not a factor with this issue.

Mozilla needs to better handle exceptions. It's one thing if there's an error message and you can try again. But the permanent wait cursor is unacceptable. Is someone working on this bug? I don't think we should wait around for Comcast (who Microsoft invested $1B in) to fix the problem for Netscape/Mozilla users.

I contacted Comcast again and got a better reception. He had heard from others regarding this issue. His impression was that it was sporadic. I explained that it was very deterministic, and that it might appear to be random to those who pulled email from multiple mailboxes at once. He made note of rfc2821 section 4.1.1 Quit command, and exlained that the degree of urgency is determined by the number of complaints. So, if you're effected by this issue, it helps to contact them at 888-824-8579.

It is neither sporadic nor deterministic for me. It fails everytime. I am polling a single mailbox from mail.attbi.com. The big issue here is that someone needs to address this bug. It has more to do with exception handling than anything else. The Comcast problem may go away but there will always be other problems. Therefore, someone has to address exception handling in the Mozilla mail client.

I dont mean to be nitpicky, but if you call att-comcast-tci, refer to rfc1939, not rfc2821. Rfc2821 refers to smtp. Rfc1939 refers to pop3. The problem here is with pop3 -- *both* in mozilla and in comcast's "Maillennium/PROXY V04.60c++"

Christian, you looked at this for some other bug, right? Is there anything we can do about it or is it just a severe server problem?

When mozilla is first started, I can retreive my attbi mail box without a problem. The bug only occurs on second and later attempts. To retrieve mail again, I have to close the mail and all mozilla browser windows. This suggests that the bug should have an easy fix: on polling error, reset to initial state.

I know of the following additional email clients reported as broken to me by fellow ATTBI users this week: - EUDORA - Incredimail - Emacs VM(ail) They all started experiencing problems the same time Mozilla did. Comcast has their head in the sand.

David, no, there was this attbi-bug (202575) for which I did a patch, but this doesn't seem related. Far from it - this one looks to me like being our own problem with folder locking, the error message doesn't come from a server. m_nsIPop3Sink->BeginMailDelivery() returns NS_MSG_FOLDER_BUSY to nsPop3Protocol::GetStat() if the folder has been locked by AcquireSemaphore() but not released (in EndMailDelivery()). That's the only situation the error can occur. How this can occur is something to be investigated, but it's surely not the servers fault. The server can hang up or do something nasty, but we've to catch whatever it is.

right, it looks like we're not handling the server disconnecting on us. Even if we did, you still wouldn't be able to get your mail. I wonder if we're not getting the notification from necko that the connection has been dropped. In theory, we could handle getting dropped like this by caching the info that the server dropped us on a particular command and disabling that command for the rest of the mozilla session, i.e., storing the fallback state in the server as well as the connection object.

Uh, no log here? Could someone with this problems please attach a log created with these instructions: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#pop I'd like to know in which situation we're getting kicked to simulate this problem here with a dummy server.

yes, a log would be useful here. From what I can see in the code, we don't set the folder busy flag until we try to fetch mail (i.e., after we logon) and we clear the busy flag in all the error cases that I can see. So simulating this, or getting access to an attbi accout would be very useful.

0[2344c8]: Entering NET_ProcessPop3 81 0[2344c8]: POP3: Entering state: 1 0[2344c8]: POP3: Entering state: 2 0[2344c8]: POP3: Entering state: 4 0[2344c8]: RECV: +OK <12464.1053623311@attbi.com> (sccrpxc12) Maillennium POP3/PROXY server #238 0[2344c8]: POP3: Entering state: 29 0[2344c8]: SEND: AUTH 0[2344c8]: Entering NET_ProcessPop3 32 0[2344c8]: POP3: Entering state: 3 0[2344c8]: RECV: -ERR authorization not enabled 0[2344c8]: POP3: Entering state: 30 0[2344c8]: POP3: Entering state: 31 0[2344c8]: POP3: Entering state: 5 0[2344c8]: SEND: USER robertlaferla 0[2344c8]: Entering NET_ProcessPop3 5 0[2344c8]: POP3: Entering state: 3 0[2344c8]: RECV: +OK 0[2344c8]: POP3: Entering state: 32 0[2344c8]: POP3: Entering state: 6 0[2344c8]: Logging suppressed for this command (it probably contained authentication information) 0[2344c8]: Entering NET_ProcessPop3 11 0[2344c8]: POP3: Entering state: 3 0[2344c8]: RECV: +OK ready 0[2344c8]: POP3: Entering state: 7 0[2344c8]: SEND: STAT 0[2344c8]: Entering NET_ProcessPop3 9 0[2344c8]: POP3: Entering state: 3 0[2344c8]: RECV: +OK 0 0 0[2344c8]: POP3: Entering state: 8 0[2344c8]: POP3: Entering state: 22 0[2344c8]: SEND: QUIT 0[2344c8]: Entering NET_ProcessPop3 80 0[2344c8]: POP3: Entering state: 1 0[2344c8]: POP3: Entering state: 2 0[2344c8]: POP3: Entering state: 4 0[2344c8]: RECV: +OK <14330.1053623368@attbi.com> (sccrpxc11) Maillennium POP3/PROXY server #43 0[2344c8]: POP3: Entering state: 31 0[2344c8]: POP3: Entering state: 5 0[2344c8]: SEND: USER robertlaferla 0[2344c8]: Entering NET_ProcessPop3 5 0[2344c8]: POP3: Entering state: 3 0[2344c8]: RECV: +OK 0[2344c8]: POP3: Entering state: 32 0[2344c8]: POP3: Entering state: 6 0[2344c8]: Logging suppressed for this command (it probably contained authentication information) 0[2344c8]: Entering NET_ProcessPop3 11 0[2344c8]: POP3: Entering state: 3 0[2344c8]: RECV: +OK ready 0[2344c8]: POP3: Entering state: 7 0[2344c8]: SEND: STAT 0[2344c8]: Entering NET_ProcessPop3 12 0[2344c8]: POP3: Entering state: 3 0[2344c8]: RECV: +OK 2 1043 0[2344c8]: POP3: Entering state: 8 0[2344c8]: POP3: Entering state: 9 0[2344c8]: SEND: LIST 0[2344c8]: Entering NET_ProcessPop3 40 0[2344c8]: POP3: Entering state: 3 0[2344c8]: RECV: +OK 2 messages (1043) 0[2344c8]: POP3: Entering state: 10 0[2344c8]: RECV: 1 522 0[2344c8]: POP3: Entering state: 10 0[2344c8]: RECV: 2 521 0[2344c8]: POP3: Entering state: 10 0[2344c8]: RECV: . 0[2344c8]: POP3: Entering state: 11 0[2344c8]: SEND: UIDL 0[2344c8]: Entering NET_ProcessPop3 100 0[2344c8]: POP3: Entering state: 3 0[2344c8]: RECV: +OK 2 messages (1043) 0[2344c8]: POP3: Entering state: 12 0[2344c8]: RECV: 1 20030522170916s1200i9oa5e00009h 0[2344c8]: POP3: Entering state: 12 0[2344c8]: RECV: 2 20030522170922s1300nda63e00009i 0[2344c8]: POP3: Entering state: 12 0[2344c8]: RECV: . 0[2344c8]: POP3: Entering state: 15 0[2344c8]: POP3: Entering state: 35 0[2344c8]: SEND: XSENDER 1 0[2344c8]: Entering NET_ProcessPop3 5 0[2344c8]: POP3: Entering state: 3 0[2344c8]: RECV: +OK 0[2344c8]: POP3: Entering state: 36 0[2344c8]: POP3: Entering state: 18 0[2344c8]: SEND: RETR 1 0[2344c8]: Entering NET_ProcessPop3 5 0[2344c8]: POP3: Entering state: 3 0[2344c8]: RECV: +OK 0[2344c8]: POP3: Entering state: 19 0[2344c8]: Opening message stream: MSG_IncorporateBegin 0[2344c8]: Done opening message stream! 0[2344c8]: RECV: (null) 0[2344c8]: Entering NET_ProcessPop3 525 0[2344c8]: POP3: Entering state: 19 0[2344c8]: RECV: Received: from www.anydomain.org ([192.168.2.1]) 0[2344c8]: RECV: by sccrmxc12.attbi.com (sccrmxc12) with ESMTP 0[2344c8]: RECV: id <20030522170916s1200cc1she>; Thu, 22 May 2003 17:09:16 +0000 0[2344c8]: RECV: Received: (from user@localhost) 0[2344c8]: RECV: by www.anydomain.org (8.11.6/8.11.6) id h4MH9AH10916 0[2344c8]: RECV: for robertlaferla@attbi.com; Thu, 22 May 2003 13:09:10 -0400 0[2344c8]: RECV: Date: Thu, 22 May 2003 13:09:10 -0400 0[2344c8]: RECV: From: Robert La Ferla <user@www.anydomain.org> 0[2344c8]: RECV: Message-Id: <200305221709.h4MH9AH10916@www.anydomain.org> 0[2344c8]: RECV: To: robertlaferla@attbi.com 0[2344c8]: RECV: Subject: test 0[2344c8]: RECV: 0[2344c8]: RECV: testing 0[2344c8]: RECV: . 0[2344c8]: RECV: (null) 0[2344c8]: POP3: Entering state: 20 0[2344c8]: SEND: DELE 1 0[2344c8]: Entering NET_ProcessPop3 5 0[2344c8]: POP3: Entering state: 3 0[2344c8]: RECV: +OK 0[2344c8]: POP3: Entering state: 21 0[2344c8]: POP3: Entering state: 15 0[2344c8]: POP3: Entering state: 35 0[2344c8]: SEND: XSENDER 2 0[2344c8]: Entering NET_ProcessPop3 5 0[2344c8]: POP3: Entering state: 3 0[2344c8]: RECV: +OK 0[2344c8]: POP3: Entering state: 36 0[2344c8]: POP3: Entering state: 18 0[2344c8]: SEND: RETR 2 0[2344c8]: Entering NET_ProcessPop3 5 0[2344c8]: POP3: Entering state: 3 0[2344c8]: RECV: +OK 0[2344c8]: POP3: Entering state: 19 0[2344c8]: Opening message stream: MSG_IncorporateBegin 0[2344c8]: Done opening message stream! 0[2344c8]: RECV: (null) 0[2344c8]: Entering NET_ProcessPop3 524 0[2344c8]: POP3: Entering state: 19 0[2344c8]: RECV: Received: from www.anydomain.org ([192.168.2.1]) 0[2344c8]: RECV: by sccrmxc13.attbi.com (sccrmxc13) with ESMTP 0[2344c8]: RECV: id <20030522170922s1300iao0ce>; Thu, 22 May 2003 17:09:22 +0000 0[2344c8]: RECV: Received: (from user@localhost) 0[2344c8]: RECV: by www.anydomain.org (8.11.6/8.11.6) id h4MH9ME11125 0[2344c8]: RECV: for robertlaferla@attbi.com; Thu, 22 May 2003 13:09:22 -0400 0[2344c8]: RECV: Date: Thu, 22 May 2003 13:09:22 -0400 0[2344c8]: RECV: From: Robert La Ferla <user@anydomain.org> 0[2344c8]: RECV: Message-Id: <200305221709.h4MH9ME11125@www.anydomain.org> 0[2344c8]: RECV: To: robertlaferla@attbi.com 0[2344c8]: RECV: Subject: test 2 0[2344c8]: RECV: 0[2344c8]: RECV: test 0[2344c8]: RECV: . 0[2344c8]: RECV: (null) 0[2344c8]: POP3: Entering state: 20 0[2344c8]: SEND: DELE 2 0[2344c8]: Entering NET_ProcessPop3 5 0[2344c8]: POP3: Entering state: 3 0[2344c8]: RECV: +OK 0[2344c8]: POP3: Entering state: 21 0[2344c8]: POP3: Entering state: 15 0[2344c8]: POP3: Entering state: 22 0[2344c8]: SEND: QUIT

For me, this bug only began around the beginning of May, after upgrading to 1.4b and then back to 1.3.1

Er, Robert, you saw the problem while creating the log? I can't see anything going wrong there. And BTW, please always create an attachment for such logs to make the bug better readable and to not breaking long lines.

at first glance, it looks like we're never getting a response from the QUIT command. Perhaps the server is just dropping the connection. I'd still think we'd get told about this by necko and cleanup, but I'd have to step through it in the debugger.

I did not get the alert dialog but Mozilla mail did hang with a permanent busy cursor. It only happens after retrieving e-mail. If there were no messages to be retrieved, the bug doesn't appear. Perhaps we need to create two bug reports. One for the alert dialog and another for the busy cursor???

Once you have the permanent clocking cursor, try to get more mail for that folder and watch the Mozilla logo. The characteristic clawmarks do not appear and there is no evident network activity. In my case, mail on the POP3 site is waiting, but never retrieved until Mozilla is killed and restarted. BTW, my platform is Macintosh OS/X 10.2.6 As an aside, as a vertebrate paleontologist I believe the slashing should be replaced by a "shark bite" if you plan on keeping a Tyrannosaurian mascot. Slashing would be more appropriate for the Maniraptoria.

one fix for this in the pop3 protocol code would be to move the endmessagedownload code to the place where we know we're finished downloading messages, instead of in the DONE part of the pop3 protocol state machine. Then we wouldn't care if we didn't get a QUIT response.

this code moves the notification that we've finished downloading mail to before we send the quit command. If indeed that's why we're having trouble with this server, this patch might help. I've tried it on my pop3 server, and it doesn't seem to cause any regressions.

Comment on attachment 123997 [details] [diff] [review] potential fix r/sr/a=sspitzer, it looks reasonable. something I think we want now, for rc1.

I've checked in this patch - if anyone who's seeing this problem can download tomorrow's mozilla daily build and let me know if it fixes the problem, that would be extremely helpful. Thx!

All 3 of my problematic accounts were fixed yesterday (miraculously) so I am unable to verify this fix. Anybody else?

ha ha, it looks like attbi beat me to it. Marking fixed. If anyone still has this problem, it would be great if they could try today's build.

Disappeared in 2003052208. Thanks!

I know this bug apparently is fixed, but I saw a report on the WELL today which I am copying over here (with permission): > I recently had a problem with Mozilla 1.3.1. I kept getting a > recurring and very annoying message whenever I had the mail client > open. > > "This folder is being processed. Please wait until processing is > complete to get messages." > > The problem started almost immediately after I installed the following > Windows update: > > 330994: April 2003, Security Update for Outlook Express 6 SP1 > > I unistalled and now everything is happy again. The poster told me that he does, in fact, use attbi.com as a POP mailer, but that the problem was solved by uninstalling.

It looks like Comcast fixed their server yesterday. Unfortunately, we can't verify the fix but it should help in the future. You never know what may happen at or around the time of the actual switchover from ATTBI to Comcast on 6/30/03. I am running the latest build.

It looks like Comcast reverted their server change, as there is another mozilla 1.4b bug that effects their current ssl pop server on port 995. This server is used when you are roaming off the attbi/comcast network, such as at work. Does anyone else use that server? I get a different kind of hang than this one - the login info is sent, but it just hangs for a few minutes until the tcp connection times out. I'll file a separate bug on that problem next week.

After verifying that my Mozilla client worked fine again, I followed up with Comcast and confirmed that the ticket was closed. Unfortunately, the person I spoke with could not say why it was closed.

I recently (6/30/03) started getting this bug again with comcast mail... I have version 1.3.1 in Windows XP

I recently began having this bug appear again after the switch from ATTBI to COMCAST. WIN2000

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

I just tried out Mozilla 1.6a and I get the same bug. This bug began sometime ago, and became unbearable with Mozilla 1.5. In fact, just to be able to use my mail again, I had to go back to Mozilla 1.3.

Had a colleague whose Moz mail started doing this. We went into her Comcast.Net mail using the web interface and killed off the mail. After this step, Moz mail started working properly. It is a possibility that this error happens when a rare circumstance confuses ComCast's SMTP system,

I started seeing this message under 1.5 a couple of months ago (well after the comcast takeover of attbi). It continues under 1.6. Once I get the message, the only remedy that works is to exit all of Mozilla and start over. It has definitely not gone away.

I am pretty sure this is not a Moz problem but some fluke in the client IP stack. I use two different Post offices, (1 Comcast, 1 local=OpenVMS), and have not had this issue with MAC & VMS clients. It sometimes happens with 2000, though. I think something "goofy" is happening in Gatesland.