Closed Bug 205379 Opened 21 years ago Closed 21 years ago

"This folder is being processed" alert getting mail from ATTBI.COM

Categories

(MailNews Core :: Networking: POP, defect)

Product:
MailNews Core
Component:
Networking: POP
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: hlb, Assigned: sspitzer)

References

Details

Attachments

(1 file)

potential fix
1.62 KB, patch
sspitzer
: review+
sspitzer
: superreview+
sspitzer
: approval1.4+
Details | Diff | Splinter Review 
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 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
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.
OS: Linux → All
Summary: Alert: This folder is being processed. Please wait until processing is complete to get messages. → "This folder is being processed" alert getting mail from ATTBI.COM
*** 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.
Attached patch potential fix — — Splinter Review 
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.
Attachment #123997 - Flags: superreview+
Attachment #123997 - Flags: review+
Attachment #123997 - Flags: approval1.4+
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.
Status: NEW → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
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.
Product: MailNews → Core
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: