Or, how I lost several hours of my life to a tricky and hard to diagnose networking issue.

I recently set up broadband Internet service with AT&T U-Verse. The internet appeared to be working correctly, except that I was not able to send or receive email (via IMAP and SMTP) from my work account, which is hosted by Microsoft on their office365.com platform.

I could send and receive email via IMAP/SMTP with two OTHER email providers, and if I used any other network (Brighthouse, T-Mobile, etc) the outlook 365 email would work just fine.

After calls to AT&T (Internet is working just fine, must be a problem with Office365), and my companies’ helpdesk (sorry, we don’t support Thunderbird or K-9 mail). I finally had to figure out the problem myself.

I thought that perhaps the issue was with the IP address I had from AT&T (perhaps Microsoft’s servers had blacklisted it for some reason, although I could still access the web based Office365 cloud with no problems), so I turned on my VPN software to tunnel all of my traffic through the work network (and get a new IP address).

Even with a new IP address via the VPN software, I still had the problem!
(BUT, if I used my t-mobile phone mobile hotspot, and THEN turned on the VPN, everything worked just fine). However, I was able to ping the smtp server just fine, so it wasn’t a network routing issue.

So the problem was definitely a symptom of the U-verse network. And if a tunneling VPN wasn’t fixing it, it had to be a packet problem (the tunneling VPN would get my packets out of the local network, but not change them).

The solution:
So I found the MTU (maximum transmit unit) on my modem, which defaulted to 1500 (usually a safe number) and changed it down to 1472. Problem solved: Suddenly I was able to communicate with the Microsoft IMAP servers.

I did this with the online web interface for the modem. Settings -> Broadband -> Link Configuration, changed “Upstream MTU” to 1472 (from the default of 1500).

I found that I also had to disable IPv6 on my modem to be able to send email via SMTP.

My best guess is that Microsoft may be running IPv6 inside their server farm, but tunneling it over IPv4 connections, which means that any 1500 byte packets are too big to be tunneled. (And they are not supporting packet fragmentation correctly.)

So by artificially limiting my packets to 1472 on the sending end, it allowed them to make it all the way to the SMTP/IMAP servers.

[I’d like to point out that the other two email providers I use on a regular basis did not have this issue, so it is probably something specific to the Microsoft Cloud.]

So, now I can get back to work. I pity the casual user who doesn’t have a background in computer networking…..of course, they probably all use the Outlook application, which hopefully doesn’t have this issue.