In Tools/Options/Advanced/General/Config. editor, you can try changing mailnews.tcptimeout, but the main problem is that IMAP is not suited for large-scale uploading to the mail server. Besides timeouts, you may be subject to upload bandwidth limits, as e.g. with gmail.

Thanks sfhowes.

I bumped it up from its current 100 setting to 250 and it was able to handle 5Mb emails when previously, it had trouble handling >3.5Mb emails.

You're also right about the large scale uploading point of view. Its extremely inefficient. Is there an alternate way I should get my emails onto an mail server instead?

If the reason to upload mail to the IMAP server is to make it available on other computers, it may be easier to just manually copy the mail to Local Folders on the other computers. If you don't have access to the other computers, you could save the folders as mbox files, upload them to a file storage site, then download to a computer and copy into Mail/Local Folders in the profile folder.

There are several recent comments worth reading here:

https://bugzilla.mozilla.org/show_bug.cgi?id=538375#c127

Thanks @sfhowes. I need to move email messages people have on their local machines to the mail server so they are backed up.

The recent bugzilla thread you referenced is exactly what I expect mailnews.tcptimeout to behave. It is highly dependent on what the LAN and WAN latencies are, the slowest network transfer speed between the two points of transfer and traffic. Todd probably would get better results if he tries to migrate customer data overnight during the graveyard shift when traffic is minimised.

I was curious as to what the boundaries were for the value of mailnews.tcptimeout. I see Todd bumped it up to 1000 but not sure if Thunderbird simply ignores values outside its bounds and falls back to a default.

Gene Smith created a IMAP APPEND bug associated with that thread.

He seems to be suggesting that another parameter be created called mailnews.tcptimeout_append but this is just another static timer which I feel won't resolve issues for users because every user's environment is different. i.e. The path from the user's computer where Thunderbird is running can traverse firewalls, proxies, routers, switches and other appliances before it even gets to the destination IMAP server.

What he should do is if the user attempts to transfer a message greater than 3Mb or if a number of messages are concerned, where at least one of them is greater than 3Mb, before the copy/move of large message(s), Thunderbird should test the transfer with a large message or a 1024Kbyte IMAP payload and measure the time it takes to get that across without a timeout. Once Thunderbird gets a feel for how long it might take, Thunderbird can then simply adjust mailnews.tcptimeout or mailnews.tcptimeout_append if there is a good reason to have a second parameter (I like to keep things simple).

That is an interesting approach, and while large manual uploads to IMAP servers are not too common, uploading draft messages with attachments to an IMAP Drafts folder happens frequently unless drafts are directed to Local Folders, which avoids some issues.

Gene Smith created a IMAP APPEND bug associated with that thread.

I was experiencing the same thing you were, and I found that above bug (and this subsequent bug https://bugzilla.mozilla.org/show_bug.cgi?id=1618455) extremely helpful.

If APPEND acknowledgement takes more than 20 seconds, TB will fail the transfer. It appears that even short/small emails might timeout to gmail. I had 20 kB emails taking more than 20 seconds that were in deep nested folders or multiple folders. I'm guessing gmail is doing some indexing before actually appending them in to the correct folder(s), which might take more than 20 seconds.

The annoying part is that the 20 second timeout is not editable anywhere and independent of all other timeouts, so having a separate setting might be needed.