User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1 When both the POP and SMTP server passwords are saved in password manager the following undersired behavior occurs when the password is changed. When opening Thunderbird the pop account attempts to login and fails but will not prompt for a new password until the account is locked out. When the SMTP password fails it immediately prompts for a new password. The POP password should work like the SMTP password and immediately prompt for a new password after the first failure. Reproducible: Always Steps to Reproduce: 1. Change password 2. Open Thunderbird 3. Attempt to get mail Actual Results: Login failed repeatedly, after account lockout, then prompts for new password. Expected Results: Thunderbird should have prompted for a new pop password immediately following the first failure. I realize a user could go to the password manager and delete the password. However in this workgroup environment passwords changes are frequently required. Having users delete passwords out of password manager would be like pulling my own teeth.

applies to version 0.7 and 0.7.1

Oh god, we have already had any situation were any of the behaviour (prompt immediately, prompt after 3 wrong attempts, never prompt) made somebody scream that this is wrong. Currently the situation is nearly as bad as with the first fix from bug 160425. The behaviour now (since bug 219162) is, if a password has proven to be valid in *this* session it's never discarded. If this is the first login you've two tries before discarding the password. I guess the best solution would be modifying this further. Either by giving the user the chance to stop authentication (via Cancel in the alert, I think this is bug 189633) or automatically do this after say three failed tries without discarding the password.

Actually if this is the first login it tries once and fails. The password is not discarded. Then when you hit get mail again it tries twice and then discards the password. In many environments after 3 failed attempts accounts are locked out. If it tried twice when opened and then prompted the lockout would be avoided. However what is the benefit of attempting the password multiple times? I would like to think that all mail systems are reliable enough for one attempt and then discard the password if it fails. Also a password should be immediately discarded when it fails regardless of the session. Passwords can be changed at any time and to assume it will not be changed mid-session is fairly unreasonable. Thanks,

See discussion in e.g. bug 160425 and bug 219162. > I would like to think that all mail systems are reliable enough for one > attempt and then discard the password if it fails. It would be great if this were reality. We had many cases reported in which servers failed to accept valid credentials via CRAM-MD5 or PLAIN authentication mechanism but accepted it with LOGIN or USER/PASS (note, they advertised all four mechanisms as being available). So we have to fall back and try PLAIN after CRAM-MD5 and LOGIN after PLAIN a.s.o. (Actually falling back from highest to lowest mechanism is counted as one try, so in reality we can really issue maxtries*available mechanisms tries.) Or scenarios in which the server says "logged in to often, please wait 5 minutes" or "mailbox in use". Discarding the password immediately in these cases made people angry. > Also a password should be immediately discarded when it fails regardless of > the session. I guess this has been implemented because it's unlikely that a server password realy changes while the user uses the application (at least for people that only start the mail client for getting and reading mail and then close it - so it's open for say 20 minutes continuously).

So essentially what you are stating is this software will never be usable in a secure commercial workgroup environment?

Also please note if you examine other commercial mail clients you will find they rely upon the user to properly configure the client. If they want MD5 or a secure connection they must specify it, and so on. After a failure the other commercial applications will ask for a new password after one failure. At some point you have to rely upon the software and the server being properly configured and not taking responsibility for working around their mistakes. Also in a world going towards single sign on user accounts / password it will be more common for passwords to change mid stream.

> Also please note if you examine other commercial mail clients you will find > they rely upon the user to properly configure the client. If they want MD5 > or a secure connection they must specify it, and so on. That's AFAIK true. But that's unnecessary if > At some point you have to rely upon the software and the server being properly > configured since in this case a server would support the mechanisms it advertises properly. So what you write is a little contradictory. Either rely or do everything by hand. The motivation to not ask the user what mechanism to use is that most will simply don't use any advanced function if he don't know it. > After a failure the other commercial applications will ask for a new > password after one failure. Any other client I know has a password field in the server configuration and will not discard the password at any time. But they stop at the first error encountered. As I wrote, we had asked for a new password at every error. And users complained as you do now about the opposite. > At some point you have to rely upon the software and the server being > properly configured and not taking responsibility for working around > their mistakes. I know a dozend bugs reported by users where the cause was a corrupt server. But users don't care about that, that's a fact.

I know users don't care about a corrupt server, but neither should you. You cannot take the responsibility of making every corrupt server work and maintain a quality piece of software. In the end that is a great disservice to you and especially your users. From what you are saying, this software will never be suitable for a secure commercial workgroup environment. This is really a shame as it is a wonderful piece of software with great capabilities. If you choose to eliminate such a large audience, that is your decision. I will simply find another software product for the multiple isolated secure workgroups and not look back. While at it we will also remove all other Mozilla applications as the intent of the software development now appears tainted and unstable.

> I will simply find another software product for the multiple isolated secure > workgroups and not look back. Well, it's up to you, but please no empty threats. > From what you are saying, this software will never be suitable for a secure > commercial workgroup environment. Really? What did say? I just explained why it is like it is and what I know about other software. There was no "and we're not gonna change it" or something similar. > as the intent of the software development now appears tainted and unstable. Wow, you know what "the project" or "the maintainers" say? I don't, and I'm no official, I'm no module owner or so. Before damn the whole software you should have a more definitive knowledge about the further development. Maybe David will say something about his thoughts. Also you can't expect all jumping around to do what you want. Some constructive critics and respect to what other users want and expect would be nice. Why should someone make changes to the client in order to please you while this will make other hundred people throw it away?

Er, to echo what Christian said, he was describing the way it works now, and why, not that it couldn't and shouldn't be improved...see http://bugzilla.mozilla.org/show_bug.cgi?id=249240#c2 If we're really talking about enterprise deployments, it's trivial to add a pref that enterprises can customize through MCD or at install time that gets rid of fallback and password retries, or one which specifies which authentication mechanism to use. Adding a UI that says something like "only use most secure authentication supported by server" might be reasonable as well. I'm a little confused about your situation, Rich, however. Have you turned on "Use secure authentication" in your pop3 server settings? How many secure authentication mechanisms does your server support?

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

Bug 246291 and Bug 246542 appear to report the same password problem while using IMAP. I believe that they might be duplicates of this bug. If they are, the summary of this bug ought to be changed to mention both POP and IMAP (or not mention the protocol at all).

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

Yes, this should be moved to Networking: MailNews General. Duping the other addresses. Asking for blocker of aviary1.0PR.

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

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

Henrik: Nice catch on changing the subject. I like the new subject a lot better. The old one almost made it sound like the pop server should bring up the dialog ^.^

sounds like bienvenu might be working on this one. plus for now.

we aren't working on this for 0.8. so this should be a minus for the firefox 1.0PR flag since that maps to .8. We may consider it for .9/1.0

This patch adds a server pref that allows the user to disable logon fallback. Then, during pop3 logon, if that pref is true (it defaults to false), then we will not fallback on an authentication failure. There's no UI for this pref currently, but we should consider adding on. For enterprises, they can set this pref via MCD, if important. The reason we default to false is that there are so many bad servers out there, as has already been discussed. If this approach is reasonable, we can add similar code to the imap protocol code.

(In reply to comment #20) > This patch adds a server pref that allows the user to disable logon fallback. > Then, during pop3 logon, if that pref is true (it defaults to false), then we > will not fallback on an authentication failure. You should be aware that the problem described in bug 262584 could still occur. We'll never increase logonFailureCount (not to speak of isAuthenticated could be true) and still loop. You could continue with this patch and modify the one from bug 262584 (or use the first variant I posted there but is uggly) or modify this patch so it includes the necessary changes to prevend a loop. Additionally, solving bug 259679 would also solve this one too because it would define one mechanism to use and nothing else. If you/we think a fix of bug 259679 will take too long, your patch would be a ok interims solution - but IMHO nothing more.

> modify this patch so it includes the necessary changes to prevent a loop. what would that look like? re bug 259679, I think forcing the user to limit themselves to one authentication mechanism would be confusing for a lot of users - they'd have no idea which one to pick. Only using the most secure by default and not falling back to less secure mechanisms by default is also going to be a support pain. So, I think giving the user the options in bug 259679 is a good feature, but I think out of the box we want to work on the greatest variety of servers. I think the situation described in this bug is definitely a less common issue than the issues we've had with bad servers so I don't mind making users with this problem have to configure some UI. I don't think that runs counter to anything you've said about the relationship between this bug and bug 259679, but I just wanted to make sure that's true.

(In reply to comment #22) > > modify this patch so it includes the necessary changes to prevent a loop. > > what would that look like? I can think of three ways. Either faking authenticated and the count by putting m_nsIPop3Sink->SetUserAuthenticated(PR_FALSE); m_pop3ConData->logonFailureCount = 2; in the action of if (TestFlag(POP3_AUTH_FAILURE) || !logonFallback) or doing something like - if (!isAuthenticated && m_pop3ConData->logonFailureCount > 1) + if ((!isAuthenticated && m_pop3ConData->logonFailureCount > 1) || + TestFlag(POP3_AUTH_FAILURE) || !logonFallback) rv = server->ForgetPassword(); while logonFallback needs to be global here. Or we set POP3_AUTH_FAILURE if !logonFallback in AuthFallback() and go with patch v2 from bug 262584. > re bug 259679, I think forcing the user to limit themselves to one > authentication mechanism would be confusing for a lot of users - they'd have > no idea which one to pick. Sure, but if you remember, you proposed this in bug 258077, comment #17. > So, I think giving the user the options in bug 259679 is a good feature, but I > think out of the box we want to work on the greatest variety of servers. Of course the default would "automatic" be as I layed out in the description and thus the current behaviour. > I think the situation described in this bug is definitely a less common issue > than the issues we've had with bad servers so I don't mind making users with > this problem have to configure some UI. But because it's less common I think it would be tolerable to use a UI (though the pref of bug 259679 could also be set directly). The problem for the user would be to find out which mechanism to use. :(

(In reply to comment #23) > > I think the situation described in this bug is definitely a less common issue > > than the issues we've had with bad servers so I don't mind making users with > > this problem have to configure some UI. > > But because it's less common I think it would be tolerable to use a UI (though > the pref of bug 259679 could also be set directly). The problem for the user > would be to find out which mechanism to use. :( Actually, it's possible to auto-detect this if you want to. If the default is to try all the authentication mechanisms one after the other, you just try them all (in some sensible order) until one works. It would even be possible to set that default behaviour on startup for a new account is to try them all until connection is achieved, and then remember that one thereafter. Eg Preferences: * method 1 * method 2 * method 3 # autodetect (initially selected) Once it successfully autodetects, it changes to that method unless the user manually switches it back to autodetect. You could add another setting to try all methods every time, but that strikes me as an option that would rarely get used.

This patch is a combination of David's and mine from bug 262584. This makes sure that the user will be prompted even if already succeeded in this session and it's the first time login fails. If this patch is ok, we should dupe bug 262584.

Comment on attachment 162493 [details] [diff] [review] patch v2 I should have rev'ed the uuid for nsIMsgIncomingServer - can you add a new one?

Added new uuid.

Patch has been checked into trunk and aviary branch on 26th.

So, it doesn't appear on the 1.0RC1? Seems to be listed as fixed, but I still do have problems. It is behaving the same way as before. Another problem I am finding is, if one deletes an email account and add it back(hoping to resolve the issue), it still saves up the old profile info, (username/password) giving the same annoying problem. I think UNDER THE MAIL SETTINGS THERE NEED TO BE A LOCATION TO CHANGE PASSWORD, not on a prompting basis. Hem (In reply to comment #28) > Patch has been checked into trunk and aviary branch on 26th.

(In reply to comment #29) > So, it doesn't appear on the 1.0RC1? Seems to be listed as fixed, but I still > do have problems. It is behaving the same way as before. Yes it does. The changes where the new pref to prevent retries and stopping login immediately if server issued [AUTH]. So if you didn't change the pref or your server uses the advanced code, nothing changes for you. What's your situation? The server password changed, you start TB and check mails, an alert pops up saying the password is wrong but you don't have a chance to enter a new one? Or what is happening exactly? > Another problem I am finding is, if one deletes an email account and add it > back(hoping to resolve the issue), it still saves up the old profile info, > (username/password) giving the same annoying problem. Therefore TB has the password manager. If you want to manage your passwords, use it.

> What's your situation? The server password changed, you start TB and check > mails, an alert pops up saying the password is wrong but you don't have a chance > to enter a new one? > Or what is happening exactly? This happens for me with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050116 Thunderbird/1.0. When starting TB I get this popup four times. IMO TB should stop authenticating to the server after the first login fails - the other 3 times will result in the same warning. The solution - what the summary also describes - would be to show the password dialog. The user should be able to input the new password directly. Why he should do that over the password manager? Every other client asks for a new password when the login fails. I reopen this bug because the current solution isn't that one which is described in the summary.

(In reply to comment #31) > This happens for me with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) > Gecko/20050116 Thunderbird/1.0. When starting TB I get this popup four times. > IMO TB should stop authenticating to the server after the first login fails - > the other 3 times will result in the same warning. But we show the password dialog right on the first error - if we can be sure it's a password problem, i.e. the server send [AUTH]. As I wrote in comment #2 directly discarding the password/showing the password dialog as we did before also made people scream.

In my opinion, the best way would be to have a password box just under the username under Server Settings. And have a check box to save it. That would require different handling of the password pop up box. Might even completely eliminate it, and ask with a popup box - if the password is wrong- to go to Server settings and reenter it.

(In reply to comment #33) > In my opinion, the best way would be to have a password box just under the > username under Server Settings. Well, in a better world the current behaviour would be perfect. Since we have to live with this world, what you wrote has also become in the last months. But that is a different (IMHO already existing) bug, no?

Mmh but there isn't a chance to stop the login process. The dialog only tells me that my password is not correct and I have to click OK. Why there isn't a cancel button? I have to wait until TB tried logging in 4 times without a positive effect. If I know that the password has changed I would prefer to stop the process immediately after the first failure. I've taken a look at the patches. Where is the part for an IMAP server? I can only see changes for the POP3 protocol. Any reason why there is no IMAP patch while the summary of that bug enclose this protocol?

Well, at least, I can go back and redo the password and try it again. Yes, I see your point, it need to prompt for password again, if it cannot log in. It can be as simple as that. I have a feeling that the this problem is fixe d in POP, but not on IMAP. But I am not sure. Sorry, I am not a geek, don't look at code, so I dont know where things are. Just an end user. (In reply to comment #35) > Mmh but there isn't a chance to stop the login process. The dialog only tells me > that my password is not correct and I have to click OK. Why there isn't a cancel > button? I have to wait until TB tried logging in 4 times without a positive > effect. If I know that the password has changed I would prefer to stop the > process immediately after the first failure. > > I've taken a look at the patches. Where is the part for an IMAP server? I can > only see changes for the POP3 protocol. Any reason why there is no IMAP patch > while the summary of that bug enclose this protocol?

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

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

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

I reported this a while back too. In my opinion, it is simply a matter of usability (Ref: Schneidermann, Nielson et al.): The user must feel that they are in control. This behaviour violates that directive. In addition to this, virtually every other commonly used mail client discards an invalid or failed password immediately. Therefore, for consitency's sake, Thunderbird should exhibit the same behaviour. Neil McLeish

It's still existent in Thunderbird version 1.5 (20051201) and Exchange IMAP server. Can we get this for TB 2.0?

this patch makes it so when the pop3 password changes, we will reprompt. It also makes it so we'll fill in the previously sent password in the password dialog, if any. To do that, I had to stop doing getter_Copies on the return password, which made me do some extra string allocation/copying/freeing, that I'd like to figure out how to avoid.

this makes it so when we reprompt, we auto-fill in the dialog with the last password sent (which probably failed, but we don't know why...). I'd like to get this some baking on the trunk.

Comment on attachment 222962 [details] [diff] [review] proposed fix + //nsXPIDLString uniPassword; should we just remove that line? + nsCString aCStr; aCStr.AssignWithConversion(uniPasswordAdopted); two lines?

fixed on trunk - I'll land on branch when it has baked on the trunk for a bit.

Comment on attachment 222962 [details] [diff] [review] proposed fix approving for 1.8.1 branch

version is listed as 1.0 branch. Will this also go onto the 1.8.0.x branch?

no, I doubt it. Trunk and 2.0 branch only, most likely.

fixed on 1.8 branch as well

flag cleanup

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

you'll need this fix if you want the fix for bug 286628 .

Comment on attachment 222962 [details] [diff] [review] proposed fix approved for 1.8.0 branch, a=dveditz for drivers

fixed for 1.5.0.7

Can folks that are having this issue please try the Tbird build in this directory (ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/1.5.0.7-candidates/rc4) and confirm that this bug is fixed? Thanks.

(In reply to comment #55) > Can folks that are having this issue please try the Tbird build in this > directory It is not fixed for any version of Thunderbird. I've tested following win32 versions: * version 1.5.0.7 (20060906) * version 2 alpha 1 (20060906) * version 3 alpha 1 (20060907) Changing the password for my POP3 account let's Thunderbird infinitely repeat the user/pass combination and only shows me the error dialog. => Reopen

I'd say this definitely blocks Thunderbird 2.0, and we'll take it in 1.5.0.x when it's really fixed. But at this point I don't think we hold Thunderbird 1.5.0.7 for this.

Henrik, can you attach a pop3 protocol log of a session where your password has been changed so I can see which authentication mechanism is used and what error the server returns?

I'm using Courier mail server. Here its output from mail.log Sep 7 21:36:05 xxx courierpop3login: LOGIN FAILED, ip=[::ffff:84.57.233.245] Sep 7 21:36:06 xxx courierpop3login: LOGIN: DEBUG: ip=[::ffff:84.57.233.245], command=CAPA Sep 7 21:36:06 xxx courierpop3login: LOGIN: DEBUG: ip=[::ffff:84.57.233.245], command=USER Sep 7 21:36:06 xxx courierpop3login: LOGIN: DEBUG: ip=[::ffff:84.57.233.245], command=PASS Sep 7 21:36:06 xxx courierpop3login: LOGIN: DEBUG: ip=[::ffff:84.57.233.245], username=%username% Sep 7 21:36:06 xxx courierpop3login: authdaemon: starting client module Sep 7 21:36:06 xxx courierpop3login: authdaemon: REJECT

This is now a showstopper here. Is there a key or any way to fix this? I tried an older version (1.5 and 1.5.0.6), but I think the settings were already set and cannot be undone. Thanks.

no, you need to go into the password manager and delete the password...1.5.0.5 and 6 had the same bug.

David, were the log files helpful for you? Or do you need any further information?

Henrik, no, those were helpful. I just have to try it out with my servers...I'm just doing that now.

ok, my pop3 server does auth login, where this works as expected...I'll turn off auth login and try to recreate the problem you're seeing.

It still works when I turn off auth login so TB does user <user> login just like in your pop3 log. This is on the trunk, when I've changed the password before starting TB. I'm not sure what would be different about your case, Henrik. Do you have a master password set? There was a bit of weirdness where TB tried to do a stat after the failed logon before reprompting for the password...maybe that's somehow involved.

Henrik, perhaps it's because you're trying to do an auth login, which is failing, and then we fall back to normal logon, and get confused when the password is wrong. You might try turning off auth logon by going into the config editor and searching for auth_login, and toggling the prefs you see to false, and see if it works better after that. I'll try to figure out a way to simulate your situation, but it's tricky because my server supports auth logon.

(In reply to comment #62) > no, you need to go into the password manager and delete the password...1.5.0.5 > and 6 had the same bug. > There IS NO PASSWORD in password manager. It is completely blank. That is part of the problem.

Henrik, do you have the ability & time to apply and build patches? Unless I can find a pop3 server that doesn't support AUTH, I'm going to have to try to guess at a fix, because the pop3 auth fallback code is complicated...

(In reply to comment #69) > Henrik, do you have the ability & time to apply and build patches? Unless I can > find a pop3 server that doesn't support AUTH, I'm going to have to try to guess > at a fix, because the pop3 auth fallback code is complicated... David, I don't have a build system at the moment. That's why I don't have the ability to build my own Thunderbird. But I have another solution. I could give you a POP3/IMAP account on my server. I think that would help you much. You can reach me on Moznet. My nick is whimboo.

I forgot, no I don't have set a master password.(In reply to comment #67) > password is wrong. You might try turning off auth logon by going into the > config editor and searching for auth_login, and toggling the prefs you see to > false, and see if it works better after that. I'll try to figure out a way to > simulate your situation, but it's tricky because my server supports auth logon. No, that doesn't help. Turning off auto login shows me the warning dialog (login failed) 4 times and stopps afterwards. Later tries results in one warning dialog and a STAT failure dialog. But I don't have the chance to change my password. There is no such dialog. I really think it is better when you can test it for your own.

Henrik, it turns out that one of my mail servers shows this same bug for pop3 (I was only using it with IMAP, so I didn't see it before). So I'm debugging that. I may need to get a test account to recreate the problem you're seeing with IMAP (it's completely separate code, believe it or not).

(In reply to comment #72) > Henrik, it turns out that one of my mail servers shows this same bug for pop3 > (I was only using it with IMAP, so I didn't see it before). So I'm debugging > that. I may need to get a test account to recreate the problem you're seeing > with IMAP (it's completely separate code, believe it or not). I've sent you a message with the needed account data. You should see the problem immediately. By the way I can see the same behavior after changing my password on an Exchange Server 2003 and accessing it by IMAP.

The remaining bug was that if the username contained a '.', we were failing to remove the bad password from the password manager because the process of converting the server uri string to an actual URI was escaping the '.'. So we were adding the password using an unescaped '.' but trying to remove it using a uri that when wallet got the spec, was escaped, and so didn't match. So the fix was to use the password manager RemoveUser interface directly, which takes a uri string instead of a uri object.

fixed on trunk - I'll wait to see if this fixes it for Henrik before landing on the 2.0 branch

(In reply to comment #75) > fixed on trunk - I'll wait to see if this fixes it for Henrik before landing on > the 2.0 branch I'll test it as soon as a new trunk build is available. Thanks David.

With version 3 alpha 1 (20060914) I get asked now. But why do we try to login three more times after we still got the response that the login had failed? Can't we display the password dialog immediately after we got a login error?

we do that for imap because some servers advertise certain authentication mechanisms, but always fail when you use them - we retry to fall back to other authentication mechanisms - maybe we should only put up the logon failed alert after the final one fails...

(In reply to comment #78) > authentication mechanisms - maybe we should only put up the logon failed alert > after the final one fails... Yes, this is a great idea. I'll open a new bug for that issue later today.

fix for account name with '.' in user name checked into 1.8.1 branch

Comment on attachment 238302 [details] [diff] [review] fix case where username contains a '.' requesting 1.8.0.8 approval - user names with '.' in them are becoming much more common.

Restoring lost blocking flag

Comment on attachment 238302 [details] [diff] [review] fix case where username contains a '.' approved for 1.8.0 branch, a=dveditz for drivers

According to all the dupes pointing here, this must be the place to post my problem, although it has nothing to do with a changed password. I always type my IMAP account password in manually. If I accidentally mistype it, T'bird 3 does not give a prompt that says the login failed, please re-enter the password. Instead, the status text in the lower-left of the just keeps saying "Sending authenticate login unformation..." This is contrary to how Thunderbird 2 worked. This problem occurs in 3.0 release and 3.0.1pre (nightly build 20091220033857).

donotcare, can we get an IMAP protocol log of a session where that happens? https://wiki.mozilla.org/MailNews:Logging thx. And if you want to just send it to me at bienvenu@mozillamessaging.com, instead of posting it here, that would be fine. It won't contain your password, but it will tell us a little about what it tried to do.

[also emailed bienvenu privately as requested] Here is an IMAP log which shows Tbird getting the password failure. I entered the wrong password (remember password is UNchecked), and Thunderbird gave no indication that the login had failed. I clicked on a few folders, and they either showed up empty, or showed the cached messages from the initial login during account creation (with the correct password as forced by the Account Wizard). Thunderbird did not prompt me at all, it just kept using the wrong password everytime I clicked on a folder or message. NOTE: in the logfile I have replaced my real userid with USERID%40EXAMPLE%2ECOM@imap.example.com and my real IMAP server hostname with imap.example.com . Thunderbird 3.0.1pre (nightly 20091220033857) on Windows XP. Thanks,

Thx, yep, it's definitely broken - this may have to do with auth=plain auth being broken in TB 3 with a bad password. I remember BenB making noises to that effect. I think we need a new bug for this.

Hello, I still am seeing this today with Thunderbird 3.0.1 release and 3.0.2pre (Shredder) and also 3.1b1pre (Lanikai). All on Windows XP. The problem occurs with one of my IMAP servers (fastmail.fm, SSL) but not on another one (cyrus-imapd-2.3.14-3, TLS). Again, my issue is when an incorrect IMAP password is entered, TB does not give any "failed login" type of message, and does not prompt for password re-entry. It keeps using the bad password, and the user is given no indication of the password failure whatsoever. The user will see any locally cached messages, but obviously no new messages from the IMAP server. Attaching a new IMAP:5 trace log. I replaced my user id with "USERID".

this regressed with the new password management stuff, I believe, in the case of the server dropping the connection after an authentication error. I'm not sure if there's a new bug open on the regression (there need to be separate bugs for imap/pop3/smtp, because the fixes are all distinct, unfortunately). I have a patch somewhere in a bug for the imap case, though I haven't been able to test it.

(In reply to comment #93) > this regressed with the new password management stuff [...] Yep, it did. Looks like Bug 505481 was reopened for this case (I'll add corroborating info there).