1761008 - Default mailnews.tcptimeout value, 100, is too short for saving large message to imap Sent folder

Status: UNCONFIRMED

(Thunderbird :: Preferences, defect)

Description

[snowboard975]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

System info: Thunderbird version 91.7.0 (64-bit) on Windows 10. Internet connection of the place where this experiment was done: 1 Gbps

I tried sending an email with attachments of 10 MB. The email was sent normally, the receipient received the email normally, and its copy was also saved in my sent folder correctly. However, I still encoutered with an error message, "Your message was sent but a copy was not placed in your folder (Sent) due to network or file access errors. You can retry or save the message locally to Local folders/[e-mail].", and "Connection to server xxxx.xxxxxx.com timed out."

I entered the Configuration editor through Menu > Preferences > General > Config Editor. I searched for the variable, mailnews.tcptimeout. Its value was 100 by default. I increased it 1000.

I closed the Thunderbird program completely, and opened it again.

And then I tried to send the same email with the same attachments, and the email was sent, received, and saved in my Sent folder normally as before, and there was no more aforementioned error any more.

Actual results:

When mailnews.tcptimeout = 100 : two error messages of "Your message was sent but a copy was not placed in your folder (Sent) due to network or file access errors. You can retry or save the message locally to Local folders/[e-mail].", and "Connection to server xxxx.xxxxxx.com timed out." appeared although the email was sent, received, and copied to Sent folder correctly.

When mailnews.tcptimeout = 1000 : no error message was appeared and the email was sent, received, and copied to Sent folder correctly.

Expected results:

The error messages of "Your message was sent but a copy was not placed in your folder (Sent) due to network or file access errors. You can retry or save the message locally to Local folders/[e-mail].", and "Connection to server xxxx.xxxxxx.com timed out." should not disappear when sending an email with large attachments.

Comment 1

[snowboard975]

Correction of typos :

• "I increased it 1000" -> "I increased it to 1000" in Steps to reproduce
• "should not disappear" -> "should not appear" in Expected results

Comment 2

[snowboard975]

In my test, the email server that I used is serviced by a web-hosting company. It took about 70 seconds to send the email with attachments of 10 MB.

Comment 3

[snowboard975]

There is a related article at https://support.mozilla.org/mg/questions/1366121

In this article, david, wrote on 2022-01-28 08:27, "Just a possibility (as I also sometimes receive this message), there is a setting in config that may assist: mailnews.tcptimeout click tools>preferences>general and open config editor and increase the default setting of 100 to something higher, such as 250. That affects the server timeout setting."

This article also shows that this problem affects not only me but also other users.

Comment 4

[Matt]

I do not see the link between the TCP/IP timeout value and the failure to update the server with the sent mail. Waiting 100 seconds for a timeout failure is bad enough as it is. Sitting looking at the screen for almost 2 minutes while nothing happens. Your suggestion is make that longer!

I would think fixing the issues raised here might be more important bug 538375 comment 127

Then finding ways to make the transaction faster, starting with the ubiquitous sent mail virus scan which loads another delay on something that clearly can not be infected. These frequently are the cause of the issue, because they are slow and a very inefficient use of resources.

Also, the bandwidth of the connection is not all that important. The shaping of that bandwidth and the latency of it are. A 1Gb connections could be shaped at the router to a very small percentage of that. Or the utilisation of the bandwidth could be approaching saturation.

Comment 5

[Wayne Mery (:wsmwk)]

This article also shows that this problem affects not only me but also other users.

Not all issues that have the same symptoms have the same cause.