Inundated Servers

On the ninth day of Listmas, my data showed to me 9 inundated servers…

If you add up all the other days of Listmas (except the SBLs and the authentication issues), you end up with a lot of extra mail being sent. In fact, the period between late October and just a couple of days before Christmas is the busiest period for mailing in any given year.

By and large, that’s good news. Billions of messages go out to willing and happy recipients. They get news about good deals, marketers make a lot of money, and everyone is happy. That is … until they’re not.

Generally speaking, mailbox providers know they’ll need extra capacity during the holiday rush. But, they cannot plan for everything, and they shouldn’t have to plan on every single message arriving at the exact same moment. What you may not realize is that (thanks to human foibles) they do.

You see, people like to think in terms of round numbers. So, what do we do? We set up email jobs to go out at :00 and :30 in an hour. And everyone does it. Receiving mail servers have only so many open spots to handle requests to hand off an email. Those slots fill up, and things back up. The result is a lot of messages receiving “Server busy, please try again later” error messages. There’s nothing that a sender can do but wait until new slots open up.

Picture it this way: You need to fill a swimming pool, but all you have is a set of 6 fire hoses. How do you do it? Ultimately, it comes down to “use all of the hoses, but understand that you’re still going to have to wait.”

So, receiving mail servers get slammed at the top and bottom of the hour, mail queues on the sending mail servers slowly drain over the next few minutes, and delivery is perceived to be slow. Now, as it turns out, this happened this year, too (as it always does), but some providers found their systems slammed by incoming requests that wouldn’t let up for multiple days.

So, who is at fault here? Well, it’s easy to say that the receivers should have more infrastructure. But, the truth is that their capacity works for the volumes that they see far more often than it doesn’t, and if the receivers planned for handling all incoming messages on the busiest hour of the busiest day of the year, they would have server capacity that would sit idle for an entire year just to be used on that one hour when the next year rolls around.

Now, that is a problem, especially when you consider that email is designed to handle these issues. Email is designed to have the message stored on one server until the next server says it has accepted the message, or gives a rejection that really means about the same as “and don’t try this message again.” If the message is delayed, the sending server will wait a few minutes and try again, over and over, until the message is received or times out (generally after 72 hours).

It’s not really the sender either. They are just doing their job. But they also have some control over the problem. Rather than sending their messages at 8:00 or 8:30, they could offset that by a small amount to take advantage of anticipated lower loads. So, send the message at 8:08 or 8:36 rather than the top and bottom of the hour.

8 annual mailings
“That’s our business model!”
“We’ve gotta make our numbers,”
5 SBLs,
4 authentication failures,
sending 3 times daily,
2 purchased lists,
and that’s why they’re having slow delivery.

Bibliography

1. Retail Email (2013, January 1), Alert: Retail email volume grows 19% during 2012. Retrieved December 18, 2017 from https://blogs.oracle.com/marketingcloud/alert-retail-email-volume-grows-19-during-2012.
2. Retail Email (2012, December 24), Alert: Retail email volume hits all-time weekly high during week before Christmas. Retrieved December 18, 2017 from https://blogs.oracle.com/marketingcloud/alert-retail-email-volume-hits-all-time-weekly-high-during-week-before-christmas.