We all love the odd debugging story, so I finally sat down and wrote up how I debugged a configuration issue that got in the way of the iOS mail app’s ability to retrieve email while I was on the go.

tl;dr – iOS Mail uses IPV6 to access you email server when the server supports IPV6 and doesn’t fall back to IPV4 if the IPV6 connection attempt fails. If if fails, you don’t get an error, but you don’t get any email either.

The long story of why I sporadically couldn’t access my email from the iOS 10 Mail app

Somewhere around the time of upgrading my iPhone 6 to iOS 10 or even iOS 10.2, I lost the ability to check my email using the built-in iOS Mail app over an LTE connection. I am not really able to nail down the exact point in time was because I used Spark for a little while on my phone. Spark is a very good email app and I like it a lot, but it turned out that I’m not that much of an email power user on the go. I didn’t really need Spark as Apple had added the main reason for my Spark usage to the built-in Mail app. In case you’re wondering, it’s the heuristics determining which folder you want to move an email to that allow both Spark and now Mail to suggest a usually correct destination folder when you want to move the message.

Long story short, after switching back to the built-in Mail app, I noticed I that somehow I had lost the ability to retrieve email when the phone was connected to the Internet via LTE. Retrieval over WiFi still worked fine most of the time. Unfortunately iOS Mail does not give you any useful error information that allow you to figure out what’s wrong – all I could see was that Mail went from ‘Connecting’ with network access to ‘Last updated <whenever I left a working WiFi network>’. No errors, no hints as to what went wrong. Initially it wasn’t a big deal. Well, until I changed jobs. Now I’m on the road pretty much every week and having access to my personal email while I’m somewhere with no WiFi access would be, kinda, you know, nice?

So, no email access while travelling, outside WiFi hotspots. Then, I started having trouble getting email while I was using WiFi, but only occasionally. At that point and as a fallback, I installed Boxer on the Android phone I use for work. That worked fine until one day it stopped working, too, with the same symptoms.

Clearly, Something Needed To Be Done.

So I started digging. The first clue was that neither phone’s connection attempts to my IMAP server showed up in the mail server logs when I tried to connect via LTE, but they did show up as expected when I connected via my home WiFi. Of course the phones were able to send and receive email via my home WiFi, but not via LTE. Hmmm.

Checked Spark and the connection does show up, LTE or WiFi. Remember, that connection goes via Readdle’s servers, not directly from my phone to my email server.

Next step, I checked the firewall logs. Nothing in there other than – hang on a minute, why am I seeing IPV6 ICMP messages being dropped? For those not overly familiar with IPV6, the IPV6 ICMP messages not only carry useful packets like echoreq (the packet type used by ping/ping6) but also even more useful information like router advertising and neighbour solicitations and announcements, the latter two being the IPV6 equivalent of ARP.

At this point a very small and dim light bulb started coming on. Surely they wouldn’t…

Well, surely they did.

My PVS has an IPV6 address in addition to a normal IPV4 address. I also made sure that I put an AAAA record into DNS so the IPV6 address would resolve correctly. At some point after adding the AAAA record, the Sysadmin In Charge (aka me) forgot to update the firewall rules to allow IPV6 access to both this blog and the email infrastructure. Oops. That wasn’t a visible issue until the email clients I was using either started using IPV6 or at least stopped falling back to IPV4 connectivity in case the IPV6 connection timed out. After all, I knew that T-Mobile US (my mobile phone provider) had been happily handing out IPV6 addresses to phones for quite a while, which actually was the original reason for making sure my server was accessible via IPV6.

After making sure that the IMAP server was listening on both IPV4 and IPV6 and very carefully updating the firewall rules to also allow IPV6 traffic through including the filtered ICMP messages, iOS 10 Mail is now happily pulling down emails from the server again and even appears to be a little faster connecting. And as an additional bonus, you can now connect to this blog using IPV6, too!