The hard truth about email

30 November 2009

Many clients expect email to be sort of an automatic thing. The thinking is “I should hit ‘Send’ and it should arrive within moments.”

So, sometimes those of us who work in email hear comments like the following:

I understand that these delays may not be your fault, but we can’t have delays.

and:

It’s just not acceptable that they may rate limit us due to their own capacity issues.

Read moreThe Spock Trap

With it now being “Cyber Monday” and with clients doing their best to ramp up holiday sales, we are are to the time of the year when these kinds of comments become more common. So common, in fact, that I’m going to head things off early this year by giving you the hard truth about email.

Email is like anything else on the Internet: It is a finite resource. How do you know when your mail campaign is going a little too well? Perhaps when the clicks pour in so quickly that your IT staff reports that the web server is starting to shake just a little bit? Or maybe when you hear the IT staff talk about the need to purchase extra capacity and bandwidth at the holiday planning meeting? Well, that need is there because there are finite resources available to handle those demands.

When we send email, we tend to consider it a “fire and forget” mechanism. “I hit ’send’ and the message arrives. It just works!” is how the thought goes. But, the same thing is true for your webserver. Your customers put in your URL and they expect to see your website. But that doesn’t always happen, does it? It does happen often enough that people expect it to work without giving any thought to the fact that it may not. That’s amazing reliability, but discounts such terrible things as coding errors that got put into production without QA, denial of service attacks, the failure of aging equipment, or that everyone in the world wants to get to your website RIGHT NOW!

Read moreBad Advice

And the same is true for email. ISPs and other receivers build their data centers with the needs of their customers in mind, and you are usually not their customer. When every relative your customer has wants to send mail inviting them to Christmas dinner (all at the same time) and you and every other marketer in the world want to send them mail inviting them to shop at your all-important sale (all at the same time), it overloads the available capacity of your customer’s ISP. While they do build their systems (more or less) robustly and with many normal, seasonal surges in mind, you have to understand that sometimes something happens that means that your email will not arrive instantaneously.

Sometimes email gets held up because:

  • a hard drive on an aging server has finally given up the ghost
  • some botnet herder in Eastern Europe has decided that they hate the ISP’s anti-spam systems so much that they will retaliate by sending the ISP 100 million messages per hour
  • some intermediate link between your (ESP’s) mailserver and the ISP has gone dead
  • that new filter that they’re using didn’t undergo enough QA and has either
    1. caused the server to lock up tighter than 8 day clock or
    2. caused all incoming mail to be delayed, filtered, or blocked

They way to deal with these issues is the same: spend more money. They can spend money on new servers, more bandwidth, and/or more personnel to code, do QA, and/or monitor and run the equipment. And, unlike WalMart, they really can’t do seasonal hires or 90 day equipment leases for this. It takes a long time to become proficient in how an existing setup works, and setting up a new server is not usually something that anyone relishes doing during the busy holiday period.

Email is a store-and-forward mechanism that can deal with lots of things. But, the hard truth about email is that the system cannot deal with everything so sometimes an email won’t go through at all, and sometimes it takes longer to get there. And unless you want to spend the money to buy an ISP more personnel or equipment, it’s not likely to ever change.

Mickey Chandler
Latest posts by Mickey Chandler (see all)