Closed Bug 423354 Opened 16 years ago Closed 16 years ago

Thunderbird appears to be locking out Gmail IMAP accounts (forces password re-entry)

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: pennfamily, Assigned: Bienvenu)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fixed by bug 422814] [see "patch" in comment 59])

Attachments

(1 file)

proposed fix (1.8 branch)
1.59 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080207 Ubuntu/7.10 (gutsy) Firefox/2.0.0.12
Build Identifier: 2.0.0.12 (20080227) - Ubuntu Gutsy distro version

I manage five Gmail accounts, all accessed via IMAP, and periodically, and regularly, Thunderbird "forgets" the password to one or more accounts and I have to re-enter it. Because sometimes Gmail does not accept the re-entered password, I have a suspicion the problem is that something Thunderbird is doing via its IMAP implementation is temporarily locking out the affected accounts, and that after a while, Google unlocks them. If I wait long enough, I can always re-enter the password and have Gmail accept it, and Thunderbird will retain the passwords... until the next time it occurs.

Another user is having this problem as well; please see the following:
http://groups.google.com/group/mozilla.support.thunderbird/browse_thread/thread/fdea398b89c3e383/236bff6cb52b7d95

Thanks. 

Reproducible: Sometimes

Steps to Reproduce:
1. I'm not sure if multiple Gmail IMAP accounts are required to cause this, but set some up.
2. Run Thunderbird for a while (it often stays running for days on my workstation). Within a few days, one or more of the IMAP accounts will prompt for a password, even though you had correctly entered the password and had Password Manager save it before.




Actual Results:  
Sometimes you can re-enter the password and it will accept it, but many times it will not (this appears to be due to a temporary account lockout).

Expected Results:  
Well... it shouldn't be locking out my Gmail IMAP account, or forgetting the password, whichever it is.

Thanks for your help.
Duplicate of bug 423687 perhaps?
It could be a duplicate, but there's more to it. Something appears to be locking out the account on the IMAP server (the initial authentication failure). This is evidenced by the fact that I can re-enter the Gmail password, and it will refuse it for a while, but eventually will take it.

When I first encountered this issue, I was moving a large number of emails from another set of local email folders into the Gmail account. It did a significant number of the moves, then prompted for authentication--and for an hour or so would not accept the credentials. 

To Arthur Penn(bug opener):

Gmail IMAP also sometimes becomes unaccessible status due to trouble in Gmail IMAP, even though Gmail IMAP server itself is reachable, even if Gmail have many servers for fault tolerance and/or high availability. And, the "unaccessible time" is sometimes relatively long for users even if Gmail IMAP (I saw report of "4 to 6 hours" of unaccessible time of Gmail SMTP server from his PC, at forum in Japan.)
In your case, because of mail upload of very large volume, busy in "mail data base update work" for your Gmail account(Back end task. Common task for Gmail Web, Gmail IMAP, Gmail POP) is possibly a cause of your "unaccessible time".
In these situations, phenomenon of Bug 423687 can occur.

Fortunately, IMAP permits simultaneous access from different IMAP clients even on same PC. And, fortunately, Seamonkey has Mail&News component and can be activated while Thunderbird is active.
1. Setup Seamonkey(any of release build or trunk build),
   set up Gmail IMAP accounts, and access Gmail IMAP accounts and save passwords.
   (If big mail box is involved, unsubscribe them from active Thunderbird    )
   (before access by Seamonkey, and re-subscribe them from Thunderbird again.) 
2. When problem occurs, 
2-1. Get IMAP protocol log for Gmail IMAP access with Seamonkey.
   (If big mail box is involved, unsubscribe them from active Thunderbird    )
   (before access by Seamonkey, and re-subscribe them from Thunderbird again.) 
2-2. Check your Gmail IMAP accounts/mail box status via Browser.
     (any of Firefox or Seamonkey can be used)
See Bug 402793 Comment #1 for getting IMAP protocol log(NSPR log).
Blocks: tb-gmailWIP
I see same problem for my users, I didn't see it yet by myself. Will grab IMAP log ASAP.
To Arthur Penn(bug opener), Nikolay Shopik:  
When problem occurs, many TCP connections with "TIME_WAIT" status remain?
Check status by "netstat" command when problem occurs again, please.
Will do, its just takes time because its happens on non regular basis.
Happening to me too.

I started experiencing problems again, so I exited Thunderbird and started it again with logging on.  This time it asked me for my password a bunch of times right at start-up.  I removed my email address from the log, but there doesn't appear to be any other private data, so I'm pasting the rest here.

There is obviously a connection issue with gmail, but there is also a GUI issue.  If the password given does not work, Thunderbird's presentation layer doesn't know if the password is bad, or the server is denying it for other reasons.  Therefore, "...remember this password" checkbox should retain state and regardless of that state, the user should be able to hit "cancel" without Thunderbird forgetting the checkbox state or clearing the stored password.  Furthermore, if multiple folders are trying to re-fresh, a single cancel should be sufficient for all of them.

2216[238c140]: ImapThreadMainLoop entering [this=238b698]
0[274b38]: 238b698:imap.gmail.com:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
2216[238c140]: 238b698:imap.gmail.com:NA:ProcessCurrentURL: entering
2216[238c140]: 238b698:imap.gmail.com:NA:ProcessCurrentURL:imap://XXXXXXXXXXX%40gmail%2Ecom@imap.gmail.com:993/select%3E/INBOX:  = currentUrl
2448[23702f8]: ImapThreadMainLoop entering [this=2365008]
0[274b38]: 2365008:imap.gmail.com:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
2448[23702f8]: 2365008:imap.gmail.com:NA:ProcessCurrentURL: entering
2448[23702f8]: 2365008:imap.gmail.com:NA:ProcessCurrentURL:imap://XXXXXXXXXXX%40gmail%2Ecom@imap.gmail.com:993/folderstatus%3E/%5BGmail%5D/Sent%20Mail:  = currentUrl
2448[23702f8]: ReadNextLine [stream=2349748 nb=66 needmore=0]
2448[23702f8]: 2365008:imap.gmail.com:NA:CreateNewLineFromSocket: * OK Gimap ready for requests from 67.93.26.126 30if7121017yxk.0

2216[238c140]: ReadNextLine [stream=2356f20 nb=65 needmore=0]
2216[238c140]: 238b698:imap.gmail.com:NA:CreateNewLineFromSocket: * OK Gimap ready for requests from 67.93.26.126 4if7122506yxq.0

2448[23702f8]: 2365008:imap.gmail.com:NA:SendData: 1 capability

2216[238c140]: 238b698:imap.gmail.com:NA:SendData: 1 capability

2448[23702f8]: ReadNextLine [stream=2349748 nb=75 needmore=0]
2448[23702f8]: 2365008:imap.gmail.com:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA XLIST CHILDREN XYZZY

2448[23702f8]: ReadNextLine [stream=2349748 nb=44 needmore=0]
2448[23702f8]: 2365008:imap.gmail.com:NA:CreateNewLineFromSocket: 1 OK Thats all she wrote! 30if7121017yxk.0

2216[238c140]: ReadNextLine [stream=2356f20 nb=75 needmore=0]
2216[238c140]: 238b698:imap.gmail.com:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA XLIST CHILDREN XYZZY

2216[238c140]: ReadNextLine [stream=2356f20 nb=43 needmore=0]
2216[238c140]: 238b698:imap.gmail.com:NA:CreateNewLineFromSocket: 1 OK Thats all she wrote! 4if7122506yxq.0

2448[23702f8]: 2365008:imap.gmail.com:NA:SendData: Logging suppressed for this command (it probably contained authentication information)
2216[238c140]: 238b698:imap.gmail.com:NA:SendData: Logging suppressed for this command (it probably contained authentication information)
2448[23702f8]: ReadNextLine [stream=2349748 nb=30 needmore=0]
2448[23702f8]: 2365008:imap.gmail.com:NA:CreateNewLineFromSocket: * BYE Temporary System Error

2216[238c140]: ReadNextLine [stream=2356f20 nb=30 needmore=0]
2216[238c140]: 238b698:imap.gmail.com:NA:CreateNewLineFromSocket: * BYE Temporary System Error

2448[23702f8]: 2365008:imap.gmail.com:NA:SendData: Logging suppressed for this command (it probably contained authentication information)
2448[23702f8]: ReadNextLine [stream=2349748 nb=29 needmore=0]
2448[23702f8]: 2365008:imap.gmail.com:NA:CreateNewLineFromSocket: 2 NO System Error (Failure)

2448[23702f8]: 2365008:imap.gmail.com:NA:SendData: Logging suppressed for this command (it probably contained authentication information)
2448[23702f8]: ReadNextLine [stream=2349748 nb=30 needmore=0]
2448[23702f8]: 2365008:imap.gmail.com:NA:CreateNewLineFromSocket: * BYE Temporary System Error

2216[238c140]: 238b698:imap.gmail.com:NA:SendData: Logging suppressed for this command (it probably contained authentication information)
2216[238c140]: ReadNextLine [stream=2356f20 nb=29 needmore=0]
2216[238c140]: 238b698:imap.gmail.com:NA:CreateNewLineFromSocket: 2 NO System Error (Failure)


I suppose the solution is bug 121647. (And this can be closed as invalid/duped to that.)
There is no solution at 121647.  This is a chronic problem that I'm sure thousands of users are experiencing.  It is a major and extremely frustrating annoyance which is actually one of the worst software problems we've experienced with any software.  If THunderbird wants wider adoption, this would be a key problem to take seriously and address.  I'm sure that user frustration from this problem will drive users to alternatives.  Nothing will drive away users faster than chronic hourly frustration of a password request dialog boxes.
S Davis, keep in topic please - useless comments doesn't helps ether its distracts developers just even more, thanks!
I stopped using Thunderbird due to this bug - having 4 Gmail accounts that trigger this bug at least a few times a day means that Thunderbird is unusable to me. Outlook reports that the connection has been prematurely closed on these same accounts occasionally, could this be the same problem that causes TB to forget passwords?
(In reply to comment #8)
> There is obviously a connection issue with gmail, but there is also a GUI issue.
Clear of saved password in this case may be done by following reason.
 - User's request to clear saved password upon password change at servers side
   (If user cancels at password entry panel, next start up or Get Mails will    )
   (always produce trying of old(already invalid) password. It's not good manner)
   (for mail server.)
 - Possibly due to severe problem(such as loop) upon password change at server
Duane Bronson, can this bug's case be easily/surely distinguished with "AUTH failure upon password change at server"?
(In reply to comment #14)
> (In reply to comment #8)
> > There is obviously a connection issue with gmail, but there is also a GUI issue.
> Clear of saved password in this case may be done by following reason.
>  - User's request to clear saved password upon password change at servers side
>    (If user cancels at password entry panel, next start up or Get Mails will   
> )
>    (always produce trying of old(already invalid) password. It's not good
> manner)
>    (for mail server.)

agreed - upon canceling the password dialog, the potentially invalid password should not be attempted again until
1) user directed move/delete/refresh, or
2) "check for new messages every X minutes" is set and has elapsed, or
3) restart and "check for new messages at startup" is true.

Google may be breaking connections intentionally due to too many authorizations in a time period for that user and thus causing this problem.  Just speculation, though.

>  - Possibly due to severe problem(such as loop) upon password change at server
> Duane Bronson, can this bug's case be easily/surely distinguished with "AUTH
> failure upon password change at server"?
> 

I have not changed my gmail password in a long time, so I can easily distinguish it.  Whether Thunderbird can distinguish it is irrelevant.  The GUI response to canceling a password dialog box should be to abort the connection attempt and stop retrying.  Since the email can be stored and read locally, there is no need to insist on re-connecting.
(In reply to comment #15)
> I have not changed my gmail password in a long time, so I can easily distinguish it.
>  Whether Thunderbird can distinguish it is irrelevant.

Oh sorry for my confusing question. My question was "Whether Thunderbird can distinguish or not" by IMAP protocol level flow only when your case.
There is AFAIK no standard answer for a failed login.
The client doesn't know if the login failed because of a username/password mismatch or other server problem.
TB must asks you again for the password because the password may now different on the server. We had reports that Accounts got be disabled because of a changed password on the server and sending 3 times wrong login information (old password). This is worse than asking again for the new password.
Gmails answer is at a very bad point of the connection (as answer to the login), they should deny the connection early (before the login starts) or accept the login but close the connection after it.




(In reply to comment #17)
> We had reports that Accounts got be disabled because of a changed password on
> the server and sending 3 times wrong login information (old password).
> This is worse than asking again for the new password.

Matthias Versen (matti), thanks for your explanation. I've understood the reason why saved password is currently cleared by Tb upon connection failure.
(In reply to comment #17)
> on the server. We had reports that Accounts got be disabled because of a
> changed password on the server and sending 3 times wrong login information (old
> password). This is worse than asking again for the new password.

Good point.  However, that does not entirely invalidate my recommendation.  Allow me to amend it to also prevent the automatic retry of a failed password:

Upon canceling the password dialog, the potentially invalid password
should not be attempted again.  The password dialog should not reappear until 
 1) user directed move/delete/refresh, or
 2) "check for new messages every X minutes" is set and has elapsed, or
 3) restart and "check for new messages at startup" is true.

If the Password Manager is told to remember the password, it should continue remembering passwords unless the user un-checks the option, regardless of whether the password succeeded or failed.  Since Thunderbird does not know why a password has failed, it should not assume the password is invalid.

Thanks for helping to make Thunderbird the best mail handler available.
The password should be cleared from the password manager, one reporter with the disabled Account didn't found the password manager himself to clear the old password (search and you may find this old report, 2-3 years ago in SM)
The deleted passwords are also happening on NNTP/SMTP and we should have an old bug about that.
Filtering in the error response for "Username" "Password" to catch only real login errors  doesn't work for some servers because the servers sends many different errors in the response..
The real problem is that there is no exact wording for such errors in the RFCs (AFAIK).

I agree that the current UI Feedback is bad, the user doesn't know why Seamonkey or Thunderbird asks for the password again.
I suggest a dialog if SM/TB hits an error response from the server during login with an option for retry or clear password.
That would be simple but you would still get a popup and a few people would still not like that for broken servers which are often temporary not available.

BTW: This should be a dupe and this also belongs into Core:Networking/Networking:Pop3/Networking:Imap because only the Username is stored in the Accountmanager and the username isn't deleted, it's also happening in Seamonkey and this is an error on the network protocol level.

(In reply to comment #20)
> I suggest a dialog if SM/TB hits an error response from the server during login
> with an option for retry or clear password.

I think it's one of the best solutions which can be implemented shortly without too tough work or many design changes, and which will be effective for many users and in many situations.
Matthias Versen, could you open separate bug(enhancement request), please.
I believe many bugs which complain "saved password was lost when connection error" can be closed as DUP of the new enhancement request.

> The real problem is that there is no exact wording for such errors in the RFCs
> (AFAIK).

For "invalid password":
I believe that reason why no response code of "invalid password", and reason why no wording of "invalid password" in response text, is "security".
Exact reason of "invalid password" will make attack very easy.

For "password clear" in this bug's case:
I think this bug's case can be distinguished with "login/authentication failure due to invalid password", because error(BYE from server when this bug's case) occurred at outside of "IMAP level login process", even if error occurred during "Tb's internal login process". I think window of "saved password clear" is too wide currently.
Matthias Versen, what do you think?

Confirming based on IMP log.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I have this happening on my machine with several GMail accounts set up, all google-apps variety.  It will *frequently* "forget" the password and present me with a prompt which already has the password filled in.  Every single time I have to re-check the "remember" box and hit OK, and this repeats between 2 and 6 times every single instance before it finally takes.  At various points in time it occurs so often that I can barely send email out.  The saved password is always correct, though earlier it was eventually coming back with a password prompt *without* it filled in.

I've reduced the check period on my lesser used accounts to try to minimize the disruption, but it's causing me to miss email for lengthy periods as the entire thunderbird network stack freezes for all accounts while a password box sits on an alternate desktop.

Machine is stock Ubuntu 8.10 updated as of today (6/20/08), Thunderbird 2.0.0.14 (20080505).
OS: Linux → All
Hardware: PC → All
Version: unspecified → 2.0
(In reply to comment #23)
If continuous connection failre of Gmail IMAP during a Thunderbird session(from start of Tb to shutdoen of Tb), "DNS Cache" & "DNS Round Robin" have possibly relation to your problem.
If Google stops IMAP service on a server for maintenance, but if Google doesn't stop server itself nor software for IMAP service, and if Google tries to stop client's access to the server via "DNS Round Robin" setting(Gmail really uses "DNS Round Robin"), flow like comment #8 can continue for long time, because Mozilla family has problems around "DNS Cache" & "DNS Round Robin".

To Erik Walthinsen:
Will "shutdown of Tb then restart of Tb" resolve connection error problem of Gmail IMAP shortly?
It appears that, when Thunderbird has multiple connections to the server, a password prompt is queued for each connection, and each must be acknowledged. 

If so, it would probably be better if the additional prompts could inherit the answer to the first prompt for the same account.
"This is a chronic problem that I'm sure thousands of users are experiencing.  It is a major and extremely frustrating annoyance which is actually one
of the worst software problems we've experienced with any software.  If Thunderbird wants wider adoption, this would be a key problem to take seriously
and address.  I'm sure that user frustration from this problem will drive users to alternatives.  Nothing will drive away users faster than chronic
hourly frustration of a password request dialog boxes."

Same problem here, and it's driving me up the f*cking wall!!!  Multiple Gmail IMAP accts, and I'm so g*d*amned annoyed with this, I'm about to dump T-bird altogether. The app is for all intents and purposes, worthless.  Most of the time, the dialog asking for the password for one or more of the accts, is displayed behind other windows, so I don't even know for as long as I have the front window(s) up, that Tbird has stalled and is waiting for me to enter a password, a password that it was remembering just fine the day or hour before.

And, in some cases, repeated failure to login successfully, when provided a guaranteed correct password (same one that worked an hour or day before), trips Gmail's security feature, which then requires finding Google's "clear CAPTCHA" form.

This also happens with non-Gmail and POP accts.  This bug MUST BE FIXED, or I will be dumping Tbird for good.  This is not something trivial I can just overlook, the d*amned app is critically broken, IMO. And I'm one of the most loyal Tbird and Firefox fans on the planet, but it's impossible to overcome this problem.

Dependency or duplicate of: bug 423687 and bug 121647 ?
Flags: wanted-thunderbird3?
Flags: blocking-thunderbird3?
(In reply to comment #27)
> Dependency or duplicate of: bug 423687 and bug 121647 ?

Bug summary of bug 121647 is for same symptom as this bug. But the bug was opened on 2002-01-24. I can't believe initial problem of bug 121647 is same problem as this bug, even though external phenomenon(==bug summary) is same. Bug 121647 looks for me a "meta bug" for complaints of "password lost upon connection error". And, when this bug's case, Gmail IMAP case, server side behavior which is no-so-happy for Tb is involved. 
These are reasons why I don't dup this bug to bug 121647, even though bug 423687 was closed as dup of bug 121647. 
What do you think?
Just adding my voice of concern - I have seen people complain that it occurs in Outlook connecting to Google Apps too.  But we are a Thunderbird, IMAP, Google Apps site.  I would dearly like this problem to go away, if anyone wants me to assist with testing under certain conditions please email me.  But the randomness is difficult to make happen and the fact that it always happens would mean others should be able to reproduce.
Changing to Core/Networking:IMAP, because I think main problem of this bug is "needles saved password clear" when IMAP flow of Comment #8(BYE from Gmail IMAP server just after greeting).
If it's wrong, change to appropriate Product/Component, please.
Assignee: nobody → bienvenu
Component: Account Manager → Networking: IMAP
Product: Thunderbird → Core
QA Contact: account-manager → networking.imap
Version: 2.0 → Trunk
(In reply to comment #25)
> It appears that, when Thunderbird has multiple connections to the server, a
> password prompt is queued for each connection, and each must be acknowledged. 
> 
> If so, it would probably be better if the additional prompts could inherit the
> answer to the first prompt for the same account.

It doesn't look like this Bug report is going in the direction that Comment 25 referenced. Since I also see similar issues as he does, I've created Bug 444999 which addresses that problem. I do not believe it is related to this bug, but it might be.

Wada, I think comment 8 don't give us real clue about passowrd lockout. In my case users are working for all day long but usually in evening TB start asking passwords. Probably we also need log before this happens to make it clear.
Occurred for me on one of my google app accounts (typically the one it most occurs on) at 11:30am (Australian EST).
Happens for me too.

TB 2.0.0.14 (20080421) running on WinXP SP2.

Both GMAIL IMAP accounts I have forget their passwords even though I have the checkbox checked. Its a huge pain because you can't just ignore the dialog since it forces the taskbar to stay open which overlaps your work.

In the dialog, the password is written into the box with bullets, but if I just hit Ok, it doesn't work. I have to actually re-type the password.
Sorry I don't have any fancy log file information to give more input to this troubleshooting session. If anyone needs me to dig up a hidden log file or whatever, just say so, and explain how and what you need.
(In reply to comment #29)
> I have seen people complain that it occurs in
> Outlook connecting to Google Apps too.  

I ended up switching to Outlook because this issue was too difficult to work around (sorry!). I can confirm that Outlook does handle this differently. Outlook will throw errors and will stop working with the given account, but you can close it and reopen it later and it retains the passwords. 
The IMAP log quite clearly shows that the root problem is on gmail's end, in that it dies on password authentication. IMAP's lack of a clear differentiation between "authentication failed" and "server borkage" makes the right thing hard to do, although it seems that gmail is sending a BYE at the same time as the NO, which may make this particular case easy to solve.

In any case, the fact is that authentication failure--for whatever reason--brings up an interesting point. I set up bug 435306 some time ago as a forum for deciding under what circumstances passwords should be forgotten; it is therefore relevant to this discussion.
Depends on: 435306
(In reply to comment #36)
> The IMAP log quite clearly shows that the root problem is on gmail's end, 

After almost 3 years of my bug just sitting there, it's nice to know I wasn't the only one with the problem.

I wouldn't point the finger at gmail directly.  My bug was reported when I was using a personal mail server running Postfix & Courier IMAPD.

--
Dave
I upgraded to TB 2.0.0.16 on my Mac and PC and found that the problem stopped appearing for a about a week.  Then it came back again sadly although it doesn't ask as often.
Following is IMAP log for connection error due to "Too many simultaneous connections".

>(0-A) Seamonkey alreaady has 10 connections :
>      Two Gmail IMAP accounts, 5 cached connections per account.
>(0-B) Start Tb. Define one Gmail IMAP account.
>      Change max number of cached IMAP connection to 10 from default of 5.
>(1) Click(open) some folders at Tb, and click(open) a folder additionally.
>   ImapThreadMainLoop entering [this=2eaaf48]
>   imap.gmail.com:NA:ProcessCurrentURL: entering
>   imap.gmail.com:NA:ProcessCurrentURL:imap://yatter%2Eone%40gmail%2Ecom@imap.gmail.com:993/select%3E/Label-A/X0:  = currentUrl
>   imap.gmail.com:NA:CreateNewLineFromSocket: * OK Gimap ready for requests from 222.9.106.185 m29if910396wrm.19 
>   imap.gmail.com:NA:SendData: 1 capability 
>   imap.gmail.com:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA XLIST CHILDREN XYZZY 
>   imap.gmail.com:NA:CreateNewLineFromSocket: 1 OK Thats all she wrote! m29if910396wrm.19 
>   imap.gmail.com:NA:SendData: Logging suppressed for this command (it probably contained authentication information)
>   imap.gmail.com:NA:CreateNewLineFromSocket: 2 NO [ALERT] Too many simultaneous connections. (Failure) 
>(2) Error dialog)
>(3) Password dialog(i.e. password clear) => pype correct one, press OK
>   imap.gmail.com:NA:SendData: Logging suppressed for this command (it probably contained authentication information)
>   imap.gmail.com:NA:CreateNewLineFromSocket: 3 NO [ALERT] Too many simultaneous connections. (Failure) 
>(4) Error dialog again
>(5) Password dialog again => cancel
>   imap.gmail.com:NA:ProcessCurrentURL: aborting queued urls
>   imap.gmail.com:NA:SendData: 4 logout 
>   imap.gmail.com:NA:CreateNewLineFromSocket: * BYE Logout Requested m29if910396wrm.19 
>   imap.gmail.com:NA:TellThreadToDie: close socket connection
>   ImapThreadMainLoop leaving [this=2eaaf48]

When above case, reason of failure is "NO response during authentication phase". So "clear password" can not be avoided, unless reason guessing based on error message text of "Too many simultaneous connections" will be implemented.

Because user can obtain multiple free Gmail accounts very easily, and Tb's default of "number of IMAP cached connection" = 5, connection count can easily exceeds server's limit of MAXPERIP setting when Gmail IMAP. 

To all problem reporters:
Is above situation involved in your "password clear"?
If yes, reduce "number of IMAP cached connections" as many as possible.

To reduce unwanted password clear cases, I think two kinds of action will be required.
(A) Don't clear password when apparent non-authentication failure,
    even if the failure occurs during execution of Tb's logic for login.
(B) Don't clear password even when real authentication failure,
    if error message text clearly says "never be password error".

(B) can be implemented as "White List" of error message.
    If user thinks Tb should keep password upon above error, add next in list.
       "[ALERT] Too many simultaneous connections. (Failure)"
And (B) looks for me to be easy exercise for extension(add-on) developers.
But I believe Tb's behavior needs improvement in case of (A).
I found this:
http://collegedood.blogspot.com/2008/02/problem-thunderbird-keeps-asking-for.html
the problem is very disconcerting.

I purchased an iPhone the other day, logged onto Google Apps, via IMAP and it has worked flawlessly for 2 weeks now - never to re-ask for the password.

Whilst I can appreciate that it is seemingly a Google problem from the reading above, a work around in TB would be handy to so many people who are trying to show the world that there are more solutions than MS, and that it is a better solution with standards that will allow the world to integrate.  With people who can create specific applications easily for there requirement.
I see that all the ubuntu people are screaming for the same fix.  To me it is sad that since IMAP was invented, I am thinking over 20 years ago - we still can't find a great IMAP client and server combination.  I have this understanding that most people now have 2 or more devices that are receiving email and POP just doesn't cut it.
Robert: would you please stop spamming this bug, thanks
read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
I think this needs fixing for tb3, marking blocking. (Though it might as well be bug 435306, but this is soo visible.)
Flags: wanted-thunderbird3?
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3+
In nightly builds, I've made it so we don't forget imap passwords in the case of background check new mail urls failing, and we don't prompt the user for a new password either - we just silently fail, and then try to use the same password the next time we check for new mail. We are planning on having some indication that the connection failed, but it won't be a modal dialog. That may help a bit with this problem.
FYI. Bug 435306 was request for improvement in all Mail&News protocol.
> Bug 435306 : Mailnews needs to remember passwords better
(In reply to comment #46)
> In nightly builds, I've made it so we don't forget imap passwords in the case
> of background check new mail urls failing, and we don't prompt the user for a
> new password either - we just silently fail, and then try to use the same
> password the next time we check for new mail.

David, thank you so much for your effort since it represents the very first time that a developers pay any real attention to this very severe malfunction. I second every single word that Angus states in #26.

I've downloaded what I think is the most recent nightly build from http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8/, in fact http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8/thunderbird-2.0.0.18pre.en-US.mac.dmg.

I'm very sorry to tell you that that version doesn't fix the miserable failure - the passwort dialog keeps on popping in and popping and popping in, only to finally display "Failure: wrong credentials".

I simply can't tell you how much I'm fed up with it by now. Please understand that the problem is even more severe under Mac OS X: Thunderbirds icon keeps on jumping in the dock area, distracting all attention from the work to be done. You click on is, hit that god-damned button to confirm the right and known password, switch back to your work only to spot that jumping icon again a few seconds later.

PLEASE stop this, and please do it for all the time being. I'm going MAD about this - and this is not meant as a literal term. I can't believe that such an otherwise fantastic piece of software like Thunderbird suffers from this insanly tantalising misbehaviour for months now.
Thomas, my changes are only in 3.0 builds, e.g., Shredder A3, which was released today.
(In reply to comment #49)

David, thanks for that clarification. Would you please point me to an appropriate download location? "A3" sounds like this: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/3.0a3-candidates/build3/mac/en-US/, but the timestamp reads 10-Oct-2008 which isn't even near "today". Sorry take your time, I'm not experienced with the folder hierarchy there.
Wow, that was fast. Thank you, Nikolay!

David - is there any chance that you will apply the change to a 2.x build, too? None of my Add-ons seem to be compatible with Shredder A3. While "FolderFlags" was only of use to integrate the Gmail IMAP folders and "Folderpane Tools" is pure cosmetic, I do need "Lightning" and "Provider for Google Calendar" badly. Not to mention "Quick locale switcher" and "Remove duplicate messages" which are of use from time to time.

Thanks for considering and any support!
Thomas, I don't know if I'll apply my changes to a 2.x build. They were a part of a much larger set of changes, and we'd definitely need some evidence that they help with the problem before considering them for 2.x. 2.x fixes are mostly security related...
I just downloaded onto my pc shreader from lastnight - how do I confirm that your changes are in the PC version?

Unfortunately I don't have a test apple available at present only an old PC.  So I will confirm or deny during the next week or so, whether I am asked the eternal password question on the PC version.
I have now been running shreader on my test PC, on one account since 15th and it hasn't asked me for the password.  I should hedge this comment to say that, I have had periods of "days" in sanity where it hasn't asked.

In support of Thomas and all others who have responded to this bug, I would love to see it in 2.0, I fear that 3.0 is far away.  I will continue to use this test email account that gets 15 emails per day, so it is a usefulish test.
Let me know if you wish for my testing updates to be somewhere else.

This morning, my Macintosh complained for hours for the password to be re-entered, on all google app accounts I have, including the one account that my PC accesses via Shreader.  Shreader did not ask for the password ever.

Are there any appropriate log files that I could post that would confirm that TB had ignored the google request?
I don't think that's necessary. We're only interested if it starts happening again for some reason.

I haven't seen this on trunk either, so it looks like David's fix helped. I don't know the bug number so

->WFM
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Whilst you have resolved it (more than likely) for 3.0 - how do I go about getting the change into TB 2.0?
The change was in bug 422814, in particular this part, where we don't forget the password if there was no msgwindow:

@@ -7755,18 +7764,23 @@
       }
 
       if (!clientSucceeded || !GetServerStateParser().LastCommandSuccessful())
       {
           // login failed!
           // if we failed because of an interrupt, then do not bother the user
           // similarly - if we failed due to a local error, don't bug them
           if (m_imapServerSink && !DeathSignalReceived() && clientSucceeded)
+          {
+            nsCOMPtr<nsIMsgWindow> msgWindow;
+            GetMsgWindow(getter_AddRefs(msgWindow));
+            // if there's no msg window, don't forget the password
+            if (msgWindow)
             rv = m_imapServerSink->ForgetPassword();
-
+          }
           if (!DeathSignalReceived() && clientSucceeded)
           {
             AlertUserEventUsingId(IMAP_LOGIN_FAILED);
             m_hostSessionList->SetPasswordForHost(GetImapServerKey(), nsnull);
             m_currentBiffState = nsIMsgFolder::nsMsgBiffState_Unknown;
             SendSetBiffIndicatorEvent(m_currentBiffState);
             password.Truncate();
         } // if we didn't receive the death signal...
Depends on: autoconfig
Resolution: WORKSFORME → FIXED
Whiteboard: [fixed by bug 422814]
FYI.

(A) For disabling of connection to Gmail IMAP after upload of many mails, which was reported in Comment #0.
Google explains as; 
> http://mail.google.com/support/bin/answer.py?answer=81312&topic=12815
> Google Help  › Gmail Help  › IMAP  › Can I upload messages through IMAP?
> Please note that uploading an excessive number of messages to Gmail via IMAP may lead to 
> being temporarily locked out of Gmail. If this happens to you, please be aware that
> these lockouts are temporary and you should be able to re-access Gmail shortly.

(B) For "too many connections" in Comment #41.
Google says;
> http://mail.google.com/support/bin/answer.py?answer=97150&topic=12816
> Google Help  › Gmail Help  › IMAP  › Too many simultaneous connections   
> Gmail currently has a limit of 10 simultaneous IMAP connections per account.
> Please note that your mail client may actually open multiple connections in the background.
> This means it's possible to reach a connection threshold simply by using
> only two mail clients to access the same account at the same time.
It seems that nightly 2.0.0.18pre behaviour is changed a bit, but the bug still present, just delayed with two more annoying dialogs now happens:

1) First of all now I get dialog "Invalid credentials (failure)"/OK. Why ever  dialogs are there? Everybody want TB to work completely unattended. Perhaps account with errors should be marked with red color/or blinking icon/or something like noticeble which hints to see the Error Console or log for the reason, but no dialogs please.

2) At the next step I see known "Mail Server Password Required" dialog, but at this time password is not cleared yet and shown with asterisks. I press "Cancel" indicating I dont want to change anything.

3) At the next step I finally see exact old "Mail Server Password Required" dialog with password cleared, as it was in initial bug report we discuss here.

So the same bug just shifted with two more dialogs...
(In reply to comment #62)
Andrey 2.x tree no touched anyway, this bug only fixed on 3.x tree.
(In reply to comment #63)
> (In reply to comment #62)
> Andrey 2.x tree no touched anyway, this bug only fixed on 3.x tree.

Interesting. So it seems I just hit another form of this bug; all times before I got it in simpler one dialog form...

Could anybody merge the fix to 2.x tree, please! It is critical enough and deserve that. There is major problem with 3.x that no add-ons works yet and some of them are essential (f.e. can 3.x alone even sit all times in the Windows tray? Can 3.x alone handle PGP? etc.)

Thanx in advance.
(In reply to comment #62)
> 1) First of all now I get dialog "Invalid credentials (failure)"/OK. Why ever 
> dialogs are there? Everybody want TB to work completely unattended. Perhaps
> account with errors should be marked with red color/or blinking icon/or
> something like noticeble which hints to see the Error Console or log for the
> reason, but no dialogs please.

That's a "message" from the IMAP server, not something thunderbird puts up for fun. There is ongoing for for a more interactive status bar, where a lot of these messages are going to be shown in the future.
Could this be merged into the 2.x tree and sent out in the next update?  Thunderbird 2.x is very difficult to use on multiple computers for long periods of time if an account is connecting to a gmail imap server.  The disconnects are likely a gmail problem, but this fix should make those disconnects and the re-authentication process invisible to the user.
I second that.  This has been a daily frustration for quite some time.  I know this isn't TB's fault to begin with, but this issue needs to be patched out asap.
Flags: wanted1.8.1.x?
Whiteboard: [fixed by bug 422814] → [fixed by bug 422814] [see "patch" in comment 59]
Agreed. Please include this fix in the 2.x trunk. This bug makes using Thunderbird with Gmail a frustrating experience.
This should be a patch for the 1.8 branch. 
It compiles, but I probably lost some libraries the branch needs in a system upgrade, so branch builds won't start up at all for me... 

magnus@magnus-desktop:/opt/mozbuild_branch/mail/dist/bin$ ./thunderbird
*** buffer overflow detected ***: ./thunderbird-bin terminated         
======= Backtrace: =========                                           
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb72d0558]          
/lib/tls/i686/cmov/libc.so.6[0xb72ce680]                               
/lib/tls/i686/cmov/libc.so.6[0xb72cede8]                               
./thunderbird-bin[0x8079f67]                                           
./thunderbird-bin[0x807f349]                                           
./thunderbird-bin[0x807d420]                                           
./thunderbird-bin[0x80788fe]                                           
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb71ec685]       
./thunderbird-bin[0x8078841]
Thunderbird 3.0b1 still tries to forget my gmail password when it fails to log in. So the fix Comment 46 seems to not be working. If this is supposed to be in 3.0b1, this bug is NOT fixed.
Yes, indeed. :(
It is possible to resolve this once, and for all time? Simply to force the Thunderbird to remember the saved account passwords "forever" - until user decides to delete the stored password, and/or the whole account? Fix like this would be really cool for most of us, I suppose.
My update from earlier is that I am running a combination of 3.1 on Vista, XP and Mac OS X (Leopard) 3.1 beta 1 and 3.1 Pre beta2 and I haven't had the question once since moving to the world of "3".  I have had an error sent from Google Apps saying - "to many sessions", can't log in - at that point, it didn't forget my password.  That's my update - looks good for me.
Huh? Thunderbird is still working on 3.0, not 3.1. I am running on OS X 1.5.6, and using gmail IMAPS. I still get repeated password requests that try to forget my password if I forget to check the box. I agree with Krysztof: Only forget a password if I change the account information.
Product: Core → MailNews Core
Im considering updating all my users to TB 3, but I would greatly appreciate some more comments about this, as some users seemed to still get the issue.

I have more than 30 clients to update, so I would like to have some more info before putting such stress into the structure, considering the posibility of the massive update not solving the situation.

So, anyone else tested this under TB 3?
I'm using TB 3 now and it seems like it fixed the connection issues.  My TB 2 install on a diff computer gets connection errors multiple times a day, and TB 3 hasn't gotten any.  There are, however, many other bugs and quirks in the TB 3 beta, and trying to use the Google Calendar in Thunderbird/Lightning is still pretty bad.
Flags: wanted1.8.1.x?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: