When connected to multiple email accounts over 24/7 datalink (static IP routed DSL), if one mail server is temporarily busy or otherwise unavailable, Password Manager forces user to reenter password (the default assumption being that the password is incorrect and must be changed to the correct one). Password Manager needs an option to allow user to lock in the password to override this default assumption. This problem can happen several times a day, as the ISP (pacbell.net ) has apparently decided to overload their mail servers a little too much...

Confirming, but I think that this would be better stated as a RFE: If the mail server doesn't accept the password provided, prefill the dialog to ask for a new password with the current one, so if the user thinks that the password is fine then he just has to press enter. Moreover, if the user press cancel, the login process stops, but the password isn't cleared in the database of the password manager, so next time it will be used again.

Sounds to me like the correct behavior should be as follows. If the user types in the password, then a failure to log in should result in the password being removed from the list, which is the current behavior. However if the password was prefilled and the user didn't change it, then the password is not removed from the saved list if a login failure occurs. I'm not sure yet whether this should be implemented in the password manager or in the mailnews code that calls the password manager. cc'ing a few mailnews people to see if it's possible to handle it in their code.

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

This is a particular problem for me as Mozilla 1.1 seems to be interpreting certain messages from my IMAP server as 'not available', and deletes the saved password. This is particularly the case at Mozilla closedown. The problem seems to go away if I only subscribe to 'Inbox'. Mozilla 1.0 was fine. Is 1.1 interpreting return codes or comms delays too brutally?

If the PASS command failed, it should still warn me and prompt for the password, but since I've previously stored that password, it should appear in the dialog (as "*********"). Currently, the password field is totally empty, so I have to go to my office desktop and grab the paper with the password from my ISP and manually enter it in the password field again. Very annoying.

Attaching untested patch just so I don't lose it (I almost did). This patch considers passwords that were set more than five minutes ago to be "sacred" and will not delete them if the login attempt failed.

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

The dialog box needs to time out if not acknowledge and default to try again later with last known good. There also needs to be an option to try again later. Because a mail server can be in this mode for hours at a time, the retries and timeouts should continue silently (after the first notice) until a manual "Get Messages" or some other method of getting the mail server status is requested. Microsoft Outlook behaves this way, and it is a much more user friendly behavior than any that I have seen proposed in these bug reports. It is kind of ridiculous to have to keep checking mail manauly and dismissing the dialog box until the ISP gets their mail server fixed.

I agree that there should be a default timeout, whereafter the mail program tries again.

Comments 10 and 11 are requests for enhancement, and as such they are not part of this bug report. Please open a separate report for those features. The implementation of that would be in mailnews rather than password manager.

Comment on attachment 98249 [details] [diff] [review] same patch but tested and bugs fixed sr=jst

Comment on attachment 98249 [details] [diff] [review] same patch but tested and bugs fixed r=jag

checked in

When the mailserver is unavailable or the password is incorrect shouldn't (doesn't?) Mozilla reflect this in an error message? Outlook while quoted as behaving quite well is a pain for IT support and anyone who simply wants to know what's going on. For example when the mailserver is unavailable it simply asks for a the password instead of somehow making it obvious to the user _why_ it's asking for a password. Am I right to assume this patch introduces the same behavior?

No, this patch does not introduce such a behavior. On the contrary, it will cause relogins to be attempted transparent to the user because the saved password is not being discarded.

I have observed the following behaviour starting in 12.b. My mail server intermittently returns bad authentication, even for good passwords, and continues to do this for several minutes. During this time, Mozilla gives me an error message every couple of seconds with no prompt for a password and no way to cancel the dialog, making the whole thing unusable until my mail server gets its act together. Prior to 1.0, the whole thing was retried invisibly and I never got any dialogs. It may not have been desirable for more serious and permanent errors but at least it worked. Then in 1.0 (I think, may have been 1.1) I started to get reprompted for my password on every error, which I think is the problem this bug addresses. Anyway, in 1.2b, the mail frontend seems to lose its buttons (except for compose) after a while, perhaps a max retries has been reached. I have to completely shutdown Mozilla to get everything working again. I suppose that technically, since the password is no longer lost, this bug has been fixed, but I don't find the current behaviour acceptable.

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

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

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

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

this patch makes it so if the user's password changes on the server, we'll never throw it away and we'll never prompt the user for the correct password, effectively forcing the user to remove the password using the password manager. This is not good.

Shouldn't Mozilla just make the distinction between an -ERR response (POP3) and a failure to successfully log in. They can, and usually are, separate and distinct events.

reopening, and taking - this fix has been backed out.

taking. And yes, we should try to distinguish why the logon failed. I assume this refers to pop3; I don't think IMAP has this problem.

Yes, POP3 is a problem. The protocol itself provides no information whether the password was wrong or something else. Extended Response Codes introduced in RFC 2449 are a little improvement, but nothing we can rely on. Bug 151452 added code to prevend us from discarding the password in case of [LOGIN-RELAY] and [IN-USE]. But if a server doesn't use these extended codes, any -ERR response in login process will bring up the password dialog.

It's not the password dialog that sucks, but when Mozilla "forgets" the password. I don't imagine that there would be much reason to object to popping a password dialog when we get an -ERR from a POP3 server as long as it comes prefilled with the previous password. The problem that I was seeing that got my name on the CC list here was not related to an -ERR response, but any login failure. Say the server was offline and Mozilla had timed out trying to reach the server...boom, no password, etc. That behavior is what is unacceptable.

You're right, this bug started because the password was discarded by any login failure. And that's weird as it shouldn't happen from what the code says. We'll investigate this problem if it happens again. But the now backed out fix really was the wrong way and introduced side effects. I like the idea to prefill the password dialog. But as it looks to me it's not easy to implement. Currently we forget the password first and then calling the dialog. Realizing the prefill should be a second step resp. another bug as it only eases a symptom but not the problem.

Soulution proposal: When login fails, prompt for new password. Keep the old password as long as login fails. Save new password as soon as login succeeds. Prefill the dialogue with the saved password. This will solve all problems discussed here: - when login fails (because of connection or server problems), and the user accidently enters a wrong password, this has no effect. - when the user changes the password on the server, he can easily update his password in mozilla.

This also happens on Linux.

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

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

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

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

I checked in a fix to bug 219162 that should help with this problem for pop3 users. If any of you are having this problem with pop, and want to test tomorrow's build and report back in this bug or bug 219162, that would be helpful.

David: I don't see this problem with a recent trunk build anymore. I used to suffer from this in the last weeks because my Email-Provider restricted the access to the POP3 server with a min poll interval of 15 minutes. When I pressed "Get Msgs" to early I had to reenter the password after the error message popped up. Now I just see the error message and Mozilla still remembers the password. :-) It also regressed as expected. ;-) I changed the password for the POP3 account and wasn't prompted for a new one when the login failed.

> It also regressed as expected. ;-) I changed the password for the POP3 account > and wasn't prompted for a new one when the login failed. Hm, but you didn't loop with endless "password rejected" (or so) dialogs? Or does your Mozilla check for new messages every x minutes? Would you please try to manually get messages with the password changed on the server?

Stefan, do you mean you pressed get new mail, and you weren't prompted for a new password? Do you know if your server drops the connection when the wrong password is sent? A POP3 protocol log would help. http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap But, I guess I can mark this bug as fixed?

> Stefan, do you mean you pressed get new mail, and you weren't prompted > for a new password? Exactly. I think this is the issue you described in bug 21962 comment 47. > Do you know if your server drops the connection when the wrong > password is sent? Yes, it does directly after it sends the error message: $ telnet pop3.web.de 110 Trying 217.72.192.134... Connected to pop3.web.de. Escape character is '^]'. +OK WEB.DE POP3-Server USER borggraefe +OK Bitte Kennwort eingeben/enter password PASS totallyWrongPassword -ERR Benutzer oder Kennwort falsch/user or password wrong Connection closed by foreign host. > A POP3 protocol log would help. I'll attach it in a minute. > But, I guess I can mark this bug as fixed? I think so. Or is this a dupe of bug 219162?

POP3 log, see comment #39 and #40.

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

I think the issue has been muddied a bit due to a regression and also a request for enhancement. With every version of Mozilla up to 1.4 release (inc.), this is the behaviour I have seen: Scenario: User has a POP account with an ISP that has a temperamental POP server. User successfully sets up account on Mozilla, checks mail, saves password. Mail checks continue to work with saved details. Temperamental ISP server rejects the password for unknown reason, even though the password is correct. Mozilla, up to and including 1.4 release, would pop an error saying bad password. User waits a few minutes, checks mail again, mail is checked and downloaded successfully. New problem (in my experience) with 1.5b and later: Mozilla now pops the error saying bad password, but forgets the password. User has to enter it again. Proposed solution, taking into account what people have said: Usual error is given, bad password. User checks mail again, and a requester pops up, on the lines of: "The mail server has rejected your POP3 username and/or password. Please re-enter your details: Username: <load the already saved username> Password: <load the already saved password, or if password isn't saved, blank> [ ] Save password? <default is ticked> [ OK ] [ Cancel ] [ Create an error log* ]" * - another suggestion, tech support people might like it.

Im not sure it should be marked a dupe of 219162, but a dependency, i feel should be added, I added 91656 as being blocked due to its very similar nature

Up to 1.4, the password prompt behaves as you'd expect to if the password is bad, even if there is a different underlying issue, e.g. network fault or mail server is down.

Similar Thunderbird problem ( Bug 220010 ) was reported for news server. Is this Bug 160425 applicable to news server?

There's another very odd thing I've just noticed - email accounts that have had the passwords bounced back some time ago - if the user clicks cancel (in an effort not to have to re-type the same password in), Mozilla simply doesn't bother even trying to check the email account. I've got two email accounts that haven't been checked in a month and I was none the wiser. The lack of spam in the meantime was nice though. :-) I noticed this new behaviour with 1.5 release / win32.

If I understand you correctly, your passwords where recognized as wrong some time ago but you hit cancel in the dialog instead entering the passwords. And from this time on Mozilla didn't check these accounts, yes?

Correct. BTi's mailservers, when they get busy tend to reject authentication even though the details are correct. A reason I switched from Eudora was that it forced me to re-enter my passwords every time this happened.

Although now I'm seeing random behaviour. Sometimes the password is remembered, used again and works, sometimes it is forgotten, sometimes the password prompt doesn't appear and only the bad password message, it's very odd.

In reply to my last comment - the behaviour differs if the user presses the stop button after the error message is posted (and before the password prompt might appear).

I experience this problem frequently with BTOpenWorld, I have to re-enter my mail password at least once per week as a consequence. I would like to see a popup like this when the mail server password appears invalid: ---------- The server did not authenticate account xxxx with the stored password. You can enter a new password here or choose to try again with the new password. Password: [prefilled with old password masked as asterisks] [Try again] [OK] [Cancel] --------- Try again ignores whatever is in the Password field and tries again with the old password, OK sets the password to whatever is in the Password field (assuming its not NULL) and tries again, Cancel ignores what is in the password field and stops trying. Closing the dialogue box is the same as clicking cancel.

Although from my experience with BTo, you have to disconnect from the server first before attempting to authenticate again, otherwise (in my experience, YMMV) it will always fail.

Not sure if that is BTi mail server or mozilla - but if I shut down the mailnews component and re-open it, authentication can often start working again. I'll investigate with telnet when it happens again, to see what if anything the server is actually returning.

I have five POP3 accounts in Thunderbird, three of which use the same server, one uses a different POP3 server, and one I just use to send mail (no mail is ever received from that account). Password manager constantly fails to remember the password for the account that is using the different POP3 server. Sometimes it happens every couple of minutes, sometimes hours, and sometimes I can go days without seeing the problem. This has only happened recently while upgrading from 0.7 to 0.8, and to 0.9 somewhat recently. I've created a POP3 log as per the instructions found at http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap and this is what I have come up with: http://www.rapta.com/dump.html The account "bmblion" is the one that is raising hell, and I can only assume it has to do with the error being generated by the POP3 server that the password is invalid. However, the password was never changed between the last mail check, and the mail check where the password was said to be invalid. Either Thunderbird is kludging up the password that is being sent, or something rather goofy is going on that I can't figure out. Perhaps a better solution to this would be to add an option to Thunderbird to continue to use the same password over-and-over regardless of concurrent errors, or to prompt for a new password when an error occurs (which would be the default).

(In reply to comment #55) > The account "bmblion" is the one that is raising hell, and I can only assume > it has to do with the error being generated by the POP3 server that the > password is invalid. However, the password was never changed between the last > mail check, and the mail check where the password was said to be invalid. Right, that's since fix of bug 257299. Other than most servers this one supports the advanced response codes for more differentiated error reports. And in "-ERR [AUTH] Password supplied for "bmblion" is incorrect." it uses one that means "I'm certain the password is wrong". And so we believe it. > Either Thunderbird is kludging up the password that is being sent, or > something rather goofy is going on that I can't figure out. Yeah, that's alsways the point where we built-in logging mechanism doesn't help because it suppresses any password sent. The only way you can find out if TB sends the right or not is using an external logger like Ethereal or tcpdump/windump. If you're willing to try I can give you some more help via mail. > Perhaps a better solution to this would be to add an option to Thunderbird to > continue to use the same password over-and-over regardless of concurrent > errors, or to prompt for a new password when an error occurs (which would be > the default). Normally we fall back to other mechanisms (if available) and try logging in using the same password twice. But since we got the message the server is sure about the wrong password ...

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

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

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

I actually have the problem, that my mail-provider blocks my ip, when thunderbird tries to get mail on and on, even when errors ocour. Deleting this blokade is time consuming and expensive :-( So I dont want thunderbird to ignore login errors, but I understand that in some cases it might be wanted. So I would vote for a user option in server options. A checkbox called something like "do not delete password on error" which is off by default, would be very nice.

I am using Thunderbird 1.5 on Mac OS. "Me too!".

Thunderbird 1.5.0.9 (20061207) produces the very same on Win XP professional! Since the last update (maybe it was before the last, don't know, it's automatic) TB asks for password when there's server communication problem. I've been using 3 absolutely different internet connections on several locations (DSL, DSL fixip, cable) for a long time, so it's not the net connection that has changed. The same TB version is used on two different computers (desktop, notebook) with different mailboxes, and both TBs/mailboxes are affected.

We've basically implemented what's in #2 and #52 in 2.0 - so I'm going to mark this WFM.

Problem still occurring while using TB 2.0.0.4 and 2.0.0.5 (German). Some mail server having been unavailable, TB has deleted the (valid) password from the password manager without asking me. Cf. my posting <news:46AC570D.1050303@matthias.spanier.dialin.t-online.de> in <news:de.comm.software.mozilla.mailnews>. I kindly ask for a solution. E.g. TB might ask the user whether to delete the password or not. If the user believes the password to be valid and the problem to be caused by a mail server not being avallable, he should be able to tell the password manager to keep that password.

I'd like to ask for a fix, too. This bug is more than annoying, especially when you have to look after people who don't read the error message probably and try to type in their password for the password manager instead of the password to the pop3 server. So pleeeeeeeeeease fix this bug!

Now Mozilla Thunderbird decided that it was time to annoy the hell out of me again! As soon as the mail provider had a problem, Thunderbird took it as an excuse to throw away all the passwords that I had told it to store! This data loss bug is not yet fixed in version 2.0.0.9 (20071124).

Still seeing this in TB 2.0.0.14 on Linux - Please resurrect this bug. How to reproduce (100% reproducible): 0. Set a master password in Thunderbird. 1. Add an IMAP account, and store the password. 2. Restart Thunderbird. 3. Wait for a minute or two. 4. Fill in the master password. 5. Press OK in the IMAP password prompt. 6. Press OK in the alert box saying that the login failed. Your IMAP password is now lost from signons.txt. It looks like TB starts the login sequence, then is asked by the server to provide a password, and only then displays the master password dialog. Proposed fix: Either restart the login sequence when the master password has been filled in, or automatically retry login once if it timed out, before asking the user for a new password. Also, only remove the saved password if a login with a different password succeeds. Removing passwords should be done in the settings.