nlesueur Reporter
	Description • 13 years ago

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110510 Firefox/6.0a1
Build Identifier: 3.1.10

I have been able to successfully reproduce the POP auth spam flood with Thunderbird 3.1.10 using the following steps:

1. Start packet capture on port 110 
2. Setup an account to use any valid POP server
3. Supply an incorrect password 
4. Click "OK" to the message window that says the password is incorrect 
5. Click "Cancel" on the retry window 
6. Here is where the waiting game starts.  I have seen it take six minutes and I have seen it take up to eleven minutes, but eventually the flood will start and what you will see is the same connection being held open and multiple auth attempts being sent through.


Reproducible: Always

Steps to Reproduce:
1. Setup an account to use any valid POP server
2. Supply an incorrect password 
3. Click "OK" to the message window that says the password is incorrect 
4. Click "Cancel" on the retry window 
5. Wait ~6-15 minutes and eventually the flood will start and what you will see is the same connection being held open and multiple auth attempts being sent through.


Actual Results:  
Flood of POP authentication attempts repeated (around 3-4 a second) until Thunderbird is closed.

Expected Results:  
I would expect the software stop trying a known bad password until the user corrects the password, especially when the "cancel" button was selected in the retry window.  This behavior can appear as abusive to the POP server that is configured in the client.

I have been able to reproduce this on Windows XP and Linux X86-64.  I have not tried on any other operating systems.

	nlesueur Reporter
	Comment 1 • 13 years ago

I should note that there is no indication to the user that any authentication attempt is being made.  You have to do a packet capture to witness it on the user's side.

	nlesueur Reporter
	Comment 2 • 13 years ago

The time it takes for the flood to start seems to vary, but I am guessing that this is might be just part of the default 10 minute POP check setting, but I still do not understand why it tries with a password that is known to be invalid and why it tries repeatedly from that point forward.

	Dave Miller [:justdave]
	Comment 3 • 13 years ago

Adding security flag per request of user since this could be abused to DoS a mail server.

	nlesueur Reporter
	Comment 4 • 13 years ago

Please disregard my previous time measurements.  I have verified that the authentication attempts begin relative to the interval defined under "Check for new messages every X minutes".

	nlesueur Reporter
	Comment 5 • 13 years ago

the client is very polite (as expected) if the password is CORRECT

the tested auth method is Password with Security:None

	David :Bienvenu
	Comment 6 • 13 years ago

Can you try with a recent miramar build? I've redone some of the auth failure handling - http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-miramar/

	nlesueur Reporter
	Comment 7 • 13 years ago

David,

Thank you!  I just verified on the win32, linux i686, and x86_64 miramar builds that the behavior is now one auth attempt per ever X number of minutes as defined by the "check mail every X minutes" option.

	David :Bienvenu
	Comment 8 • 13 years ago

Great, thx very much for the verification! I'm going to mark this as a dup of the bug where I did some of the reworking...

	nlesueur Reporter
	Comment 9 • 13 years ago

I noticed that bug 428611 complains about the fact that the client does not tell the user that the password is bad and continues on as if everything is OK.  Since the client is still checking and the password is bad, is there anything planned for a "hey your password is still failing you know" dialog box?  If not, would it be beneficial if I submit a feature request for it.  It has been our experience that our customers had no idea that there was any authentication attempts being made, as 428611 states, when we call them and tell them they have a problem with their configuration.

	David :Bienvenu
	Comment 10 • 13 years ago

That's what bug 428611 is about - are you still seeing us not tell you there's a bad password? If so, would it be possible for me to get a test account?

	nlesueur Reporter
	Comment 11 • 13 years ago

Yes, during my testing, after the initial pair of "your password is wrong" and "Enter new password, cancel, retry" dialog boxes, the client is still trying to authenticate after I select "cancel" on the on Retry dialog box.  The difference now is it only does it once per X number of minutes.  The client still does not give the user any indication if you click cancel that it is still trying.

	David :Bienvenu
	Comment 12 • 13 years ago

oh, ok, we told you the password was bad - that's the main thing. The background check for new mail doesn't prompt the user because we don't want to block the UI for a background task.  If you pick cancel, you're essentially telling us the password is OK, so we're going to try again at the next background check for new mail.

	David :Bienvenu
	Comment 14 • 13 years ago

If you don't want us to check for new mail in the background, you need to turn that off in server settings.

	nlesueur Reporter
	Comment 15 • 13 years ago

Thank you... I understand the logic behind background processing and now that there is no longer a constant flood of authentication attempts after the first X minutes setting has been trigged, this is not a problem.

	David :Bienvenu
	Comment 16 • 13 years ago

ok, cool - so I'm guessing you didn't mean to re-open this again :-)