Closed Bug 91656 Opened 23 years ago Closed 21 years ago

Already have an existing POP session should not prompt for new password

Categories

(MailNews Core :: Networking: POP, defect)

Product:
MailNews Core
Component:
Networking: POP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 219162
Milestone:
mozilla1.2alpha

People

(Reporter: caillon, Assigned: sspitzer)

References

Details

(Keywords: dataloss)

Attachments

(3 files)

Screenshot of failed auth message
4.02 KB, image/png
Details
proposed fix
795 bytes, patch
Details | Diff | Splinter Review
What the dialog could look like
12.75 KB, image/jpeg
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010718 BuildID: 2001071806 This has been ongoing for a few weeks now and I keep forgetting about it. I do not know how this message gets generated by my mail server, but every so often I get a message on logging in that I already have an active POP session and therefore can't log in again. Upon recieving this message, Mozilla prompts me for a new password and forgets my old one. Reproducible: Always Steps to Reproduce: 1.Have Mail running. 2.Somehow get your mail server to respond back with you already have an active pop session. 3.Try to retrieve mail. Actual Results: Authentication failed, my password was forgotten, and I was prompted for a new one. Expected Results: Authentication failed. I did telnet to my pop server and verified that I could not log in from there either.
you can cancel the passed dialog. i think this is a won'tfix issue.
After the dialog (with the screenshot) pops up, I get a new dialog as if I entered the wrong password. It should NOT prompt here for a new password since the password check did not really fail. Instead, it should do nothing. The only time you should get an invalid password dialog is when you enter an invalid password or if it does not know your password (e.g. first use) Re-assign/mark future if needed, but I don't think this should be marked as wontfix. It is very confusing to the user, not to mention annoying.
*** Bug 89762 has been marked as a duplicate of this bug. ***
RFC 1939 and RFC 2449 gives POP3 the right to issue error responses on the PASS command, even if authentication was sucessful. This is from RFC 1939 Sect. 7 (pg 13). Possible Responses: +OK maildrop locked and ready -ERR invalid password -ERR unable to lock maildrop This is from RFC 2449: 8.1.2. The IN-USE response code This occurs on an -ERR response to an AUTH, APOP, or PASS command. It indicates the authentication was successful, but the user's maildrop is currently in use (probably by another POP3 client). We should parse the negative error respose issued by the PASS command before forgetting the password. If it contains "IN-USE" or "mail-drop" the password should NOT be forgotten.
*** Bug 97810 has been marked as a duplicate of this bug. ***
platform / OS -> ALL / ALL
Hmm, it should have already been OS All because the other dupe was on Windows. Really changing now. Adding dataloss keyword since it loses your password. And by definition ( http://bugzilla.mozilla.org/bug_status.html#severity ), a dataloss bug is severity critical
Severity: normal → critical
Keywords: dataloss
OS: Linux → All
Hardware: PC → All
*** Bug 98155 has been marked as a duplicate of this bug. ***
*** Bug 98161 has been marked as a duplicate of this bug. ***
I just tested out Eudora 5.02 and Outlook Express 5.5 on a pop server with a locked maildrop. Both Eudora and Outlook Express prompt you for a new password. However here, they do not forget it. The old password can be seen as ********* hitting enter to the prompt will try again for you without having to re-enter your password. There is NO REASON for it to forget the password when there can be a server error. The way I see it, there are two choices here: 1) Parse the server response message and forget the password if the server responds with an auth error. Leave it alone if the maildrop is locked. 2) Do not EVER forget the mail password in this instance, display the error and let the user decide if they need to retype the password. Eudora and OE went with choice #2 it seems.
*** Bug 97810 has been marked as a duplicate of this bug. ***
*** Bug 98161 has been marked as a duplicate of this bug. ***
Here is how I think this problem can be fixed. If there is an -ERR response on the pass command from the server, we can grep the server response text for "user"/"password" and use the old password if grep fails. cc jgmyers if he has better suggestion.
*** Bug 98706 has been marked as a duplicate of this bug. ***
The problem here is how do you distinguish between bad password and some other error. I mean bad password response can be anything. Some examples -invalid password -invalid login -failed to login I cannot think of how we can fix this bug.
I think the only way we can fix it as caillon suggests is to follow what outlook and eudora does, prefill the password.
Per section 8.1.2 of RFC 2449, a POP server can indicate the "mailbox locked" case by putting an "[IN-USE]" extended response code after the "-ERR". This does not help the case of nonextended servers.
Can we combine the two suggestions? Something like: if (PASS fails) { // display the server message as we do currently // do NOT forget the password if (server response contains "[IN-USE]" or "maildrop") { // do NOT prompt for a new password. } else { // prompt but pre-fill the password box. } }
Looks like Christopher Aillon is on to something. Please save us from this dreaded password bug!
We don't prefill the password for imap either. I think we cannot just change for one protocol and leave other as is. Also, it is debatable because some users would complain that they have to delete the old password and enter the new password. I am willing to add the "[IN-USE]" check. Can I get a test account on a server that sends this extended response code
Status: NEW → ASSIGNED
> users would complain that they have to delete the old password and > enter the new password. No they wouldn't. Give the password text field focus and highlight the existing text. If they type, it should delete without them having to add any steps to their process.
Attached patch proposed fix — — Splinter Review
Can, I get a test server to test this fix.
Always a problem for me here: http://www.audioasylum.com/forums/HUG/bbs.html
Sorry about that last bogus coment, I was half asleep and was thinking about 95459... There's something else going on with this, at least for me. When I get a mailbox in use error, if I type in my correct password, I then get a bad login error, which will prompt for a password, and if I type it in, I get the bad login again. This will repeat indefinately, unless I cancel out, hit get messages, and then type in the password. For some reason, while the original diaplog box is up, it's not getting the right password.
I get this fairly frequently with the message "The PASS command did not succeed. The mail server responded: mail storage services unavailable, wait a few minutes and try again." The solution in #19 would fail for me, it's obviously tricky to try and determine what text could be included in trying to determine if the password should be re-tried without prompting. I like the solution in #22, no matter what the error why not prompt but prefill the password leaving it selecting so that typing a new password dosn't require further steps from the user, this reduces #19 to : if (PASS fails) { // display the server message as we do currently // do NOT forget the password // prompt but pre-fill the password box. } is there a reason why this cannot be the case?
Just wanted to add that this is a real problem occurring regularly for me because i have Moz running at home and at work and sometimes they just try to check mail at the same time. I support the proposal at #22, but another solution would be to make the first dialog like "The PASS command did not succeed. The mail server responded: mail storage services unavailable, wait a few minutes and try again. Change password?" (wording probably not good) with buttons Yes and No. Another possibility would be "Try again?" or "Try again later?".
*** Bug 115408 has been marked as a duplicate of this bug. ***
How about this: If PASS command fails and the dialog is displayed, there would also be a checkbox (or whatever it is called in Mozilla) for "Do not ask for a new password if this error occurs" and it could even be checked by default. Or maybe even the other way around: leave it unchecked but reverse the meaning (like "ask for a new password when this error occurs". Of course it could try to parse the server response and decide which is the correct state for the checkbox. I'll add a screenshot...
*** Bug 115466 has been marked as a duplicate of this bug. ***
From comment 28 >it's obviously tricky to try and determine what text could be included in >trying to determine if the password should be re-tried without prompting. No it's not. It is in the RFC. If the mailserver you use doesn't follow the standards, we certainly shouldn't go guessing. But there is nothing wrong with omitting the prompt for those on servers who follow the RFC. It might be argued that it is an unneeded check if we do the following. But I think though that omitting the prompt is the best choice. The server tells us that it's not letting us in because of a locked maildrop but the password is OK. We should honor it. Anyway we should always give the user the choice of changing the password in the case that we determine PASS has failed for whatever reason and our check has failed.
>Anyway we should always give the user the choice of changing the password in the >case that we determine PASS has failed for whatever reason and our check has failed. But you should give the user the choice to keep the pwd in case the server gives the pass command not succeded answer and not always ask for it, too. The user should be able to configure that. In case you say, the mail server doesn't keep that and that standard, the normal user is not interested. This always asking to my mind is a block for daily/normal/business or whatever use of moz-mail. For example my mail-provider yahoo had that problem for two days and I was so f**** off of always typing in again the correct password that I thought of changing to Outlook Express or other mail client (which I didn't do by now, but will, in case that thing is not changed)
*** Bug 117223 has been marked as a duplicate of this bug. ***
*** Bug 121647 has been marked as a duplicate of this bug. ***
There is a CANCEL button in the dialog asking for a new server password. If the user clicks CANCEL, the old pw should not be forgotten. This should be true regardless of how or whether Mozilla can parse error messages to recognize common situations. If Mozilla ends up asking for a new password, then the old pw should be retained if the user doen't supply a new one. See also bug 121647
The Cancel button also cancels the mail client from retrying the login to the mail server. If this is the approach to take, then there also needs to be a [RETRY] with cached password button, and this should be obvious in the pop-up dialog. My ISP is admitting on their status page that their mail server is returning bad password erroneously. My personal preference is to set the password when I set up the POP/IMAP account name up in the account settings, and that I would have to go there to change it. Otherwise when there is any error with connecting to the mail server (As there often is) I can either click [RETRY] or [CANCEL]. Also the dialog box on Outlook being popped up does not prevent the mail server from retrying again, and it removes the dialog box when the retry eventually succeeed. Many mail server administrators do not seem to understand how to migrate from one mail server to another. They seem to make the common mistake of putting the new mail server on the Internet with no accounts, and then while it is happily bouncing all incoming mail with "Account does not exist" adding the user accounts. It is best to make the mail client tolerant of malfunctioning mail servers and incompetent mail administrators.
It appears someone has changed the behavior in 2002012903 so that it retries automatically on a mailbox in use failure. However, the problem noted in #26 hasn't been fixed, and it just loops indefinately (almost too fast to break out of if you're Ethernet connected to the mail server) in a bad password loop and never asks for a new one.
*** Bug 124227 has been marked as a duplicate of this bug. ***
*** Bug 125429 has been marked as a duplicate of this bug. ***
Discussed in 2/26 bug meeting with Mktg Engineering and PjM. Decision was to nsbeta1 minus and move to 1.2.
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.2
I run Mozilla 0.9.9 under Win2k. The pop3-password stored in mozilla mail is incorrect, and a dialogue box appers that sais: "The PASS Command did not succeed. Mail server mail.wspse.de responded: Authentication failed (bad password?) (Screenshot at http://s-inf.de/temp/pop3.gif ) Now mozilla does not offer _any_ way to correct the password. Is there a workaround how I can access my mailbox without deleting and recreating the account? In my opinion, on authenification error, mozilla should always ask for a new password, and say: "The authentication wasn't successfull", with a "TRY AGAIN" Buttion and the old password with ********. You can then retype a new password. Mozilla should now ONLY save the new password IF the login with the new password was successfull, otherwise keep the old one (as is most probably isn't a "bad password" that prevents the user from logging in, and the user would lose his correct, saved password). Regards, Klaus.
> Is there a workaround how I can access my mailbox without deleting and > recreating the account? If an incorrect password was saved, you can always go into the password-manager dialog and remove it. However you are correct in that the mailnews program should have removed the bad password once it got an authentication failure.
No, the password must not be cleared automatically, because (as previously mentioned) an authentication failure may also happen because of a mailbox lock.
Thank you for the advice. If you don't know that the mail passwords are stored in the password manager, you search for a long time how to change the password. I suggest the following behavior of mozilla: - if auth fails, say "Auth. failed, probably because of bad password" and offer old password as ****** in a field. - When user clicks OK, try with the password in the field. - ONLY IF auth. now works with the new password, store it. Otherwise keep the old password untouched.
Yes, if auth failed, it is not supposed to be remembered. I thought that's how mail/news implemented it, but perhaps there is a bug in the implementation.
Oh, sorry, I didn't see comment #45 before I posted. Is there no way to distinguish between the two types of failures? It would be very desirable if you could.
Following on from <a HREF="#c45">comment #45</a>, I'd like to remind you guys that authentication failures also occur because of a timeout during establishment of the POP session. In other words if you don't type in the password when promted, but leave the dialog hanging around for a minute or so, it erases the old password and prompts you for a new one. If this seems like an unlikely sceario, consider those of you like me, who despite your 1Ghz laptop, still make sure to time booting up Mozilla in the morning to coincide with fetching your first cup of coffee. As a result, I have to reenter my password at least once a week! And since the POP password given to me by my domaion provider is in fact an 'unguessable' (read 'unmemorisable'!) password, like "EkUdslUdx", that means I have to leave an easily accessible copy of the password lying around - which renders the whole idea of having strong passwords redundent! Also, I'm not sure why the keywords for this bug include mozilla0.9.8 0. I've been experiencing this problem for as long as I can remember with the 0.x series!
HCI observation: Server lock, timeout or failed connection (i.e. the password is good and needs to be kept) is by far the more common use case and should be optimised for in the UI, so retaining it and having a single click "try again" is essential. Having the same dialogue also contain the starred password input box so it can potentially be changed also makes it convenient for the rarer case where the password is wrong. It is possible to do this neatly and elegantly without trying to parse the response code (which is at best a vague process, there's no standard) nor trying to understand why the connection failed - that information can simply be presented opaquely to the user, e.g. "Could not connect to the mail server - reason given: xxxxx" Christopher Allion (and Eudora and Microsoft) had it dead right to begin with.
Now that bug 121926 is fixed, this one will cause trouble again.
*** Bug 158508 has been marked as a duplicate of this bug. ***
*** Bug 158946 has been marked as a duplicate of this bug. ***
Re-nominating for nsbeta.
Keywords: nsbeta1- → nsbeta1
I never had any problems with this up to 1.0. I have installed 1.1a and now 1.1b and keep getting prompted for the password. This happens intermittently when Mozilla polls for new messages, probably my ISP goes on the blink for a minute. It is currently the most annoying "feature" of Mozilla.
*** Bug 162272 has been marked as a duplicate of this bug. ***
Could someone re-summarise this bug so that the description: a. Makes more sense, and b. Is easier to find when searching for dupes? Perhaps: POP3: should only forget/prompt for new password if password really incorrect (although I'd like the word 'locked' in there somewhere). Just a comment to note that RFC1939 does not mandate any message text at all in the response to a failed PASS command. Also, I've seen a fair number of POP3 servers, and none of them implement the RESP-CODES capability in RFC 2449. I'm sure some exist, but I wouldn't say they're in the majority. Christopher is right. We should check for [IN-USE], but we must fallback to providing a 'try again' option for servers that support RFC 1939 and not RFC 2449.
Just do it that way and everyone will be happy: If login fails, open a Dialogue Box: "Login has failed. This could be because an incorrect password, or another failure. You can edit your password here. The new password will only be stored if Login is successful now.". The user now has a field with the old password in *****. If (and only if!) login is successful with the new password, store it. Otherwise ignore the new password, and show the dialogue box again with the old password in *****. When the user presses "cancel", do never store a new password. You will now be happy every time: You cannot accidently change your password (because it is not stored if login failes again), but if login succeeds with the new one, it will be stored. You should not try to look at the POP3 responses; that's not a depandable way. Regards, Klaus
Another possibility would be to try twice before reprompting. That would take care of some of the transient errors.
When Mozilla gets a bad password message, if it is not acknowleged, it should just timeout and retry later with the last known good password. There should be a button to tell it to retry later. The user should not need to reenter their password unless they know for sure that it changed. The mail server that I must use for my home broadband connection regularly goes into the mode where it eroneously claims a bad password. It will stay in this state for hours at a time. With other mail clients, this is not a big deal, as they will just retry.
OK, to finally close this annoying bug: As we all seem to agree to this solution, could someone put this into the code: 1.) If login falis, prompt for new password, with old password in "******". Show buttons "RETRY" and "CANCEL", and a message "Note: New password will only be stored if login is successful." 2a.) If user changes password and presses RETRY: Retry login with new password. Store it and finish if succeeded, otherwise show dialogue again with old password in "******". 2b.) If user presses RETRY without changing the password: Just retry with old password. Success --> finish, Failure --> Show dialogue again. 2c.) If user presses CANCEL: Abort and close dialogue, do NOT change any saved password. 3.) Mark this endless thrad solved :) Regards, Klaus
This sounds like a dup of bug 160425 for which I currently have a patch pending and am waiting for reviews. *** This bug has been marked as a duplicate of 160425 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
vrfy dup
Status: RESOLVED → VERIFIED
I don't think this is a dupe 160425, this happens all the time when the server IS available. just now I cancelled the damn request, after giving it the password 3 times and IMMEDIATELY pulled the mail from both POP accounts.
*** Bug 170713 has been marked as a duplicate of this bug. ***
reopening. that is an imho pretty bad way to fix this bug. Something like comment 11 / comment 19 would be nice.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Mail triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
I am unsure if mine is the exact problem the others are complaining about. I have already established my name and password on a news account. It should be good for all 30,000 newsgroups it supports. Yet, every time I subscribe to a newsgroup I am prompted yet again for a name & password. So how many [presumably encrypted] copies of that passowrd are floating around? My news server is happy with a single password entry, why isn't Mozilla? I have tested on some smaller groups. It did not prompt me for a password. So the problem may be confined to busier newsgroups (like over 100 message headers). Also, unlike some comments below, my authentication works, so far.
*** Bug 188072 has been marked as a duplicate of this bug. ***
Additionally, if I type a wrong password for a first time, I get the window with "wrong password" alert and the field for a new password. After typing new (correct or not) password, dialog closes with no attempt to connect again. Should it be trying to authenticate all the time until I hit "cancel" button? Now, I have to restart mail fetch process.
*** Bug 191391 has been marked as a duplicate of this bug. ***
Keywords: mozilla0.9.8
mass re-assign.
Assignee: naving → sspitzer
Status: REOPENED → NEW
I think have a similar problem as this one: after a bluescreen on w2k (page fault in non paged segment) I'm no more able to send mails (as I did 800 times before) The current state is that mozilla requires the password for my mail account whenever I want top send a mail. But even if I enter the correct password this pop-up window comes again and again disabling me to send any more mails from within mozilla. Its a very strange behavior because on the outgoing setting I unmarked the 'use name and password' item. (if I go to the provider's web page and enter my mail right there everything works fine.) Even a reinstallation of the account does not help. It seems like somewhere in the registry an invalid pattern must be stored. --> problem cathegory: urgent, very high priority
Depends on: 160425
Parsing the servers error message is bad behaviour as this is only freetext without real meaning. Support for extended response codes according to RFC 2449 resp. 3206 has been implemented through bug 151452 and bug 219282. So the specific problem which this bug refers to is fixed (at least for servers supporting the extended codes). I think we should close this bug in favour of the more general and recent bugs 160425 and 219162.
I agree with Christian - resolving as dup of 219162 *** This bug has been marked as a duplicate of 219162 ***
Status: NEW → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → DUPLICATE
Nice to see this bug (and bug 219162) 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.
Product: MailNews → Core
Fixed! i don't see where its fixed, AFAIK it still does what it's always done, looses your password whatever the cause of the failed connection is. Regardless of the reason the mail client fails to connect (pop3 server down, busy, no internet connection, local network failure, wan failure etc.) pressing cancel should NOT remove the password from password manager unless requested to do so by the user. I use obscure passwords difficult to remember and multiple email accounts, it's VERY annoying to have to retype all the passwords every time Thunderbird fails to connect to the pop3 servers whatever the reason.
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: