Using trunk build Gecko/2008041001 I go to my pop3 account, and click "Get Messages". I do not store my password for this email account in password manager, so I get a password prompt, and I enter an utterly bogus password. Expected result: get a dialog asking me to re-enter my password Actual result: It appears to behave as if the password is correct, but there is no new email. If I again attempt to "Get messages for account", it does not prompt me for a pasword again. Instead, the progress meter shows apparent progress, followed by no result, no new messages. But there is NO indication that I have entered an incorrect password.

The only way to recover from this, apparently, is to restart the process.

Behavior also present in Gecko/2008040702 nightly

Behavior also present in Gecko/2008040302 nightly

Behavior present in Gecko/2008031700 nightly

Present in Gecko/2008022502 Obviously there's a glaring need to a basic security regression test suite. Does such a thing exist for Thunderbird or SeaMonkey? Is there a way to nominate this bug for inclusion in that suite?

(In reply to comment #0) Tested with Tb trunk build on MS Win-XP, version 3.0a1pre (2008040703). Similar phenomenon was partially seen, but different result was obtained. 1. Delete saved password for mailbox:... 2. Get Msgs of PO3 account => Password Prompt => Enter wrong password => Authentication error message => Password prompt => Enter wrong password => Nothing is responded (Looks to be successful login, but no download/no "no mail" message) 3. Get Msgs of PO3 account again => Password Prompt => Enter wrong password => Authentication error message => Password prompt => Enter proper password => Mails are downloaded, or message of "no message" if no mail. > POP3 Server Settings > Port : 110, "TLS, if available", "Use secure authentication"=Unchecked > Check for new message at start up = OFF > Check for new messages every NN minutes = OFF > Automatically download new message = OFF Difference between Seamonkey trunk and Thunderbird trunk? Depends on server's behavior or response when consecutive password error?

FYI. Bug 428620 has reported Get Msgs error(nothing is done) which started to occur on 04/11 build. (looks to be phenomenon when saved password exists) Correction of test result with Tb in comment #6. Sorry for spam. (When 2nd Get Msgs, password was not prompted. Last entered one seems to be used) > 3. Get Msgs of PO3 account again > => Authentication error message => Password prompt => Enter proper password > => Mails are downloaded, or message of "no message" if no mail.

Problem occurs in Gecko/2008012402 SM build.

This regression is apparently over 60 days old. It occurs in all SM trunk builds for which I have kept the installer (basically back to Jan 24, 2008). On the chance that it is somehow related to the server's responses, here is the server info. mail.hostedemail.com, port 995 (SSL)

Tested with Seamonkey Trunk(BuildID=2008041102). (Tb trunk 4/11 build has problem of Bug 428620. So unable to test this bug) Following is test result, and test result with Tb trunk 4/07 build was same. (sorry for my inaccurate previous test report) 1. Delete saved password for mailbox:... 2. 1st Get Msgs => Password Prompt => Enter wrong password => Authentication error message => Password prompt => Enter wrong password => Nothing is responded (Looks to be successful login, but no download/no "no mail" message) 3. 2nd Get Msgs => messages of "connecting" => Authentication error message => Password prompt => Enter PROPER password => Nothing is responded (Looks to be successful login, but no download/no "no mail" message) 4. 3rd Get Msgs ==> After a while, mails were downloaded In any password entry step, "Save Password" was not checked. In my environment, it looks that : (a) Password is prompted after login failure due to wrong password (b) But, nothing is done after password entry to prompt for retry (c) On next Get Msgs, login is done with password kept at (b) (c-1) If password at (b) is wrong, login fails, and password is prompted(==a) (c-2) If password at (b) is proper, login successful, then mail is downloaded When proper password is already saved by Password Manager, no need of (a) to (c), then problem won't be exposed. In your case, no password prompt when login failure, thus no chance to enter proper password until restart once wrong password is entered.

Tested with Seamonkey trunk(BuildID=2008041102) on MS Win-XP SP2. Same test scenario as one in comment #10. NSPR log is get with following parameters(DebugView is used to get timestamp). > SET NSPR_LOG_MODULES=POP3:5,DOMLeak:5,DocumentLeak:5,nsDocShellLeak:5 > SET NSPR_LOG_FILE=WinDebug As seen in log line number(left most digits of log), no line is removed from attached log data. In my case(not SSL), phenomenon was as follows. (1) wrong password => autenticationn failure => password prompt again (2) when password is entered, CAPA is sent by TB (3) Nothing is returned from POP3 server to the CAPA => Tb looks to be waiting for response forever (4) When next Get Msgs, Tb's process seems to start from first step, and password entered at step (2) is used. Tb's action of (2) is proper? (3) is caused by POP3's wrong behavior? Or by Tb's inappropriate action of (2)? Or by something else?

(In reply to comment #10) > Tb's action of (2) is proper? > (3) is caused by POP3's wrong behavior? Or by Tb's inappropriate action of (2)? > Or by something else? WADA please could you try an SM or TB branch build so we can confirm the original behaviour? Thanks

(In reply to comment #12) I tried Seamonkey 1.1.9 & 1.1.4, with new profile generated by Seamonkey 1.1.9. Test result: Same behavior, same NSPR log - CAPA, then wait for response forever. Shall I test with Mozilla M17, my first Mozilla? ;-)

Same behavior in quick test with Mozilla 1.7.13 & Mozilla 1.0(1.0.0), with profile/account created/defined by Seamonkey 1.1.9. Re-boot is required to check? (e.g. already loaded .dll is always used)

Nelson: agreed that there are glaring needs for various test suites; Standard8, Joshua, and others have been working hard to bring some to life. As far as I can tell from the reading, this problem has been around forever, making it not a regression. On that basis, removing that keyword, and setting the blocking-thunderbird3.0a1- flag. It is, however, confusing and unpleasant behavior which (one hopes) shouldn't be terribly hard to fix. On that basis, making setting the blocking-thunderbird3+ flag.

So the failure is always only for the *second* attempt?

In reply to WADA's comments and comment 16, I think WADA and I are experiencing separate, though related, problems. I suspect the problem I experience is in some way related to the use of SSL. I absolutely NEVER get any kind of dialog asking me to re-enter the password. There is no "second attempt", because the first attempt always acts like it succeeds. That behavior is the subject of this bug. If there is ANOTHER failure behavior (as WADA reports), that should be the subject of a separate bug, I think. The behavior I see is 100% reproducible in all builds I've tried between 20080124 and 20080410. Note that I have reverted to Gecko/2008040302 due to bug 428614, an unavoidable crash in the news reader.

Nelson, could you attach a pop3 protocol log for it. http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#pop

Nelson, do you still believe the bug you are seeing is a regression? If so, based on what?

(In reply to comment #17) > In reply to WADA's comments and comment 16, I think WADA and I are experiencing separate, though related, problems. I think so too. Objective of my test/log is to provide data to find reason why password is not prompted in your environment but password is prompted in my environment. And, similar phenomenon (fake successful login) was observed too when next flow. > RECV: -ERR [AUTH] Authentication failed. > Password prompt, enter password. > SEND: CAPA, then wait response forever. Looks that login was successuful. I guess similar wait is involved in your case too, but I also believe above is different issue. When TELNET(plain text login), connection was lost after -ERR [AUTH]. This indicates something wrong at client side after "-ERR [AUTH]" response. I'll open separate bug for this issue. By the way, when test on MS Win, timestamp can be added to NSPR log by use of DebugView. See Bug 86396 Comment #15 & Bug 86396 Comment #7, please.

In answer to Dan's question: why do I think this is a regression, the answer is that I am accustomed to occasionally seeing a second dialog box asking me to reenter my password. I'm not the greatest typist, and sometimes I simply enter the wrong password entirely. On those occasions, I am accustomed to seeing a dialog asking me to re-enter the password. I haven't seen any such dialog in quite a while now, which is why I thought it was a regression. But now I have another hypothesis. A couple months ago, just since the first of the year, my mail service provider changed their servers. Previously, they did not support SSL but did support CRAM-MD5 authentication. Then when they changed, they dropped CRAM-MD5 support and added SSL support. I changed my configuration to match. It may be that I have not seen a re-prompt for a password since I made that change. I just didn't notice the loss of the password re-prompt right away. I noticed it a few days ago when I realized that I had entered the wrong password immediately after pressing enter, and yet there was no re-prompt. If the change to using SSL is the reason the reprompts stopped, then I guess it may not be a regression after all.

For this log file, I did the following steps: a) start SM trunk b) Click "Get Messages for Account" on POP3 account c) enter invalid password d) see no failure message and no new password prompt e) wait about 1 minute f) Click "Get Messages for Account" on POP3 account, again g) see no failure message and no new password prompt h) exit SM

> SEND: AUTH PLAIN > Logging suppressed for this command (it probably contained authentication information) > RECV: -ERR Authentication failed. > SEND: AUTH LOGIN Do you modify login related settings to issue "AUTH PLAIN" first? AFAIR, I saw a bug of "password is not prompted when wrong password if AUTH PLAIN (password is prompted if AUTH LOGIN)" recently, but I could find it by search. And it looks no response from server for next "AUTH LOGIN". This seems to be similar situation to my "no response for CAPA" case(I opened Bug 429069 for it. It looks to be server side fault.)

I wanted to say "I couldn't find the bug for AUTH PLAIN yet". Sorry for spam.

Two SASL CAPA-tags in CAPA response, with same arguments but different order. Affected by it? > RECV: SASL PLAIN LOGIN > RECV: SASL LOGIN PLAIN I couldn't find description about dup'ed SASL and order of arguments in RFCs. > http://www.faqs.org/rfcs/rfc2449.html > http://rfc.net/rfc5034.html

The bug I saw was Bug 417957. It was for IMAP & auth_login=false case. Sorry for my confusion.

I guess WADA's question in comment 23 was directed to me. (?) > Do you modify login related settings to issue "AUTH PLAIN" first? How would I have done that? Is there some pref I should look for?

(In reply to comment #27) > How would I have done that? Sorry for wrong question. Dual "SASL PLAIN LOGIN" & "SASL LOGIN PLAIN" was not problem. nsPop3Protocol::CapaResponse merely sets flag when exists in SASL. > When PLAIN is found in SASL, call SetCapFlag(POP3_HAS_AUTH_PLAIN); > When LOGIN is found in SASL, call SetCapFlag(POP3_HAS_AUTH_LOGIN); And, order of AUTH_PLAIN and AUTH_LOGIN was hard coded. > http://lxr.mozilla.org/seamonkey/source/mailnews/local/src/nsPop3Protocol.cpp#1403 > if (TestCapFlag(POP3_HAS_AUTH_PLAIN)) > m_pop3ConData->next_state = POP3_SEND_USERNAME; > else > if (TestCapFlag(POP3_HAS_AUTH_LOGIN)) > m_pop3ConData->next_state = POP3_AUTH_LOGIN; > else > if (TestCapFlag(POP3_HAS_AUTH_USER)) > m_pop3ConData->next_state = POP3_SEND_USERNAME; > else > return(Error(POP3_SERVER_ERROR)); I think POP3_AUTH_LOGIN is better to be tried first("AUTH_PLAIN=>AUTH_LOGIN" can be called "Fall Back"?). But it's different issue from this bug. Main cause of problem is "no response to AUTH LOGIN after -ERR to AUTH PLAIN". Please see Bug 429069 Comment #1 (explanation in RFC 1734). But I think Tb/Sm is better to be tolerant with this situation.

My some thoughts about this bug's problem. RFC 17342(2. The AUTH command) says; > If an AUTH command fails with a negative response, the session remains in the AUTHORIZATION state > and client may try another authentication mechanism by issuing another AUTH command, Tb apparently tries AUTH LOGIN after -ERR to AUTH PLAIN based on above RFC's description. Is this automatic "fall back"(I think psuedo "fall back" when this bug's case because AUTH PLAIN=>AUTH LOGIN) is appropriate action for user? Does many POP3 servers still return -ERR to AUTH xxxx even though the server returns "SASL xxxx" in CAPA response? Is "asking to user for other AUTH mechanism or different password when -ERR to AUTH" not adequate?

I strongly doubt this has anything to do with SSL - the pop3 protocol code doesn't treat authentication differently based on SSL/non SSL. Nelson, if you're up for a bit of debugging, in PRInt32 nsPop3Protocol::AuthFallback() I believe we should get to here: if (TestCapFlag(POP3_HAS_AUTH_PLAIN)) // if PLAIN enabled, disable it ClearCapFlag(POP3_HAS_AUTH_PLAIN); else if(TestCapFlag(POP3_HAS_AUTH_LOGIN)) // if LOGIN enabled, disable it ClearCapFlag(POP3_HAS_AUTH_LOGIN); else if(TestCapFlag(POP3_HAS_AUTH_USER)) and eventually decide to tell the user the password failed. But I don't know why that's not happening for you. Are we not getting into AuthFallback after AUTH PLAIN fails? It's also unclear what's happening with AUTH LOGIN. Is the server just dropping the connection?

David, I tried debugging that with the sources from CVS trunk, and they're just too different. The sources from CVS don't match the sources from which the code I'm running was built. :(

Oh, sorry, I meant to build and run the cvs trunk code.

I won't rebuild it all right now. Even though the addresses don't match (by a mile), I'm pretty fair at assembly language debugging. Here's what I see. When it gets to: if (TestCapFlag(POP3_HAS_AUTH_PLAIN)) // if PLAIN enabled, disable it ClearCapFlag(POP3_HAS_AUTH_PLAIN); The value of the cap flags word is 0x00021CAA, so the HAS_AUTH_PLAIN flag is set. It clears it, then goes to this test // Only forget the password if we've no mechanism left. if (m_useSecAuth && !TestCapFlag(POP3_HAS_AUTH_ANY_SEC) || !m_useSecAuth && !TestCapFlag(POP3_HAS_AUTH_ANY)) where m_useSecAuth is 0, and the flags word has some bits of HAS_ANY_AUTH, At that point, I let it go. No dialog. If I click "Get Messages" again, I go through that exact sequence again.

that basically leaves auth login, and it still looks to me like the server is dropping the connection when we try auth login, so we repeat the whole process, because we create a new pop3 protocol object and a new connection, and start the whole process over again. If we had some way of remembering that auth login should not be tried for this server, then we could deal with this.

In reply to comment 30, even if the client doesn't treat authentication any differently with or without SSL, the server might. I've known other mail/ news servers to behave quite differently over SSL than without it. Would an NSPR log file show sufficient detail to make this clear? Maybe I should report it to my mail service provider.

assigning to mark for processing.

FYI. Older bug is found for following case (Bug 392887). (1) AUTH => -ERR ("wrong password" due to password change), (2) POP3 server silently stops login handling, (3) USER => Tb waits for response forever.

(In reply to comment #34) > that basically leaves auth login, and it still looks to me like the server is > dropping the connection when we try auth login, so we repeat the whole process, > because we create a new pop3 protocol object and a new connection, and start > the whole process over again. I've just done some testing with some hacked up fake servers, and David's assessment is correct. Not a regression as 2.x does exactly the same thing. > If we had some way of remembering that auth login > should not be tried for this server, then we could deal with this. I think I may be able to come up with a unit test for this. Do you think we may be able to find some way of remembering this?

(In reply to comment #41) > I think I may be able to come up with a unit test for this. Do you think we may > be able to find some way of remembering this? My inclination would be to put this in the pop3 incoming server, but not persist it (in theory, auth login could be temporarily broken).

As much as we'd really like to see a fix for this, we've survived shipping without this before, and we could survive shipping without it again. Marking blocking- and wanted+.

I just created a new profile using TB's new mail account quick setup. It's great, just enter display name, mail address and password (to be saved) - done. However, my password ended up wrong (due to Caps lock). I am an expert user, and I was sure I had typed my password right. I checked all sorts of settings before finding out in password manager that my password was wrong. The out-of-the box experience of this bug is terrible, and it can happen only too easily when you're setting up your account with that old password you're not so sure of any more...

But we tell you the authentication information was wrong when setting up the account, don't we? So you should have known that something was wrong at setup time before you ended up in the password manager... Windows handles this really nicely by telling you that your caps lock key is on when entering the password - I wonder if autoconfig could detect that and do something similar.

(In reply to comment #46) > But we tell you the authentication information was wrong when setting up the > account, don't we? Hmmm... no? All I saw was 3 green spots, and I usually interpret green as "OK"? Where do I have to look? What kind of notification would I get? I'll try that again. > Windows handles this really nicely by telling you that your caps lock key is on > when entering the password - I wonder if autoconfig could detect that and do > something similar. That's exactly what I thought after the event... ;)

when you click Create Account, we verify the logon to the server, and if that fails, we shouldn't let you out of the autoconfig dialog.

There are all sorts of bad things happening in the auto-config dialogue, too many to remember them all. Here's some: Setting up gmx.de account with bad password: getting 3 green lights as I said. 1) Create account will do first complain as you say, but then - toss another error msg (something about msgwindow, can't reproduce right now for lack of time) - wrong - password field is disabled though exclamation mark next to it says password/id is wrong, user needs to find start-over button - wrong - create is still enabled (wrong) - clicking create comes up with "incoming server already exists" (might be from canceled account creations of same account, but again: wrong) 2) If you do Manual Setup instead of step 1, after confirming manual settings, you'll get no notification of wrong password whatsoever, and wrong password is saved and no way to get rid of it, no notifications, no prompts (due to this bug ), not even after restart, unless you know how to remove password in password manager (very wrong). Shredder is more of a Minefield sometimes...

Thomas: Thanks for the bug report, but please create a new issue for each point, with clear steps to reproduce it -- otherwise it's really hard to track down the work left to do.

(In reply to comment #49) > Setting up gmx.de account with bad password: getting 3 green lights as I said. > 1) Create account will do first complain as you say, but then > - toss another error msg (something about msgwindow, can't reproduce right now > for lack of time) - wrong that's an assertion - users who run release builds won't see it, so that's not an issue. > - password field is disabled though exclamation mark next to it says > password/id is wrong, user needs to find start-over button - wrong > - create is still enabled (wrong) > - clicking create comes up with "incoming server already exists" (might be from > canceled account creations of same account, but again: wrong) > 2) If you do Manual Setup instead of step 1, after confirming manual settings, > you'll get no notification of wrong password whatsoever Manual setup doesn't verify any of your logon details - it assumes you know what you're doing. Sounds like it should also forget the password you entered... , and wrong password is > saved and no way to get rid of it, no notifications, no prompts (due to this > bug ), not even after restart, unless you know how to remove password in > password manager (very wrong). >

sev major+dogfood seems better

My aged mother's mail service provider reset her pop3 account password (for some reason) and waited for her to call in. They figured she'd call in when she couldn't successfully login to read her email. But guess what. Her Mozilla email client never told her it couldn't log in. Day after day, she checked her email, only to find that apparently her inbox had no new email, but never any indication of something more seriously wrong. She normally receives numerous emails 7 days a week. After a few weeks of this, she called me. I had her try her mail service provider's webmail server (which she NEVER uses), and it confirmed my suspicion: she couldn't login to it, wrong user name and/or password. A call to the provider fixed everything, and soon she was clawing her way up out of a mountain of email. After 2.5 years, this bug needs to get more attention than it is getting. Basic core functionality of the product doesn't work. C'mon MoMo guys, put the Gloda bells and whistles down and patch the foundation.

I added the ability to make the pop3 server drop the connection on auth failure, and added an xpcshell test for our handling of bad passwords when the server does that. The test fails. I'll try to figure out how to get the core code to do the right thing...it may be a matter of remembering that there was an auth failure and a dropped connection in the server object and pre-flighting the next logon attempt with a password prompt. We don't want to forget the old password, but we do want to reprompt.

Actually, I think I'll try to do the same thing I did for SMTP, which is make the pop3 protocol code reprompt for a password and reload the url.

this doesn't fix the issue, but it shows the direction I'm going in...

this kinda works for my test case, though the async password stuff makes things a bit unpredictable. The unit test still fails, but it's going in the right direction. I had to rework it from the original pop3 password failure test because the original used performTest as a serialization mechanism, which doesn't work when the server drops the connection.

this passes the old passwordfailure test and the new one, and works with my ISP's server that drops the connection on a bad password. I need to do a little bit more cleanup, and then do a try server build.

this is quite a bit cleaner than the previous patches. I moved some of the initialization of the protocol object into Initialize, and made LoadUrl call Initialize, like we're doing for SMTP. In the case of a dropped connection during auth, I re-run the url, if the user asks us to in the retry/cancel/new password dialog.

Comment on attachment 526416 [details] [diff] [review] less hacky fix [Checked in: Comment 74] Review of attachment 526416 [details] [diff] [review]: ::: mailnews/local/test/unit/test_pop3ServerBrokenCRAMDisconnect.js @@ -47,1 +46,1 @@ Interesting, this might help bug 599609 which was going to remove that check (we currently occasionally get variable results here).

fixed on trunk

David, did you land the right patch? It looks like test_pop3PasswordFailure2.js gets an unexpected fail result. Seems to happen the majority of the time on Mac & Windows, but not so much on Linux. I'd probably disable normally due to so much orange, but you're up soon anyway ;-)

It looks like the right patch to me - I'll see if I can make it fail here. What would be interesting would be to see a pop3 protocol log of a session that fails. There may be a race condition as to how often we get through the state machine.

I've run it 30 times w/o a failure. I'll try release builds next, and I'll try it on my Mac.

if this gets favorable testing results from Nelson and others, do we want this for 3.1? Seems like it fixes a bad and often reported failure mode.

OK, I've managed to get it to fail, and in the failure case, the protocol log seems to show that we get the OnStopRequest with the dropped connection before we even get to process the -ERR response from the server. This prevents us from trying to reprompt. I don't know how "real world" this situation is. It's odd that necko isn't giving us the data before the OnStopRequest. If this situation is "real world", then the fix is probably to guess that a dropped connection during auth is a password failure, even if we haven't got an auth failure. This will be a bit tricky because we can't simply throw up an other retry dialog if there's already one requested. Otherwise, we could just make the test a lot more flexible about the responses it gets, and the flow of the test, which is also tricky and not very satisfying.

This is on top of the previously landed patch - if we get a dropped connection during auth before getting the auth error, we need to basically pretend that we did get an auth failure and get back to the protocol state. I've also added a bit of logging for these situations.

I reproduced this by causing a cpu-spike right after starting the test (firefox was very helpful in this respect :-) )

follow-on fix landed - http://hg.mozilla.org/comm-central/rev/a779d69b226f - I'll check back with tinderbox later this afternoon.

(In reply to comment #67) > if this gets favorable testing results from Nelson and others, do we want this > for 3.1? Seems like it fixes a bad and often reported failure mode. I think I'd want to roll it out gradually rather than put it straight into a security release. I also believe that 3.3 should be out around the time of the next 3.1.x scheduled update, so either way the fix will be out about the same time.

It looks like the second patch fixed the test failures - there was a round of builds that failed that claimed to be started after the checkin, but none of the subsequent builds have had this test fail.

Comment on attachment 526416 [details] [diff] [review] less hacky fix [Checked in: Comment 74] http://hg.mozilla.org/comm-central/rev/e4d3835347ce http://hg.mozilla.org/releases/comm-2.0/rev/3d4a79e471a2

Comment on attachment 528615 [details] [diff] [review] fix for test failures [Checked in: Comment 71 & 75] http://hg.mozilla.org/releases/comm-2.0/rev/4461b72ad70e

There is still an occasional failure - my guess is in the error case we're doing an extra pass through the state machine before we get the disconnect, which is throwing off the error code. I need to figure out how to get a pop3 log of a session that fails.

This is NOT fixed. The multiple other bug reports being marked as duplicates of this "fixed" report indicate that the problem still exists. I have updated to TB v 5.0 on windows xp pro I handle about 10 email accounts and have been viewing the inboxes as "unified folders". I just noticed that I hadn't received any new mail for one account since May 12. As I recall, I had changed the password on that account via web management. TB never warned me of any password failures and it had been happening on 3 of the 10 accounts. Once I noticed the certain accounts not getting new mail that existed on the server, I tried to manually 'get mail'. There was no update and no warning of any authentication errors.

Bugmagnet, if you could generate a POP3 protocol log, that would be helpful. https://wiki.mozilla.org/MailNews:Logging

I understand it may be helpful, but I am having trouble creating the log. I made a DOS batch file with the following commands: set NSPR_LOG_MODULES="pop3:5,timestamp" set NSPR_LOG_FILE=c:\!_bugmagnet_logs\pop3.log "C:\Program Files\Mozilla Thunderbird\thunderbird.exe" If this syntax is not correct, please provide more specific details on how to initiate the logging you need. When I run it, an empty pop3.log file is created and TB starts. I deleted one entry from password manager so it would ask for the PW. When I entered a wrong PW, it flagged it and asked for another, as expected. I noticed another issue too. I had several gmail accounts in the 10 that TB handles. When TB was asking for one account PW, it failed to get new mail from another gmail account for which it had the correct PW. After the initial 'get mail', I manually requested new mail for the gmail account that had been skipped and TB was able to get the new mail. When TB does not have a stored PW, it seems to work ok in detecting entry of w bad PW. However, when TB has a stored PW and the account PW is updated on the server but not in TB, it gives no failure warning, at least with my ISP email accounts.

found syntax error in my batch file - am able to produce log now - will provide forthwith.

TB fails to alert user when AUTH of stored PW fails

Testing further, unless I didn't do it right, it appears that TB does alert on AUTH failure of the gmail pop3 server. However, TB does not alert of AUTH failure of my ISP's contract email server, which is provided by another company, synacor.com Could the problem be related to the email re-routing through the synacor servers?

Thx for the log. Is that a log of a session where you're just trying to logon to one server, or two? It looks like the server dropped the connection during a second login attempt, with AUTH LOGIN, without any kind of error.

I see this is marked as RESOLVED FIXED, but I am seeing this same problem in Thunderbird 17.0.8 on WinXP 32bit. The error console says this, but could be related to the Growl extension: Timestamp: 2013-09-12 13:32:20 Error: An error occurred executing the cmd_getNewMessages command: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgIncomingServer.getNewMessages]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://messenger/content/mailWindowOverlay.js :: GetNewMsgs :: line 2650" data: no] Source File: chrome://global/content/globalOverlay.js Line: 95. I'd say this a pretty nasty bug.

2013-09-21 Not Fixed. OSX 10.4.11 Thunderbird 3.1.20 Earthlink DSL. -CK 1: Choose <Get mail> for an email acct that requires you to supply a password 2: Supply an incorrect password 3: Result: Msg that password is incorrect; as expected. 4: Try again (i.e. choose <Get mail> again). 5: Result: You are not prompted for a pwd. Instead, mail is retrieved in the background presumably using the prev supplied incorrect pwd, and you again get an "invalid pwd" msg. Etc. 6: You have to quit TBird and relaunch it. Not sure I agree with the prev poster that this is a "nasty" bug, I find it more of an annoyance. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20

In my case, when Thunderbird is already open and working and the password changes server-side, Thunderbird will then fail to automatically get new messages, and does not show any indication about the problem *at all*. Even explicitly pressing the "Get Mail" button is not realiable at causing a reaction: once I press it and nothing happen, a few minutes later I press it again and then there is an alert box asking for a password. So I already have spent around a day in 2 different occasions having my mail client open, looking OK, but not receiving anything. So, yes, in my case it is a nasty bug.

Was unaware of this variation on the theme, didn't see it described in any of the postings, not in plain English anyway. I stand corrected. Someone told me that all maintenance on TBird has ceased, so that issues such as this one are destined to remain unfixed. Anyone know if this is true?

Thunderbird is still being maintained, but mozilla doesn't put money into adding more features to it - only keeping it alive wrt. security and such. The community is free to move forward with new features (and bugfixes) though. Anyway, THIS bug is closed. So anyone seeing similar problems, file a new bug for it, and attach a POP3 protocol log - https://wiki.mozilla.org/MailNews:Logging