Summary: As a contractor, I spend a lot of time dealing with email. One of the recurring conversations I have with my clients is the reliability of email and why it should not be used for time critical stuff.

I recently wrote about the fact that email is insecure and pontificated about some of the reasons why it still pays to use SSL or TLS when connecting to an email server despite the fact that the email itself will still be sent in the clear. Evidently, email is on my mind these days and that’s probably because the number of conversations I seem to be having with people about disappearing email is growing.

I’m not sure when this happened, exactly, but somewhere along the line the general population seems to have made up their mind that email is a reliable means of communication. I think that most of us involved in servers at almost any level find that idea kind of silly. Sure, our email servers are reliable, but let’s face it, a great many email servers are misconfigured, unconfigured, broken, neglected, or run by incompetents. When someone calls me up and tells me an email went missing, my response is generally “And why do you find that surprising?”

The only things that I have control over are:

1. The behaviour of my own email server
2. The configuration of DNS records that I host

Sadly, there are about 50 other things that have to align for an email to be delivered successfully, and no one person controls everything from end to end. Unless, of course,  you’re in the incredibly lucky situation where the person you’re talking to uses your mail server and is sending to someone else that uses your mail server – but that never happens because your mail server is so well configured, right?

Let’s look at a little bit of the travel from one of my clients who uses my server for their outgoing email.

1. The write their email on their email client and click send
2. Their email client connects to my server and gives it their email
3. My email server accepts it graciously because it is soooo good lookin’
4. My email server does some DNS stuff to figure out where to send this email and then attempts to connect to the receiving mail server. This is where all hell can break loose
5. The receiving mail server may not like my email server and may refuse to accept email from it. The reasons why it may not like my email server range from:

• My server’s IP being on a blacklist (which is a horribly, horribly inefficient and draconian method of spam control only used by incompetents),
• Maybe it doesn’t like my HELO
• Maybe my client doesn’t know enough to set up rDNS records and the remote server refuses email from domains without rDNS records
• Maybe the remote server is set to do callbacks which is only marginally less incompetent than black lists
• Maybe my client doesn’t know enough to set up SPF records for his or her domain (and doesn’t let me host their DNS) and the remote server refuses email from domains without SPF records despite soft-fail being the RFC default
• Perhaps the remote server is having its own problems and just plain old isn’t receiving email from anyone right now.
• It might not even be the right server as my user may have typo’d the domain part of the address but the remote server may not be configured to refuse email not destined for it and blackhole it instead.

The

amount of things that can go wrong at this point ranges in the tens if not the hundreds of potentials.

Let’s assume that the email is accepted and the user it is destined for actually exists on the receiving server. Now that poor email has to run the gauntlet inside the machine to get delivered. Along the way it may encounter:

1. Any number of anti spam daemons. Some are good, some are bad. Even the good ones can be misconfigured or too-aggresively configured by the sysadmin and trounce good email
2. Boxtrappers. These are white-list email systems whereby the end user decides that s/he only wants to receive email from people in his or her address book and everyone else is relegated to a trap that the user may or may not check now and again
3. Procmail or other filtering processes. Many email hosts offer ‘rules’ for their users to configure to automatically sift incoming email and move it around or delete it before being delivered. This is a great feature, but on a great many systems the interface is not intuitive and I have spent many an hour sifting through some of my more intrepid user’s recipes to find their email filed where they didn’t want it or deleted outright.
4. The email client. Even if the email makes it into the users inbox where it belongs, it now has to make it past the recipient’s email client. Many email clients these days automatically look for spam and junk as email comes in so even though the email has probably already been scanned on the server, it now gets scanned again by a totally different application with a totally different set of rules and no communication with the first set of scanners.

That’s one potential journey of an email and some of the pitfalls that literally came off the top of my head and I haven’t even touched on hardware failure issues in the massive distance between sender and recipient in some cases.

So really, the surprise is not when an email goes missing. The surprise, in my opinion, is when an email actually gets to where it is going.

Back when I ran the “Buck a Gig” Hosting Puppy web service, I had a customer who freaked out on me because some email pertaining to her mortgage went missing and she had to pay late penalties because of it. To this day I cannot understand why someone would be so naive to rely on email for something of such great import. Never mind relying on their email from the $1 a month hosting service (hey, we tried, but a buck only goes so far, you know?).

I receive somewhere in the neighbourhood of 200 emails per day and another 100 or so end up in my junk folder with another handful getting trounced as too spammy at the server. It’s fair to say that I live on email. And still, even I would never trust email for something really important. It’s just not reliable enough and as long as humans are misconfiguring things, it never will be.

Related articles by Zemanta

• 12 Ways to Reduce Spam Complaints
• Make Sure Your Emails Aren’t Flagged as Spam
• Setting Up Email Filtering With Plesk

Tags: Domain Name System, email, Mail, Mail transfer agent, Sender Policy Framework, Server, Spam, Transport Layer Security

Some related posts:

• January 14, 2010 -- GoGrid: Instant Servers and Cloud Storage (0)
• December 15, 2008 -- Go-Grid: Instant Linux and Windows Computers (0)
• November 5, 2008 -- Using Thunderbird for Local Mail (0)
• October 22, 2008 -- End-to-End Email Monitoring With PHP (0)
• October 20, 2008 -- End-to-End Email Monitoring (1)