Microsoft 365 SMTP server intermittently rejecting connections
I've been running Tbird on Windows for many years. About 2 weeks ago something changed, either in Tbird or at Microsoft, which stops me from sending to the Office 365 SMTP server. I can send and receive using Outlook on the Office website, but I can't send locally from Tbird. Error message screenshot herewith. I have tried every possible permutation of server settings, which currently are:
Server name: smtp.office365.com Port: 587 Security: START/TLS Authentication: OAuth2
MS support says these are correct, and they are at wits' end to understand what is going on. They asked me to ask Tbird support, so I am.
I should add that at about the same time I started getting SMTP rejections in Gmail on my Android phone, and miraculously that was corrected yesterday, without any action from me. There is something odd going on at Microsoft - does anyone know what it is? My other accounts on Tbird work fine of course.
Modified by Wayne Mery
Chosen solution
You could report that to your VPN support service, maybe they could find a way to configure their software bypassing feature better.
Be aware that these routes assume that the whole ranges (2 x 65535 IP addresses) are belonging to Microsoft. I have not checked if it's true, if not the rules may route other sites outside of the VPN.
The best solution would be to allow connection to MS servers through the VPN, but that's another problem.
But if you are stuck with this solution, and your VPN has a way to be started from the command line, it could be possible to write 2 scripts to start and stop the VPN, creating and destroying the routes automatically.
Read this answer in context 👍 0All Replies (20)
Duh ! It's just a plain connection error all right. No OAuth2 or password apply, it's failing earlier.
Are your other accounts (the working ones) also connecting to port 587 for sending email ? How are you connecting to the Internet ? Do you have a firewall (hardware) or software (installed on your computer) ?
Usually on Windows computers when I am in doubt about mail software (well, Outlook usually) able to connect or not, I install Telnet (that's a integrated Windows feature, not installed by default, but you can add it with Windows features in the control panel), I open a terminal window to test if connecting succeeds, in this case that would be
telnet smtp.office365.com 587
if you get something like 220 PR2PR09CA0002.outlook.office365.com Microsoft ESMTP MAIL Service ready ...
connection is working (just enter QUIT and enter to exit connection with the mail server)
if it displays
connecting to smtp.outlook.com...
and hangs there to fails after one minute or two, there is something blocking the connection. This test is just to confirm that Thunderbird is not the problem and that it's a network problem.
My personal account on Gmail uses port 465, which was automatically set by Thunderbird. I am not running a hardware firewall, just normal Norton security and the usual Windows 11 stuff. I also run a VPN, Surfshark, but turning this off does not help. My ISP is BT Internet, on a wired Ethernet connection to their cable network.
Telnet says:
Connecting To smtp.office365.com...Could not open connection to the host, on port 587: Connect failed
Sorry, I started a new thread on much the same topic which I should not have done, and you have replied to the old one.
lesrose1959 said
My personal account on Gmail uses port 465, which was automatically set by Thunderbird. I am not running a hardware firewall, just normal Norton security and the usual Windows 11 stuff. I also run a VPN, Surfshark, but turning this off does not help. My ISP is BT Internet, on a wired Ethernet connection to their cable network. Telnet says: Connecting To smtp.office365.com...Could not open connection to the host, on port 587: Connect failed Sorry, I started a new thread on much the same topic which I should not have done, and you have replied to the old one.
I'll still reply here. Connect failed is not normal. Can you try
telnet smtp.gmail.com 465
Note that even if it succeeds, it will just display a black screen and hitting enter will return you to the prompt. That's because it is doing TLS right away, so the mail server prompt is not displayed, and hitting enter aborts the dialog. Nonetheless, the black screen shows that *connecting* works.
If you get a 'connecting to smtp.gmail.com...' and connect failed after one minute or so, you have the same behaviour than with the Microsoft server - but this should NOT happen, since Thunderbird succeeds in sending mail with Gmail. But trying it is just for confirmation.
So it seems that the problem is not with Thunderbird, but with your system since for me, telnet smtp.office365.com works fine. Using telnet is testing the first step that Thunderbird is doing.
The main suspect is the firewall for me. Can you start your system in troubleshooting mode (with network) and do the telnet test ?
I am in safe mode now, and just tried telnet again, which said:
220 LO4P123CA0172.outlook.office365.com Microsoft ESMTP MAIL Service ready at Thu, 17 Nov 2022 12:00:05 +0000
It eventually timed out.
So in short: when you have problems, testing connection with outlook.com with Telnet FAILS in windows normal mode, but SUCCEEDS in safe mode. So something Windowsy looks the real problem, but why the firewall would block access only intermittently is very enigmatic. Do you use an additional security product on top of Windows Defender ? Do you use a VPN ? Anyway, it does not hurt to look at the Windows Firewall settings. Go to the firewall advanced settings and create a outbound rule, specify the port 587 and on the next screen click on 'Allow' (block is the default action). Give it any name, for example 'Thunderbird'. Then try again with Telnet in normal mode, if it succeeds it should unblock Thunderbird.
As I said before, I do use a VPN, Surfshark, but turning this off made no difference. I also have Norton security. I have created the Windows firewall rule, and after that Telnet said it could not connect to 587. I then created a bypass for Thunderbird in Surfshark and still could not connect. But when I turn off Surfshark completely I can connect.
So far the situation is:
1. Without the firewall outbound rule, and the VPN turned off, I can't connect. 2. With the firewall outbound rule, and the VPN turned on, I can't connect. 3. With the firewall outbound rule, and the VPN turned on, but with Thunderbird bypassed, I can't connect. 4. With the firewall outbound rule, and the VPN turned off, I can connect.
So I can only connect using the firewall outbound rule and no VPN. Basically because of something specific to Thunderbird I can't use the VPN.
Well, this is more like it, no more mystery, the VPN has struck again. There is an article on your VPN provider web site titled 'Why am I unable to send emails while connected to Surfshark?' showing that this is a known problem. Unfortunately the solution is to use port 465, and it will not work with Microsoft servers (smtp.office365.com only allow port 587 for secured mail send)
I see what you call bypassing on the Vpn website, it's not very logical that Thunderbird can connect with the additionnal rule and VPN turned off, while it can't connect with the VPN turned on, and you instructed it to not route Thunderbird through the VPN. Unless the VPN works by copying first the existing firewall rules, adding its own mix of rules, and enforces them while running, replacing the whole existing bunch. In this case, a rule that you add *after* installing the VPN would not be taken in account while running the VPN.
If this is the case, I think that asking the question to your VPN support could be of interest. If they have a trick to solve the problem, thanks for reporting it here, it may help other people.
I have indeed already reported all this to VPN support and await a reply, which I will certainly post here. I am still puzzled as to why I can't connect with the VPN turned off.
lesrose1959 said
I am still puzzled as to why I can't connect with the VPN turned off.
Huh ? then why did you say in your previous post:
>> 4. With the firewall outbound rule, and the VPN turned off, I can connect.
What I mean is, I can only connect with the firewall outbound rule. I never needed that before I installed the VPN.
I got a reply from Surfshark support, which is not very clear. They seem to be telling me to change the port to 465 or 2525. Neither of those of course works
These support guys are really a great help these days, of course it will not work as the mail server only allows port 587. Reading the Internet about your product, it seems a favoured trick is to reset the network in the Vpn settings and restart the computer. You could as well give it a try, maybe it will allow the Vpn to take in account the added firewall rule. If not try to create a bypass for the mail server smtp.office365.com.
VPN support suggested changing protocol to OpenVPN. Didn't work. I also tried bypassing smtp.office365.com. Didn't work either.
OpenVPN ? I know this stuff a bit. Could you give a try to look at the way the bypass work.
When not connected to the VPN, do a
tracert smtp.office365.com
should report a dozen of lines or so describing the way the query is going to the server.
and now do the same connected to the VPN.
if the bypass works, the result should be similar or even identical.
If you feel that posting the result is too intrusive on your privacy, although normally it should not include your IP address, do whatever you need but report if the result look to have routed the result in the same or similar way. If it's different do the result when connected seems to go through your VPN or not ?
With VPN off:
Tracing route to LHR-efz.ms-acdc.office.com [52.97.219.226] over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.254 2 3 ms 2 ms 3 ms 172.16.14.115 3 * * * Request timed out. 4 5 ms 4 ms 4 ms 62.172.102.76 5 5 ms 5 ms 7 ms peer2-et0-0-7.slough.ukcore.bt.net [62.172.102.5] 6 * * * Request timed out. 7 47 ms 19 ms 7 ms ae22-0.icr02.lon24.ntwk.msn.net [104.44.238.211] 8 * * * Request timed out. 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 4 ms 6 ms 4 ms 52.97.219.226
Trace complete.
With VPN on:
Tracing route to LHR-efz.ms-acdc.office.com [40.99.205.114] over a maximum of 30 hops:
1 * * * Request timed out. 2 4 ms 4 ms 4 ms 172.20.21.254 3 4 ms 5 ms 4 ms 172.20.22.3 4 * * * Request timed out. 5 5 ms 4 ms 5 ms cs0-cr.ldn.as25369.net [89.34.96.1] 6 54 ms 5 ms 7 ms ae1.rt0-hex.ldn.as25369.net [5.226.136.11] 7 4 ms 5 ms 5 ms 195.66.224.112 8 7 ms 7 ms 6 ms ae22-0.icr02.lon22.ntwk.msn.net [104.44.238.215] 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. 14 82 ms 6 ms 23 ms 40.99.205.114
Trace complete.
It seems crystal clear that the VPN bypass does NOT work. When the VPN is off, you get an adress like 192.168.1.254, that seems very much like an internet router box address. Then after that, 2 public addresses belonging to a UK ISP. When the VPN is on, no such thing.
So 2 ways of solving the problem are:
- making the bypass work. It may be a route problem. Normally your VPN does not make your normal Internet connexion magically disappear, it just routes all traffic through its special software created interface. If it's possible to make the route be correct, it could solve the problem even if it's a hack.
Try to report when the VPN is ON:
route print
While I'm thinking about it, a possibility could be that your VPN is adding a route to an IP address when you are creating a bypass, but as MS has *many* servers with *tons* of IP addresses, the specific route created when you are asking a bypass is of no use 10 seconds later when you are trying to connect, since the reported address for the name will be different. This would be actually a software limitation for your VPN, it would need to actually allow to add a IP range for a bypass, such as 52.97.0.0/16 *and* 40.99.0.0/16 instead of a single IP address (that is, allowing about 130000 IP addresses)
- making the mail trafic work actually through the VPN. A nasty possibility could be that the MS servers are detecting that the originating address is a VPN and block it. It is not likely since normally the behaviour is to allow connecting, then more or less politely answer that one do not want to talk further. But if this is the case, no software configuration will do anything (except maybe trying another VPN server that MS has still not blocked). On the other hand, I don't see why your VPN should block access to port 587, it is making even less sense. To test that, you could try to test port 587 with Telnet with a non MS server, such as:
telnet smtp.gmail.com 587 if it connects (that is, display something like 220 smtp.gmail.com ESMTP .....) with the VPN ON, it means that it is MS that is blocking the VPN.
Here is what I get from root print with VPN on:
IPv4 Route Table
===============================================================
Active Routes: Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.254 192.168.1.189 25
0.0.0.0 128.0.0.0 10.10.10.1 10.10.10.8 3
10.10.10.0 255.255.255.0 On-link 10.10.10.8 259
10.10.10.8 255.255.255.255 On-link 10.10.10.8 259
10.10.10.255 255.255.255.255 On-link 10.10.10.8 259
40.99.150.130 255.255.255.255 192.168.1.254 192.168.1.189 25
40.99.150.178 255.255.255.255 192.168.1.254 192.168.1.189 25
40.99.205.98 255.255.255.255 192.168.1.254 192.168.1.189 25
40.100.174.226 255.255.255.255 192.168.1.254 192.168.1.189 25
52.97.211.130 255.255.255.255 192.168.1.254 192.168.1.189 25
52.97.212.66 255.255.255.255 192.168.1.254 192.168.1.189 25
52.98.207.2 255.255.255.255 192.168.1.254 192.168.1.189 25
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
128.0.0.0 128.0.0.0 10.10.10.1 10.10.10.8 3
138.199.29.187 255.255.255.255 192.168.1.254 192.168.1.189 25
192.168.1.0 255.255.255.0 On-link 192.168.1.189 281
192.168.1.189 255.255.255.255 On-link 192.168.1.189 281
192.168.1.255 255.255.255.255 On-link 192.168.1.189 281
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.1.189 281
224.0.0.0 240.0.0.0 On-link 10.10.10.8 259
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.1.189 281
255.255.255.255 255.255.255.255 On-link 10.10.10.8 259
===============================================================
Persistent Routes:
None
IPv6 Route Table
===============================================================
Active Routes:
If Metric Network Destination Gateway 1 331 ::1/128 On-link 1 331 ff00::/8 On-link
===============================================================
Persistent Routes:
None
I can't connect to Gmail SMTP on 587, my account is on 465 which works with VPN on. Well I just get a blank screen and no error message so I suppose that means it works. Surfshark support is now telling me to set a custom DNS. I get the impression they're firing a shotgun in the hope of hitting something.
You see this route to 40.99.150.130 ? it's ONE of the many MS mail servers. That's it, when you are creating a bypass for the symbolic name of the MS mail service (I won't type it in the probably vain hope that this forum will not yet delay the appearance of my message by several hours...), your VPN is creating ONE route to the MS server pool. When you are actually trying to connect, the address pool will allocate you another server that will try to go through the VPN, having no specific route, and then will be blocked. So... creating 2 routes to actually bypass the VPN for the whole MS pool server can be achieved by typing something like:
route add 40.99.0.0 mask 255.255.0.0 192.168.1.254 metric 25 route add 52.97.0.0 mask 255.255.0.0 192.168.1.254 metric 25
I hope that the fact that the route add instruction don't include an interface will not make it fail. Theoretically route should pick the 'right' interface automatically. Unfortunately, I can't guess remotely the right interface number.
Do that when connected to the VPN, then try to make Thunderbird do its thing. Note that these routes are not perfect and may have side effects, but as they are not permanent, any side effect will be canceled by restarting your computer. It's just for validating the idea. If you need to delete them replace 'add' by 'delete'.
As of the custom DNS, I can't have an opinion about that. If it's the failure of the bypass, my best guess is above, that is, it's a limitation of the VPN software, so I think it will do nothing. If it's the blocking of the connection to MS servers through the VPN, I have no idea so it's not impossible they are right.
I have tried changing the DNS as per the VPN support advice, and it has made no difference.
I then tried adding the routes, but it appears I don't have permission to do that. The operation requires elevation. There is only one account on this PC, which I thought was an admin account. I will have to check.
Yes my account is of course admin. Forgive my ignorance, but is there another privilege I should have?