Closed Bug 219162 Opened 17 years ago Closed 17 years ago
Password Manager forgets password when checking mail
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030912 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030912 Several times in the past week, Mozilla has started forgetting my password when checking mail. It will keep prompting me for a password. Quitting and reopening Mozilla, and entering my password, will fix it for several hours... rince and repeat. Definately not a mail server problem. Another email client is working just fine, no interuptions. Reproducible: Always Steps to Reproduce:
I confirm this ! I got this problem several times. It could be that the server answers with an error during the login but i couldn't see an error popup. Christian: Is it possible that Mozilla displays no error message from the server in such a case ?
I don't think the server is giving an error. Looks to me like it's just forgetting the password. Either way, it looks like a serious regression for 1.5 (not sure if it impacts 1.4.1) IMHO blocker, but I'll let someone else make that decision as I'm not important.
We indeed changed the behaviour on failure to prevend loops. But this should make PM forget the PW only in case of error. Robert, please change Product to MailNews and the Component to the protocol you're using to get mail (POP3, IMAP). Or do you have this problem with both protocols? Matti, what protocol are you using? It's possible to get no error message displayed if you have checked your mail automatically background. But for manual mail check I don't think so. A communications log would be best again. But not that easy to create in this case as it doesn't happen always, right?
I use pop3 and I know that my server sometimes respons with an error but I never get a error message with recent builds and the password is sometimes lost. I know that the password is lost due to the other reopened bug (btw: I hate it !) but older builds displayed the server error message.
> I use pop3 and I know that my server sometimes respons with an error but I never > get a error message with recent builds and the password is sometimes lost. You _know_, your server sometimes respons with an error? Do you know with what error? Or know how to produce? Without knowing the error or the situation in which it occurs I cannot tell why it's not displayed. IMO we don't hide errors except when auto check is active. > I know that the password is lost due to the other reopened bug (btw: I hate it > !) but older builds displayed the server error message. I guess you speak of bug 160425. That might be, yes and it's your right to hate it. But before reopening that patch other people hated the old behaviour ...
for my case : just let mozilla autocheck and get this error popup with Mozilla1.4 : "The PASS command did not suceed. Mail server foo responded: les: fatal: unable to move /home/vpopmail/etc/tcp.smtp.tmp.2108 to /home/vpopmail/etc/tcp.smtp.cdb: file does not exist" A log could be difficult (size) because I get this only sometimes (every 1-2h with a 5 minute auocheck) My password is lost (bug 160425) but the error doesn't display with a nightly trunk
Changing to mail&news, flagging blocking1.5 as it seems I'm not the only one with this issue (and I continue to see it).
Component: Password Manager → Networking: POP
Product: Browser → MailNews
Is this blocking 1.5? I personally find this a blocker. Not sure how wide spread it is. I like it to remember my password, as entering it every few minutes is a real pain. Lastly, can someone change this to "new"
I'd rather dupe this bug to bug 160425. All aspects of this bug are covered by that - except that you say, you don't get an error message. But that's only an issue if you auto check your account. > Not sure how wide spread it is. I don't think that wide spread. It affects users using faulty servers. Good servers only throw an error in answer to password if the password is wrong. I don't wanna say, this bug can't be annoying. And I don't wanna say it shouldn't be fixed. But this Mozilla bug is only a symptom of a server bug. At least as far I can see from the informations provided here.
bug 160425 looks like an old bug. This is a *new* issue. There was no problem in 1.4, 1.3, 1.2, 1.1, 1.0, or any other release in my memory. I'm using the same mail server since May 03, and another one since Sept. 02. I even tried one that I stopped using way back... and it had the same result. 3 mail servers that worked with previous versions. So it's not the server, it's Mozilla, as previous versions (anything below 1.5) didn't have a problem. IMHO it's a new bug, because it's a different issue with the same impact on the end user. This bug, doesn't apply to anything other than 1.5 (1.4.1 I haven't tested, but I know 1.4 doesn't have this issue). So it's different because it doesn't matter what the mail server is or does. AND it only effects 1.5+ that I can see. bug 160425 should effect all versions to my understanding.
> There was no problem in 1.4, 1.3, 1.2, 1.1, 1.0, or any other release in my > memory. Because the former patch for bug 160425 was backed out on 2003-07-30, short after relaese of 1.5a. This patch made that passwords saved more than 15 minutes ago never be discarded - even if they were wrong. > So it's not the server, it's Mozilla, as previous versions (anything below > 1.5) didn't have a problem. > So it's different because it doesn't matter what the mail server is or does. Ah great, so you think Mozilla discard the passwords randomly, without any signal from the server, yes? Ok, so your original Product and Component would have been right. But I can't do anything against it. I won't go hunting a random error that occurs without a visible reason.
> Because the former patch for bug 160425 was backed out on 2003-07-30, short > after relaese of 1.5a. > This patch made that passwords saved more than 15 minutes ago never be > discarded > - even if they were wrong. It can happen repeatedly. can happen after 1 minute, or several hours. > Ah great, so you think Mozilla discard the passwords randomly, without any > signal from the server, yes? Can't confirm that, but it's my belief. I can't packet sniff, on a school network for legal reasons... so I can't really say. > Ok, so your original Product and Component would have been right. But I can't > do anything against it. I won't go hunting a random error that occurs without > a visible reason. I think it was password manager, though I will let someone else change it back if they feel it's more qualified. I'm not quite sure. I don't see random errors, or any other problems other than this.
mscott, ssptizer, bienvenu, can one of you take a look at this?
I still see this problem on RC1. I can't find any pattern to this. "it just happens from time to time". To get it to take my password successfully again, I need to quit Mozilla, open mozilla again, enter my password, and check save to password manager. Then I'm good for a while.
Christian, might your patch to look err codes for pop3 servers with CAPA help here? I think I checked that into 1.6. Could we get a log from someone who sees this? Then we could tell if the server in question has the CAPA extension and if so, if the problem is likely to be fixed.
Assignee: dveditz+bmo → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true
I see this sometimes 2-5 times a day... sometimes not for 2-3 days. Just had it this morning. Teach me how to log, and I will log. Hopefully catch this. It's real annoying. Password Manager is very unappreciated until it doesn't seem to work for you. Then you realize how great it is.
ah, sorry, I thought there were already instructions. Follow these instructions for POP3: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
Should the value be: Variables: NSPR_LOG_MODULES Value: IMAP:5 ?
no, setenv NSPR_LOG_MODULES=POP3:5
That would explain why it wasn't logging anything. Off to logging. Hopefully back sooner than later with something useful.
David, the patch could help if the cause is an -ERR sent by mistake. But, five days ago Robert denied the problem can be caused by a server answer. And even if the server sends -ERR this can only be the reason for discarding the password. But wouldn't explain why Robert has to quit Mozilla and open it again before it takes the password again. Will see the log tomorrow.
It's now logging... hopefully the problem will manifest again so we can see. I try re-entering the password when prompted, but it just keeps asking me again and again and again. Never actually checking. Restarting Mozilla corrects it.
no, that doesn't explain why he has to quit and restart - we'll just have to see the log and hope it has something helpful.
Ok, I got something, a little different from the error before (this is the first time I've gotten it with 1.5rc1). In 1.7MB Log file. Since this log does contain some email information, I would perfer the bug be considered security if possible. I'm not exacly thrilled on posting it to the general public (would take quite some time to clean up the log... and not sure if that would negatively effect it's validity).
It apparantly starts after a set of binary characters (which no text editor I have can read). It then reads as follows --------------------------- Log --------------------------- 4018]: POP3: Entering state: 2 0: POP3: Entering state: 4 0: RECV: +OK <c23c9b1ddc10770290c90a5e3faee30c@green> 0: POP3: Entering state: 31 0: POP3: Entering state: 5 0: SEND: USER firstname.lastname@example.org 0: Entering NET_ProcessPop3 28 0: POP3: Entering state: 3 0: RECV: +OK Tell me your password. 0: POP3: Entering state: 32 0: POP3: Entering state: 6 0: Logging suppressed for this command (it probably contained authentication information) 0: Entering NET_ProcessPop3 78 0: POP3: Entering state: 3 0: RECV: -ERR Unable to open mailbox; it may be locked by another concurrent session. 0: POP3: Entering state: 7 0: POP3: Entering state: 24 0: POP3: Entering state: 0 0: POP3: Entering state: 25 --------------------------- /Log --------------------------- To me the question is what's happening before (where those binary characters are)? This is the only intelegent (readable) portion of the log.
A few lines before the start of the snap you posted is binary crap? You can e-mail the whole unchanged log to my address if you like. You could use a hex editor to cut the 1.7 MB file down before. But is no must.
Robert sent me a complete log file. The printable text is the same like in comment #25. But it also contains two confusing things: 1. the file is filled with over hundred KB of null bytes (0x0) before the printable text (the 1.7 MB log he mentioned is almost all 0x0 too). 2. behind the string SEND: USER email@example.com the log contains a single 0x0d (CR) (hence the additional line break in the log above). I don't think this is the cause of Roberts problem. But maybe another symptom of the problem. If Mozilla writes out thousands of null bytes, something is really wrong.
Here's why we dropped the password: POP3: Entering state: 3 0: RECV: -ERR Unable to open mailbox; it may be locked by another concurrent session. We can't tell this logon failure from a bad password failure. I'm not sure why the server couldn't open the inbox but I don't think it was Mozilla that had the session open. I think the only way we can handle this, other than sniffing the error returned by the server to see if it mentions password, the only think I can think to do is check if we've been authenticated to this pop3 server in the current mozilla session, and if so, don't drop the password. Or, if the password is in the password manager, we could just try it again one more time and see if the error is temporary... I don't know what the null bytes in the log are - that's very odd.
Status: NEW → ASSIGNED
David, Is this a change of functionality since 1.4? In 1.4 I had no problems. In 1.5b+ (never used 1.5a) I see the problems.
yes, it's a change since 1.4. With 1.4, if your password changed, we would just continually logon with the original password, and fail, and never prompt the user for the new password. So we made it so if the logon failed, we forgot the password. Unfortunately, POP3 is really primitive about error codes and so on, so the client basically has to guess.
Well your little change is annoying the ____ out of me ;-) It's driving me nuts. Any chance on getting some sort of solution in for 1.5? It's making mail&news seriously stink. I can't just trust it to check my mail on interval anymore... that's a big regression (to me personally).
I realize it's a painful problem. I doubt this will get into 1.5 (since we don't even have a fix) but we would try to get it into 1.5.1 or something like that.
Robert, if you've influence on the servers software, choose one (or an enhancement) that implements the Extended POP3 Response Codes from RFC 2449 (especially [IN-USE]) or RFC 3206. This makes POP3 error codes more meaningful. David, your suggestion from comment #28 would be easy to implement. If a login succeeded, we set a flag and if login fails later, we'd handle it like POP3_STOPLOGIN. Besides I hate workarounds for silly servers I hope this won't have another annoying side effect.
yes, we already have such a flag in the nsIMsgIncomingServer: GetIsAuthenticated() I think it does the right thing for us. If the password has been saved in password manager, returns true, or if a logon has succeeded in the current session. This will allow us to specialize the case where the user is trying to logon to a server w/o a stored password for the first time in a session. I'll attach a patch shortly. This will have to go into 1.6 first, so, Robert, once I check in, you would need to try 1.6 to verify this is fixed for you. If it is verified, we can try to get it into 1.5 final or 1.5.1
Not exactly thrilled about using 1.6 (pre alpha)... but if it's required. Ok.
this is as I described earlier. It worked for me in the case I tried (which is bringing up webmail and bonking get new mail simultaneously until I got an error). I think it will work for the biff case too.
Comment on attachment 131969 [details] [diff] [review] proposed fix That doesn't convince me. If I understand the parch correctly, the password should be discarded every time if not saved. If saved, we have two chances before it will be discarded. What if the server throws two or three errors after another before it's alright again? Or say about one minute? With your patch the get will performed immediately after the user presses ok and very likely produce more than one failure. Or what if through a failure the mailbox is really in-use? The server will close the connection in this case -> nsPop3Protocol will be deleted and logonFailureCount reset to 0. So the count is useless.
this patch assumes the inability to open the folder is temporary. It is POP3, after all - no one should be holding onto the connection for a long time. The time it takes the user to dismiss the warning alert is probably sufficient for the mailbox lock to get released. It certainly was in the case I was able to reproduce. >nsPop3Protocol will be deleted and logonFailureCount reset to 0. >So the count is useless. Well, in this case, we won't forget the password. So I wouldn't say it's useless. It does what we want. Think about it this way - there are two scenarios: 1. The user presses get new mail. If we get an error, we'll try sending the password one more time. If that fails, the failureCount will be > 1, and we'll forget the password. If the password had changed on the server, this is the behaviour we want. If the password is correct but the server has an error with the inbox, either the server will drop the connection as you say, and we won't forget the password (which would be the desired behaviour), or the server won't drop the connection and we'll try again. If that fails, we will drop the password, but most locks will be very temporary. 2. Biff fires. With this patch, biff firing and failing should *never* cause us to drop the password because we don't retry (because there's no msgWindow) and thus the count will never get > 1, and again it does what we want.
Comment on attachment 131969 [details] [diff] [review] proposed fix Ok, with these assumptions you're right. So let's try and see if this helps in Robert's case.
Attachment #131969 - Flags: review- → review+
too risky for 1.5
Flags: blocking1.5? → blocking1.5-
fix checked in. Robert, I know it's a little risky using a pre-alpha build, but I use the daily builds exclusively and I very rarely have problem.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
FYI, fixed in the thunderbird 0.3 branch.
Comment on attachment 131969 [details] [diff] [review] proposed fix putting my plus back for clarity
As long as I can back up into 1.5 builds, I'm fine. Just pop me an email when a build with this patch hits the FTP servers, since I'm not in te routine of using trunk builds.
Asa: Provided the fix works... is it more risky to ship with this bug? I for some reason doubt I'm the only one effected by this on two servers (one of which I am pretty sure is running iPlanet, don't know the version, don't know about the other one). I'm of the reasoning that there may be quite a few more like myself who are finding Mail&News to be unreliable since it can't check mail as it should. Perhaps if there is going to be an RC2 it could be included? I'm wondering how widespread this symptom can be of mail&news users.
You can use the .zip build. Just uncompress it to a different folder and run Mozilla.exe (close the other Mozilla before). You can always delete the directory if you want...
FWIW, I think this fix is fairly safe. The only potential regression is that we might go back to the way things were in 1.4 - i.e., if the password has changed on the server, we might end up not being able to log on until the user removes the password from the password manager. I don't think that will generally be the case, except on pop3 servers that drop the connection after a bad password.
Comment on attachment 131969 [details] [diff] [review] proposed fix Scott and David sold me. a=asa (on behalf of drivers) for checkin to the 1.5 branch. Please add the fixed1.5 keyword when this has landed. Thanks.
Attachment #131969 - Flags: approval1.5+
David, you make me feel smart. That was exactly what I infered as the only real possible regression... which I think someone besides myself would be able to detect fairly quickly (I'm looking to see if it curesmy issue). As a sidenote. Wouldn't it be wiser to perhaps make an error "Server rejected password", with an option to open the password manager (and change the password). Or just ignore it (for the instance that Mozilla is running).
fixed on the 1.5 branch. Fixed on the Thunderbird 0.3 branch.
Flags: blocking1.5- → blocking1.5+
Robert, something like that is a possiblity, but it's such a crap shoot with POP - you just don't know why the connection failed, so it might be misleading to bring up the password manager...
Gottcha. I'm just wondering how Outlook Express 5/Mac did it? It seemed to know the difference. Just wondering how. Then again, it had a boatload of other issues.
*** Bug 220128 has been marked as a duplicate of this bug. ***
Robert, Outlook maybe looks at the server answers text for "bad login" or "password". This is bad behaviour though it might give the right result in 90% of the servers.
I'm assuming since this has been checked into 1.5, sometime this afternoon I can download a latest-1.5 build: http://ftp.mozilla.org/pub/mozilla/nightly/latest-1.5/ and test this patch on the 1.5 branch (which I much perfer, thanks Scott, David, and Asa).
This is... semi-fixed, I think. Before this fix, Mozilla would forget my password whenever there was a problem logging into the mail server (caused by my xlassie biff'ing at the same time, I expect). Now this is usually okay, but a few minutes ago I got the usual 'problem' dialog twice in a row, one after the other, dismissed them both and then my password had been forgotten, prompting me to enter it again.
OS: Windows XP → All
Hardware: PC → All
I haven't seen a 1.5 nightly yet: http://ftp.mozilla.org/pub/mozilla/nightly/latest-1.5/ They are still from the 23rd. When are the new ones coming out?
Is this included in 1.5rc2? (which according to Asa's blog is due out tonight).
yes, it should be.
Bug 189335 Looks like a duplicate of this bug
I haven't seen it in days. VERIFIED
Status: RESOLVED → VERIFIED
*** Bug 189335 has been marked as a duplicate of this bug. ***
reopening as it happened again. Don't have a log, will turn on logging hoping I can caputure it again.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Can confirm. A lot of users on mozillapl.org support forums are complaining about password dialog popping up all the time. This seems to affect only some of POP3 accounts.
Mozilla should never decide to forget the password on it's own. The dialog that pops up should give the options: 1. Retry NOW with the old password. 2. Retry a few minutes later with the old password. 3. Cancel and give up for now, still remembering the old password for use the next time the user tries to access the mail server. 4. Enter in the new password. This is the behavior of Outlook Express, and to me it is the obvious proper behavior, with a timer on the dialog to default to retrying every few minutes if no one response to the dialog. I am having a problem with only one mail server where it periodially causes this password dialog to come up. I should not need to type in my password again, which is the only option that I apparently have now. In my opinion, I should be entering in the password to the accounts when I set up the e-mail account, and maintain it on through those dialogs by default.
this fix makes it so we don't throw away a pop3 password that has worked in the current session. The password prompting code we're using in mailnews doesn't allow us to pass in the current password to the password dialog so I can't currently prompt for a password, so we'll keep trying the password that worked before. I've also cleaned up the name of another method to avoid confusion with the new method I've added to tell if we've authenticated successfully with the pop3 server.
Attachment #135520 - Flags: superreview?(mscott) → superreview+
fix checked in - please let me know how it goes.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Awesome work David. I'll give it shot when 1.6b comes out. I had lots of issues with 1.6a, so I'm waiting until post 1.6b to hopefully avoid more problems.
Really, this bug should be a duplicate of bug 91656. This fix will probably help most cases, but not the real problem, nor the problem I originally filed bug 91656 for. The reason this appears to be a new regression is because it was causing other regressions as noted earlier by others. I outlined an algorithm in bug 91656 comment 19 as to the best way to fix this. As far as I can tell, this patch still does not fix the problem where a user has multiple machines and is trying to access mail from those multiple machines at the same time (by forgetting/neglecting to shutdown the mail app on the other computer). Or if someone is using say both Mozilla mail and Thunderbird and they happen to ping the mailbox at the same time. The bottom line is, we don't need to guess whether the password is correct or not. Mail servers will respond that the server is in use if it is. We should parse that and act appropriately.
I'm not sure why you say this won't fix the problem of multiple machines/apps pinging the pop3 inbox since that's exactly what it attempts to fix. Fix, in the sense of not forgetting the pop3 password in that case, which is what this patch does. Parsing server response text is not the way to go, for reasons explained in bug 91656. Also, as I mentioned earlier, we're not using a prompting interface that allows us to pre-fill the password, and I'll bet you dollars to donuts the interface we're using is frozen.
*** Bug 91656 has been marked as a duplicate of this bug. ***
Christopher, what you outlined in bug 91656, comment #19 has already been implemented by bug 151452 (and improved by patch for bug 219282). Ok, not the "maildrop" thing cause that's not only forbidden by RFC but it would have caused more problems. Some servers say "+OK maildrop locked" if login succeeded ... The problem where (and IMHO are even after Davids patch in cases like initial login failes although right login data entered) servers not supporting the extended response codes like [IN-USE].
using - Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031118 my mozilla mail is used to pull 2 POP accounts. under server settings on BOTH, the only box I have checked is "Empty trash on exit" even though "check for messages every _____ minutes is unchecked, I have it set to 3000. the damn thing still requests a password every 5 minutes. I believe this is only happening on the "first" account. for the life of me, I can't see why it is asking/checking at all
Nice to see this bug (and bug 91656) fixed. But there is still a related issue in bug 189633. Now, in case of POP error, MailNews doesn't forget the password but annoy the user with endless error Alerts.
What do you mean with "endless error Alerts"? Mozilla reports the errors the server sent. Shouldn't it do so?
By fixed in 1.5 does that mean it is fixed in a release after 1.5b? The problem is still visible in Mozilla 1.5b. Mozilla/5.0 (X11; U; OpenVMS AlphaServer_DS10_617_MHz; en-US; rv:1.5b) Gecko/20030827 Reproduction is less frequent, but it appears that after 2.5 years the broadband ISP is starting to get their mail servers under some control.
This bug was fixed very close to the 1.5 release. It didn't really make much time in beta (it was a small fix anyway, not high risk). So yes, it's fixed in 1.5 final, I have seen it only once since, and can't reproduce it so far.
It is still present when accessing news. Bugs number 214533 and 206634 are related.
*** Bug 300113 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.