The Email That Could Not Travel More Than 500 Miles
A department head reported, in all seriousness, that they could not send email more than 500 miles. It sounded like nonsense. It turned out to be exactly, measurably true. The best war story in IT.
One of the most beloved stories in the history of system administration begins with an absurd bug report. A department head at a university emailed the IT team to say, with complete sincerity, that they could not send email more than 500 miles. Mail to nearby cities went through fine. Mail to anywhere beyond roughly 500 miles vanished. It sounded like nonsense. It turned out to be exactly, measurably true.

An impossible complaint
The story was written up in the mid 1990s by an administrator named Trey Harris, and it has been passed around ever since because it is both genuinely funny and genuinely instructive. The complaint landed on his desk the way these things do, framed as something the computer obviously could not be doing. Email does not have a range. It does not know how far away the recipient is. And yet the users had done the legwork: they had plotted the failures on a map, and the boundary really was a rough circle about 500 miles across.
The chain of small accidents
The cause was a quiet pileup of ordinary mistakes. The campus mail server ran sendmail, the venerable program that shuffled email around the early internet. During some routine maintenance, its carefully tuned configuration had been replaced with a much older default one. That default set the timeout for opening a connection to a remote mail server to a value so small it was effectively a few thousandths of a second.
Here is where it gets beautiful. To deliver a message, a mail server has to open a network connection to the receiving server and wait for it to answer. That handshake takes time, and the time is governed by physics, because a signal can only travel so fast down a wire. A few thousandths of a second is, near enough, the time it takes light to travel a few hundred miles and back.

The maths that matched the map
So the server was not refusing distant mail on principle. It was simply hanging up the instant a connection took longer than its impossibly short timeout to complete. Nearby servers answered inside the window and the mail went through. Servers far enough away that the round trip exceeded the timeout were cut off mid-handshake, and the message bounced. When Harris worked out how far a signal could travel in that sliver of time, the number landed at a little over 500 miles. The users had accidentally measured the speed of light with a broken email server.

Why the story endures
It survives because it captures something true about running infrastructure: the most baffling problems usually have boring, physical explanations, and the user describing the symptom is often more right than the expert dismissing it. The email system was behaving perfectly logically. It was the assumptions around it that were broken. Every part of that handshake is still defined in the email standards you can read in our RFC archive, and the same fundamentals decide how a modern site feels today, which is why the physical distance between a server and its users still matters when you choose where to host.
The next time something at the edge of your stack does something that seems physically impossible, it is worth remembering the 500-mile email. The computer is almost never lying. It is doing exactly what someone told it to, and the job is to find out who, and when. If you ever want to see the mail and network records behind a domain for yourself, our who is hosting this site tool lays them out, and the glossary explains the pieces.
0 Comments
No comments yet
Be the first to share your thoughts on this article.