Perhaps you could try to adjust your SMTP server port settings. Outlook servers support both ports 587 (STARTTLS) and also port 465 (SSL/TLS). Sometimes one breaks after updates.

• Port 465: A legacy port for SMTPS (SMTP over SSL/TLS). While still used, it's generally recommended to use port 587 with STARTTLS for more-secure email transmission. Try this one and see if that fixes your issue for the time being.

• Port 587: Is the recommended port for secure SMTP communication (SMTP with STARTTLS) when sending emails.

I think you already know how to do this: But (on desktop) go to thunderbird-> Account Settings -> (btm right) Edit SMTP Server. Then change the port and type to match the above:(port 465, SSL/TLS, Normal Password)

Let me know if this helped!

Thanks for the idea, though unfortunately that didn't help: tried 465 + SSL/TLS and got a server did not respond/could not be reached error (same with 465 + STARTTLS, though I'd assumed that wouldn't work anyway). Switching back to 587 + STARTTLS still gives timeouts as before.

OK, Thanks for the prompt reply.

Have you tried to reboot in Troubleshoot mode to see if an add-on might be causing the issue? Always a good idea to rule this one out.

Thanks likewise - just tried that, but sadly no luck there either: I was only running one add-on in any case.

Thanks for your prompt replies James.

Please try the following if you haven't already:

1. Please try removing the add-on. Generally, Thunderbird Troubleshoot mode works but sometimes it doesn't! 2. Please try disabling all 3rd party software including anti-virus (often anti-virus blocks Thunderbird updates) as you probably know but can't hurt to try. (I know you tried disabling the firewall) 3. " work runs an Outlook/Microsoft mail server" <-- Have you tried filing a support request with your Microsoft admin? Microsoft runs a diversity :-) of email servers and can often change them unpredictably without warning which can result in SMTP i.e. sending email failing.

Cheers! ...Roland

I know this thread is a few months old, but I suddenly started getting the dreaded SMTP server timeout error today using TB143.0.1 while trying to send an email. Only one of my Gmail accounts is affected. It can still receive emails (POP3) but can't send them. My other accounts send/receive without problems. Tried loading TB in Troubleshooting mode, but the problem with this account persisted.

My accounts use these SMTP settings: Server Type: SMTP Outgoing Server Server Name: smtp.gmail.com Port: 587

I changed the port to 465 and attempted to send that email from the problem account. Gmail asked me to log in and give TB permission to access the account, which I did, and then the email could be sent.

If I changed the port to 465, why didn't any of my other accounts make me log into Gmail and give TB permission? Any ideas why 587 stopped working for that one account, but not the others?

What am I missing here? Thx!

I have stumbled into this problem when Fedora changed their standard shipped TB from 140 to 145. There are bug reports on this. The one below goes back the furthest I could find:

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

A workaround seems to be to force Thunderbird to have some network activity, like selecting another mail folder. If you are suffering from the problem reported there, you should see the "sending message ..." progress quite quickly after that.

I have downgraded to TB 140 for now. That version doesn't have the problem. Hopefully they track down the problem and fix it in a release soon. It looks like the report was already made on a beta version but wasn't recognized as something serious.

@NB - Is the problem only sending email in TB 145, or sending and receiving?

I haven't had that "SMTP server timeout" error with that one email account (all @gmail.com) since I changed its outgoing server port from 587 to 465, and I'm currently using TB 145.0.

All my other accounts still use outgoing server port 587 and never experienced the SMTP timeout problem. Don't know why only one account had a problem using 587, and don't want to change it back to using 587.

Have you tried changing the outgoing SMTP server port used by your account(s) when running TB 145?

@rohe1318 - The problem is only with sending email in TB 145 for me. All the other reports I have seen are also only related to SMTP connections -- with STARTTLS, OAuth2, and on port 587. For my setup, the STARTTLS/OAuth2 configuration is the only one supported.

From the analysis on the bug report I quoted I understand the following: TCPDump traces on the tickets seem to suggest the bug here has to do with the server requesting a certificate. TB tries to return an empty response for that (which apparently isn't a problem), but the traces show TB isn't actually sending that response: it only does so after a time-out. Apparenty, further network traffic can nudge TB out of that state; hence changing the selected folder will usually move things along. I did not run TCPDump myself, but the described behaviour is certainly compatible with what I have observed. It certainly provides a good lead for a developer to start tracing where the bug comes from, even if the subsequent investigation shows the actual cause is not quite what is hypothesized.

If you are using a server that allows for legacy authentication on port 465 then you can probably avoid the scenario above. But many institutional configurations do not allow for that because they need to lock down their access to comply with data security legislation.

TB 140 is fine, though.

@NB - All my email accounts are @gmail, and all of them are accessed using TB on same Windows desktop (Win 11 25H2, TB 145). I typically use these accounts, one right after another, to send/receive emails, in the same log-in session.

So why would only one of them have to be set to SMTP port 465 to send email, and the others don't? Order in which they're accessed doesn't make any difference. I don't use a server or router. This is my home PC and its ethernet port is hardwired to RJ45 port in the wall that connects to a 1G FiOS internet service provider. I don't use a VPN and/or log into any corporate/institutional server.

It just doesn't make sense to me.

Suggest you try using your problem account on 465, if allowed, at least until they sort this out.

BTW: Just got offered TB 146.0.1 today, so maybe give this one a try...

I don't know how STARTTLS and OAuth2 interact. Are the SMTP authentication settings of your accounts completely identical? Perhaps there are subtle difference that induce the server to request a certificate for one account but not for the other. It may be a very particular part of the handshake where TB gets stuck. If you can track down any difference between these accounts it could help them in tracking down where the problem lies. Or perhaps your problem is a different one that just happens to occur on one account (sounds improbable).

Concerning fixes: https://bugzilla.mozilla.org/show_bug.cgi?id=1993576 is reporting the problem persists in TB 146. From all the reports on this issue it does seem like a bug that has been there since 143 and didn't get accidentally solved. Until one of those bug reports indicate that a fix has been pushed, I think it'll be safe to assume the bug is still there and that it's better to stick to TB 140 (which is an esr anyway!)

It's been reported elsewhere that SSL/TLS connections through 465 are indeed not affected. But many office365 configurations only allow STARTTLS connection to 587

All the settings were originally identical and used StartTLS, OAuth2 and port 587.

The problem account was changed to use SSL/TLS, OAuth2 and port 465 to get it to send email without the timeout error. Haven't tried to set it back its original settings, like the others are still using, even now after updating to 146.0.1 today.

Only obvious difference I see between these accounts is the problem account has 8 lines of plain text in the Signature text box on its Account Settings screen in TB. None of the other options for Signature text are selected for this account (eg Use HTML, Attach from file, attach vCard, etc).

None of the other accounts have any Signature text and I don't know if sig text has anything to do with the problem, but who knows...?

Seeing the same SMTP timeout problem on V145 on Manjaro Linux.

Have tried removing all add-ons, switching to port 465. Nothing works. Typical behavior is: sending msg box is up for 30 sec to a min, then eventually the timeout error. This all going to server: smtp.office365.com

Mostly want to report that this problem is still there. And if anyone has any other work arounds be glad to try them.

@steve777 - When you changed to port 465, what security and authentication were you using, eg, SSL/TLS and OAuth2 or something else?