Hilfe durchsuchen

Vorsicht vor Support-Betrug: Wir fordern Sie niemals auf, eine Telefonnummer anzurufen, eine SMS an eine Telefonnummer zu senden oder persönliche Daten preiszugeben. Bitte melden Sie verdächtige Aktivitäten über die Funktion „Missbrauch melden“.

Weitere Informationen

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

  • 7 Antworten
  • 4 haben dieses Problem
  • 5 Aufrufe
  • Letzte Antwort von 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.

Alle Antworten (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.