User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3 If I set up a mail account and when asked for the pop3 password I enter it incorrectly, I can no longer use that account. Deleting the mail account and starting again does not solve this problem like it used to. The incorrect password is sticking somewhere. This is a fundamental error. There needs to be a setting in the mail accounts preferences where the the password can be entered and changed by the user. If the password sent is incorrect, the software must ask the user for a correct password rather than stupidly attempting to send the incorrect password again. This error has always been present in TBird as far as I can remember. Reproducible: Always Steps to Reproduce: 1.set up pop3 email account 2.when asked for pop3 password, enter an incorrect password 3.close TBird 4.open TBird 5.attempt send/receive for thet pop3 account 6.see error message. Actual Results: The same as in the 'Details' box above Expected Results: I should have been asked to supply a correct password.

and why do you don't remove the stored password in the apssword manager ?

(In reply to comment #1) > and why do you don't remove the stored password in the apssword manager ? > RTFM you see :) Actually, I removed the actual pop passwords file (number).s However, my point still stands; other mail clients ask for another password on fail. For consistency of usability (see Schneidermann) "Keep the users' memory load as low as possible" I suppose this could be more of a feature request than a bug.

Dupe of bug 249240, I think. See also bug 289816.

Is this fixed on the trunk? I know I get reprompted for my pop3 password in some situations, so I know we do throw it away on occasion. I think the fix for bug 249240 may not have been in 1.0

(In reply to comment #3) > Dupe of bug 249240, I think. > See also bug 289816. Yes, it would appear to be a dupe of these two. Sorry if I am causing unnecessary effort here. N.

Duping per reporter's comment 5. (In reply to comment #4) > I think the fix for bug 249240 may not have been in 1.0 Bug 249240 comment 30 states that the patch was in 1.0RC1. I don't understand why 249240 was reopened shortly after that, the comments are a little confusing. *** This bug has been marked as a duplicate of 249240 ***