Closed Bug 561055 Opened 15 years ago Closed 1 year ago

Unable to connect to your IMAP server. You may have exceeded the maximum number of connections to this server.

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Type:
defect

Tracking

(thunderbird_esr115 affected, thunderbird122 wontfix)

Status:
RESOLVED FIXED
Milestone:
123 Branch
Tracking Flags:
Tracking Status
thunderbird_esr115 --- affected
thunderbird122 --- wontfix

People

(Reporter: jimpeterson212, Assigned: gds)

References

Details

Attachments

(1 file, 1 obsolete file)

Bug 561055 - Improved and add imap server name to 'too many connections' notification. r=mkmelin
48 bytes, text/x-phabricator-request
Details | Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 Build Identifier: Thunderbird 3.0.4 Sometimes I get this message when I try to connect to my IMAP email account at the place I work: Unable to connect to your IMAP server. You may have exceeded the maximum number of connections to this server. If so use the Advanced IMAP Server Settings dialog to reduce the number of cached connections. Reproducible: Sometimes Steps to Reproduce: Use Thunderbird with an IMAP account Actual Results: See above. Expected Results: See above. The procedure given to fix this does not work. If I close Thunderbird for a while it seems to clear up. While this is occurring, if I log remotely into my computer at work, I can bring up Thunderbird there and it works.
So how many cache connections do you have ? how many do you lower it to ?
Right now it is set to 5. I tried raising it or lowering it and it did not clear the problem. Also, it is not clear to me whether it is saying the Thunderbird application has reached its limit, or the IMAP server. If Thunderbird is claiming that the IMAP server is reaching its limit, that is incorrect. This problem happens when I am logged into work from home. I can work two ways in that situation, directly on my computer at home, or I can connect into my computer at work and work from it just as if I was at work. If Thunderbird gives me this message on my computer at home, I can log into my computer at work and use Thunderbird there with no problem. Also, this problem has happened on my computer at work only once, and cleared quickly. So, I think this is some interaction with Windows 7. I am also not sure why I need to manually configure the number of IMAP connections in Thunderbird. This seems like something the application should handle automatically.
This web page provides additional information on the problem: http://kb.siteground.com/article/How_to_change_max_number_of_IMAP_connections_in_Thunderbird.html I searched the Thunderbird knowledge base for "IMAP Connections" and there were no results. I am guessing that maybe the server only allows a certain number of IMAP connections for one account, and if that maximum is less than 5 this problem occurs. Based on the error message I thought that reducing the setting for the maximum number of IMAP connections would clear the problem when it occurs. It did not do that. But, perhaps reducing that number to 1 will prevent it from happening. I also use Thunderbird on my computer at work. There the maximum number of IMAP connections is also set to the default of 5. I have only had the problem once at work, and it cleared quickly. If this is just a configuration problem, my recommendation would be to enhance the error message or add some explanation in the help for Thunderbird somewhere.
How many clients are connecting to your server, 1 at work and one at home ?
I leave my computer at work on with Thunderbird active. When I connect to my IMAP account at work from home that is with a new instance of Thunderbird on my home computer. When the instance of Thunderbird on my computer at home is reporting that I have exceeded the maximum number of IMAP connections, I have been able to log into my computer at work and use Thunderbird there. So, it seems like the limit is per instance of the email client, not for the account overall. I believe that this is just a configuration problem on my part, unless you see something else going on. I changed the configuration of both instances of Thunderbird to allow a maximum of only one IMAP connection. I am guessing that this will prevent the problem from happening.
The limit is on the server .... and depends on the clients. So if the limit on your server is 4 and you have 4 connections form the home computer then you get the error on the work one.
Here is some additional information on the problem that leads me to believe it could be a bug in Thunderbird. If I am working at home and get the error, even if I close Thunderbird and restart it, I still get the error. I can't retrieve email at all from my work account. I would think that closing Thunderbird would remove all IMAP connections. Also, the problem occurs when I am just viewing emails one at a time. I don't know why Thunderbird would be opening multiple connections in that case.
Reducing the maximum number of IMAP connections seems like it prevents the problem from occurring. But, I would recommend some things: 1. Change the default number of IMAP connections to 1. 2. Improve the error reporting when this error occurs. Reducing the maximum number of IMAP connections seems to prevent the problem from happening, but when it occurs it does not clear it up. The problem would occur. I would reduce that connection setting and restart Thunderbird. But, the problem would still be there so I would conclude that the recommended fix did not work, and then change the connection setting back to the default of 5. The error message when the problem occurs should explain this, and that the use must just wait for the connections to time out. 3. Add some explanation of this setting in the Thunderbird help text. I don't think it is covered at all in any of the setup instructions for Thunderbird.
Message of "exceeded the maximum number of connections to this server" is error message from IMAP server when Tb tried to connect(not login) to IMAP server, when existent TCP connection counts with an IP count(not Tb's active cached connections count itself) exceded a limit like MAX-CONNECTIONS-PER-IP. If TCP connection error happens, the TCP connection is not cleared immediately at server. It can remain for a while with CLOSE-WAIT status, TIME-WAIT status etc. AFAIR, TCP's default period of TIME-WAIT is around 12 minutes. It same at client side. If problem happens again, check TCP connections by next command. netstat -n -b -o One of causes of "remaing TCP connection with CLOSE-WAIT status(sooner or later chaged to TIME-WAIT)" is possibly "connection close witout clean LOGOUT from IMAP" in some cases. Trick of smaller Tb's "max cached connection count" is as follows. Even if remaining TCP connection count exceeds MAX-CONNECTIONS-PER-IP, oldest connection of TIME-WAIT status is deleted sooner or later, and at least one connection becomes available. If Tb's "max cached connection count=1", Tb request one connection only, so frequency of "exceeded the maximum number of connections to this server" is reduced very much. If available connection count at IMAP is less than 5, and if "max cached connection count=5" is Tb's setting, one of five connection requests is always rejected by server. Do you have multiple IMAP accounts on same IMAP server? As IMAP server usually assumes that access to IMAP server from a PC is for one account only, MAX-CONNECTIONS-PER-IP setting is usually not so large. If you need to access multiple IMAP accounts on same IMAP server from a PC at same time, you need to reduce "max cached connection count" of each IMAP accout setting, because Tb's setting is "per account", not "per server", not "per IP address of server". (In reply to comment #7) > Here is some additional information on the problem that leads me to believe it > could be a bug in Thunderbird. > If I am working at home and get the error, even if I close Thunderbird and restart it, I still get the error. > I can't retrieve email at all from my work account. > I would think that closing Thunderbird would remove all IMAP connections. Please don't believe "Tb's bug" based on wrong assumption. As cleanup of remaining connections at server side(CLOSE-WAIT and/or TIME-WAIT) takes a while according to SPEC of TCP, Thunderbird can do nothing once "exceeded max connection to server" occurred at server side. You need to wait for a while before try to access IMAP server again.
I have just one IMAP account. It is at the place I work. I normally leave my computer at work running with Thunderbird up because I can log into my computer at work remotely from home after I connect to the VPN at work. I also use Thunderbird to connect to my IMAP account at work directly from my computer at home. I had left the default maximum number of IMAP connections set to 5 in both instances of Thunderbird, so I am sure that is why it exceeded the number of IMAP connections allowed for my account. I have reset that to 1 on both my home computer and work computer. One point of confusion I had is that when the problem occurred, I thought that reducing the maximum number of IMAP connections configured in Thunderbird would clear the problem. It does not clear it when it occurs, but seems to prevent it from occurring. But, when reducing the maximum number of connections did not clear the problem, I thought there was something else going on. So, this was just a misunderstanding on my part. Maybe it would be better to set the default maximum for IMAP connections to 1.
(In reply to comment #10) > So, this was just a misunderstanding on my part. No. Your misunerstanding is only for reason why "exceeded max connection to server" is returned from server, and for recovery procudere(wrong thought of "restart of Tb" should resolve your problem). I use two Gmail IMAP accounts, and Gmail IMAP's MAX-PER-IP seems to 10 to 15. If I repeatedly do next while I'm using 5 connections to Gmail IMAP server by SeaMonkey, I can easily produce the "exceeded max connection" error from Gmail IMAP. Immediately restart Tb after normal termination of Tb, and access many Gmail IMAP folders to force open 5 connections per account, and terminate Tb. In such case, I frequently saw "CLOSE-WAIT" status for some remaining TCP connections, even though normal termination of Tb. If your server's MAX-PER-IP setting=5(Courier's default is 4), similar phenomenon can occur. There really is Tb side problem which produces TCP session status of "CLOSE-WAIT" at client side, even though normal termination of Tb. It may produce "CLOSE-WAIT" status of TCP session at IMAP server. And, AFAIR, there is problem of "normal LOGOUT is not done upon termination" in some cases. I may be problem when SSL is used(Gmail IMAP uses SSL). And, IMAP server side issue is suspected in your case. IMAP server possibly fails to cleanup TCP sessions due to VPN, after normal logout and normal TCP session close request by Tb. Please check TCP connection status by "netstat" command which I previous wrote upon each termination of Tb, (i) just before termination of Tb and (ii) afetr termination of Tb.
I am satisfied with the work around of just setting the maximum number of IMAP connections to 1 in the instances of Thunderbird on both my home and work computers. But, I can reset it to 5 and when the problem occurs, do the netstat -n -b -o command and report the results.
My brother and I both got the same error message, and changing the number of cached connections made no difference. The error message appeared after a server account change occurred. In my brother's case, it was after he installed a new server; it started for me after an account was deleted on the server. The error disappeared after I uninstalled Thunderbird and reinstalled (using the same data files). Does something perhaps change in the configuration when an unsuccessful connection occurs that also affects normally operating accounts?
(In reply to comment #13) As written in comment #0 to comment #12, situation of "Message about maximum number connection from IMAP server" can ordinaly happen, due to spec of TCP, due to restrictions of protocols, .... "You added comment to this bug at B.M.O" means that you are claiming that "Message about maximum number connection exceeded from IMAP server" in your case was really caused by Tb's flaw in code. (Here is B.M.O, never support forum.) michael@msr-mail.com, what is your base or evidence that your "Message about maximum number connection from IMAP server" was really caused by flaw in Tb's code?
I've been using TB with the same email configuration for over a year and the problem never occurred until an email account on an external server was removed. I then removed the email account from TB's configuration, but it would not connect with my server where the remaining email accounts are located. I am the only user on this server. Changing the number of cached connections did not make any difference, nor did rebooting both the server and client. My resolution was uninstalling TB 3.0.5 and installing 3.1 (I had not upgraded previously because Lightning was not initially supported). Again, the issue did not occur until TB was unable to find an email account, then persisted across all accounts. Even if TB finds one account is invalid, it should still connect to a server with valid, working accounts. Especially after the invalid account is removed from the configuration.
(In reply to comment #15) > I've been using TB with the same email configuration for over a year and the > problem never occurred until an email account on an external server was > removed. Does the external server itself is alive? Removal or revoke of account only? Did you enable "check new messages at start up" and per folder option of "include this folder for new mail check" of many folders? If yes, Tb 3.0 attempts login for new mail check of all folders and every attempt fails. It probably causes forced connection close at your server and it may produces many remaining TCP connections of TIME-WAIT status at server. This Tb 3.0's behaviour causes revoke of IMAP account due to "max wrong login attempt count", if reason of login failure is wrong saved passward due to password change at server(known bug). The bug was probably fixed by Tb 3.1. Tb 3.1 probably asks new password upon first login failure for first access to server, and doesn't try to login for other folders. So, if you reply cancel with Tb 3.1, password will probably be cleared, and other attempt of login is probably not invoked. It probably resolves "max connection count exceeded" problem in your case, because consumed TCP connection is one(or a few or several in worst case). > I then removed the email account from TB's configuration, but it would not connect with my server > where the remaining email accounts are located. It's not surprizing, because "number of remained TCP connections at SERVER" won't be reduced by account deletion of Tb nor by restart of Tb nor by reducing of max cached connection count. Next is probably required with Tb 3.0. (1) If problem happened, change server name of the account to non-existent one, in order to force connection failure and to prohibit further server access. (2) Terminate Tb. Wait for while, until all TIME-WAIT TCP connections will be cleared at server(10 to 20 minutes?). (3) Restart Tb, and reply "Cancel" if password is asked for the account. By the way, I changed user name setting of Tb 3.1 for a Gmail account, and replied "Retry" many many times at dialog for Retry/Cancel/New Password. Finally, following message was shown at Activity Manager. Gmail's IMAP server killed connection due to too many wrong login attempt. > Server username-X@gmail.com has disconnected. The server may have gone down or there may be a network problem.
The account was removed from the external server, but the server itself was not changed. Is that what you were asking? Yes, "Check for new messages at startup" is enabled. I'm not sure where to find the "include this folder in new mail check" option. TB 3.1 did not ask for a password after being installed -- it picked up my profile left over from the 3.0 installation. I only received the too many connections error. No others. Thanks for your efforts and the TB 3.0 suggestions, but installing 3.1 worked for me. I only reported the issue because I'm a big believer in what the Mozilla project is doing and wanted to give feedback in case it can help others.
> (I had not upgraded previously because Lightning was not initially supported). > but installing 3.1 worked for me. Can you afford to Tb 3.1 without Lightning? Or already no problem with offcial Tb 3.1? If so, it's good. Some users continue complaining about fixed bug by Tb 3.1, Tb 3.2pre, etc., because add-on he wants to use doesn't work with Tb of bug fixed... Thanks for providing another example of hard-to-understand "maximum number of IMAP connections exceeded" problem which is mainly produced by Tb's bug. It'll help other future victims.
Lightning/1.0b2 was recently released and is compatible with TB 3.1, so I'm good. Thanks again.
Summary: Message about maximum number of IMAP connections exceeded → Message about maximum number of IMAP connections exceeded - improve message
Whiteboard: [dupeme]
Component: General → Untriaged
Component: Untriaged → Networking: IMAP
OS: Windows 7 → All
Product: Thunderbird → MailNews Core
ubuntu 12.04.4 LTS/tbird 24.6.0 Same issue resurfaced after updating to this version of TBird. I have 6 different IMAP email accounts, all have max connections set to one.
Upgraded to TB 31.1.1 on Ubuntu 12.04, and I still get the problem with maximum connections despite setting every account maximum server connections to 1, I still cannot access two email accounts on the same server. Yet GMail accounts work OK. I can access these accounts from my phone, iPad, but from the laptop, it is highly variable, even when server connections set to 5. Any ideas? Many thanks,
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
I still think this is bug somewhere deep in Thunderbird. Issue only started to occur after upgrade to 38.3.0. At first I thought it might be the number of IMAP connections at our MDaemon Server in our Datacenter. However, dozens of other IMAP users were connected without issue. Even after increasing the number of IMAP and POP3 simultaneous sessions, TB was still giving the "Connections Exceeded" message. In fact, we were getting SMTP connection refused and connection lost during transmission. Seems that our MDaemon Server Dynamic IP Screening tool started to block my office IP. This is usually caused by an excessive number of failed authentication request within a short period of time. If not in the IMAP section, there is definitely some bug related to saving of passwords. In a number of other Forums and even in one other Bug report that I cannot locate, I recall users having a similar SMTP Connection Refused/Lost/Connections Exceeded and the solution was to remove the stored passwords, shut down TB, restart TB re-enter account password for send and receive and all was back to normal. My assumption is that TB was sending malformed authentication data to MDaemon which made it look like an attack which then blocked the IP. In short, TB needs SIGNIFICANTLY BETTER ERROR MESSAGING AND EASIER TO REVIEW LOGGING TOOLS.
I still think this is bug somewhere deep in Thunderbird. Issue only started to occur after upgrade to 38.3.0. At first I thought it might be the number of IMAP connections at our MDaemon Server in our Datacenter. However, dozens of other IMAP users were connected without issue. Even after increasing the number of IMAP and POP3 simultaneous sessions, TB was still giving the "Connections Exceeded" message. In fact, I was getting SMTP connection refused and connection lost during transmission. Seems that our MDaemon Server Dynamic IP Screening tool started to block my office IP. This is usually caused by an excessive number of failed authentication request within a short period of time. If not in the IMAP section, there is definitely some bug related to saving of passwords. In a number of other Forums and even in one other Bug report that I cannot locate, I recall users having a similar SMTP Connection Refused/Lost/Connections Exceeded and the solution was to remove the stored passwords, shut down TB, restart TB re-enter account password for send and receive and all was back to normal. My assumption is that TB was sending malformed authentication data to MDaemon which made it look like an attack which then blocked the IP. Clearing and resetting the stored account password information resolved the issue. In short, TB needs SIGNIFICANTLY BETTER ERROR MESSAGING AND EASIER TO REVIEW LOGGING TOOLS. Had there been an easy way to see the connection dialog between TB and the Mail Server, I would have discovered this issue much sooner.
I have not received any emails through Thunderbird, due to this same message, for almost a month now, even though I have reported it twice, and plead with them to fix it. Foxfire is giving me lots of problems, too, and I've reported it, as well. In my 1st email to them, I told them I was so frustrated with it, I was ready to change. Does anyone have any ideas as to a similar browser and email program with comparable features? I really like Thunderbird's ability to drag emails into folders, and the fact that Firefox doesn't come loaded with one of those silly bars across the top (can't think of the name of them right now) that you have to uninstall after installing the program. I've used T'bird and Ffire for many years, and really DON'T want to switch, but I just can't put up with this any longer. Thank you!
I started seeing this same issue with the past two versions of both Thunderbird (38.3 and 38.4) and SeaMonkey (2.38 and 2.39). Bug 641553 seems to be a duplicate of this bug, however the resolution on that report was a firewall settings change. I have used other e-mail software (non-Mozilla) and have not experienced this issue.
Can we at least change this bug to confirmed? I had to deal with it for weeks, looked for work-arounds, worked with our IT staff and evenutally had to revert to a different email client to get things done. It's too bad as I greatly prefer using Thunderbird with Enigmail for PGP to Outlook or Mac Mail, but this is farely glaring. I think it's a flaw that you can only reduce minimum cached connections to "1" instead of 0, and I don't really even see the need for 5, which is what the default is and what people are encouraging as the work-around, which doesn't in fact work.
Similar Problem in Seamonkey. I just get "Could not connect" with the option to retry connectin. No clue why it doesn't work... I had to try another mail client to figure out that it was because of the maximum number of connections.
I started getting this problem in March. I am running Exchange 2003 at the office and it worked fine for years with Thunderbird. Last year I did have an issue with needing to disable certain SSL methods in "options" due to certificate issues on the server but otherwise it worked fine. My iPhone and iPad can still access the server without any issues using the same settings. Only Thunderbird has given up the ghost.
I myself am not using a VPN so there is nothing to turn off. I have one computer running Thunderbird 45.2 and it cannot connect to my work Exchange Server running IMAP. I have a laptop running 38.5.1 and it connects to the same IMAP server without any problems. I have held of upgrading it because I do not want to lose my IMAP access.
I also have been experiencing this same issue. I manage about 28 computers across a mpls network. Earlier this year we started experiencing the imap connection error. I've read about lowering the cache default down from 5. That seemed to work temporarily until recently we started receiving the same error. I adjusted the cache down to 2 and some computers 1, they were able to receive, send, and view email messages but it the imap connection error pops up every once in awhile. I have the user close TB and reopen and sometimes it works and sometimes I just have to wait. Totally annoying and after reading all of the previous comments here I'm seriously thinking of changing to another email program. After many years TB was the best and now, they seem to be losing there edge. Sad Face insert here!
Hello, I have the same problem with latest releases. When I used version 37.1.0 it worked flawlesly. I didn't even check any later versions, but I did check the version 45.2.0 which is the last up until today. Does anyone have any clue what changed between this versions (I can use 5 simultanious connections and no problem with 37.1.0)?
Hello it's me again. I have now tried every version of Thunderbird after 37.1.0. The last one which is working for me is beta version 43.0b1 under https://ftp.mozilla.org/pub/thunderbird/releases/43.0b1/. I looked at the release notes for 44.0b1 but I couldn't find anything that would hint on the problem which arose in 44.0b1 release. Is there someone who can do a better job than me ? I use Linux, Ubuntu Mate version 16.04 LTS but I've had the same problem on Windows 8.1, Windows 7 and Windows 10 machines.
(In reply to borut.fister from comment #35) > Hello it's me again. > > I have now tried every version of Thunderbird after 37.1.0. The last one > which is working for me is beta version 43.0b1 under > https://ftp.mozilla.org/pub/thunderbird/releases/43.0b1/. > > I looked at the release notes for 44.0b1 but I couldn't find anything that > would hint on the problem which arose in 44.0b1 release. Is there someone > who can do a better job than me ? > > I use Linux, Ubuntu Mate version 16.04 LTS but I've had the same problem on > Windows 8.1, Windows 7 and Windows 10 machines. Thanks for narrowing it down to a specific version. I have stayed at 38.5.1. I too looked at the notes in the past and did not find anything indicative of an IMAP change. Quite frustrating because my home computer has not been able to connect in to my company for several months now. I use the laptop or iPad.
Several people at my company are complaining about the same problem. It started around end of December 2015, when people updated their Thunderbirds. Unfortunately I don't remember the exact version that introduced the problems. There were no changes on the server side when the problems appeared. We have been running MS Exchange 2013 on the latest CU (currently Build 1210.3). Network packet captures on a Mac and on a PC showed that the TCP connection is being terminated by the server immediately after initialization and before any actual logon traffic occurs. I suspected an incompatibility between TBs and the server's encryption requirements. I therefore suggested some of my users to set security.tls.version.min=3. This seems to solve it for some. Still I am not sure whether it solves it for all users, and whether this is the right thing to do.
(In reply to Marco Senft from comment #37) > Several people at my company are complaining about the same problem. It > started around end of December 2015, when people updated their Thunderbirds. https://www.mozilla.org/en-US/thunderbird/38.5.0/releasenotes/ was released in that time frame. According to the release notes, very little changed in that release. Per https://wiki.mozilla.org/RapidRelease/Calendar#Past_branch_dates the beta equivalent is Thunderbird 44 beta, which matches the timing described in borut's comment 35. But does not match Brian's comment 33.
I just seem to have stumbled into the same problem. My wife has a large number of IMAP folders in her Thunderbird, and perhaps Thunderbird opens a new connection for each of them. Luckily I am also the mail server operator, so I can look into the server logs and see what happened. I did not check very thoroughly, but apparently Thunderbird ignores its "Maximum number of server connections to cache" setting. I cannot really discern what that means, because I do not know what it means to cache a connection. I only know that a connection either exists or it doesn't. If "cache" means "keep open", then why not write "keep open" instead of this abnormal wording? I also have a difficulty to understand what Thunderbird needs 5 connections for. I think, Thunderbird needs only one at a time, or perhaps two, if it wants to keep the inbox connection open while working with secondary folders. Has anybody ever noticed a difference in behavior or performance between having this setting at 1 vs. 2 vs. 5? Moreover, this setting requires cooperation between all users on each IP address, which we cannot reasonably expect. My workaround is to increase the simultaneous connections limit on the mail server to an inordinately high number. This seems to solve the problem, but it makes it much easier for attackers to flood the server, so I don't like it. What are the chances of getting this defect repaired? What are the chances of fixing the number of simultaneous connections in Thunderbird to 1 or 2 and removing the stupid "cached connections" setting? Two log file excerpts from mail.info follow. Both email and IP addresses are mangled for protection. When shutting down courier-imap: Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=inge@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=103, sent=427, time=8, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=inge@xxx.com, ip=[::ffff:91.34.117.162], headers=533139, body=579169205, rcvd=20004, sent=588132882, time=283, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=inge@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=64, sent=161, time=287, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=inge@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=3070, sent=4041, time=299, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=hans-georg@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=13336, sent=96917, time=698, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=hans-georg@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=171, sent=976, time=698, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=heather@xxx.org, ip=[::ffff:141.105.164.130], headers=0, body=0, rcvd=260, sent=11057, time=779, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=shivani@xxx.org, ip=[::ffff:141.105.164.130], headers=0, body=0, rcvd=361, sent=3820, time=942, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=hans-georg@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=90, sent=435, time=959, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=shivani@xxx.org, ip=[::ffff:141.105.164.130], headers=0, body=0, rcvd=646, sent=19302, time=823, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=inge@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=58, sent=342, time=992, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=inge@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=205, sent=1466, time=992, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=shivani@xxx.org, ip=[::ffff:141.105.164.130], headers=0, body=0, rcvd=442, sent=14659, time=942, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=inge@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=56, sent=342, time=992, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=inge@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=209, sent=1441, time=992, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=inge@xxx.com, ip=[::ffff:91.34.117.162], headers=256, body=434, rcvd=613, sent=2965, time=992, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=inge@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=201, sent=1458, time=992, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=inge@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=153, sent=903, time=992, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=inge@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=197, sent=1408, time=992, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=inge@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=134, sent=728, time=992, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=inge@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=199, sent=1344, time=992, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=inge@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=189, sent=1320, time=992, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=hans-georg@xxx.com, ip=[::ffff:91.34.117.162], headers=256, body=1000, rcvd=11846, sent=86387, time=993, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=inge@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=176, sent=1369, time=992, starttls=1 Sep 24 13:07:32 linkcafe courier-imaps: NOTICE: Disconnected during shutdown by signal, user=inge@xxx.com, ip=[::ffff:91.34.117.162], headers=0, body=0, rcvd=209, sent=1500, time=992, starttls=1 Note that inge@xxx.com had 17 connections instead of the permitted 5. When restarting courier-imap: Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[56270], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[52771], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[45875], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[49333], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[37042], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[49499], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[59052], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[46463], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[56908], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[35979], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[34667], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[37296], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[56133], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[36831], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[45462], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[56129], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[55948], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[37940], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[59556], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[56447], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[50942], protocol=IMAP Sep 24 13:13:44 linkcafe courier-imaps: LOGIN, user=inge@xxx.com, ip=[::ffff:91.34.117.162], port=[60997], protocol=IMAP Note that inge@xxx.com opened 22 connections instead of the permitted 5.
> Thunderbird ignores its "Maximum number of server connections to cache" setting. That would be strange. That said, I just encountered this warning - perhaps related to AVAST mail shield being (very unwelcomed) enabled. I experienced extremely slow new mail downloading, lagging UI including very delayed display of messages, "loading message" in status bar, etc. The affected account has max connections 5. More research coming...
Summary: Message about maximum number of IMAP connections exceeded - improve message → Unable to connect to your IMAP server. You may have exceeded the maximum number of connections to this server.
Here are some news about the problem. Thunderbird clashes with AVAST!. It totally blocks almost all of the IMAP communications, it is responsible too for the other problem i encountered (many of you too, as i see on the forums) of the too many cached connections on IMAP servers! If i shut down protection by AVAST i can add as many email accounts as i like and it authenticates. If I leave it running it doesnt let Thunderbird authenticate, it multiplies the cached connections so that you cant receive mails, it totally ruins the Thunderbird services. I dont know if it is AVASTs programming error or Thunderbirds', but i know that you shouldnt turn off antivirus when receiving emails that nowdays are full of viruses.

This comment is inconclusive. Perhaps it will help someone figure out what the trouble is.

For years Thunderbird (Win 7 Pro 64 bit) has been frequently hanging when I click on a new message line, when normally it displays the message within a second or two. I thought the problem was due to high latency between Thunderbird .au) and the server (.de). When I made the new server (again Courier IMAP) very close (100km) this greatly reduced the time it takes to display messages when the system is working, but had no impact on problem of interminably "Downloading message". This is TB 60.6.1 (32 Bit), with Courier IMAPD 4.17.2+0.76.3-5+deb9u1 installed with apt-get.

Account Settings > Server Settings > Connection security = None; Authentication method = Password, transmitted insecurely.

Account Settings > Server Settings > Server Settings > Advanced > Show only subscribed folders is Off.

I tried a somewhat older (2.49.1 2017-10-16) SeaMonkey and the outcome was much the same. This and related faults with error text quoted below [1] are clearly extremely flaky, hard to reproduce consistently and so very difficult or impossible to resolve through changing settings. Even a large reduction in the incidence of the problems, such as 50%, is difficult or impossible to measure.

MailBird and Sylpheed exhibited no such problems.

I found the Comment 15 description of TCP error states persisting for minutes on the server to be a reasonable explanation for some of the behavioural flakiness.

I found Hans-Georg Michna's Comment 39 to be particularly helpful, since it indicates that Thunderbird is opening far more IMAP sessions than the number in Tools > Account Settings (particular account > Server Settings> Server Settings > Advanced > Maximum number of server connections tocache.

There is surely room for improvement in how this setting is named (bug 315713). It would make no obvious sense to me for TB to open more sessions than were cached. So while I have no cl ear idea of what caching would mean in an IMAP session, my best guess was that the setting actually provided some upper limit for the number of IMAP sessions TB would open with any given server, at least for a given account.

I am using the latest Courier IMAPD, via a Debian package, on a small (1 vCPU, 1GB RAM) Azure VM. htop indicates that it is never working hard due to IMAP processes, including with the settings mentioned below.

My only change to /etc/courier/imapd was to change ADDRESS from 0 to 0.0.0.0. I read somewhere that this forces it to work only on IPv4, which is what I want - and I needed to do this to get it to work at all for me.

There are multiple machines here with TB, all going out via the same public IP address. Each TB instance has multiple accounts, three of which are on the same server. One account has 100+ folders.

Inspired by I changed the server settings (/etc/courier/imapd):

MAXDAEMONS=100 (was 40)
MAXPERIP=100 (was 20)

This did not fix the problem.

I changed "Account Settings > Server Settings > Server Settings > Advanced > Maximum number of server connections to cache (hereafter MaxCache) from 5 (default) to 1 (frequently recommended in discussions of this problem), but this was not decisive in preventing the hanging problem. TB did hang while trying to get a message and in this state I tried to save a draft, which failed after some time. Changing MaxCache to 3 enabled the draft to be saved, and I think TB was still hanging on that message.

I changed to STARTTLS Normal password and the problem still occurred: After 5 or 10 minutes inactivity, click on a message in a large (29k) mailing list folder and the message window remains blank, or on the previously displayed message, for tens of seconds at least. Yet click on an adjacent message and that immediately displays. Click back to the first message and it immediately displays too.

I changed to SSL/TLS Normal password and disabled Trend Micro's Device > Security settings > Internet and email control > Network > Activate the firewall booster. (The two items in "Spam and emailed files" were disabled.) I also cleared the files and directories from Thunderbird's profile directory ImapMail directory.

No trouble yet.

Of potential interest is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364450 from 2006 "courier-imap-ssl: TLS/SSL session caching conflicts with widespread MUAs", which refers to bug 333661. However, perhaps this session caching bug was fixed in 2007-08: https://fossies.org/linux/courier/libs/imap/ChangeLog

I got Thunderbird to write an IMAP log: https://wiki.mozilla.org/MailNews:Logging#Windows .

I used the program quite a bit, with no trouble.

I opened a big mailing list folder, left the program untouched for about seveal minutes, and clicked at random on a message. Sure enough: "Downloading message" for more than a minute. I copied the 108MB log file at this point and took another copy a few minutes later, during which I clicked on the next message, to have that hang as well, then the next, which loaded quickly. Then I was able to load the first two quickly as well.

I know nothing about IMAP or these log files, but it seems strange to me that TB apparently fired off 3074 commands, one for each message in the folder, in 73 milliseconds. Each one is represented by a pair of lines such as:

2019-04-07 11:27:48.639000 UTC - [5680:Unnamed thread 1CBC26D0]: D/IMAP ReadNextLine [stream=0AEF4920 nb=39 needmore=0]
2019-04-07 11:27:48.639000 UTC - [5680:Unnamed thread 1CBC26D0]: I/IMAP 24C24800:ns1.firstpr.com.au:S-INBOX.Lists.LeCroy:CreateNewLineFromSocket: * 3074 FETCH (UID 4915 FLAGS (\Seen))

My connection to the Net is NBN FTTC running at 31MBps upstream. It could handle 2.2k bits in this time, so these 3074 commands or whatever to the IMAP server could not have been sent in this timeframe.

I eyeballed the prior log lines, from before the time when I noticed any trouble, and there were several such instances of thousands of such requests in tens of milliseconds, evidently all resulting from me opening a large mailing list folder. So perhaps this is nothing unusual.

This log file is too big to post here and contains list message text which should not be public. I can make a compressed
version of it available to anyone who needs it.

Robin, Not sure that I understand all of your comment but it sounds sort of like this: Bug 1428097. The reporter of that bug also had a large mailing list folder that took a long time to access. There's a lot of discussion there but it resulted a a patch to allow use of the CONDSTORE capability that is normally disabled. It can be enabled using the Config Editor: set mail.server.default.use_condstore to true.

However, this CONDSTORE fix is not yet in the release and is only in the beta release so you will need to use the latest tb beta for the fix to have an effect.

Without CONDSTORE, tb has to fetch the "flags" for every message in a folder to know the status of of each message that may have been changed by another client. That's what the many line you see in the log saying CreateNewLineFromSocket: * 3074 FETCH (UID 4915 FLAGS (\Seen))mean.

Also, are you seeing an error about too many connection to the server which is the subject of this bug? If not, we should probably fork your comment into a new tb bug report.

I should also ask if the "slow" folders are configured to have local offline storage (default) or possibly are you only storing the headers locally? If you have disabled local storage, each message access will fetch (download) the message from the server when it is first accessed instead of just getting it from a local file.

Gene, thanks for your responses. I spent several hours on this to no great effect and can't devote more time to it at present.

Tools > Account Settings (particular account) > Syncronization & Storage > Keep messages in all folders for this account on this computer is not enabled.

My understanding of bug 1428097 is that this is enabled, and the OP's problem is that he can't read any messages, which are presumably locally stored, while TB is synchronizing to a large folder. His folders are bigger than mine and my problem is that I can click on the line for message A, and have TB hang indefinitely, whereupon I can click the line for message B one below, or anywhere else in the folder, (usually, since the bug might appear for B too) have B display fine in a fraction of a second. Then, I can click the line for A and (usually) have it display the message instantly as well.

I just opened a mailing list folder with 5k messages and TB took a minute or so "Downloading message header nnnn ...", which is fine. It displays a line for each message it has the headers for, and while it is downloading more headers, I can click one of these lines and (usually) see the message within a fraction of a second. The problem is that sometimes, that message display operation hangs apparently indefinitely - at least an hour in one instance, without any error message.

I think what I am describing may not belong with this bug. My earlier mention of an error message, which I intended to quote, was for the message mentioned in the intial report of this bug. I was seeing this with an earlier version of SeaMonkey but I haven't seen it in my recent Thunderbird 60.6.1 tests.

Should I continue to try to characterise this problem with 60.6.1 or should I try installing a nightly, or some other version?

In my case K9-Mail from Android was causing too many connections, so that Seamonkey was affected.
So it is not necesarly Thunderbird to blame, but if you cannot ask your mail provider you could check with TCPview on windows to figure out how many connections TB established.

I still have problems with Thunderbird hanging interminably when I try to open a message A from a large mailbox, especially if this is the first action with the program for 5 or more minutes, with the folder headers already read. (As noted above, I am not storing messages locally in TB.) I can click an adjacent message B and it usually appears instantly. Then I click A, which has been stalled for minutes, and A usually appears instantly. However, the error message quoted at the start of this bug does not appear, so what I am observing may belong with some other, bug or a new one.

The fact that TB doesn't work properly for me when other email clients did does not necessarily mean that there is something wrong with TB or its configuration, since the other clients I tested were not opening as many accounts with the server as my 4 account TB client, and they may not open as many IMAP sessions per account.

At least some of my difficulties were probably caused by two pairs of courierlogger and couriertcpd running on the server, an earlier set with earlier (default imapd config file "-maxprocs=40 -maxperip=20") settings. The pair I did not notice until now had earlier PIDs and were probably started a day or two before I wrote my messages above. I guess they were operating while the more recent pair were not, so my attempts at changing settings were not affecting the behaviour of the entire server.

I had been getting multiple errors, associated with the timeout problems mentioned above, in /var/log/mail-err for imapd (no security and STARTTLS) and for imapd-ssl (later when I tried SSL/TLS with some success): "Maximum connection limit reached for (... TB's public IP address)". I rebooted the server, closed the 3 instances of TB here (two with 1 account on the server and one with 4), deleted their IMAP cache files/directories and restarted them all with STARTTLS, since I couldn't get them to work with SSL/TLS. (These TB instances all appear to the server via NAT on the one public IP address.)

The server's /etc/courier/imapd still has my MAXDAEMONS=100 (default was 40) and MAXPERIP=100 (20). Using htop and filtering with "courier" I can see the command lines for courierlogger and couriertcpd both have "-maxprocs=100 -maxperip=100".

Now there are no "Maximum connection limit reached" errors in mail.err, though there are occasional "/etc/courier/shared/index: Permission denied." errors relating to some obscure permissions problem in the server. AFAIK these only occur at TB startup and are not related to the continuing problems with interminable delays loading messages.

With "netstat netstat -n | grep :143" I see there are 23 to 25 IMAP sessions in progress with the public IP address of these TB instances, thought in htop I only see 14 or so "/usr/bin/imapd Maildir" processes.

Before I rebooted the server, I was getting the first mentioned error messages with SSL, when netstat was showing 19 or 20 993 processes. So I guess my earlier problems were caused by hitting the limit of 20, which was the default setting and with which the first pair of courierlogger and couriertcpd were running.

I was hoping to report no problems, but the delays are quite common, especially if I haven't clicked on a message in the folder for 10 minutes or so. I am not sure if the size of the folder matters.

I again deleted the IMAP caches of the 4 account TB instance and restarted it. Using netstat on the server I could see more IMAP sessions appearing according to how many TB windows I opened, each looking at a different folder in any of the accounts. I got up to 31 sessions with 5 TB windows. I opened up a total of 16 windows for different folders and viewed a message in most of them. Still there were 30 or 31 sessions. (The 1 vCPU 1GB VM didn't seem overly burdened by these, even when loading all the headers, since CPU usage was generally less than 30% and ~40% of RAM was green, with no swap activity.)

All these TB account settings now have the default 5 for number of server connections to cache. I cleared the cache dirs/files and started TB again. The problem still occurs. The workaround is to click another message and then click the first one again, so it an inconvenience - not a major problem.

With 4 windows, one for each account, Tcpview reports 6 TCP port 143 connections to the server - the same as with one window.

There is a less frequently discussed option "-maxperc" for number of connections per Class C (256 IPv4 addresses) in couriertcpd: https://www.courier-mta.org/couriertcpd.html . There is no matching MAXPERC setting in the original imapd or imapd-ssl files and I don't know what its default value is, or whether it overrides the -maxperip value. I mention this in case it helps someone else solve similar problems. In 2005 https://courier-users.narkive.com/HPhYgF8b/what-is-max-value-of-maxperc-and-maxperip Sam Varshavchik (Courier author) warns about setting MAXPERIP, MAXPERC and the absolute limit of MAXDAEMONS too high, due to the possibility of DOS attacks.

Should I try a nightly or some other version?

Robin, Thanks for the information. However, I really don't know much about Courier setup or configuration so probably can't help with that.
You do mention a few times that you "cleared tb's cache files". Which files exactly did you clear or delete? Maybe you are referring to the files under your profile in ImapMail called <mailboxname>.msf? Also, in "Advanced" settings there is a button to click that will clear your memory cache for recently accessed emails that don't have offline storage (which you say you don't).

Maybe an IMAP:5 log file would help. However, maybe a better way would be for you to provide me with a temporary test account on your courier server with a mailbox that contains problem messages and I might try to duplicate what you see from here. Would this be possible?

I currently can access a Courier imap server test account but I've not noticed any problems like you describe. But that account is rarely used and only has a few random test messages in it. I have no idea how it is configured. I think it is somewhere in Europe.

Should I try a nightly or some other version?

I don't think that would help since no recent changes address your problem specifically (or tangentially). My guess is that tb needs to make a connection but all have been used at the imap server for the NAT address since you have several hosts running tb. If you ensure only one host is running when you do your test is there a problem?

You may have already considered this and it doesn't seem to explain why when you click to another message and then go back to the original problems message that it comes right in.

Robin, There is one change that should be in daily build that there is a remote possibility that it might fix your problem:
Bug 1535969
This adds a tcp keepalive feature to the imap connections. If the connection to a mailbox is dropped for some reason and tb doesn't know about it, tb may wait up to 100s before it re-connects to the mailbox. So, without this fix, you may see the "spinner" for 100s after accessing a folder before tb makes the connection. With the tcp keepalive, this 100s delay may be eliminated and the connection occurs quicker after being lost when the folder is accessed. So if you could try this it might help. It's only in daily AFAIK.

My best guess is that my problems result from an interaction between TB without the new keepalives and something in the Azure firewall. I am abandoning the Azure VM in favour of a Digital Ocean one.

Can anyone tell me precisely what the setting "Maximum number of server connections to cache" does? The number cached might be less than the number opened to any one IMAP server. Does this limit apply per IMAP server or per account within TB? I have multiple accounts all on the one IMAP server. Does it really set a limit to the number of connections? If not, what does?

More tiresome details follow: I spent several hours with two Windows 32 bit Thunderbird daily/nightly installers, of 11th and 12th April: https://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-central/ thunderbird-68.0a1.en-US.win32.installer.exe Both were difficult to use due to many tick boxes not visibly changing state until the dialogue was reloaded or at least until after a long delay, and due to the program freezing before I could do any useful tests.

WiFi and cabled Ethernet produce the same observations and I changed to a second VDSL router made by a completely different company. I think that tunneling the Windows PC's Internet access to a VPN provider also resulted in the same misbehaviour.

The best way to reproduce the behaviour seems to be to open multiple windows, each for a different folder, and leave TB untouched for 5 or more minutes. Then click on an email line. The misbehaviour is: at the bottom (status bar) a message appears for ~~22 seconds: "Loading message". Then there may be some other text there for a moment, followed by an interminable period of "[email address]: Downloading message". Then, clicking on another message usually works and clicking on the first one then usually works, in both cases with a fraction of a second delay if the message is short.

I was able to run a Linux daily: thunderbird-68.0a1.en-US.linux-x86_64.tar.bz2 68.0a1 (2019-04-12) (64-bit) on a local machine, presumably with the Bug 1535969 keepalive patch, also behind the VDSL router's NAT. With all the same settings, I observed no misbehaviour with the Azure IMAP server.

On my Windows machine I ran a VirtualBox VM which has a complete Linux system with a ca. 2013 4.15-1.6 Courier IMAP server with the default settings (MAXDAEMONS=40, MAXPERIP=20), and a bunch of archival mailing list folders. I fired up 6 TB windows each looking into a different folder. There was no misbehaviour at all, while the same instance of TB was frequently stalling on many attempts to read or save messages on the Azure server.

Gene had no trouble using a test account I made on the Azure server, but I am not sure what version of TB he was using on his Chromebook, or how patient he was trying to elicit the misbehaviour.

I made a Digital Ocean VM (1 vCPU, 1GB RAM) in Singapore and installed Postfix, Courier IMAPD and the requisite gamin library. I configured Courier IMAPD identically to how the Azure server is set up. Despite a lot of effort, I have not observed any misbehaviour with my original 60.6.1 Windows TB.

I wish I could find a Windows daily which worked long enough to test. That might be able to establish whether the recent Bug 1535969 keepalive patch makes a difference. I think it is a very good idea.

My best guess is that without the keepalive, TB is disrupted by some aspect of Azure's firewall. This is controlled by a bunch of settings in the Web console. It is not something runs in the VM itself. I only chose the Azure VM because it was physically close. Normally I avoid MS things as much as possible possible due to a long history of fancy features which are not robust. If the Azure firewall is not playing nice with Thunderbird, then this would be consistent with the Azure representative, who wrote to me offering to help with my new account, responding in totally generic terms to my nice reply about why I chose their server. Scrutinising her signature later I found the word "Automated" in front of "Solution Assistant". She was a bot - and not a very good one.

(In reply to Robin Whittle from comment #51)

My best guess is that my problems result from an interaction between TB without the new keepalives and something in the Azure firewall. I am abandoning the Azure VM in favour of a Digital Ocean one.

Has this change taken effect on the test account you provided me? When I click on a message in the one subscribed mailing list folder "Analogue Heaven", nothing comes in and all I see in the status is "gene@mx1.firstpr.com.au: Checking mail server capabilites". Moving to another message and then back doesn't help. I can still see the messages in Inbox.

Can anyone tell me precisely what the setting "Maximum number of server connections to cache" does? The number cached might be less than the number opened to any one IMAP server. Does this limit apply per IMAP server or per account within TB? I have multiple accounts all on the one IMAP server. Does it really set a limit to the number of connections? If not, what does?

It is the maximum number of connections per account with default of 5. If you only click on Inbox after starting tb you will typically only have 1 imap connection to Inbox. If you click on other folders, you will get a new connection until you have clicked on up to 4 more so you have 5 connection with 1 always selected on Inbox and the other 4 being on the most recent 4 folders. This is supposed to allow immediate notification of new mail in the selected (connected) folders when the imap IDLE feature is available on the server and you have immediate notification enabled in tb server setup page.

If new mail is only delivered to Inbox then 2 connection is probably OK. With just one connection, Inbox gets un-selected when you go to another folder so you won't be immediately notified of new main in Inbox until you click on it again. (You will still be notified when the "check for new mail" time arrives.) With 2 connection, Inbox is always selected even when you click another folder so you will be immediately notified of new mail in Inbox.

More tiresome details follow: I spent several hours with two Windows 32 bit Thunderbird daily/nightly installers, of 11th and 12th April: https://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-central/ thunderbird-68.0a1.en-US.win32.installer.exe Both were difficult to use due to many tick boxes not visibly changing state until the dialogue was reloaded or at least until after a long delay, and due to the program freezing before I could do any useful tests.

That's probably due to mozilla framework integration that Jorg is always trying to keep working.

WiFi and cabled Ethernet produce the same observations and I changed to a second VDSL router made by a completely different company. I think that tunneling the Windows PC's Internet access to a VPN provider also resulted in the same misbehaviour.

The best way to reproduce the behaviour seems to be to open multiple windows, each for a different folder, and leave TB untouched for 5 or more minutes. Then click on an email line. The misbehaviour is: at the bottom (status bar) a message appears for ~~22 seconds: "Loading message". Then there may be some other text there for a moment, followed by an interminable period of "[email address]: Downloading message". Then, clicking on another message usually works and clicking on the first one then usually works, in both cases with a fraction of a second delay if the message is short.

The other day, my connection to your test account worked fine. Now not so good. See above.
If the problem is a dropped connection that tb was not informed of, when you click on the message and you don't see a response, just wait about 100s (1m 40s) and tb should then timeout and re-establish the connection and the message should come in. If the message never comes in even after >100s, then probably not something the keepalive will help (but I could be wrong, maybe it would).

I was able to run a Linux daily: thunderbird-68.0a1.en-US.linux-x86_64.tar.bz2 68.0a1 (2019-04-12) (64-bit) on a local machine, presumably with the Bug 1535969 keepalive patch, also behind the VDSL router's NAT. With all the same settings, I observed no misbehaviour with the Azure IMAP server.

On my Windows machine I ran a VirtualBox VM which has a complete Linux system with a ca. 2013 4.15-1.6 Courier IMAP server with the default settings (MAXDAEMONS=40, MAXPERIP=20), and a bunch of archival mailing list folders. I fired up 6 TB windows each looking into a different folder. There was no misbehaviour at all, while the same instance of TB was frequently stalling on many attempts to read or save messages on the Azure server.

Gene had no trouble using a test account I made on the Azure server, but I am not sure what version of TB he was using on his Chromebook, or how patient he was trying to elicit the misbehaviour.

Sorry, forgot to mention that I am running tb 60.4 on the chromebook (chroot jail with the chrome-os linux kernel -- crouton kubuntu). I did quite a bit of testing but didn't do the multiple tb windows you mention. I haven't tried your account on a "real" computer. So not testing with the new keepalives. I've got 5 tb windows now, but unfortunately, something is wrong when I access your account.

I made a Digital Ocean VM (1 vCPU, 1GB RAM) in Singapore and installed Postfix, Courier IMAPD and the requisite gamin library. I configured Courier IMAPD identically to how the Azure server is set up. Despite a lot of effort, I have not observed any misbehaviour with my original 60.6.1 Windows TB.

I wish I could find a Windows daily which worked long enough to test. That might be able to establish whether the recent Bug 1535969 keepalive patch makes a difference. I think it is a very good idea.

My best guess is that without the keepalive, TB is disrupted by some aspect of Azure's firewall. This is controlled by a bunch of settings in the Web console. It is not something runs in the VM itself. I only chose the Azure VM because it was physically close. Normally I avoid MS things as much as possible possible due to a long history of fancy features which are not robust. If the Azure firewall is not playing nice with Thunderbird, then this would be consistent with the Azure representative, who wrote to me offering to help with my new account, responding in totally generic terms to my nice reply about why I chose their server. Scrutinising her signature later I found the word "Automated" in front of "Solution Assistant". She was a bot - and not a very good one.

I'm not a bot, I don't think.

(In reply to Gene's comment #52.)

Several hours before you wrote this comment I turned off the Azure server and changed the DNS so that the FQDN mx1 points to new mailserver I made with a Vultr VM in Sydney. This is closer to me than Digital Ocean's closest data centre. So your attempt to log in would have gone to the Vultr server which has no "gene" account.

I have turned the Azure server on again and you can access it by the IP address I sent you in a private email. I made a test account on the Vultr server with identical mailboxes to the "gene" Azure account. I have sent you the name of the new test account.

These servers are set up almost identically, but I have not yet got STARTTLS or SSL/TLS working on the Vultr VM, whereas STARTTLS worked on the Azure VM. I am not running a firewall on these VMs themselves, though I plan to run one on the Vultr server.

Thanks for the explanation of the setting. I think it should be renamed: "Maximum number of IMAP connections per account." Whether they are cached or not is a separate matter not affected by the value of this setting. Is there a bug concerning the wording of this setting?

My main Windows machine and one other is running TB 60.6.1 and the third is running 67.0b1 (beta) all 32 bit. I think they all behave the same way regarding the Azure IMAP server, but I did notice unresponsive tick boxes in 67.0b1. I am about to replace the beta one with a 60.6.1 version for another reason.

As far as I know, all my observations to date are consistent with my particular Azure server upsetting Windows 60.6.1 and 67.0b1, but not a recent Linux 64 bit daily. I have spent days on this problem and I need to get back to paying work, so I have no interest in developing a more refined or robust explanation.

All my observations are consistent with the hypothesis that you are the polar opposite of a bot. The two test accounts may enable you, with sufficient effort, to develop a better explanation for the trouble I experienced. This may be a way of testing the effectiveness of the keepalive patch.

Thanks very much for your help!

For a week I have been using TB 60.6.1 with my new mailserver on a Vultr VM and everything is working fine. Thanks for Thunderbird and Firefox!

I have used Thunderbird for years under Ubuntu Studio without encountering this problem, even though I have numerous other devices which check mail on my various IMAP accounts. The problem has appeared for a few weeks now, in Thunderbird 68.10.0 (64 bit). Even if the error is, in fact, due to server limits, the error message is less than useful: I have several IMAP accounts configured in Thunderbird, and the error message gives no indication of which server was involved. Even if it did, the message appears only briefly and is half transparent, making it difficult to capture any information it might provide. As others have indicated, the error message appears when I start Thunderbird and does not appear to limit my use of any of the IMAP accounts I have configured within Thunderbird. As a workaround I have disabled the automatic checks for new messages on startup and every 10 minutes for each of the IMAP servers I have configured, as that was easier than trying to change the number of connections Thunderbird uses for each account.

rsbrux, Been a few years since I heard any complaints about this. How many accounts do you have in tb? Do any accounts receive email into other than INBOX? If not, there should only be one connection per account at tb startup until you maybe start clicking on other folders. Also, junk processing or other filtering may cause additional connections to occur.

The error "possibly too many connections" is just a fall-back error and occurs when tb can't make a connection to the server. I guess it really should at least say which server can't connect.

Note: with check new mail at startup and check every X mins disabled, you have to manually click on each account's INBOX to receive new mail. There won't be any connections to the server until you do. I guess you know this.
P/S: You can click "Get all messages" to force a check on all accounts. I forgot about this.

I had forgotten about this until I started getting messages yesterday from this thread. In the case of my report five years ago, the problem was ultimately tracked down to an expired SSL certificate that prevented secure IMAP connections on port 993. The immediate workaround was to switch to unencrypted port 143.

The "real" bug is really the wrong error message being shown as the problem was not an exceeded number of connections.

@gene, I have 7 accounts in Thunderbird. None receive messages into folders other than Inbox, but all have additional folders, and one has quite a lot of them. Most of the accounts were caching 5 connections. I tried turning off all automatic mail fetching and reducing all accounts to 1 cached connection for a while and didn't get any more such messages. However, the failure messages have been episodic. I have now turned back on "Check for messages on startup" and "Check for new messages every 10 minutes" and have upped the number of cached connections to 3 per account. So far I haven't seen any more connection failure notices. I will report back here if I do.

I used to have this issue too on my notebook, and I figured out the problem was in fact caused by my phone's e-mail program. I configured my phone to check for a number of folders which ate a large number of connections to the IMAP server. Also, my wife was checking e-mails at the same server, both from her notebook and phone. From the perspective of the server, we were all the same ip address (home wifi) so I suspect that made things worse.

I reduced the number of folders my phone was checking and my notebook's Thunderbird stopped complaining about maximum number of connections.

Attached patch conn-alert.diff (obsolete) — — Splinter Review

In comment 56 I wrote:

The error "possibly too many connections" is just a fall-back error and occurs when tb can't make a connection to the server. I guess it really should at least say which server can't connect.

If you add a %S to the error string you get a server hostname string in the alert. This also updates the error string so that "connection exceeded" is just a possibility and not necessary the main cause. Also, mentioned that other devices/apps can cause this error to occur. (The error string is getting kind of long so not sure if it's OK.)

From comment 57:

The "real" bug is really the wrong error message being shown as the problem was not an exceeded number of connections.

When connection quota at the server is exceeded this is typically not reported by the server and just a failure to connect occurs. Tb has no knowledge of how many connection the server allows. So I tweaked the message some to indicate that connection count exceeded is only a possibility and not necessarily the cause of the problem.

Assignee: nobody → gds
Attachment #9219619 - Flags: feedback?(benc)
Comment on attachment 9219619 [details] [diff] [review] conn-alert.diff Review of attachment 9219619 [details] [diff] [review]: ----------------------------------------------------------------- ::: mail/locales/en-US/chrome/messenger/imapMsgs.properties @@ +200,5 @@ > +# LOCALIZATION NOTE (imapServerDroppedConnection2): %S is the imap server hostname. > +imapServerDroppedConnection2=Unable to connect to your IMAP server %S probably due to a temporary network error. \ > +Another possible cause is that the maximum number of connections to this server has been exceeded. You can use \ > +the Advanced IMAP Server Settings dialog to reduce the number of cached connections. Your other devices or apps \ > +connecting to this server can also cause the connection quota to be exceeded. I'm not very up on localization, but I'm guessing that you went with "imapServerDroppedConnection2" rather than reusing "imapServerDroppedConnection" in order to not confuse existing translations of "imapServerDroppedConnection" without the "%S" , right? It does seem like a sensible approach to me.
Attachment #9219619 - Flags: feedback?(benc) → feedback+

When I would forget to put a suffix number incremented on a modified string name I was always reprimanded by Magnus or Jorg so I think it it SOP to do that.
I still think the string is now way too long so before submitting an official patch for review I'll try to come up with a shorter one. Any suggestions for improvement would be appreciated.

Severity: normal → S3

One problem here, which I do not think that the voluminous thread above points out, is that the error message does not tell the user which IMAP account is at issue.

I submit that this IMAP problem (i.e. the problem that causes the error message) is one that the forthcoming Thunderbird rewrite should treat.

(In reply to JN from comment #63)

One problem here, which I do not think that the voluminous thread above points out, is that the error message does not tell the user which IMAP account is at issue.

The draft patch is in that direction.

I submit that this IMAP problem (i.e. the problem that causes the error message) is one that the forthcoming Thunderbird rewrite should treat.

115 is not a totall rewrite. It is focused mainly on UI - what you see in the panes, not the backend like imap.

I looked at this again and see that "too many connections" to the server can trigger just about any network related error. And for at least one server (dovecot) having too many connections doesn't trigger a network error at all but, instead, dovecot only reports an error after TB sends authentication info and the server reports a login failure. This is because dovecot allows the over limit connection to still occur and sends the standard "greeting" but only fails when TB sends something to the server (the authentication info) and the server responds with "NO [UNAVAILABLE]". Tb then shuts down the connection and asks the user, needlessly, for a password.

I can't really add imap specific info to the password prompt since it's used by other non-imap protocols too. So I'll just go ahead and update the network error prompt similar to how I described in the patch at comment 60, mainly just to add the server name to the string and to indicate that "too many connections" is just a possibility and maybe not the main cause of the error.

So the notification will now say:

Unable to connect to IMAP server <server name> most likely due to a temporary network error.
Another possibility is the number of connections allowed by the server has been exceeded by your devices. 
Use the Advanced IMAP Server Settings to reduce the number of connections used by Thunderbird.
Attachment #9219619 - Attachment is obsolete: true

(In reply to gene smith from comment #65)

So the notification will now say:

Unable to connect to IMAP server <server name> most likely due to a temporary network error.
Another possibility is the number of connections allowed by the server has been exceeded by your devices. 
Use the Advanced IMAP Server Settings to reduce the number of connections used by Thunderbird.

I've got a user in Support Forum asking about this because they have 10 accounts and would really like to know which one this message relates to.

Can you tell me what release version will show the name of server?

Flags: needinfo?(gds)
See Also: → 1602375, 620088
Whiteboard: [dupeme]

I submitted the patch about 6 months ago and never followed up on the requested changes. Just now updated the patch with the requested changes. So sorry for the big delay, I had completely forgot about this so thanks for the NI.

Can you tell me what release version will show the name of server?

Since this involves a string that has to be translated I think it can't be released until the next ESR after the current ESR 115. So it might be while.

Flags: needinfo?(gds)

Magnus,
In another bug (bug 1868275 comment 4) someone mentioned the string that is the subject of this bug and I though we had changed it. But I see here my last update is still waiting for your review.
The very small patch still applies OK to c-c head (no bit rot).

Flags: needinfo?(mkmelin+mozilla)

Sorry for the delay.

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(mkmelin+mozilla)
Hardware: x86_64 → All
Keywords: checkin-needed-tb

Pushed by alessandro@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/0609ace424dc
Improved and add imap server name to 'too many connections' notification. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Keywords: checkin-needed-tb
Resolution: --- → FIXED
Target Milestone: --- → 123 Branch

Does localization look good?

Flags: needinfo?(rob)

Yes. 34 locales have translated.

Flags: needinfo?(rob)
See Also: → 1892490

Gene, I'd like to take this to 115 for it's debugging value to users for accurately identifying the source of the problem

Flags: needinfo?(gds)

Should be ok, just some text.

Flags: needinfo?(gds)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: