Closed Bug 160425 Opened 22 years ago Closed 17 years ago

Forgets previously saved password if mail server unavailable

Categories

(SeaMonkey :: Passwords & Permissions, defect, P2)

x86
All
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME
mozilla1.2beta

People

(Reporter: rm, Assigned: Bienvenu)

References

Details

Attachments

(2 files, 1 obsolete file)

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
Status: NEW → ASSIGNED
Keywords: nsbeta1
Priority: -- → P2
Target Milestone: --- → mozilla1.2beta
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.
Attachment #98178 - Attachment is obsolete: true
*** 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
Attachment #98249 - Flags: superreview+
Comment on attachment 98249 [details] [diff] [review]
same patch but tested and bugs fixed

r=jag
Attachment #98249 - Flags: review+
checked in
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Assignee: morse → bienvenu
Status: REOPENED → NEW
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.
OS: Windows 2000 → All
*** 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.
Blocks: 91656
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
Depends on: 219162
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.
Product: Browser → Seamonkey
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.
Status: NEW → RESOLVED
Closed: 22 years ago17 years ago
Resolution: --- → WORKSFORME
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: