The Case of the 500-mile Email

I stumbled across this story again this morning, and it’s such a lovely delivery yarn I thought I’d share it.

It’s from Trey Harris, and it’s set in the mid 90s.

Here's a problem that *sounded* impossible...  I almost regret posting the
story to a wide audience, because it makes a great tale over drinks at a
conference. :-)  The story is slightly altered in order to protect the
guilty, elide over irrelevant and boring details, and generally make the
whole thing more entertaining.

I was working in a job running the campus email system some years ago when
I got a call from the chairman of the statistics department.

"We're having a problem sending email out of the department."

"What's the problem?" I asked.

"We can't send mail more than 500 miles," the chairman explained.

I choked on my latte.  "Come again?"

"We can't send mail farther than 500 miles from here," he repeated.  "A
little bit more, actually.  Call it 520 miles.  But no farther."

"Um... Email really doesn't work that way, generally," I said, trying to
keep panic out of my voice.  One doesn't display panic when speaking to a
department chairman, even of a relatively impoverished department like
statistics.  "What makes you think you can't send mail more than 500
miles?"

"It's not what I *think*," the chairman replied testily.  "You see, when
we first noticed this happening, a few days ago--"

"You waited a few DAYS?" I interrupted, a tremor tinging my voice.  "And
you couldn't send email this whole time?"

"We could send email.  Just not more than--"

"--500 miles, yes," I finished for him, "I got that.  But why didn't you
call earlier?"

"Well, we hadn't collected enough data to be sure of what was going on
until just now."  Right.  This is the chairman of *statistics*. "Anyway, I
asked one of the geostatisticians to look into it--"

"Geostatisticians..."

"--yes, and she's produced a map showing the radius within which we can
send email to be slightly more than 500 miles.  There are a number of
destinations within that radius that we can't reach, either, or reach
sporadically, but we can never email farther than this radius."

"I see," I said, and put my head in my hands.  "When did this start?  A
few days ago, you said, but did anything change in your systems at that
time?"

"Well, the consultant came in and patched our server and rebooted it.
But I called him, and he said he didn't touch the mail system."

"Okay, let me take a look, and I'll call you back," I said, scarcely
believing that I was playing along.  It wasn't April Fool's Day.  I tried
to remember if someone owed me a practical joke.

I logged into their department's server, and sent a few test mails.  This
was in the Research Triangle of North Carolina, and a test mail to my own
account was delivered without a hitch.  Ditto for one sent to Richmond,
and Atlanta, and Washington.  Another to Princeton (400 miles) worked.

But then I tried to send an email to Memphis (600 miles).  It failed.
Boston, failed.  Detroit, failed.  I got out my address book and started
trying to narrow this down.  New York (420 miles) worked, but Providence
(580 miles) failed.

I was beginning to wonder if I had lost my sanity.  I tried emailing a
friend who lived in North Carolina, but whose ISP was in Seattle.
Thankfully, it failed.  If the problem had had to do with the geography of
the human recipient and not his mail server, I think I would have broken
down in tears.

Having established that--unbelievably--the problem as reported was true,
and repeatable, I took a look at the sendmail.cf file.  It looked fairly
normal.  In fact, it looked familiar.

I diffed it against the sendmail.cf in my home directory.  It hadn't been
altered--it was a sendmail.cf I had written.  And I was fairly certain I
hadn't enabled the "FAIL_MAIL_OVER_500_MILES" option.  At a loss, I
telnetted into the SMTP port.  The server happily responded with a SunOS
sendmail banner.

Wait a minute... a SunOS sendmail banner?  At the time, Sun was still
shipping Sendmail 5 with its operating system, even though Sendmail 8 was
fairly mature.  Being a good system administrator, I had standardized on
Sendmail 8.  And also being a good system administrator, I had written a
sendmail.cf that used the nice long self-documenting option and variable
names available in Sendmail 8 rather than the cryptic punctuation-mark
codes that had been used in Sendmail 5.

The pieces fell into place, all at once, and I again choked on the dregs
of my now-cold latte.  When the consultant had "patched the server," he
had apparently upgraded the version of SunOS, and in so doing
*downgraded* Sendmail.  The upgrade helpfully left the sendmail.cf
alone, even though it was now the wrong version.

It so happens that Sendmail 5--at least, the version that Sun shipped,
which had some tweaks--could deal with the Sendmail 8 sendmail.cf, as most
of the rules had at that point remained unaltered.  But the new long
configuration options--those it saw as junk, and skipped.  And the
sendmail binary had no defaults compiled in for most of these, so, finding
no suitable settings in the sendmail.cf file, they were set to zero.

One of the settings that was set to zero was the timeout to connect to the
remote SMTP server.  Some experimentation established that on this
particular machine with its typical load, a zero timeout would abort a
connect call in slightly over three milliseconds.

An odd feature of our campus network at the time was that it was 100%
switched.  An outgoing packet wouldn't incur a router delay until hitting
the POP and reaching a router on the far side.  So time to connect to a
lightly-loaded remote host on a nearby network would actually largely be
governed by the speed of light distance to the destination rather than by
incidental router delays.

Feeling slightly giddy, I typed into my shell:

$ units
1311 units, 63 prefixes

You have: 3 millilightseconds
You want: miles
        * 558.84719
        / 0.0017893979

"500 miles, or a little bit more."

Read the FAQ about the story.

Related Posts

Deliverability Help: Information checklist

When asking a for assistance with email delivery, there are some pieces of information that are required before anyone can help. Be prepared with the information so you can get timely assistance. This advice is true whether you’re looking for help from peers or working with paid deliverability consultants.

Read More

Wildfires and deliverability

A few weeks ago we took a drive down I5 to attend a service at Bakersfield National Cemetery. Amid the acres and acres of almond farms there were patches of black from recent grassfires. Typical but boring California landscape. Wildfires are a hugely destructive but continual threat in California. Growing up on the east coast, I never really understood wildfires. How can acres and acres and square miles just burn?
Having lived in California for almost as long as I lived on the east coast, I understand a bit better. In some ways, I have to. Even living right on the bay, there’s still some risk of fire. Like the grass fire a few miles from here across the street from the FB headquarters a few years ago. Further up the hills, there’s an even bigger risk of fire. Every driver can see the signs and precautions. Fields have plowed firebreaks around the edges. CAL FIRE posts signs alerting the public to the current fire risk status.
Fire Danger
What do wildfires have to do with deliverability?
I associate wildfires and deliverability together because of a radio show I did a few years ago. It was pitched as a “showdown” between marketers and deliverability. I was the representative of deliverability. During the conversation, one of the marketers mentioned that deliverability people were too focused on the worst case scenario. That we spoke like we expected a fire to break out at any moment. His point was that deliverability spent too much time focused on what could happen and not enough time actually just letting marketers send mail.
His overall point was deliverability people should put out the fires, rather than trying to prevent them in the first place.
I thought about that conversation during the long drive down I5 the other day. I saw the firebreaks plowed into fields at the side of the road. And I saw the patches of blackness from fires reach along the highway where there were no firebreaks.
There are a group of marketers who really hate the entire concept of deliverability. Their point of view is that deliverability is hampering their ability to make money. I’ve even heard some of them assert they don’t care if 70% of their mail goes to the bulk folder. They should be allowed to send blasts of mail and deliverability shouldn’t tell them what they can do. Deliverability, so the complaint goes, is simply out to hurt marketers.
The only good deliverability is that which gets them unblocked when their behavior triggers IP based blocks. When the field is burning down, they’d like us to come spray water on it. And then go away and let them keep throwing lit cigarettes out their car windows.
But that’s not all that firefighting is about. Much of the work is preventing fires in the first place.  In the US, a lot of that work is done through building codes. There are mandates like smoke detectors, fuel free spaces around dwellings, and sprinklers for some buildings. Monitoring local conditions and enforcing burn bans are also a large part of what the fire service does.
I like the fire fighter motif a lot. Much of what deliverability does is actually about preventing the block. ESPs have building code like standards for what mail is good and what is bad and what can be sent on their networks. Many of us publicly speak and educate about good practices and preventing blocks in the first place.
Fire prevention is about risk management and understanding how little things add up. Deliverability is similar. All the little things senders do to improve their deliverability adds up to a lower risk of fire. Yes, things like listbombing happen where even the best deliverability advice wouldn’t have prevented it. But, overall, deliverability wants to help senders get their mail in front of the people who can act on it. Some of that advice, though, takes the form of risk management and saying no.

Read More

Whose side are you on?

A few weeks ago I was on an industry call. We were discussing some changes coming down the pike at the ISPs and filter providers. These changes are going to cause some headache at ESPs and other places that do email but don’t provide mailboxes. During the call I ended up explaining why what the ISPs were doing made sense and how it fit in with their mission and customer needs.

Read More