270249 - Thunderbird is hitting the server 1000+ times per minute

Status: RESOLVED FIXED

(MailNews Core :: Networking: POP, defect)

Description

[amy]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Thunderbird 0.9

I am a student living on campus at Penn State University, main campus. I have
been using Thunderbird to check my Penn State (@psu.edu) E-mail since mid
September. From my end, it seems to be working fine, and I find it much easier
to use than their Webmail.psu.edu. Apparently, Thunderbird is causing some
problems for the server, but I am not sure if it is Penn State's fault of
Thunderbird's fault. 
I got a phone call a few weeks ago from Penn State Security, and they informed
me that Thunderbird was going out to the server 100-1,000 or more times per
minute. At that time, I had Thunderbird 0.7.3. Going out to the server this many
times was making it so that other people on campus could not check their
@psu.edu E-mail online. Apparently, there were a few other people on campus that
were having the same problem. I have the options set to check for new messages
every 2 minutes. I downloaded TB 0.9, to see if that would fix the problem, and
it seemed to, but then, last night, I got the following E-mail:

>Unfortunately, your computer was abusing the POP server again. To stop the
>activity, the Postmaster has blackholed your connection.

>Here is an excerpt from the logs:

>Nov 15 00:01:39 f07g05.cac.psu.edu From seawolf: popper: -ERR adp5001 must
wait 2 seconds before checking mail again.
>Nov 15 00:01:39 f07g05.cac.psu.edu From seawolf: popper: -ERR adp5001 must
wait 2 seconds before checking mail again.
>Nov 15 00:01:39 f07g05.cac.psu.edu From seawolf: popper: -ERR adp5001 must
wait 2 seconds before checking mail again.
>Nov 15 00:01:39 f07g05.cac.psu.edu From seawolf: popper: -ERR adp5001 must
wait 2 seconds before checking mail again.
>Nov 15 00:01:39 f07g05.cac.psu.edu From seawolf: popper: -ERR adp5001 must
wait 2 seconds before checking mail again.
>Nov 15 00:01:39 f07g05.cac.psu.edu From seawolf: popper: -ERR adp5001 must
wait 2 seconds before checking mail again.
>Nov 15 00:01:39 f07g05.cac.psu.edu From seawolf: popper: -ERR adp5001 must
wait 2 seconds before checking mail again.
>Nov 15 00:01:39 f07g05.cac.psu.edu From seawolf: popper: -ERR adp5001 must
wait 2 seconds before checking mail again.
>Nov 15 00:01:40 f07g05.cac.psu.edu From seawolf: popper: User adp5001 from
**.**.**.*** 0 0 1
<<**.**.**.*** represents my ISP>>

>Your connection will remain blackholed until the problem can resolved.

Apparently, since I installed TB 0.9, there wasn't a problem until last night.
Does that log appear to be TB's fault or Penn State's? If it is PSU's fault, any
suggestions of what I could tell them to do to fix it? It looks to me like that
"seawolf" computer might be somewhat responsible for the repeated checkings, as
if "seawolf" is encouraging TB to check back too often, but maybe it's TB...
I just did a virus scan (Symantic) last night, and I did Spybot and Ad-Aware
this morning, but maybe there is something on my computer that they don't
find... I updated each right before I used it, but I did hear from someone that
they had to find a virus that was causing them different problems (they don't
even use TB) by going through the list of Running Processes in Task Manager and
deleting the bad one, but I don't even know how I would go about looking for a
virus or something on my own... I don't know what is good and what is bad.
Ignorance is not always bliss.

Do you have any suggestions as to what I can do or what Penn State can do to fix
this problem? Or is this a Thunderbird Bug that could be fixed for a future TB
version?

Thank you very much for your help... I hope I am contacting the right place... I
have been communicating with a few people on your Thunderbird Bugs forum... That
conversation is titled: Mail checks about 1,000 times per minute :(

AMY

Reproducible: Didn't try
Steps to Reproduce:
I don't know how to reproduce the problem... it seems pretty random... Security
just notified me to let me know that they were blocking Thunderbird from the
server and that I would not be able to use TB again until the problem was fixed.
Actual Results:  
N/A

Expected Results:  
TB should have behaved itself and not gone absolutely nuts when communicating
with "seafox"

The problem does not occur if I disconnect from the internet by blocking
internet traffic using Zone Alarm or pulling the internet cable, but I am not
sure if just telling TB to not check automatically for messages would fix the
problem. 

The problem has occured using both Thunderbird 0.7.3 and Thunderbird 0.9

Comment 1

[David :Bienvenu]

yikes, are we looping trying to logon?

Comment 2

[Jo Hermans]

dupe of bug 189633 (for MailNews)

Comment 3

[David :Bienvenu]

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

Comment 4

[Christian Eyrich]

(In reply to comment #0)
> Do you have any suggestions as to what I can do or what Penn State can do to
> fix this problem? Or is this a Thunderbird Bug that could be fixed for a
> future TB version?

I'd say if a client throws requests like mad it's very likely the client but I
can't say for sure at the moment.
If a server implements a delay between logins, supporting LOGIN-DELAY from RFC
2449 is always a good idea. That could help here if it's TB's fault or not.

My question is, did you see any alert like "login failed" or "The PASS command
did not succeed" when logging in your psu account?

Comment 5

[David :Bienvenu]

I suspect that at times the mailbox gets locked or for whatever reason, the
logon fails, and it seems like we might just keep retrying...Christian, I'm
going to try to code up a patch to limit the retry count on a single url
(probably to 5), unless you're in the middle of already doing that.

Comment 6

[Christian Eyrich]

(In reply to comment #2)
> dupe of bug 189633 (for MailNews)

Well, it's a psu account affected both times.
But the server log should not show that many hits without the user is clicking
away the alert at the same rate. So I wouldn't dupe it for now.

(In reply to comment #1)
> are we looping trying to logon?
I fear we do but I can't imagine why.

Comment 7

[Christian Eyrich]

(In reply to comment #5)
> I suspect that at times the mailbox gets locked or for whatever reason, the
> logon fails, and it seems like we might just keep retrying...Christian, I'm
> going to try to code up a patch to limit the retry count on a single url
> (probably to 5), unless you're in the middle of already doing that.

As I wrote in bug 269292 (which should be duped against 189633 I guess) that
should be done in any case. But I didn't start yet.
But I'm not sure it will help here. Each failed attempt (resp. each time after
falling through the different mechanisms) we issue Error() (see
http://lxr.mozilla.org/seamonkey/source/mailnews/local/src/nsPop3Protocol.cpp#1466).
And at this point no server request should be issued until the user clicks OK.
But if this mechanism fails, I fear that logon limitter would too.

Comment 8

[David :Bienvenu]

Check for new mail doesn't pop up alerts, right? And if we think we've failed to
logon because of a bad password, but it's really a different error, and the user
has remember password turned on, and has logged on successfully in the current
tbird session, couldn't we loop forever?

Comment 9

[Christian Eyrich]

(In reply to comment #8)
> Check for new mail doesn't pop up alerts, right?

Not without a problem being reported by the server.

> and has logged on successfully in the current tbird session, couldn't we loop
> forever?

From the current concept we can loop forever but not without intermediate
alerts. How would it be possible line 1466 is being bypassed?

Comment 10

[David :Bienvenu]

I'm not saying that line is being bypassed. But that line won't put up an alert
if it's the automatic check for new mail. If we then get to line 3772, we'll
start all over again, right? If the password is saved, and it's an automatic
check, and a logon has already succeeded in this session, won't we continue w/o
alerting the user?

Comment 11

[David :Bienvenu]

Attachment: potential fix

limit retries to 5

Comment 12

[OstGote!]

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

Comment 13

[Christian Eyrich]

(In reply to comment #10)
> I'm not saying that line is being bypassed. But that line won't put up an alert
> if it's the automatic check for new mail.

Ah sorry, I must have been blind. I didn't realize Error() doesn't display the
error if biffing ...

So yes, the limiter works. Though I would have modified the code around line
#1478 like
  m_pop3ConData->logonFailureCount++;
  if (m_pop3ConData->logonFailureCount <= 5)
    SetFlag(POP3_PASSWORD_FAILED);


Maybe not the right place but I want to note that here. We're not looping in the
POP3_AUTH_FAILURE-case though the Error() isn't displayed and though
logonFailureCount isn't increased.
That's because we're always ask for a new password and this prompt isn't hidden
even when biffing.
But I think the user could be irritated if we're prompting before saying what's
happend (since Error() is suppressed).

Comment 14

[David :Bienvenu]

Christian, do you want to propose a patch? You're much more familiar with the
various error code paths...I've checked my patch into the tbird 1.0 branch so
Amy can try it out but improvements would be welcome for both the trunk and branch.

Comment 15

[Christian Eyrich]

(In reply to comment #14)
> Christian, do you want to propose a patch? You're much more familiar with the
> various error code paths...

I just meant not even setting POP3_PASSWORD_FAILED would be nicer than setting
it and adding a condition to ignore it down in POP3_ERROR_DONE. But if you
already checked yours in, I can live with that of course.


Regarding the password prompt without issuing an alert before I've no idea for
an improvement. How should the nsIMsgMailNewsUrl suddenly get a non-nsnull
nsIMsgWindow? But I guess I'd better open a separate bug for that.

Comment 16

[Asa Dotzler [:asa]]

Comment on attachment 166190 [details] [diff] [review]
potential fix

a=asa