User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040501 Firefox/0.8 Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040501 Firefox/0.8 If you enter your password incorrectly you get prompted to re-enter it. If, after re-entering it you are successful, your new mail is not fetched. Reproducible: Always Steps to Reproduce: 1. Start Thunderbird 2. Thunderbird will attempt to retrieve new mail 3. Thunderbird doesn't know the accounts password so it prompts 4. Enter incorrect password 5. Thunderbird prompts again 6. Enter correct password 7. Thunderbird does NOT download new messages Actual Results: Thunderbird does NOT download new messages. Expected Results: After authenticating successfully, new messages should have been downloaded.

I can confirm on Windows XP using Tbird 1.0.2. I have to cancel the password dialog and click "check mail" again to clear the bad password entry. If I retry with the same dialog, it never succeeds.

I've just downloaded and setup the new and have mistakenly put in the wrong password. I get an error that the login failed and don't have the option to correct the user/pass. I should get the option immediatly (like in OE) as well as the ability to set it from within the Account Settings dialog, right?

I should add that I reproduced this bug on an IMAP account.

Do you see problem using thunderbird 2? Or, better yet, Thunderbird 3 beta 2**? If you do, please comment. If you do not, please close the bug with resolution WORKSFORME (or some appropriate resolution, but not FIXED) ** Beta 2 has big fix of Bug 239131 Thunderbird should use the new password manager http://www.mozillamessaging.com/en-US/thunderbird/early_releases/ (suggest you backup your profile before using beta release)

I find a similar problem with 2.0.0.23. I don't store my account passwords. I have each account set to request password entry at start-up time. If, by accident, an incorrect password is initially entered the connect to the account fails and a pop-up box request re-entry of the password. That then succeeds the first time but for all subsequent access to the account, the re-entry of the password is demanded again. The box that pops up does contain the corrected password but it is clear that Thunderbird hasn't replaced the initially entered incorrect password with the subsequently entered correct one. I find that the work-around of clicking Cancel on the password re-entry window and then clicking Get All New Messages does seem to rectify the problem.

Still reproducible with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 (RC2). The only difference is that now a dialog "Retry | Enter New Password | Cancel" appears, clicking the center button and entering the correct password brings me back to this dialog. The workaround of clicking "Cancel" and then "Get Mail" proceeding without an error (and apparently the second correctly entered password) still works as well.

Now on Thunderbird 11.0.1. Not had any reoccurrence with recent releases.

I'm still seeing what I have described in comment #6 with current releases, however using an IMAP account. It's not obvious to me whether or not this bug was filed for POP specifically, which may behave differently than an IMAP account.

some possible dupes amongst https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced;short_desc=password;field0-0-0=short_desc;short_desc_type=allwordssubstr;type0-0-0=anywordssubstr;value0-0-0=wrong%20bad%20incorrect;resolution=---;product=MailNews%20Core;product=Thunderbird;list_id=3523113

bug 623596, bug 985018, bug 607935 dupes?

Possibly. Part 2 of bug 623596 matches, but the delay in response to the failed authentication may or may not be covered by what's discussed here; bug 985018 seems to be a more clear dupe of this one; and, bug 607935 describes the same what I see in comment #8, thus it may be the same issue regardless of whether a POP or an IMAP account is used. FWIW, SeaMonkey does /not/ exhibit the problem. When mistyping the mail password the first time, the correct password will be accepted immediately without the need to cancel the dialog and initiate a new-mail retrieval from scratch. Maybe that's a hint comparing what the two applications do differently.

(In reply to rsx11m from comment #12) > FWIW, SeaMonkey does /not/ exhibit the problem. Actually, that's wrong - or maybe not quite, but... It seems to depend on the account type. My SeaMonkey profile accesses a Gmail account whereas my Thunderbird profile accesses a non-Gmail account (both IMAP, as said). If I start SeaMonkey with a new profile and let it import the Thunderbird profile it behaves exactly like Thunderbird, with delayed response and the delayed recognition of the changed password. Conversely, Letting Thunderbird import the SeaMonkey profile with the Gmail settings now behaves as desired, reporting the wrong password back quickly and immediately accepting the new password from the dialog. Weird.

Is this still present in latest Thunderbird version?

(In reply to Phoenix from comment #15) > Is this still present in latest Thunderbird version? Yes, reproducible on current Thunderbird 55.0a1 with a new profile. One difference between affected and non-affected accounts may be the presence of GSSAPI authentication competing with password authentication (wild guess, but that's distinguishing the two setups). When starting with a new profile, Thunderbird tries to set up the account with GSSAPI given that (a) the IMAP server advertises it and (b) Kerberos is installed and configured on that machine, however for a different domain, hence authentication with that ticket fails for the IMAP server located in the other domain. To complete setup, I had to go into manual configuration and switch both IMAP and SMTP ends to "Normal Password" in order to proceed. Hypothesis: When configured with password, and password fails the first time, Kerberos may be attempted as a fallback and fails. When reentering the password and retried, it's still remembered that Kerberos was active the last time and again attempted, again fails. Only when cancelling that cycle and starting a new one by hitting the "Get Messages" button, the new and correct password is used to reconnect. Contrary to that hypothesis, I see the behavior also on a machine where no Kerberos is configured, but with the same server that advertises GSSAPI support (also assuming that Gmail does not offer GSSAPI, given that the issue isn't observed there).