June 23rd, 2012 • 2:31 pm
Sometimes the sheer stupidity of how Mail handles (or rather cannot handle) network failures just boggles my mind. A couple of days ago I heard that people using one particular ISP in our area (the cable company Eastlink) were experiencing a general system failure and did not have any Internet access for several hours.
Then yesterday one of my regulars called me to tell me that, yes, he was with Eastlink, and he knew about the system failure, but the network was now back up and he was able to browse the web and receive e-mail. However, he was unable to send any e-mail.
I first asked him if he had changed any settings during the outage in order to try and get back on-line and he assured me that he had not. I asked him what the exact error message was and he read it to me over the phone: Mail was essentially telling him that the Eastlink SMTP server was rejecting his user id. Of course, his user id was perfectly correct. He hadn’t changed any settings and, in any case, the Eastlink SMTP server was an exclusive server for Eastlink customers that did not require any authentication.
I made him review the SMTP server settings and there was absolutely nothing wrong with them. He told me he had already tried all the usual things: quitting and relaunching Mail; rebooting the entire machine; power-cycling the cable modem; and so on. Nothing appeared to help.
Finally, I used iChat’s screen sharing feature to take over his machine and I did what has unfortunately become a “normal” troubleshooting step for me with Mail: I deleted the SMTP server altogether in Mail’s preferences, and then I recreated it from scratch, using the exact same settings, i.e. the server address and pretty much nothing else.
And guess what? It worked. Even though the settings I used were exactly the same as the ones that the existing SMTP server defined in Mail’s preferences was using, now the settings were working and the Eastlink SMTP server was no longer rejecting my client’s attempts to send mail.
What on earth how we supposed to deduct from this? I think the answer is quite obvious: Apparently, Apple’s engineers have never heard of network failures, and Mail is simply not equipped to handle them gracefully. In Apple’s world, our ISP’s service is always perfect, there are never any disruptions, and sending mail works smoothly all the time.
Of course, in the real world, network failures do happen, and when they do and software applications like Mail and Safari start behaving in inexplicable ways, good luck finding your way out of the mess if you’re not an experienced troubleshooter.
I have written about issues with outgoing mail in Mac OS X in the past. If you tend to travel and switch providers on a regular basis, sending out mail with e-mail accounts that are not managed by Apple itself (i.e. that are not @mac.com or @me.com accounts) can be a real pain. Many people are resigned to using a web-based e-mail solution (their provider’s webmail system or a free web-based e-mail service like Gmail) simply because of the numerous issues with outgoing mail when they are on the road and don’t have time trying to figure out how to adjust their settings to make things work in Mail.
But in this case we are not even talking about travelling. We are talking about a network failure with the user’s regular ISP, at home. He didn’t change any settings when the network was down, and when the network came back up his existing settings refused to work properly again. Deleting them and re-entering them fixed the problem. Why? The settings were exactly the same. What kind of hidden crap was there in Mail that caused it to fail to send mail and was somehow flushed out of the system by deleting the SMTP server settings and re-entering them?
It’s all too painful for words. Even when there isn’t an outright network failure, I too still experience problems with my own ISP on occasion. Sometimes, all of a sudden, the SMTP server I normally use has a problem. The process of sending mail remains stuck at some undefined stage, as illustrated by the progress bar in Activity Viewer, which is full but refuses to go away so that Mail can play the “whoosh” sound that confirms that the e-mail was sent. It remains stuck for five, ten minutes and I have no choice but to finally click on the STOP button to interrupt the process.
Fortunately, I know my way around, and I know how to use a different SMTP server if needed. Usually I manage to find one that works, and then when I go back to the one I normally use a few hours later, it works properly again.
What really happens in such cases? Who knows? As I said, Apple’s engineers don’t seem to have ever put any effort into designing Mail so that it handles network failures or occasional glitches gracefully, so there is no hope in trying to figure out what is really going on. And there is also no point in even trying to report the issue to Apple, since bug reports have to fit into a very clearly defined mould with a 100% reproducible scenario. How do you reproduce an ISP’s network failure or glitch reliably? It’s impossible.
The only solution to this problem is to have Apple engineers using their own software in real-world situations themselves and taking an interest in improving Mail so that it handles these real-world situations better. There is little sign that this type of approach has ever being a priority for anyone at Apple.