Will the problem of not being able to send emails when you're 500 miles away be solved by 2025?
There are some phenomena in the world that can only be described as mysterious until the cause is identified, such as '
Can an email go 500 miles in 2025?
https://flak.tedunangst.com/post/can-an-email-go-500-miles-in-2025
The original story about 'not being able to send email 500 miles away' was compiled in 2002 by Trey Harris, who was in charge of part of the university's email system at the University of North Carolina, based on an experience he had sometime between 1994 and 1997.
The case of the 500-mile email
https://www.ibiblio.org/harris/500milemail.html
The story began when Harris was consulted by the head of the statistics department, who said that he couldn't send e-mail. Moreover, the condition for not being able to send e-mail was 'only when the recipient was more than 500 miles away.' Harris was perplexed because e-mail doesn't have a mechanism for determining whether it will arrive or not depending on the distance, but after trying to send e-mails here and there, he discovered that it was indeed possible to send e-mails only up to a distance of a little over 500 miles.
After further investigation, Harris tried telnetting to the SMTP port and got a Sun OS sendmail banner back, which suggested that the problem was caused by a company that had come in and patched the server and rebooted it a few days before the problem started.
In other words, the server already had the stable version of Sendmail 8 installed, but the vendor had downgraded it to the older version, Sendmail 5, that was included with the OS. By coincidence, the Sendmail 5 included with SunOS was compatible with the Sendmail 8 sendmail.cf file, so many of the rules that Harris had written in the sendmail.cf file remained intact, but some of the new settings were ignored. On the other hand, many settings had no default value, so they were set to '0'.
The settings that were treated as '0' in this case included the 'timeout when connecting to a remote SMTP server.' When Harris tested it, he found that in the given environment and under a typical load, if the timeout was set to '0,' the connection would be disconnected after just over 3 milliseconds.
At the time, the University of North Carolina's network was 100% switched, and the time it took to connect to a remote host on a nearby network was determined by the 'distance to the destination at the speed of light.' In conversion, the '3 milliseconds' that would cause a remote connection to be cut off was 'approximately 558 miles (about 900 km),' and it turned out that the settings in this area were the problem.
It's 2025, about 30 years after the original episode and 23 years after Harris posted the story online. Developer Ted Anungst has investigated whether technology has advanced to the point where it's now possible to send emails to people more than 500 miles away. However, since he can't test it in the exact same environment, he started by writing code to make a non-blocking connection that would time out quickly. Here's the code in question:
[code]#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int
connect_wait(int s)
{
struct pollfd pfd[1];
int error = 0;
socklen_t len = sizeof(error);
pfd[0].fd = s;
pfd[0].events = POLLOUT;
error = poll(pfd, 1, 3);
if (error == -1)
return -1;
if (error == 0) {
errno = ETIMEDOUT;
return -1;
}
if (getsockopt(s, SOL_SOCKET, SO_ERROR, &error, &len) == -1)
return -1;
if (error != 0) {
errno = error;
return -1;
}
return 0;
}
int
main(int argc, char **argv)
{
struct addrinfo hints, *res, *res0;
int error;
int save_errno;
int s;
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
error = getaddrinfo(argv[1] ?: 'www.openbsd.org', 'www', &hints, &res0);
if (error)
errx(1, '%s', gai_strerror(error));
s = -1;
for (res = res0; res; res = res->ai_next) {
s = socket(res->ai_family, res->ai_socktype | SOCK_NONBLOCK,
res->ai_protocol);
if (s == -1)
continue;
error = connect(s, res->ai_addr, res->ai_addrlen);
if (error == -1 && errno == EINPROGRESS)
error = connect_wait(s);
if (error == -1) {
warn('connect failure');
close(s);
s = -1;
continue;
}
break; /* okay we got one */
}
if (s == -1)
return -1;
printf('it's a live one!\n');
freeaddrinfo(res0);
}[/code]
First, they tried connecting to various universities, but the results were not what they expected, so Anangst speculated that 'Maybe they're all hosted in the same data center?'
So instead, they turned their attention to finding schools with realistic ping times, and found that connections to the University of Maine and the University of Dayton, about 500 miles away, timed out. Just as Anungst predicted before the tests began, 'the same thing will happen in 2025.'
By the way, Anungusto explains that 'the kernel rounds up 3 ms to 10 ms as a kernel tick, so the actual timeout is between 10 ms and 19 ms.'
In addition, there are likely to be many questions about the details, so Harris has created and published his own FAQ.
FAQ on the 500-mile email
https://www.ibiblio.org/harris/500milemail-faq.html
According to Harris, 'Isn't it better to make it 6 milliseconds instead of 3 milliseconds because we need to get a response before the timeout?' This is one of the details I left out because I thought it was irrelevant and uninteresting.
Harris also acknowledged that 'Sendmail 5 cannot read a Sendmail 8 sendmail.cf file,' but said that the fact that Sendmail 5 could actually read a Sendmail 8 sendmail.cf file forced him to conclude that the Sendmail 5 that shipped with SunOS had some special specifications.
In the first place, the original story was posted to a thread called 'Favorite Impossible Tasks' on a mailing list for system administrators, and was just an internal story shared with colleagues. He didn't expect it to spread so much, so he didn't go into detail. He also explains that he no longer has the notes and logs from that time, so it's difficult to write the details again.
Related Posts:
in Note, Posted by logc_nt