Major Performance Issue
Actions causing issue: 1. Select ~100 messages in a folder on an account of a particular mail provider. 2. Drag selected messages into a folder of an account of a different mail provider.
Result: Thunderbird very slowly moves the messages. It then almost grinds to a halt, regularly showing "Not Responding" and losing window border characteristics (goes white [in Dark Mode]). It indicates in the messages area that it is downloading messages from the original email account. It continues like this for HOURS. It becomes unusable. Even the simplest tasks freeze up.
In the troubleshooting info below, account3 is the original account and the destination account is account7.
Any advice, rectification greatly appreciated. Thanks.
Troubleshooting Info [Most account names made generic for privacy]
Application Basics
Name: Thunderbird Version: 115.6.0 Build ID: 20231215200246 Distribution ID:
Update Channel: release User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderbird/115.6.0 OS: Windows_NT 10.0 19045 OS Theme:
Launcher Process: Enabled
Multiprocess Windows: 0/0
Fission Windows: 0/0
Enabled by default
Remote Processes: 1
Enterprise Policies: Inactive
Google Location Service Key: Missing
Google Safebrowsing Key: Missing
Mozilla Location Service Key: Missing
Safe Mode: false
Memory Size (RAM): 31.9 GB
Disk Space Available: 31.4 GB
Mail and News Accounts
account1:
INCOMING: account1, , (imap) mail.Provider1.com:993, 3, passwordCleartext
OUTGOING: , mail.Provider1.com:465, 3, passwordCleartext, true
account2:
INCOMING: account2, , (none) Local Folders, 0, passwordCleartext
account3:
INCOMING: account3, , (imap) mail.Provider1.com:993, 3, passwordCleartext
OUTGOING: , mail.Provider1.com:465, 3, passwordCleartext, true
account4:
INCOMING: account4, , (imap) mail.Provider1.com:993, 3, passwordCleartext
OUTGOING: , mail.Provider1.com:465, 3, passwordCleartext, true
account5:
INCOMING: account5, , (imap) mail.Provider1.com:993, 3, passwordCleartext
OUTGOING: , mail.Provider1.com:465, 3, passwordCleartext, true
account7:
INCOMING: account7, , (imap) mail.Provider2.com:143, 2, passwordCleartext
OUTGOING: , mail.Provider2.com:587, 2, passwordCleartext, true
account8:
INCOMING: account8, , (imap) mail.Provider2.com:143, 2, passwordCleartext
OUTGOING: , mail.Provider2.com:587, 2, passwordCleartext, true
account9:
INCOMING: account9, , (imap) mail.Provider3.com:143, 2, passwordCleartext
OUTGOING: , mail.Provider3.com:587, 2, passwordCleartext, true
OUTGOING: , mail.Provider3.com:587, 2, passwordCleartext, false
account10:
INCOMING: account10, , (imap) imap.gmail.com:993, 3, OAuth2
OUTGOING: , smtp.gmail.com:465, 3, OAuth2, true
account11:
INCOMING: account11, , (imap) outlook.office365.com:993, 3, OAuth2
OUTGOING: , smtp.office365.com:587, 2, OAuth2, true
account12:
INCOMING: account12, , (imap) outlook.office365.com:993, 3, OAuth2
OUTGOING: , smtp.office365.com:587, 2, OAuth2, true
account13:
INCOMING: account13, , (imap) outlook.office365.com:993, 3, OAuth2
OUTGOING: , smtp.office365.com:587, 2, OAuth2, true
account14:
INCOMING: account14, , (imap) mail.Provider4.com:993, 3, passwordCleartext
OUTGOING: , mail.Provider4.com:465, 3, passwordCleartext, true
account15:
INCOMING: account15, , (imap) mail.Provider1.com:993, 3, passwordCleartext
OUTGOING: , mail.Provider1.com:465, 3, passwordCleartext, true
Libraries
Library
Status
Expected minimum version
Version in use
Path
RNP (OpenPGP)
OK
0.17.0
0.17.0+PR2073.MZLA.115.6.0
C:\Program Files\Mozilla Thunderbird\rnp.dll
Crash Reports for the Last 3 Days
Remote Processes
Type: Count
GPU: 1
Security Software
Type: Name
Antivirus: Microsoft Defender Antivirus
Antispyware:
Firewall: Windows Firewall
Library Versions
Expected minimum version
Version in use
NSPR
4.35
4.35
NSS
3.90.1
3.90.1
NSSSMIME
3.90.1
3.90.1
NSSSSL
3.90.1
3.90.1
NSSUTIL
3.90.1
3.90.1
Όλες οι απαντήσεις (5)
This is the part that most folk to not appear to get. IMAP is not a file system and moving more than a few mails between accounts is almost always going to fail in some way. You are lucky, it just goes slow. Most people end up with lost mail, corrupt mail or just unexplained connection dropouts because their mail server is busy in the background with other things don't work like getting new mail.
The process itself is top heavy with each mail to be moved checked with the server to ensure it is the latest copy. This is slow enough, but most folk then have an antivirus program scanning each and every one of those downloads to make sure it has not virus.
Then the process is repeated to upload the same mail and it is again scanned to make sure things go slowly.
Additionally recent releases of Thunderbird have gone from asking for the 100 selected mails to be processed in a single trip to asking for each being processed to completion individually as far to much mail was being lost in the bulk updates with quiet but fatal timeouts and cache failures etc, individual errors were oft times just not reported. So Thunderbird is now more exact and more reliable, but also slower in performing the action. This is not really considered a big deal as moving more that a couple of emails from account to account is also a fairly rare event, except for those trying to update an account from one provider to another without using server side tools. Those folk are also rarely long term users, often downloading the application transferring their mail and then removing it.
Thanks for your response. Actually, I'm very familiar with IMAP. I've also used a variety of email clients. Outlook, for example, moves dozens of messages between accounts without issue, and in a reasonable timeframe. Regardless of the specific comparison, to say that the occurrence of this action is not common and to discount the essentially crippling behaviour of Thunderbird for this activity does not serve the Thunderbird cause well. If other clients can do this reasonably well, so should Thunderbird. As a Software Engineer, I understand how such things may be challenging, but they are solvable if one is inclined to take the problem seriously and be thorough in analysis and resolution with performance a key component of the solution. I urge the Thunderbird developers to address this specifically and make it as efficient as it can be. Thanks.
I suggest you take the discussion to Bugzilla, I am just pleased the change stopped folk loosing significant amount of mail. Personally I simply do not use IMAP to any extent. I use POP for all mail that I consider valuable enough to backup.
I have not interest in how Outlook performs as the source is closed and so are the bug lists. Microsoft may well have the cavalier attitude Thunderbird had, you just loose some mail after the first thousand or so. Tough.
Have look at these bugs and those they block and are dependant on to get some idea of the curent state of play. https://bugzilla.mozilla.org/show_bug.cgi?id=1828372 and https://bugzilla.mozilla.org/show_bug.cgi?id=538375
You might even want to file your own bug. As a developer you will be aware you need exacting detail so a developer can reproduce the issue an therefore test a fix.
Thanks. I appreciate the constructive comments.
Does this affect a specific mail provider? If so, which one?