All IMAP accounts show "Connected to" status but no new messages
I have a bunch of IMAP accounts, most gmail, but one at alumni.caltech.edu. At the end I copy-pasted the start of Troubleshooting Information. All have been working fine with Thunderbird for years.
Today, for every account, if I click "Get Messages" I see "<account-name>: Connected to <hostname>..." at the lower-left in the status line, but it never completes or times out, and I don't get any new messages, even though I can login to webmail and see that there are new messages.
I've quit and restarted Thundbird, I've paused my Eset Smart Security firewall, and I've rebooted.
I tried turning on Thunderbird logging in an elevated cmd window with: C:\WINDOWS\system32>set NSPR_LOG_FILE=%HOMEDRIVE%%HOMEPATH%\Desktop\tbird_log.txt C:\WINDOWS\system32>set NSPR_LOG_MODULES=POP3:5,IMAP:5,SMTP:5 C:\WINDOWS\system32>start thunderbird
Thunderbird eventually went into offline mode and I exited, but I don't know how to read the log file properly.
This is on Windows 10 Home. I did get a significant Windows Update overnight: Version 1709 and an update to it, KB40058043. I noticed this morning that I had a Windows Mail app in my taskbar (which I removed). I'll also say that my wife's PC got the same Windows update, and her Thunderbird client is working fine.
I'm out of ideas how to fix or further analyze this - can someone look at the log file? Since it contains email addresses I don't want to try posting it.
Troubleshooting Information:
================
Application Basics
Name: Thunderbird Version: 52.5.0 User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 Profile Folder: Open Folder
(Local drive) Application Build ID: 20171121193617 Enabled Plugins: about:plugins Build Configuration: about:buildconfig Memory Use: about:memory Profiles: about:profiles
Mail and News Accounts account1: INCOMING: account1, , (none) Local Folders, plain, passwordCleartext
account3: INCOMING: account3, , (imap) imap.googlemail.com:993, SSL, passwordCleartext OUTGOING: , smtp.googlemail.com:587, alwaysSTARTTLS, passwordCleartext, true
account5: INCOMING: account5, , (imap) imap.googlemail.com:993, SSL, OAuth2 OUTGOING: , mail.freestylefarm.org:587, alwaysSTARTTLS, passwordCleartext, true
account6: INCOMING: account6, , (imap) imap.googlemail.com:993, SSL, passwordCleartext OUTGOING: , smtp.googlemail.com:465, SSL, passwordCleartext, true
account7: INCOMING: account7, , (imap) imap.googlemail.com:993, SSL, passwordCleartext OUTGOING: , smtp.googlemail.com:465, SSL, passwordCleartext, true
account8: INCOMING: account8, , (imap) imap.googlemail.com:993, SSL, passwordCleartext OUTGOING: , smtp.googlemail.com:465, SSL, passwordCleartext, true
account9: INCOMING: account9, , (imap) imap.googlemail.com:993, SSL, passwordCleartext OUTGOING: , smtp.richpeterson.org:587, alwaysSTARTTLS, passwordCleartext, true
account10: INCOMING: account10, , (imap) mail.onesourcehorse.com:143, alwaysSTARTTLS, passwordCleartext OUTGOING: , mail.onesourcehorse.com:587, alwaysSTARTTLS, passwordCleartext, true OUTGOING: , mail.onesourcehorse.com:587, alwaysSTARTTLS, passwordCleartext, false
account11: INCOMING: account11, , (imap) mail.alumni.caltech.edu:993, SSL, passwordCleartext OUTGOING: , mail.alumni.caltech.edu:587, alwaysSTARTTLS, passwordCleartext, true
account12: INCOMING: account12, , (imap) imap.googlemail.com:993, SSL, OAuth2 OUTGOING: , mail.freestylefarm.org:465, SSL, passwordCleartext, true
account13: INCOMING: account13, , (rss) Feeds, plain, passwordCleartext
account15: INCOMING: account15, , (imap) imap.googlemail.com:993, SSL, passwordCleartext OUTGOING: , mail.freestylefarm.org:587, alwaysSTARTTLS, passwordCleartext, true
account16: INCOMING: account16, , (imap) imap.googlemail.com:993, SSL, passwordCleartext OUTGOING: , smtp.googlemail.com:465, SSL, passwordCleartext, true
account19: INCOMING: account19, , (imap) mail.freestylefarm.org:143, alwaysSTARTTLS, passwordCleartext OUTGOING: , mail.freestylefarm.org:465, SSL, passwordCleartext, true
account20: INCOMING: account20, , (imap) mail.freestylefarm.org:143, alwaysSTARTTLS, passwordCleartext OUTGOING: , mail.freestylefarm.org:587, alwaysSTARTTLS, passwordCleartext, true
Crash Reports
Extensions CompactHeader, 2.1.3, true, {58D4392A-842E-11DE-B51A-C7B855D89593} gContactSync, 2.0.13, true, gContactSync@pirules.net ImportExportTools, 3.2.5, true, {3ed8cc52-86fc-4613-9026-c1ef969da4c3} Lightning, 5.4.5, true, {e2fda1a4-762b-4020-b5ad-a41df1933103} Mail Merge, 4.9.1, true, mailmerge@example.net Provider for Google Calendar, 3.3, true, {a62ef8ec-5fdc-40c2-873c-223b8a6925cc} Remove Duplicate Messages, 0.1.14, true, {12345678-1234-1234-1234-123456789abc}
Vybrané riešenie
Well, the problem is now solved, but unfortunately I don't really know how it happened. I had restored my pre-update Macrium backup at least three or four times, fixing the problem, then installed the "Autumn Creator Update", and that caused the problem every time.
With the Thunderbird traces not giving me a clue, I then installed Wireshark and examined its traces of traffic between my PC and an IMAP server that I only use for one account (i.e. not gmail) so I could be sure of the correspondence between my actions in Tbird and the traffic. I could see the IMAP protocol issue STARTTLS, then the TLSv1.2 hello exchange. But with the broken Thunderbird there were no significant APPLICATION DATA packets sent under TLSv1.2, while with the working Thunderbird there was a flurry of them each time I refreshed the folder subscription list. So it really just confirmed the EOF seen in the Thunderbird trace output.
Then with the Creator Update installed I tried creating a new Windows user account, and running Thunderbird there, creating a new email account accessing my primary gmail IMAP account just like the one I had been using. It worked fine, while the Thunderbird under my original Windows account still failed.
So I went back to my original Windows account, and renamed both my AppData/Roaming/Thunderbird and AppData/Local/Thunderbird folders. Then ran Thundbird and created a new email account accessing my primary gmail IMAP account, and that one worked, too.
So I resigned myself to naming the folders back, collecting screenshots of all the account settings screens, renaming folders again, and manually re-creating all 10 accounts. I actually ran into problems with my second gmail account, which had been using oauth2 authentication. When I tried to create the account, it kept failing the password. At least once a recovery email account got a message from google about rejecting a login from an insecure application, but even after changing the password through webmail, Thunderbird kept refusing to create the account with a complaint about the account name or password.
Then I remembered that I had the ImportExportTools extension, so I renamed my folders back to the originals, and exported my profile, with the intention of renaming them again and importing. But lo and behold, Thunderbird seemed to be working again, even though I had not knowingly made any changes to my profile. I even had the "Unread/Total/Size" columns back in the Folder Pane Toolbar. Couldn't see any way to get that feature in the Windows account where I started with an empty Tbird profile.
So I guess I should mark this solved, even though I really don't know what solved it. Once again I thank you for your patience in sticking with this, and apologize for not having any reusable contribution come out of this ordeal.
Čítať túto odpoveď v kontexte 👍 0Všetky odpovede (18)
I see you tried pausing Eset, but did you try running in Windows safe mode (Shift+Restart) to test for possible interference?
Thanks! I haven't used safe mode since Windows XP!
In Safe Mode with networking, Thunderbird downloaded the new messages in all folders no problem. Then rebooted to normal mode and it still worked, so I can't tell exactly what the problem was.
The problem now is that when sending a message, I get an error saving it to the Sent folder, which only gives options to retry or cancel the send, effectively making Thunderbird "read-only". I changed the "Copies & Folders" "Place a copy in" setting from "Sent Folder on <the Tbird account>" to save in "Sent Folder on Local Folders", and that allows the message to be sent, but obviously limits the functionality.
Guess I should go back into Safe mode and see if the same problem saving the sent message occurs there.
Note that for gmail accounts, you should uncheck 'Place a copy in:' under Account Settings/Copies & Folders, as gmail automatically copies sent messages to the Sent folder. I don't know if that causes the error, but it's recommended (see SMTP section here).
Thanks for your note about gmail sending behavior, sfhowes, but it's not relevant here as the main account in question (and most others of mine) use a gmail server for IMAP, but they use a different SMTP server for outgoing mail. Typically I have email hosted on a custom domain that forwards to a gmail account where I read it with Tbird, but I have Tbird configured to send mail through that custom domain's SMTP server. And as I said at the beginning, this configuration has been working fine for years.
So I just tried rebooting into Safe mode with networking again. That causes the sending of mail to work just fine with the Copy sent messages set to copy to the Sent Mail folder as it always has been. And the "Manage folder subscriptions" link in "Advanced Features" for the accounts now shows the list of folders with subscribed folders check-marked as it always has.
Unfortunately, when I reboot to normal mode, saving a copy to Sent Mail still fails, and the folder subscription lists are still empty.
Any ideas on next steps? I'm stumped at the moment. Should I make logs of sending that produce the unable to save message, and of the Manage folder subscriptions action (what logs should be requested for the Manage folder subscriptions action?).
If it works in safe mode, there's some program that runs in normal mode that causes the problem. Typically, this is an antivirus program that is scanning email, a practice that is generally discouraged. Disable Eset's email scanning component or add the TB profile folder as an 'exception':
Before I saw your previous reply, I had started in Safe mode again, then used msconfig and the Task Manager to disable the Eset Service and the Eset command line client startup task and rebooted normally. After reboot, verified that Eset was not running. Then started Thunderbird and still had the problem saving a copy and the empty folder subscription list.
But just for completeness and because it's so embarrassing to say you've covered a suggestion when you didn't actually try the exact suggestion given, and then find out it would have worked, I went ahead and both disabled Eset's scanning of emails and excluded my TB profile folder from scanning. Then restarted Thunderbird and both problems (failed copy of sent message and empty folder subscription list) were still present.
I'm thinking I could make logs of the same actions on my wife's PC which has fairly similar setup and has no trouble saving a copy of sent messages and shows folder subscription lists correctly, and logs of the same actions on my PC that's having trouble, then looking for differences between them. Again, suggestions for what logs to generate would be helpful. The only names I know are POP, IMAP, and SMTP. I suppose maybe IMAP:5 could be useful for folder subscription lists, not sure if IMAP or SMTP would be complicit in the failing save of outgoing message copy.
You stated above that the problem vanished in Windows safe mode, so the first thing is to see what changes when you run in normal mode, the effect of Eset being one factor.
I don't have experience with session logging, but you can read about it here:
Right - though I think I ruled out Eset. Though I didn't uninstall it, I did use msconfig and task manager to disable its service and prevent its startup from running, and confirmed that it wasn't running (and saw Windows Defender take over). So I'm pretty sure that's not the culprit.
The most likely candidate would seem to be the large Windows Update that happened overnight - Tbird was fine the previous day, and broken after the reboot forced by the update. That update was large enough that it can't be undone by "Uninstall Update", so I might have to look into reverting to a previous build of Windows. But first I think I should try to get more info on where things are going wrong. Since my wife's laptop got the same update and has not had a problem with Tbird accessing a gmail IMAP account, comparing logs from the working Tbird to logs from the broken one seems like a good idea before possibly further breaking my laptop by trying to revert a Windows build and winding up requiring a restore from a Macrium Reflect backup.
But thanks very much for the reference on logs, that should help a lot!! I had only seen something about expert developers being the only ones able to understand the logs.
Instead of comparing to a different system, after looking at the log output a little I thought it might be simplest just to compare the logs running in safe mode and normal mode. Each line of log output begins with
decimal-integer[hex-integer]:
I don't know the actual meaning of the integers, but it appears that lines beginning with the same pair of integers form a single conversation, while lines beginning with different pairs of integers form different conversations.
I enabled logging as before with
set NSPR_LOG_MODULES=POP3:5,IMAP:5,SMTP:5
Then I started Thunderbird. After quitting Thunderbird, I went to the log files, and extracted all lines beginning with the same pair of integers as the first line, which was labeled "ImapThreadMainLoop".
When booted in normal mode, this produced only 9 lines of output, showing obvious failure but no obvious cause, The Thunderbird GUI just showed the busy cursor on the window for the email account example@gmail.com:
9604[1825c3a0]: ImapThreadMainLoop entering [this=18cb2800] 9604[1825c3a0]: 18cb2800:imap.googlemail.com:NA:ProcessCurrentURL: entering 9604[1825c3a0]: 18cb2800:imap.googlemail.com:NA:ProcessCurrentURL:imap://example40gmail%2Ecom@imap.googlemail.com:993/liteselect%3E/INBOX: = currentUrl 9604[1825c3a0]: ReadNextLine [stream=18bb5fb0 nb=4294967295 needmore=0] 9604[1825c3a0]: 18cb2800:imap.googlemail.com:NA:CreateNewLineFromSocket: clearing IMAP_CONNECTION_IS_OPEN - rv = 805a1ff6 9604[1825c3a0]: 18cb2800:imap.googlemail.com:NA:TellThreadToDie: close socket connection 9604[1825c3a0]: 18cb2800:imap.googlemail.com:NA:CreateNewLineFromSocket: (null) 9604[1825c3a0]: 18cb2800:imap.googlemail.com:NA:ProcessCurrentURL: aborting queued urls 9604[1825c3a0]: ImapThreadMainLoop leaving [this=18cb2800]
When booted into safe mode, a similar extraction of the log file begins as shown below, and goes on for thousands of lines, describing the folder structure for this account and then the new messages being downloaded in it:
3872[18383e60]: ImapThreadMainLoop entering [this=183ab800] 3872[18383e60]: 183ab800:imap.googlemail.com:NA:ProcessCurrentURL: entering 3872[18383e60]: 183ab800:imap.googlemail.com:NA:ProcessCurrentURL:imap://example40gmail%2Ecom@imap.googlemail.com:993/liteselect%3E/INBOX: = currentUrl 3872[18383e60]: ReadNextLine [stream=18de5240 nb=68 needmore=0] 3872[18383e60]: 183ab800:imap.googlemail.com:NA:CreateNewLineFromSocket: * OK Gimap ready for requests from 108.20.56.164 u31mb638580645qge 3872[18383e60]: 183ab800:imap.googlemail.com:NA:SendData: 1 capability 3872[18383e60]: ReadNextLine [stream=18de5240 nb=173 needmore=0] 3872[18383e60]: 183ab800:imap.googlemail.com:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH2 AUTH=PLAIN AUTH=PLAIN-CLIENTTOKEN AUTH=OAUTHBEARER AUTH=XOAUTH 3872[18383e60]: ReadNextLine [stream=18de5240 nb=45 needmore=0] 3872[18383e60]: 183ab800:imap.googlemail.com:NA:CreateNewLineFromSocket: 1 OK Thats all she wrote! u31mb638580645qge 3872[18383e60]: try to log in 3872[18383e60]: IMAP auth: server caps 0xc080c1625, pref 0x1006, failed 0x0, avail caps 0x1004 3872[18383e60]: (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN = 0x200000, PLAIN = 0x1000, 3872[18383e60]: trying auth method 0x1000 3872[18383e60]: got new password 3872[18383e60]: IMAP: trying auth method 0x1000 3872[18383e60]: PLAIN auth 3872[18383e60]: 183ab800:imap.googlemail.com:NA:SendData: 2 authenticate PLAIN 3872[18383e60]: ReadNextLine [stream=18de5240 nb=4 needmore=0] 3872[18383e60]: 183ab800:imap.googlemail.com:NA:CreateNewLineFromSocket: + 3872[18383e60]: 183ab800:imap.googlemail.com:NA:SendData: Logging suppressed for this command (it probably contained authentication information) 3872[18383e60]: ReadNextLine [stream=18de5240 nb=218 needmore=0] 3872[18383e60]: 183ab800:imap.googlemail.com:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ENABLE MOVE CONDSTORE ESEARCH UTF8=ACCEPT LIST-EXTENDED LIST-STATUS LITERAL- SPECIAL-USE APPENDLIMIT=35651584 3872[18383e60]: ReadNextLine [stream=18de5240 nb=57 needmore=0] 3872[18383e60]: 183ab800:imap.googlemail.com:NA:CreateNewLineFromSocket: 2 OK example@gmail.com authenticated (Success) 3872[18383e60]: login succeeded 3872[18383e60]: 183ab800:imap.googlemail.com:A:SendData: 3 namespace 3872[18383e60]: ReadNextLine [stream=18de5240 nb=32 needmore=0] 3872[18383e60]: 183ab800:imap.googlemail.com:A:CreateNewLineFromSocket: * NAMESPACE (("" "/")) NIL NIL 3872[18383e60]: ReadNextLine [stream=18de5240 nb=14 needmore=0] 3872[18383e60]: 183ab800:imap.googlemail.com:A:CreateNewLineFromSocket: 3 OK Success 3872[18383e60]: 183ab800:imap.googlemail.com:A:SendData: 4 COMPRESS DEFLATE 3872[18383e60]: ReadNextLine [stream=18de5240 nb=14 needmore=0] 3872[18383e60]: 183ab800:imap.googlemail.com:A:CreateNewLineFromSocket: 4 OK Success 3872[18383e60]: 183ab800:imap.googlemail.com:A:SendData: 5 ID ("name" "Thunderbird" "version" "52.5.0") 3872[18383e60]: ReadNextLine [stream=1b786700 nb=161 needmore=0] 3872[18383e60]: 183ab800:imap.googlemail.com:A:CreateNewLineFromSocket: * ID ("name" "GImap" "vendor" "Google, Inc." "support-url" "https://support.google.com/mail" "version" "gmail_imap_171217.11_p0" "remote-host" "108.20.56.164") 3872[18383e60]: ReadNextLine [stream=1b786700 nb=14 needmore=0] 3872[18383e60]: 183ab800:imap.googlemail.com:A:CreateNewLineFromSocket: 5 OK Success 3872[18383e60]: 183ab800:imap.googlemail.com:A:SendData: 6 xlist "" "%" 3872[18383e60]: ReadNextLine [stream=1b786700 nb=42 needmore=0] 3872[18383e60]: 183ab800:imap.googlemail.com:A:CreateNewLineFromSocket: * XLIST (\HasNoChildren) "/" "AmpedAndy" 3872[18383e60]: ReadNextLine [stream=1b786700 nb=43 needmore=0] 3872[18383e60]: 183ab800:imap.googlemail.com:A:CreateNewLineFromSocket: * XLIST (\HasChildren \Inbox) "/" "Inbox" 3872[18383e60]: ReadNextLine [stream=1b786700 nb=41 needmore=0] 3872[18383e60]: 183ab800:imap.googlemail.com:A:CreateNewLineFromSocket: * XLIST (\HasNoChildren) "/" "LinkedIn" 3872[18383e60]: ReadNextLine [stream=1b786700 nb=47 needmore=0]
This doesn't really tell me anything about the problem other than that there's a problem communicating with the server. In normal mode, it looks like the first read from the server gives Thunderbird 4294967295 bytes of data, and Thunderbird immediately reports "clearing IMAP_CONNECTION_IS_OPEN - rv = 805a1ff6". Of course 4294967295 is the 32-bit 2's complement representation of -1, so most likely the read returned EOF.
In Safe mode, that first read returns 68 bytes of data: "* OK Gimap ready for requests from 108.20.56.164 u31mb638580645qge", which begins the IMAP connection protocol.
But there's no clue as to why that first read from the server gets an EOF in normal mode. I guess all I can do at this point is try reverting to the Windows build before the big Windows Update. Any other ideas appreciated.
The bad news: I tried using "Settings->Recovery->Go back to an earlier build" to undo the effect of the big Windows Update that coincided with this problem. That process took some time and seemed to work properly - but Thunderbird continued to behave badly.
The good news: I restored the Macrium Reflect image backup of my C:\ drive from the day before the Windows Update, and now Thunderbird is working again!
The residual bad news: I'm no closer to finding the real problem than I was at the outset. If, when I get that Windows Update again, the problem comes back, I guess I'll have confirmation that the update triggered the problem, but I still won't know how to fix it.
As I posted, reverting to the previous build of Windows did not solve the problem, but restoring my C:\ drive to the Macrium Reflect image taken the day before the big Windows feature update to version 1709 did solve it. So I was happy for a day.
But just now I was prompted to reboot to accept a Windows Update, and doing that gave me version 1709, and now the Thunderbird problem has returned. So there's no doubt that the Windows Update to version 1709 was the cause of the problem, but I have no idea how to fix it. I can restore the Macrium Reflect image again, but I don't know how to hold off this poisonous Windows Update indefinitely other than to disable updates altogether, which isn't really a good idea. Any ideas on that? It seems that Microsoft has made it much more difficult both to find out what's in a given update, and to install them selectively.
I guess I need to report this to some Windows 10 forum, but don't know a good place - any suggestions on that?
I really am attached to Thunderbird, and I really dislike webmail interfaces. Even if I had only a single gmail account I'd greatly prefer Thunderbird to any webmail I've seen - but with the number of different accounts I have plus the way I mix-and-match IMAP and SMTP servers for each account, webmail would be intolerable.
HELP!
I somehow doubt the problem is due directly to the 1709 update, otherwise there would be numerous reports like yours. There are probably thousands, if not millions of TB users with gmail accounts running on W10 1709. You mention that your wife's computer doesn't have issues.
One possibility is that the update conflicts with another program, such as Eset, that itself has not been updated to be compatible with 1709. Or, maybe you have a network-related device driver that is not fully compatible with 1709, which shows up as a problem connecting to your accounts. Here is an example of a user who couldn't open Firefox after the 1709 update due to a conflicting adware program.
Okay, the update might conflict with another program rather than Thunderbird. But Eset seems fairly unlikely since I still saw the problem with the Eset service and its startup program disabled. So I'm still stuck trying to figure out what program it might be. I did peruse the Event log, but nothing stood out to me. I guess another approach might be to record the services (msconfig) and startups (task manager) on my wife's computer (where Tbird works), and compare them to those on mine. To do that I'll need to update mine again so that it fails. It did fail when I ran Thunderbird immediately after booting, so it's got to be a service or startup program.
One possibly interesting thing is that in the process of trying to figure out how to block the update, I came across this article on the subject. I tried its recommendation for Win10 Home, which was to change my internet connection to "metered", but found that I had no such setting for the ethernet connection, only for wireless connections. That then led me to check the exact Win10 version I was running before the update to 1709. And it turns out that instead of version 1703 (the April Creators update) as the article expected, I was actually running version 1607. Most likely my wife's computer was running 1703 when the update to 1709 arrived (her computer, which has no problem with Thunderbird, also runs the same version of Eset). Is it possible the number of Win10 Home systems updated directly to 1709 from 1607 without going through 1703 is small, and that could explain why this problem hasn't been reported before?
Obviously I'm grasping at straws with that last one, but I'm fairly desperate. To prevent getting the deadly update to 1709 forced on me unexpectedly, I unplugged my ethernet cable and am going wireless, which does have the "metered connection" setting (which appears to default to "on"). When I've got some spare cycles, I'll plug in my ethernet and update to 1609, verify that it breaks Thunderbird, and then pursue comparing the services and startups between the two computers. If I have some that she doesn't, I'll disable them all to see if that fixes it. If so, I'll do a binary search to identify exactly which one is the problem.
One more idea to try I suppose might be to uninstall and reinstall Thunderbird after upgrading to 1709. Could you point me at something describing the best way to do that without losing any messages, address books, or settings?
Thanks very much for sticking with me on this, it really helps to have someone to talk to :-)
sootsnoot said
One more idea to try I suppose might be to uninstall and reinstall Thunderbird after upgrading to 1709. Could you point me at something describing the best way to do that without losing any messages, address books, or settings?
Uninstalling TB doesn't affect your personal data, which is stored in a separate folder, the profile folder, and neither does installing a different version of TB over an existing version.
If you were to reinstall your gmail accounts, it's recommended to use OAuth2 authentication instead of normal password - not that I think that's the source of your problem.
Vybrané riešenie
Well, the problem is now solved, but unfortunately I don't really know how it happened. I had restored my pre-update Macrium backup at least three or four times, fixing the problem, then installed the "Autumn Creator Update", and that caused the problem every time.
With the Thunderbird traces not giving me a clue, I then installed Wireshark and examined its traces of traffic between my PC and an IMAP server that I only use for one account (i.e. not gmail) so I could be sure of the correspondence between my actions in Tbird and the traffic. I could see the IMAP protocol issue STARTTLS, then the TLSv1.2 hello exchange. But with the broken Thunderbird there were no significant APPLICATION DATA packets sent under TLSv1.2, while with the working Thunderbird there was a flurry of them each time I refreshed the folder subscription list. So it really just confirmed the EOF seen in the Thunderbird trace output.
Then with the Creator Update installed I tried creating a new Windows user account, and running Thunderbird there, creating a new email account accessing my primary gmail IMAP account just like the one I had been using. It worked fine, while the Thunderbird under my original Windows account still failed.
So I went back to my original Windows account, and renamed both my AppData/Roaming/Thunderbird and AppData/Local/Thunderbird folders. Then ran Thundbird and created a new email account accessing my primary gmail IMAP account, and that one worked, too.
So I resigned myself to naming the folders back, collecting screenshots of all the account settings screens, renaming folders again, and manually re-creating all 10 accounts. I actually ran into problems with my second gmail account, which had been using oauth2 authentication. When I tried to create the account, it kept failing the password. At least once a recovery email account got a message from google about rejecting a login from an insecure application, but even after changing the password through webmail, Thunderbird kept refusing to create the account with a complaint about the account name or password.
Then I remembered that I had the ImportExportTools extension, so I renamed my folders back to the originals, and exported my profile, with the intention of renaming them again and importing. But lo and behold, Thunderbird seemed to be working again, even though I had not knowingly made any changes to my profile. I even had the "Unread/Total/Size" columns back in the Folder Pane Toolbar. Couldn't see any way to get that feature in the Windows account where I started with an empty Tbird profile.
So I guess I should mark this solved, even though I really don't know what solved it. Once again I thank you for your patience in sticking with this, and apologize for not having any reusable contribution come out of this ordeal.
The moral of the story might be that when all the suggested remedies fail to help, it's often faster and more effective to create a fresh profile in TB, set up the accounts, and transfer as little of the old data from the old profile as possible.
When setting up gmail accounts, it's recommended to allow access from 'less-secure apps' from the gmail website.
That's the approach I intended to take, but setting up 10 accounts manually exactly the same way that they had been set up previously is pretty mind-numbing when you have a number of accounts (I "only" had 10). Not just filling in the forms, but it's annoying just getting the information to supply on the forms - as far as I could see, the only way to do it was to take a screenshot of each page of "View setting for this account" for each account, with 6 pages for each account (I could skip the "Return Receipts" and "Security" pages, else it would have been 8 pages for each account). And since they're screenshots, you have to type the info into the forms for the new accounts, no copy-paste.
But as I said in my long-winded description, I wound up not needing to start fresh. After abandoning my attempt to start fresh when I ran into trouble getting the password accepted, I went back to the old profile and exported it with ImportExportTools; then the old profile started working without my doing anything consciously that should have changed it. All I did was rename the folders a few times, and export.
BTW, instead of just deleting the exported profile created with ImportExportTools extension, I logged into the Windows account I had created for testing, deleted its Thunderbird profile folders, and imported the exported profile. That also seemed to work just fine. Besides retaining my "Unread/Total/Size" columns in the Folder Pane Toolbar, it also retained my RSS feeds.
When trying to start over from scratch, I couldn't create two of my feeds because they were deemed invalid (date format, self references, and an unacceptable style attribute). I suppose I might not get future updates on those feeds if Thunderbird detects those problems in new content, but at least I have the structure in place. So if I can get the feed authors to fix the problems, hopefully they'll just start working again on their own instead of becoming lingering issues to track.
Upravil(a) sootsnoot dňa