after receiving authentication error the password is forgotten

[Broomer68]

Binary package hint: thunderbird

When receiving 'negative vibes' with the web-mail Hotmail extension or a plain pop account which gives a server failure, thunderbird responds with a pre-filled (remembered) password window, and the checkmark 'remember password' unchecked.
Then the next time this account is checked the password is not remembered anymore, and I have to fill it in myself again.

Can the default-behaviour of this remembered-password window also remember that I want it to remember? (this is: check the checkmark for remembering if the password was previously remembered (and [or if] previously accepted by the server)

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 8.10
NonfreeKernelModules: nvidia
Package: mozilla-thunderbird 2.0.0.17+nobinonly-0ubuntu1
PackageArchitecture: all
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: thunderbird
Uname: Linux 2.6.27-8-generic i686

[Matti-mversen (matti-mversen)]

dupe of bug 91656

Please reopen if you disagree !

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

[jimav (james-avera)]

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.

[Matti-mversen (matti-mversen)]

<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
--------------------------------------------------------------------------------

[jimav (james-avera)]

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)

[Jo-hermans (jo-hermans)]

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

[Jo-hermans (jo-hermans)]

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

[Felix Miata (mrmazda)]

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

[Alfonso (amla70)]

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

[David-fuller (david-fuller)]

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.

[Sspitzer (sspitzer)]

mass re-assign.

[Matt Mastracci (mmastrac)]

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.

[Lferro (lferro)]

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...

[Stepfahn (stepfahn)]

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

[Moco (moco)]

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

[Dhpelz (dhpelz)]

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

[M0zillabugs (m0zillabugs)]

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.

[V+mozbug (v+mozbug)]

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!

[Mkmelin+mozilla (mkmelin+mozilla)]

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

[Tallhall (tallhall)]

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.

[Stephend-panamnursery (stephend-panamnursery)]

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

[Mkmelin+mozilla (mkmelin+mozilla)]

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

[Gary-rumblingedge (gary-rumblingedge)]

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

[Mkmelin+mozilla (mkmelin+mozilla)]

Agreed this would be good to fix.

[Stephend-panamnursery (stephend-panamnursery)]

(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!

[V+mozbug (v+mozbug)]

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.

[Mkmelin+mozilla (mkmelin+mozilla)]

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

[Mkmelin+mozilla (mkmelin+mozilla)]

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

[Stephend-panamnursery (stephend-panamnursery)]

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.

[Steve-creativeinfluence (steve-creativeinfluence)]

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.

[Bugzilla-standard8 (bugzilla-standard8)]

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

[Matti-mversen (matti-mversen)]

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..

[Steve-creativeinfluence (steve-creativeinfluence)]

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.

[Dhpelz (dhpelz)]

(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

[Stephend-panamnursery (stephend-panamnursery)]

(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.

[Dhpelz (dhpelz)]

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

[Gwlperl (gwlperl)]

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'. "

[Matti-mversen (matti-mversen)]

>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)

[jimav (james-avera)]

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.

[Baldur-foo (baldur-foo)]

(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.

[V+mozbug (v+mozbug)]

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.

[Tallhall (tallhall)]

I'm sure you guys and gals will agree that over 6 years since initial reporting is quite a while to get a fix. Is there something we are not doing to get it done? I know we need a coder to do the job (I'd do it if I knew how) so how do we go about getting this done?

Gmail/Google Mail frequently drops out on IMAP and POP which prompts this error, with the growing popularity of this email provider surely many people must be experiencing this bug. ???

What I'm trying to get at is, how do we up the ante so that Mozilla notice this?

Matt

[Peter-lairo (peter-lairo)]

Dependency or duplicate of: bug 423687 and bug 423354 ?

[Mkmelin+mozilla (mkmelin+mozilla)]

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

[Freakboy2k (freakboy2k)]

@Matt
I agree. 6 years is an unacceptable amount of time for this bug to be in place. My old university has just shifted over to using GMail as their email provider, so any students there using Thunderbird are in for a rough time. I have stopped using Thunderbird because of this issue, as I have 4 GMail accounts that all throw up this message at once.
I agree with the idea that the password should not be forgotten - the box should have a retry button if it is impossible to determine if the error was due to an incorrect password or a server problem. that way the majority of us can get back to what we were doing without having to retype our passwords.

[Matti-mversen (matti-mversen)]

Please stop complaining here, this is a bug database and not a Forum.
If you want to get it fixed faster you can attach a patch.
Please only add a comment if you have new technical (!) informations but not for anything else, thanks

[Textureglitch-hotmail (textureglitch-hotmail)]

Can someone with the skills to do it please fix this bug?

This has been annoying me for years too, and is especially annoying when a mailserver is down. Just look at all the duplicates that have been created through the years by people with the same problem.

[Justin-justin-bell (justin-justin-bell)]

I am experiencing this issue with Thunderbird and Gmail IMAP accounts as well. Even after selecting remember password and OK, a failure pops up and it forgets the password.

I have also noticed that Thunderbird seems to have login failures to GMAIL without even trying a connection when memory usage by other applications is high.

[Tallhall (tallhall)]

(In reply to comment #47)
Add yourself to the list :)

GMail can be flaky at times causing these errors but if there is an issue with Thunderbird and memory then it should be reported as a separate bug.

Matt

[Bugzilla-standard8 (bugzilla-standard8)]

Retriaging according to new policy for flags.
https://wiki.mozilla.org/Thunderbird:Release_Driving
(bugs marked wanted- don't indicate we wouldn't accept patches, but that they're not going to be the focus for release drivers)

[Bryan Clark (clarkbw)]

I'm going to take on these dialogs so we can get this bug moving.

[Bryan Clark (clarkbw)]

I mid-air collided, which crashed and burned all the settings

[Bryan Clark (clarkbw)]

Is this dialog showing when the server is disconnected? It appears from the comments that either there is no way to really know the server error or we're just using the same dialog for it. If it's possible to detect login failure vs. server failure we need to separate those kinds of errors.

At the same time I don't understand why we would destroy the persons password in any case. Even if the password has changed on the server what does destroying the old password give us? It seems we should at least always keep the old password even if it appears to be failing.

[Cheechge (cheechge)]

I too am having the same problem as most of the others. I have 2 gmail accounts both of which are connected to TB (2.0.0.16) via IMAP and both of which have their passwords stored in TB and are encrypted using the master password facility. TB frequently prompts me for the password of my primary account during the day, and frequently will do so several times in succession even though I have checked the box to save the password. My secondary account, although not used as much, never requires that I manually enter a password.

I've checked the stored passwords for both accounts and they have always been the correct ones. When TB is first started sometimes it will prompt me for the password on my primary account before prompting me for the master password. Other times it will prompt me only for the master password and correctly log on the both email accounts. And, other times I am not prompted for a master password at all. As I mentioned earlier I am never prompted for the password on my secondary email account.

This happens frequently enough each day that I will gladly capture any additional information to help resolve the problem, however, I will probably need some technical guidance as to what additional information is required and possibly how and where to get it.

[Bienvenu (bienvenu)]

this situation is improved in 3.0 nightly builds - we won't forget passwords on logon failure from the background check for new mail, as opposed to the user checking for new mail on startup, or clicking get new mail. And we won't forget the password if the user has managed to logon once in the session. I'm going to move this off to b2. I hope that the new password manager stuff will allow us more flexibility in our password handling, but I want to wait for that to land before tackling more of this.

[Broomer68 (jbezemer)]

Binary package hint: thunderbird

When receiving 'negative vibes' with the web-mail Hotmail extension or a plain pop account which gives a server failure, thunderbird responds with a pre-filled (remembered) password window, and the checkmark 'remember password' unchecked.
Then the next time this account is checked the password is not remembered anymore, and I have to fill it in myself again.

Can the default-behaviour of this remembered-password window also remember that I want it to remember? (this is: check the checkmark for remembering if the password was previously remembered (and [or if] previously accepted by the server)

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 8.10
NonfreeKernelModules: nvidia
Package: mozilla-thunderbird 2.0.0.17+nobinonly-0ubuntu1
PackageArchitecture: all
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: thunderbird
Uname: Linux 2.6.27-8-generic i686

[Bugzilla-standard8 (bugzilla-standard8)]

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

[Nomis101 (nomis101)]

On the old password manager the given password was prefilled after the login failed, since the new password manager the password isn't prefilled anymore. So you have to retype it. If you have an free email account from the german webmail provider "web.de" (one of the most frequent provider in germany), than you are not allowed to retrieve your emails more often than every 15 minutes on POP3 accounts. If you are under this limit, than you receive a message and Thunderbird thinks your connection failed. So, you have to retype your password. This is annoying if you had to restart Thundebird e.g. after installing a Add-On. So I also vote for fixing this bug!

[Bienvenu (bienvenu)]

so this has regressed? That's not good. Maybe yet an other reason to have our own password dialog.

[Killjay (killjay)]

Could be the fix DavidB did a few years ago was Wallet specific and needs re-evaluation for working with the PWM widget. That fix at least prefilled the textboxes in the popup for the User to verify before activating a re-connect attempt.

[Bitzinius (bitzinius)]

Hi everyone, after a little code spelunking I noticed that /content/pippki/password.js (stored inside %TB%/chrome/pippki.jar, where %TB% is the program install dir - open the jar as a ZIP file) has two functions, getPassword() and setP12Password(), that contain exactly the same code. This looks like a bug, and *could* be related to this problem. Unfortunately I am unable to set up a build env to test this... could somebody please check it out?
BTW, a quick debugging method might be to add alert("something") to the javascript.

[Bugzilla-standard8 (bugzilla-standard8)]

(In reply to comment #59)
> Hi everyone, after a little code spelunking I noticed that
> /content/pippki/password.js (stored inside %TB%/chrome/pippki.jar, where %TB%
> is the program install dir - open the jar as a ZIP file) has two functions,
> getPassword() and setP12Password(), that contain exactly the same code. This
> looks like a bug, and *could* be related to this problem.

Nope. The slightly worse regression problem is in mailnews or toolkit, and the actual bug is in mailnews.

[Joshua Cranmer (jcranmer)]

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

[Bienvenu (bienvenu)]

I'll have a look at this, unless Standard8 is actively working on it.

[Bienvenu (bienvenu)]

I think what regressed this is this:

void nsMsgIncomingServer::GetPasswordWithoutUI(nsACString &aPassword)
{
  aPassword.Truncate();

aPassword happens to have the previously sent password, and this crunches it. Which is a bit goofy because it never actually sets it as an out value; m_password gets set...so I don't really know what the semantics here are meant to be now, but removing that line would probably fix the issue...

[Bugzilla-standard8 (bugzilla-standard8)]

Created an attachment (id=362782)
Part 1 - Unregress including prompt in password dialog (WIP)

This patch is a starter for unregressing putting the password in the password dialog if we do prompt it again. It is unfinished (see the two XXX comments) and doesn't cover the smtp protocol (and maybe news as that does things differently), but its a starter...

[Bienvenu (bienvenu)]

Created an attachment (id=362790)
gets us back to b1 behavior

I think we might consider this for b2 - it basically gets us back to where we were with b1...

[Bugzilla-standard8 (bugzilla-standard8)]

(From update of attachment 362790)
As long as the unit tests pass, I'm happy to take your word that this fixes the recent regression.

Its a simple patch to fix something that was obviously wrong anyway.

r/sr=me. We'll leave the bug open, but target it to b3 to try and come up with a full fix.

[Bienvenu (bienvenu)]

ok, I've landed the patch, so the regression is fixed - moving off to b3 for remaining issues.

[Dave (fehe)]

It doesn't look like this is back to beta b1 behavior. It's still forgetting passwords. This is what I'm observing:

1. "Enter your password:" prompt appears and is filled in, but "Use Password Manager to remember this password" is not checked (but it should be).

2. Now since I know there is an error and hitting OK would require me to do so ad infinitum, I click Cancel. Next time I try check email, the "Enter your password:" prompt appears and the password has been FORGOTTEN.

3. If I try again from Step 1 (above) but this time check "Use Password Manager to remember this password" before clicking Cancel, the password is still FORGOTTEN next time "Enter your password:" appears.

So "Use Password Manager to remember this password" must be automatically checked for this to work properly.

[Bienvenu (bienvenu)]

that was an excellent description of beta 1 behavior, unfortunately.

[Dave (fehe)]

Here's another example of the silliness of this bug:

Shredder starts and attempts to check my Hotmail email. Authentication fails and Shredder reports, "Sending of password did not succeed. Mail server pop3.live.com responded: authentication server unavailable, please try later."

Nevertheless, Shredder completely ignores the server response message and immediately asks me to enter my password again!

In addition to making "Cancel" not forget password, MailNews Core Shredder desparately needs a way to determine the reason for an authentication failure--rather than treating every authentication failure as a bad password issue.

[Bugzilla-standard8 (bugzilla-standard8)]

Per our discussion on irc last night, here's some comments about this bug and where we want to go.

Firstly: due to the existing mail protocols, we do not get clear error codes and are not guaranteed specific responses (indeed they may not even be in one language) which is why we can't account for every situation and we have to play it cautiously.

UI proposal:

If we get to a situation where we think we may need to change the password, offer a dialog as follows:

Text: "Thunderbird tried contacting the server 3 times and received the following message: $MSG"
Default Button: Retry
Other Buttons: Cancel, Enter New Password

If the "Enter New Password" button is pressed, then we put up another dialog for changing the password.

Suggested Backend Implementation:

1) Look for the existing "ForgetPassword" function calls in mailnews:

http://mxr.mozilla.org/comm-central/ident?i=ForgetPassword

2) Instead of calling "ForgetPassword" throw up dialog as described above (maybe function in nsMsgUtils to do it?)

I think nsIPrompt::confirmEx can be used to do this - http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/base/public/nsIPrompt.idl#100

3) Adjust the logic around the ForgetPassword calls to handle the responses.

4) For the "Enter New Password" case we can initially just use ForgetPassword as we do now, but I think a better follow-up would be to make it a change password dialog (and use nsILoginManager's modifyLogin function) - but I think this can wait if it means we get 1-3 implemented.

I've got a lot on my plate for b3, so if anyone wants to take this off me, please do, ping me on irc if there's questions about the implementation.

[Ralf-mozilla-org (ralf-mozilla-org)]

Your comment completely hits the nail on its head, IMHO.

[Bronson-real-time (bronson-real-time)]

Mark Banner,
I like the proposal to handle the cases where the user needs to be prompted for a different password. However, you have merely tapped the nail on the head, and it needs a bigger smashing. Please forgive the metaphor mutilation. :)

Please make sure that there are no failure conditions where a dialog continually pops up asking for a password. Even in the case where a password is wrong, Thunderbird still has utility and does not need to continually prompt or a password. In your proposal, what happens on the next refresh attempt when a user clicks cancel and the password is retained yet wrong?

To be successful here, there needs to be some sort of connection status indicator that can display which accounts are offline in a concise yet thorough manner. It may be difficult to show that one POP connection hasn't been refreshed for 3 hours, 1 IMAP connection is offline, 1 IMAP connection has been disabled intentionally, but one POP and one IMAP are still online. Perhaps we need a single icon/button showing online, partially online, or error conditions can be clicked for more details.

[Bugzilla-standard8 (bugzilla-standard8)]

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

[Dbkh999 (dbkh999)]

No doubt this has been a major PITA for many users, for a very long time -- thus the huge number of search results and duplicate claims...

The auto-change of passwords might seem like a "feature", but nearly 100% of the time, this feature is a major PITA.

Seems like a very simple solution:
Don't ever auto-change any send or receive passwords. At most, there should be a pop-up notice informing of "server log-in failure -- would you like to alter your password".

for many users, for a very long time.....

[Bugzilla-standard8 (bugzilla-standard8)]

Created an attachment (id=385846)
Proposed UI

This is the proposed UI as per comment 71.

I've got a patch that I'll post in a minute that is IMAP-only but implements steps 1 - 3, I'll be looking at POP soon. News doesn't seem to use ForgetPassword, and I believe SMTP isn't an issue.

[Bugzilla-standard8 (bugzilla-standard8)]

Created an attachment (id=385850)
IMAP patch

As mentioned, this is the IMAP patch implementing steps 1-3 in comment 71. Still needs some unit tests.

[Bienvenu (bienvenu)]

this looks reasonable - just need to make sure that urls with no msg window don't throw up this prompt (e.g., biff).

[Bryan Clark (clarkbw)]

(From update of attachment 385846)
dialog looks good

[Ralf-mozilla-org (ralf-mozilla-org)]

(In reply to comment #76)
> Proposed UI

Please make sure that the default is "Retry", and that even if user clicked
"Enter new password" there is still a way to back out (i. e. if user changes
mind, clicks "Cancel", password will not be forgotten.)

[Dmose (dmose)]

Getting this for b3 would be great, but we wouldn't actually hold b3 for it, I don't think.

[Mkmelin+mozilla (mkmelin+mozilla)]

(From update of attachment 385846)
I think HIGs want button text capitalized.

[Dbkh999 (dbkh999)]

Great you folks are working on this.
For SMTP
Every time TB pops up the change password option with the SAVE unticked, even though always ticked, I still ALSO have to reenter password next time I use that account to send. So SMTP is effected unless already fixed elsewhere.
Thanks for your work!!

[Bugzilla-standard8 (bugzilla-standard8)]

(In reply to comment #78)
> this looks reasonable - just need to make sure that urls with no msg window
> don't throw up this prompt (e.g., biff).

The code actually does this already, but the patch isn't as clear. I have no changed the interface so that we pass nsIMsgWindow rather than the url.

(In reply to comment #80)
> Please make sure that the default is "Retry",

That is what comment 71 says we will have.

> and that even if user clicked
> "Enter new password" there is still a way to back out (i. e. if user changes
> mind, clicks "Cancel", password will not be forgotten.)

I'm probably not going to do this in the first version of the patch as that is more complex and I'd like to see how POP3 and SMTP turn out. As I've got this far I'd like to get at least an initial version of the patch in for beta 3 and I can deal with that improvement later either in further patches in this bug, or in a different bug.

[Bugzilla-standard8 (bugzilla-standard8)]

Created an attachment (id=386024)
IMAP patch v2

I'm still attempting to write a unit test for this, but I'm happy with the patch. I'd like to get this into b3 so we can get some idea of how well it is working.

Most of it is fairly obvious I think. I redid the calls in AlertUserEventUsingId which aren't strictly part of this patch, but are a bit of tidy up to avoid going across the imap thread -> ui thread barrier twice. Also enables some tidy of the functions in nsImapProtocol.

[Neil-httl (neil-httl)]

(From update of attachment 386024)
>+ // We're not really interested in this, but supply a check value anyway.
>+ PRBool checkValue;
Just call this dummyValue, saving you a comment ;-)

>+ // Error condition
>+ message.AssignLiteral("String ID ");
>+ message.AppendInt(aMsgId);
>+ FEAlert(message, aUrl);
I assume we only expect to hit this in development so we don't need to know which server is reporting the alert?

>+nsImapIncomingServer::GetFormattedStringFromName(const nsString &aName,
...
>+ result.AssignLiteral("Failed to get string named ");
s/get/format/ ;-)

>+imapLoginFailedRetryButton=Retry
No access key? (&Retry iirc)

[Bienvenu (bienvenu)]

(From update of attachment 386024)
this seems generally OK - I haven't tried the temporary server failure case, but I verified that I do get reprompted if I change the server password.

[Ralf-mozilla-org (ralf-mozilla-org)]

(In reply to comment #86)
> >+ // Error condition
> >+ message.AssignLiteral("String ID ");
> >+ message.AppendInt(aMsgId);
> >+ FEAlert(message, aUrl);
> I assume we only expect to hit this in development so we don't need to know
> which server is reporting the alert?

I'm not sure whether the context of the error message is visible to users without the above "server" identifier -- please in any case make absolutely sure that users can clearly identify to which account the error message applies.

FYI: I have 21 (twenty-one) accounts set up in Thunderbird, a lot of them are hosted on the same server, so a message like "IMAP server myserver.de reported invalid password" doesn't do me any good. It also needs to refer to the account name as given on the "topmost-level" in "Account Settings."

[Bugzilla-standard8 (bugzilla-standard8)]

(In reply to comment #86)
> >+ // Error condition
> >+ message.AssignLiteral("String ID ");
> >+ message.AppendInt(aMsgId);
> >+ FEAlert(message, aUrl);
> I assume we only expect to hit this in development so we don't need to know
> which server is reporting the alert?

Correct, in theory l10n development can hit this, though with l10n merge that's less likely. It is just what we did before as a fallback so I kept it.

> >+imapLoginFailedRetryButton=Retry
> No access key? (&Retry iirc)

nsIPrompt::confirmEx doesn't give us an access key option. The only way we could do something about this would be to spin our own prompt dialog. Whilst I can see that happening after the next major version of TB/SM, I'm not sure it is what we want to do now.

[Bugzilla-standard8 (bugzilla-standard8)]

Created an attachment (id=386080)
IMAP patch v3

Updated patch with Neil's comments address except where mentioned in comment 89.

[Mkmelin+mozilla (mkmelin+mozilla)]

(In reply to comment #89)
> nsIPrompt::confirmEx doesn't give us an access key option.

Putting a & in front of the letter you want as access key didn't work? (&Retry for _R_etry)

[Bugzilla-standard8 (bugzilla-standard8)]

Created an attachment (id=386102)
IMAP patch v3a

I misread/misunderstood Neil's comment. Patch with accesskeys.

[Neil-httl (neil-httl)]

(From update of attachment 386102)
>+imapLoginFailedCancelButton=&Cancel
You don't need to do Cancel. It's not expected to have an access key, as the Escape key always works. (Besides, if it was expected to have an access key, then the default Cancel button title would have it anyway.)

[Bugzilla-standard8 (bugzilla-standard8)]

Created an attachment (id=386277)
IMAP test case

Unit test for the IMAP case. In this patch I've also included some changes to alertTestUtils.js including:

- fixing returning values from the functions that should be returning values.
- fixing getNewAuthPrompter so that it returns an nsIAuthPrompt object. This is in fact the login manager prompter as that is what you'd end up getting running the application anyway.
- adding an nsIPromptService implementation.

As a result, I've updated test_bug155172.js to use alertTestUtils.js as well.

The test should cover all the prompt cases including ensuring we haven't inappropriately forgotten the password. Additionally this means we have an IMAP test using the password manager.

[Bugzilla-standard8 (bugzilla-standard8)]

Created an attachment (id=386280)
IMAP patch v3b

The final version of the IMAP patch addressing Neil's comments.

[Bienvenu (bienvenu)]

the test failed with this error - was signons-mailnews1.8-imap.txt not hg added?

Directory request for: CurWorkD that we (mailDirService.js) are not handling, leaving it to another handler.
TEST-UNEXPECTED-FAIL | C:/mozilla-build/msys/tbirdhq/objdir-tb/mozilla/_tests/xpcshell/test_imap/unit/test_imapPasswordFailure.js | [ru
n_test : 87] C:\mozilla-build\msys\tbirdhq\objdir-tb\mozilla\_tests\xpcshell\mailnews\data\signons-mailnews1.8-imap.txt does not exist
TEST-UNEXPECTED-FAIL | (xpcshell/head.js) | [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIFi
le.copyTo]" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: C:/mozilla-build/msys/tbirdhq/objdir-tb/mozilla/_
tests/xpcshell/test_imap/unit/test_imapPasswordFailure.js :: run_test :: line 90" data: no]
before 139264, after 135168, break 00000000
JS Component Loader: ERROR (null):0

[Bugzilla-standard8 (bugzilla-standard8)]

Created an attachment (id=386462)
IMAP test case v2

Yep, missed the file, I'm sure I remembered to add it before submitting the patch, but somehow it didn't get onto the bug.

[Bugzilla-standard8 (bugzilla-standard8)]

(From update of attachment 386280)
Checked in:
http://hg.mozilla.org/comm-central/rev/1d71913d2b49

[Bugzilla-standard8 (bugzilla-standard8)]

(From update of attachment 386462)
Checked in: http://hg.mozilla.org/comm-central/rev/5cf38a1e038e

[Joshua Cranmer (jcranmer)]

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

[Bugzilla-standard8 (bugzilla-standard8)]

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

[Bugzilla-standard8 (bugzilla-standard8)]

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

[Bugzilla-standard8 (bugzilla-standard8)]

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

[Bugzilla-standard8 (bugzilla-standard8)]

Created an attachment (id=391329)
POP patch and unit test

This patch extends the new retry/cancel/enter new password dialog to the POP protocol as well as IMAP.

As a result, there's a little bit of re-arrangement. The actual code for the retry/cancel/password prompt has been moved to nsMsgUtils, with the associated strings moving to messenger.properties.

I have also adjusted the POP3 password prompt dialog strings to replace numbers with strings (as l10n like them) and tidy up the strings with appropriate localisation notes (the previous notes were just wrong).

Unit test also included.

[Bienvenu (bienvenu)]

(From update of attachment 391329)
one nit - any reason to leave the commented out code in?

+ // Let OnStopRunningUrl return cleanly before doing anything else.
+ // async_driver();

[Bugzilla-standard8 (bugzilla-standard8)]

(In reply to comment #105)
> (From update of attachment 391329 [details])
> one nit - any reason to leave the commented out code in?
>
> + // Let OnStopRunningUrl return cleanly before doing anything else.
> + // async_driver();

Nope - I was going to use the async items, then realised I didn't need to, just forgot to delete the line.

[Dmgiles (dmgiles)]

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.

[Bugzilla-standard8 (bugzilla-standard8)]

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

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

[Bugzilla-standard8 (bugzilla-standard8)]

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.

[Robert-cox (robert-cox)]

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.

[V+mozbug (v+mozbug)]

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.

[Bronson-real-time (bronson-real-time)]

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.

[Bugzilla-standard8 (bugzilla-standard8)]

(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.

[Neil-httl (neil-httl)]

(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).

[Bugzilla-standard8 (bugzilla-standard8)]

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

[Bugzilla-standard8 (bugzilla-standard8)]

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).

[Bugzilla-standard8 (bugzilla-standard8)]

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

[Jh-junetz (jh-junetz)]

(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 ;-)

[Porpoise1954 (steve-srenterprises)]

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!?!

[Porpoise1954 (steve-srenterprises)]

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

[Joyce (joyce)]

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.

[Bugzilla-standard8 (bugzilla-standard8)]

(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.

[Porpoise1954 (steve-srenterprises)]

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

[Bugzilla-standard8 (bugzilla-standard8)]

(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.

[Joyce (joyce)]

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

[Porpoise1954 (steve-srenterprises)]

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...

[Christian Ertl (ertlchr)]

Steve, do you use the old profile?

[Porpoise1954 (steve-srenterprises)]

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.

[Joyce (joyce)]

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!!

[Bugzilla-standard8 (bugzilla-standard8)]

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

[Joyce (joyce)]

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 !!!!

[Joshua Cranmer (jcranmer)]

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

[Peter-schauss (peter-schauss)]

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

[Bugzilla-standard8 (bugzilla-standard8)]

(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.

[Dmgiles (dmgiles)]

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.

[James-mozilla (james-mozilla)]

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

[Micah Gersten (micahg)]

Thank you for your bug report. This bug has been reported to the developers of the software.
Therefore, I'm going to mark it as Triaged. This has already been fixed in Thunderbird 3 and will not be fixed in Thunderbird 2 per upstream. Thanks for taking the time to make Ubuntu better! Please report any other issues you may find.

[Launchpad Janitor (janitor)]

This bug was fixed in the package thunderbird - 3.0+nobinonly-0ubuntu1

---------------
thunderbird (3.0+nobinonly-0ubuntu1) lucid; urgency=low

  * New Upstream Release 3.0 (THUNDERBIRD_3_0_RELEASE)
    - LP: #50902 - Thunderbird displays useless dialog
    - LP: #52667 - Thunderbird doesn't support RFC-2369
    - LP: #49033 - Doesn't recognize upper case extension (.JPG)
    - LP: #56465 - Per folder column widths
    - LP: #68456 - CTRL-Shift-K bound to 2 functions
    - LP: #79337 - Typo in Server Information for Add Account Wizard
    - LP: #1084 - No scroll on full headers list
    - LP: #62071 - Middle click on scrollbar pastes instead of jumping
    - LP: #119358 - Weak default authentication mode
    - LP: #120672 - No option to empty junk folder with right click
    - LP: #96566 - movemail doesn't work with default privs
    - LP: #122529 - Non-Thunderbird IMAP folders not visible to Thunderbird
    - LP: #241276 - Not able to paste image into thunderbird compose window
    - LP: #244635 - scrollboxes scroll to offset 0 when resized
    - LP: #259387 - "Edit Message as New" broken for eml messages
    - LP: #120281 - Editing a message from the drafts folder leaves line breaks
    - LP: #115484 - Dialogue boxes too large for 1024x768 resolution
    - LP: #320034 - Mail with self referencing headers breaks threading
    - LP: #160794 - shortcuts different in windows and linux
    - LP: #280987 - thunderbird keeps asking a password when working off-line
    - LP: #369150 - Thunderbird splits email addresses with non-ascii characters
                    and a comma in From: field
    - LP: #135066 - Thunderbird doesn't use Ubuntu icon theme
    - LP: #297301 - after authentication error the password is forgotten
    - LP: #487541 - thunderbird-bin crashed with SIGSEGV (AFS filesystem)
    - LP: #485224 - Thunderbird saves double attachment file name endings on
                    FAT32 and NTFS
    - LP: #482496 - When using SCIM ANTHY, autosaving fails, and then get asked
                    about sending in UTF-8

  [ Fabien Tassin <email address hidden> ]
  * Add build-depends on autoconf2.13, autotolls-dev, mozilla-devscripts
    libglib2.0-dev (>= 2.12), libstartup-notification0-dev, libbz2-dev,
    libpixman-1-dev, libdbus-1-dev (>= 1.0.0), libdbus-glib-1-dev (>= 0.60),
    libhal-dev (>= 0.5.8), libasound2-dev, libreadline5-dev | libreadline-dev,
    libkrb5-dev
  * Update build-depends minimums for libx11-dev (>= 2:1.0),
    libgtk2.0-dev (>= 2.12), zlib1g-dev (>= 1:1.2.3), libpng12-dev (>= 1.2.0),
    libjpeg62-dev (>= 6b), libcairo2-dev (>= 0.5.8), libgnome2-dev (>= 2.16),
    libgnomevfs2-dev (>= 1:2.16), libgnomeui-dev (>= 2.16),
    libnss3-dev (>= 3.12.0~1.9b3)
  * Bump standards version to 3.8.0
  * Replace ${Source-Version} by ${binary:Version} in control file
    - update debian/control
  * Bump requirement for system nspr to >= 4.8 since Mozilla bug 492464 landed
  * Bump requirement for system nss to >= 3.12.3 since Mozilla bug 485052 landed
  * Use in-source hunspell when hunspell 1.2 is not available
  * Add conditionnal support for --with-libxul-sdk controlled by
    $(USE_SYSTEM_XUL)
    - update debian/rules
  * Add p...

[Phixxius (phixxius)]

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

[Bugzilla-standard8 (bugzilla-standard8)]

(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.

[Joyce (joyce)]

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.

[Bugzilla-standard8 (bugzilla-standard8)]

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

[dotniet (cubicdesign)]

the bug was not fix
i still have it in v13

[Andre Klapper (a9016009)]

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

[dotniet (cubicdesign)]

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

[Andre Klapper (a9016009)]

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