after receiving authentication error the password is forgotten

dupe of bug 91656

Please reopen if you disagree !

*** This bug has been marked as a duplicate of 91656 ***

Reopening because bug 91656 doesn't address the issue of
Mozilla making the initial POP connection before fetching the password.

Currently the POP connection is started before fetching the password, and
therefore may provoke the master PW prompt. Mozilla should get the login
and password data before starting the POP connection, which will avoid the
bogus timeouts completely. This will make the user experience more
reasonable.

<email address hidden>:
Mozilla can't get the password because it don't know if the server needs a
password !
Mozilla requests the password if the server wants a password.

-------------------------------------------------------------------------------
If I send this to my pop3 server:
user <email address hidden>
I get this answer:
+OK Password required
--------------------------------------------------------------------------------

Why not ask the PW mgr for a saved password in advance? If there is
no password saved, then just proceed as is currently done. In any case,
the Master PW interaction will be completed before the POP connection.

(This assumes the PW manager can be silently queried even if nothing
is stored, and nothing bad happens)

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

Changing component to 'General', because bug 170905 saw it in IMAP too. Chaning
summary too.

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

Please, check again with a current build if this bug still exists. I think that
it was changed some time ago.

As of Mozilla 1.2.1 I am no longer prompted for a password when another user has
that POP mailbox open. I receive the message stating that another user has that
box open, and when I hit cancel Mozilla does not forget the password.

mass re-assign.

Is it possible to clarify that hitting cancel will not forget the current
password? My mail server seems to occasionally fail authentication for no
particular reason (overloaded, perhaps). Should it present a dialog like so
instead? Feel free to fix the wording!

+-------------------------------------------------------+
| Failed to retrieve mail from the server. The error |
| was: |
| |
| Err: Server Temporarily Unavailable |
| |
| Would you like to retry or enter a new password? |
| |
| | Retry | | Enter New Password | | Cancel | |
+-------------------------------------------------------+

I have *no* idea what clicking cancel will do when prompted after an
authentication failure. I usually try entering the password again. It would be
nice to mention what was happening.

Just tryed with mozilla 1.8a1 build (w2k and xp pro) and it still erases the
password if one hit's cancel to a pop3 authentication...

Exactly the same Bug in Thunderbird version 0.7 (20040616).
one of my mailservers denies the login and Thunderbird password-manager simply
forgets the password.

I think a saved password should always stay saved until explicit instruction to
delete. If there is a problem with login you may get an dialog as described by
Additional Comment #11 From Matthew Mastracci.

Stefan Schäfer

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

Thunderbird "losing" passwords to mail accounts has been happening to my wife and me in probably every version of TB we've had, including 2.0.0.9. just now.

It seemed to be precipitated when I attempted to open an email for reading while TB was attempting to check my wife's account for new mail.

The pop-up box asking for a password opened. I canceled the box and on checking the passwords in tools/options/privacy/passwords, my wife's was no longer there, so had to add it again.

We don't use a master password.

Detlef Pelz

I strongly support this bug being addressed.

Our ISP has a temporary overload problem meaning that its POP3 server throws errors sometimes. For example, if we have two PCs polling for mail, we often get "ERR Mailbox locked, try again later".

The impact of this bug is that the user is prompted for a mailbox password, and if the error recurs the only way out is to cancel - upon which Thunderbird 2.0.0.12 forgets the password and can no longer retrieve mail.

Real-world (ie less clueful) users tend not to know their mailbox passwords, as a previous bug reporter commented, because this is something "infrastructural". Being prompted to enter it is disturbing and generates support calls.

Correct behaviour would be (as shown in previous comment) to have three choices on the error box: Retry / Enter new password / Cancel.

Is this not a dup of bug 123440 ? That bug has more commentary, all of which is useful to the understanding of it, even if it has a larger bug number!

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

I also find this bug very annoying, possibly the most annoying currently in TB.
It would be great to resolve this for all current forks. Surely (my little coding knowledge suggests) it would be fairly trivial to have passwords stored until overwritten by new ones.

Similar to bug 123440 as suggested by Glenn Linderman. Which is also annoying. Although the two might be resolvable together by means of notification icons when connection is not available or has a problem instead of pop up windows with password requests.

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

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

Nominating wanted-thunderbird3 partly due to the number of dupes and also to keep it on the radar.

Agreed this would be good to fix.

(In reply to comment #11)
> Is it possible to clarify that hitting cancel will not forget the current
> password? My mail server seems to occasionally fail authentication for no
> particular reason (overloaded, perhaps). Should it present a dialog like so
> instead? Feel free to fix the wording!
>
> +-------------------------------------------------------+
> | Failed to retrieve mail from the server. The error |
> | was: |
> | |
> | Err: Server Temporarily Unavailable |
> | |
> | Would you like to retry or enter a new password? |
> | |
> | | Retry | | Enter New Password | | Cancel | |
> +-------------------------------------------------------+
>
> I have *no* idea what clicking cancel will do when prompted after an
> authentication failure. I usually try entering the password again. It would be
> nice to mention what was happening.
>
>

This looks like it would be the ideal fix to me!

I could almost agree with comment #24, except that asynchronously appearing modal dialog boxes are bad because they block continued operations, and asynchronously appearing dialog boxes that ask for password information could be spoofed by trojans once people are used to answering them.

It would be nice if the actual error message was provided; if the password needs to be changed, there should be a facility in Thunderbird/SeaMonkey to allow the user to enter the password as a command, icon, or menu option... a synchronous operation, rather than an asynchronous one.

It is true that the "first access" to a mail server is sort of synchronous, but when these dialog boxes appear as part of biff-type operations, they are very susceptible to being spoofed by trojans, as they appear to be asynchronous to the user.

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

Sure are getting a lot of complaints about this lately... Possibly since gmail imap seems to cause this quite frequently (bug 423354).

What if TB would just silently fail when it can't login to the IMAP server. And then retry. It can set the "lightbulb" (online status) to red or something to show that it's having trouble. And when you put the mouse over it show the error and maybe right clicking on it will give you the option to enter a new pw or something?

Anything at all would be preferable the current behavior.

I submitted Bug 423354 > https://bugzilla.mozilla.org/show_bug.cgi?id=423354

I see no solution here.

Stephen DeGabiele offered a great suggestion.

Thunderbird should never need to ask for passwords if thee are already saved.

This really is a serious and chronic problem that I'm sure thousands of users are experiencing. Please make this a priority. The pop up password box pops up for me and all my other users very very often every day. It's truly rediculous and the most annoying thing that happens within any of the many applications we run.

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

S Davis:
Bugzilla is not there to find a solution for you as user. This may be fixed in the Product and you will see that if the status of this bug changes to "fixed" instead of New. If you want to get it fixed faster then attach a patch.

>Thunderbird should never need to ask for passwords if thee are already saved.
wrong !, example :The password on the server may get changed and the Account will be closed after 3x submitting the wrong password. A banned Account is worse ..

If the server answers with an error after sending the login data TB must ask you again because of that. There is AFAIK no standard in the answer and that means that all login errors must trigger this.
Create a pop3/Imap log with such a "asks again" case and attach it if the server didn't respond with a error after sending the login informations !

There is an imap log in 423354 comment #8 and this shows that the error is Gmail:
2448[23702f8]: 2365008:imap.gmail.com:NA:CreateNewLineFromSocket: * BYE
Temporary System Error

Gmail answers with an error directly after login..

Thank you Matthais. I will look out for the error logs.
Thunderbird wants to grow just like Firefox so please consider ways to mitigate this problem and/or make it easier for end users to understand and troubleshoot the common root causes of it in a future product release. As it stands today, end users get these "mail server password required" pop ups often if connecting to multiple Imap accounts, but there is no clear indicator of the root cause or resolution so the user gets stuck in an endless frustration loop unable to solve the problem themselves. I appreciate the developer community considering ways to make login error identification and correction faster, easier, and more intuitive for future releases.

(In reply to comment #15)
> Thunderbird "losing" passwords to mail accounts has been happening to my wife
> and me in probably every version of TB we've had, including 2.0.0.9. just now.
>
> It seemed to be precipitated when I attempted to open an email for reading
> while TB was attempting to check my wife's account for new mail.
>
> The pop-up box asking for a password opened. I canceled the box and on checking
> the passwords in tools/options/privacy/passwords, my wife's was no longer
> there, so had to add it again.
>
> We don't use a master password.
>
> Detlef Pelz
>

FWIW, we haven't encountered this bug in a log time now -- perhaps not since 2.0.0.9. We're using TB 2.0.0.14 at present. Our mode of usage hasn't changed, except maybe in that we use TB more frequently since I last wrote, so it looks to us like the bug is fixed.

Our thanks to the fabulous TB crew!

Detlef Pelz

(In reply to comment #33)
> (In reply to comment #15)
> > Thunderbird "losing" passwords to mail accounts has been happening to my wife
> > and me in probably every version of TB we've had, including 2.0.0.9. just now.
> >
> > It seemed to be precipitated when I attempted to open an email for reading
> > while TB was attempting to check my wife's account for new mail.
> >
> > The pop-up box asking for a password opened. I canceled the box and on checking
> > the passwords in tools/options/privacy/passwords, my wife's was no longer
> > there, so had to add it again.
> >
> > We don't use a master password.
> >
> > Detlef Pelz
> >
>
> FWIW, we haven't encountered this bug in a log time now -- perhaps not since
> 2.0.0.9. We're using TB 2.0.0.14 at present. Our mode of usage hasn't changed,
> except maybe in that we use TB more frequently since I last wrote, so it looks
> to us like the bug is fixed.
>
> Our thanks to the fabulous TB crew!
>
> Detlef Pelz
>

This bug is certainly *NOT* fixed. You are most likely not experiencing the problem because the mail server you are using is not producing any errors. Use TB with GMail + imap and you will see the problem within a day or two.

Fair enough -- perhaps I should have said, "For *us* it looks like the bug is fixed", since the only variables that have changed since the bug occurred are that we use TB more frequently than we did back then, and there have been several upgrades since then.

We use it with two different mail servers -- both POP -- so I guess the problem still exists with other arrangements.

Detlef Pelz

It's definitely not fixed as many gmail users will tell you.

While it may be difficult to grok the various and different server error messages, it is not impossible. There are less than 10 (major) IMAP servers in use today. Courier, UW, Exchange, Binc, Dovecot and gmail come to mind.

I can't understand how the behavior of forgetting the password helps protect the user from being "locked out" of an account, as the user, lacking any information as to why they are being asked for their password, is just going to enter the same "bad" password that they think is correct.

The pop-up doesn't mention any information like "Thunderbird has decided to forget your password because it thinks it's 'bad'. "

>There are less than 10 (major) IMAP servers
Major doesn't matter, it must work with near all existing and used imap servers. I use for example Hamster as Imap server.

I can not understand why you can not understand this, you must think more global not only for your own point of view.
A user gets a phone call from the sysadmins or a mail a few days ago which tells him : we got a new Imap server software and all Accounts need new passwords, here is your new password, use it tomorrow morning. User opens Thunderbird at the morninbg and thunderbird send x times the wrong password after opening Thunderbird and account is closed.

I agree that there is a UI problem, Thunderbird should tell you why it asks for a new password (The server responded with an error during the login)

Disagree. It does matter, even if there is a fundamental reason why
good behavior is impossible -in general-, but it can be made good
with specific servers (by parsing their error messages), then it should
do that; making T. have bad behavior for everyone if it can be avoided
is not desirable.

In any case, why can't Thunderbird *ask* the user what to do, offering three choices:
    - Retry with saved password
    - Cancel (stop trying) and retain the existing saved password
    - Change password (leads to new-password dialog)

I can't see why it is every desirable to silently forget the old password.

(In reply to comment #37)
> A user gets a phone call from the sysadmins or a mail a few days ago which
> tells him : we got a new Imap server software and all Accounts need new
> passwords, here is your new password, use it tomorrow morning. User opens
> Thunderbird at the morninbg and thunderbird send x times the wrong password
> after opening Thunderbird and account is closed.

That is moronic server behavior, a server should never disable an account because someone sent the wrong password for it a couple times. This is a Denial-of-service vulnerability where an attacker can disable every known account on the system. Although off topic here and some server administrators are morons so this does happen.

I agree the solution would be to make Thunderbird come with a dialog if it has two or three failed connection attempts, with the options being retry, abort or change password.

Your description of the "new password created behind my back" issue is correct;
that can happen ... however...

1) If Thunderbird gets a wrong password error, it should mark the account for
no future access until there is user interaction. However, it shouldn't force
the user interaction via a spoofable dialog, and it shouldn't halt processing
with a modal dialog.

2) If the user knows that multiple password errors might lock out the account,
he should leave the following proposed option checkbox unchecked: Try again
after password errors. However, users that will not be locked out would enjoy
this setting. The lockout algorithms usually only happen when there are too
many attempts in a particular time period, so even if there are lockout
possibilities, if the "check for mail" period is such that the time period is
not exceeded, the setting could be used by such users, also. The retry should
be only at the next biff interval for automatic checking, not immediately, to
aid in avoiding lockout.

Thunderbird could tell you why it asks for a new password, but isn't the reason
always that there was an error during login? So that seems uninformative. If
there are other reasons, they are bugs and should be fixed.

Thunderbird should never forget the old password. The user shouldn't be forced
to type the same one in again in the presence of errors at the server, when it
hasn't changed. Even the present, inappropriate, asynchronously appearing
modal dialog allows the user to change the password if that is appropriate...
but if the problem is due to errors at or communicating with the server, having
Thunderbird wipe out the old password and turn off the remember password
checkbox is always inappropriate.

And if the user has been notified that the password has been changed at the
server, and doesn't change it in Thunderbird, and gets locked out, why is that
Thunderbird's problem (especially if the proposed "Try again after password
errors" checkbox is implemented and checked)?

I disagree with the second paragraph of comment #38 and the last paragraph of comment #39 -- Thunderbird should never request a password via an asynchronous dialog -- see my comment #25 for why.

I agree with the moronic server behavior idea, but the way passwords are done these days, the server probably can't tell what the password used actually was: if it could tell that the same password is being used repeatedly, it should not call that an attack... that's a user that forget he changed his password, or forgot that it was changed behind his back.

I agree it never desirable to forget the old password, until the user says to forget the old password.

I am now running the Beta 3 version and using a master password. I have both POP and IMAP accounts set up in it. The password prompt has not been an issue with it, to date. I've had it for 5-6 days now. I have not, therefore, run the fix you provided here. Thank you for your help.

(From update of attachment 391329)
Checked in with commented out lines removed:

http://hg.mozilla.org/comm-central/rev/365823464e88

Created an attachment (id=391874)
SMTP patch and test case

Last patch for this bug - cover the SMTP case. Notes:

- NS_SMTP_CONNECTING_TO_SERVER is an unused string, hence removing.
- I swapped the password prompts from ids to names like I did in the other patches (to benefit l10n).
- The unit test I had to split into 2 files - the fakeservers and smtp don't quite like doing multiple connections in one test. Seeing as it is in two parts anyway it is quite easy to split.

I ran a TB 3.0 beta 3 on a computer to access gmail via imap - all good
Then I changed the password in gmail from the web page.

TB didn't ask me to enter a new password, instead kept trying the old password stored in TB until google locked the account - I then had to run the unlockcatchpa app to reset the gmail account.

At that point, TB did ask for the password.

I will find a computer shortly to test this further.

Re: Comment #110. The problem you describe happens only when you actually change a password... and you should know you need to change it in your email client(s) also, at that point.

The problem described by this bug is becomes annoying due to transient network issues, down servers, and the like.

If the solution to this bug discovers problems with some servers, systems, or environments in which it is impossible to detect the difference between a password change and a transient error, TB/SeaMonkey should err in handling the condition without prompting the user for a password... because most of the time it _hasn't_ changed. And if it has, the user should know to change it everywhere, not just on the server. OK, that's full circle. Repeat until you understand that the transient error prompting is much more annoying, to many more people, than the occasional user lockout.

That said, debugging your situation is appropriate, to verify whether or not there is an error in the logic that discriminates password errors from other errors.

Re: Comment #111.

While the full-circle review of the problem is informative, don't use it to
justify an inadequate solution. Debugging it to see if there is a better
solution is smart -- good call. I would also like to solicit other ideas on
the user interface side when an account is not connecting properly. This is
regardless of whether gmail (or others) don't differentiate correctly between
error conditions.

I had previously suggested the use of some connection status indicator when an
account is currently in an error state. Alerts can be displayed in multiple
places such as on the toolbar, status bar, or the accounts in the All Folders
tree. Then, clicking (right clicking?) would bring up a menu or dialog to view
and resolve the alerts. Personally, I would like the indicator by the spinning
wheel in the upper right corner, but I will leave the specifics to the
Thunderbird user interface experts.

(In reply to comment #112)
> I had previously suggested the use of some connection status indicator when an
> account is currently in an error state. Alerts can be displayed in multiple
> places such as on the toolbar, status bar, or the accounts in the All Folders
> tree. Then, clicking (right clicking?) would bring up a menu or dialog to view
> and resolve the alerts. Personally, I would like the indicator by the spinning
> wheel in the upper right corner, but I will leave the specifics to the
> Thunderbird user interface experts.

This is covered by other bugs and other ideas. Please don't try to expand the scope of this bug further than what it is.

(From update of attachment 391874)
>+## LOCALIZATION NOTE(smtpEnterPasswordPrompt): Do not translate the
>+## word %1$S. Place the word %1$S where the host name should appear.
>+smtpEnterPasswordPrompt=Enter your password for %S:
Nit: note doesn't match string (uses %1$S instead of %S).

(From update of attachment 391874)
Checked in: http://hg.mozilla.org/comm-central/rev/d58f9a90a0b0

I have raised bug 508256 for changing the "Enter new Password" dialog into more
of a "Change Password" dialog as previously suggested in comment 84.

This bug is now fixed to the best we can do - any more issues should be filed
as separate bugs if they aren't already covered by existing bugs (after having
tested with the latest builds).

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

(In reply to comment #114)
> (From update of attachment 391874 [details])
> >+## LOCALIZATION NOTE(smtpEnterPasswordPrompt): Do not translate the
> >+## word %1$S. Place the word %1$S where the host name should appear.
> >+smtpEnterPasswordPrompt=Enter your password for %S:
> Nit: note doesn't match string (uses %1$S instead of %S).

And the winner is: (both mail/ and suite/) $S ;-)

Hmmm... I actually think there is some other aspect to this, as I only get this issue on one installation - from 3 different installations (on 3 different machines)of the same profiles and accounts (using the same servers - not gmail!) and the only one having this issue is the installation on my laptop (VISTA 32bit). the other installations (XP Pro 32bit & VISTA x64) are not having this issue - with the same accounts and servers. If it was a server issue, surely they would all be throwing up this erroroneous behaviour!?!

Forgot to mention, this only started happening on this one machine a week ago - had been working fine up til then,

This is by NO means fixed on my computer. It does not happen on my laptop only on the PC. The PC has just been totally redone. It was happening on the old OS and is Still happening on the New OS with ALL new installs of everything. I am using XP Pro, latest Thunderbird, Firefox 5.5.2 and Gmail. The password prompt still pops up every time I open Thunderbird. It can be canceled of X'd out and the mail will download, BUT it wont stop popping up.

(In reply to comment #121)
> This is by NO means fixed on my computer. It does not happen on my laptop only
> on the PC. The PC has just been totally redone. It was happening on the old OS
> and is Still happening on the New OS with ALL new installs of everything. I am
> using XP Pro, latest Thunderbird, Firefox 5.5.2 and Gmail.

Which version of Thunderbird are you using? Please include the full version text from about:config.

Note that this is NOT fixed in Thunderbird 2 builds - it is fixed in the Thunderbird 3 nightly builds in the sense that it will prompt you for what to do, not for your password.

The version I have the problem with is: version 2.0.0.22 (20090605)

(In reply to comment #123)
> The version I have the problem with is: version 2.0.0.22 (20090605)

Ok, thanks you either need to wait until Thunderbird 3 is out or use the Thunderbird 3 nightly or beta builds.

Move fixes are needed for V3. 2.0.0.22 is NOT holding most of the settings for assorted things = junk mail is tagged and info is not kept, NOT junk is also tagged as such and also not kept. MOST settings are not stored, they have to redone each time Thunderbird mail is opened. This is past annoying as it seems that there may be other large problems in the settings as well as security and virus problems.
JC

Right, I've tried deleting everything and re-installing several times (currently v2.0.0.23) and it hasn't made 1 iota of difference. Yet the same version but x64 on my PC has no issues...

Steve, do you use the old profile?

I deleted the old profile and restored from a previous backup (I use IMAP, so everything is still on the server) I'm thinking I might have to try a complete uninstall and re-input all the accounts manually from scratch. Everything seems to have been OK up until I did the 2.0.0.22 update, so I might try going back to the previous version with a clean install and see what happens - it's just that I haven't had time.

Thunderbird 2.0.0.22 DOES NOT hold any passwords, junk tags, "not a scam", or any similar tag. I seems that what ever part of the software that is supposed to take care of this is missing - it simply does NOTHING at all. Every time I open the mail all tags have to redone each time with the same email addresses. It has become a real pain!!

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

Is this EVER going to get fixed??? Any new newsletters of other new emails ALSO never hold the correct info = not spam, load images, and all other tags. Thunderbird needs a total redo!!! It is most certainly NOT FIXED !!!!

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

POP/IMAP server passwords are inappropriately forgotten
this is still happening in Version 2.0.0.23 (20090812)
if the pop-server refuses connection two times the password is lost (even if one clicks cancel and checks the "remember password"-button)
this behavior is really annoying if the server refuses the password often (although it is correct, e.g. web.de)
I think an email-client should never forget a password in this way (even if the server sends a bad password message)
this bug makes the save password tools nearly useless

(In reply to comment #133)
> POP/IMAP server passwords are inappropriately forgotten
> this is still happening in Version 2.0.0.23 (20090812)

As has already been mentioned this will not be fixed in the Thunderbird 2 series as the changes it requires are too significant.

It is fixed in Thunderbird 3 which will hopefully be out within the next month or so.

Please do not comment about 2.0.0.x on this bug as there is no viable solution that can be implemented there.

I hope it is fixed in Thunderbird 3 full version. I am currently running 3.0b4 and the master password is now prompting twice on start-up before it accepts it.

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

In Windows 2000 continues to lose the password.
Every time you compose a new message ... when you add a recipient from ldap is to re-enter the password

(In reply to comment #137)
> In Windows 2000 continues to lose the password.
> Every time you compose a new message ... when you add a recipient from ldap is
> to re-enter the password

That's probably bug 151447, it certainly isn't this one as this one doesn't reference LDAP.

Situation improved with latest version of Thunderbird -- but NOT resolved. Password window keeps popping up while the emails are downloading. Can be canceled of X out without having to enter password, so its there somewhere. Annoying but not tragic. The window should not still be popping up.

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

the bug was not fix
i still have it in v13

cubicdesign: This report was closed more than two years ago.
Please file a new report with exact steps to reproduce. See https://developer.mozilla.org/en/Bug_writing_guidelines

I just changed my password in Cpanel. Then TB asked for a new password and that was it. It doesn't work since then.

cubicdesign: Again: Please file a NEW report and explain it THERE, NOT here. Thanks.