为提升您的使用体验,本站正在维护,部分功能暂时无法使用。如果本站文章无法解决您的问题,您想要向社区提问的话,请到 Twitter 上的 @FirefoxSupport 或 Reddit 上的 /r/firefox 提问,我们的支持社区将会很快回复您的疑问。

搜索 | 用户支持

防范以用户支持为名的诈骗。我们绝对不会要求您拨打电话或发送短信,及提供任何个人信息。请使用“举报滥用”选项报告涉及违规的行为。

详细了解

How to keep thunderbird from resetting timeouts? disable all add ons didn't work.

  • 7 个回答
  • 4 人有此问题
  • 4 次查看
  • 最后回复者为 Matt

more options

I have been receiving the message "Sending of the message failed. The message could not be sent because the connection to Outgoing server (SMTP) xxx.xxxx.com timed out. Try again." I have tracked it down to the timeouts in thunderbird. I change the timeouts from 29 to 200 and hitting send again immediately works (many times). The timeouts get automatically reset to 29 and messages can't be sent once the reset occurs. I have disabled all add-ons (per other threads) but the problem remains. I need a way to force the timeouts to not be reset.

I have been receiving the message "Sending of the message failed. The message could not be sent because the connection to Outgoing server (SMTP) xxx.xxxx.com timed out. Try again." I have tracked it down to the timeouts in thunderbird. I change the timeouts from 29 to 200 and hitting send again immediately works (many times). The timeouts get automatically reset to 29 and messages can't be sent once the reset occurs. I have disabled all add-ons (per other threads) but the problem remains. I need a way to force the timeouts to not be reset.

所有回复 (7)

more options

Where exactly are you setting it? In Config Editor?

like mail.server.server10.timeout
more options

The setting are being changed via the config editor. Based on the responses to previous threads I believe this should be the recommended approach. I'm open to other options at this point.

example: mail.server.server4.timeout;29

I have 10 servers configured and some reset from 200 back to 29 in <10 sec others take several minutes.

more options

Looking in bugzilla indicates that setting is for IMAP and if the idle time in minutes

https://bugzilla.mozilla.org/show_bug.cgi?id=341625

Have you tried tuning off your outging email scanning in your anti virus? That is the primary cause of timeout issues. Another is a busy internet connection or network, but I can not check anything on the server as you have redacted that information for some reason.

more options

Right, those server timeout values shouldn't help. If what Matt suggests doesn't help then look at http://kb.mozillazine.org/Can_not_send_large_attachments

more options

I have been testing for issues related to the virus scanner and I don't believe it is the problem. The outgoing virus scan has always been off (incoming is on) but I have been physically turning off all scanning for short periods of time. There was no impact on the failure to send messages.

While I fully understand what the intent of the timeout should be, here is what I can say. It looks like our ISP connection doesn't have a problem based on throughput and quality tests. I have multiple email accounts and only the ones associated with namecheap have the problem. Gmail, yahoo etc all work perfectly.

The namecheap staff had me run tracert to the mailserver I found that one of the nodes has a very long response time. When the timeout is increased it solves the problem until the value get reset. So I'm back to the challenge of changing the timeouts.

more options

The recommended preference is mailnews.tcptimeout, according to the kb article cited above.

Not sure if it makes a difference, but namecheap suggests two possible settings: mail.privateemail.com on port 465, SSL/TLS or port 587, STARTTLS, authentication = normal password, User name = email address.

more options

Might I suggest you take the failure of their infrastructure up with namecheap. Despite views that you get what you pay for, it sounds like they have something that they should be prepared to fix. Having a long response time indicates their system is either faulty, misconfigured or under resourced and therefore prone to failure.

However it is not clear which setting you are saying is being reset, or when.