使用谷歌翻译：）
来自：Trey Harris
这是一个*听起来*不可能的问题......我几乎后悔发帖
这个故事面向广大观众，因为它对饮料有着深刻的印象
在一次会议上。 :-)为了保护，故事略有改变
有罪，无视无关和无聊的细节，并且通常会做出
整个事情更有趣。
几年前，我在校园电子邮件系统的工作
当我接到统计部门主席的电话时。
“我们在向部门发送电子邮件时遇到了问题。”
“有什么问题？”我问。
“我们不能发送超过500英里的邮件，”主席解释说。
我在拿铁上ch咽。 “再来？”
“我们不能发送距离这里500英里以外的邮件，”他重复道。 “一个
实际上，更多一点。称它为520英里。但没有更远。“
“嗯......电子邮件真的不会这样，通常，”我说，试着
把恐慌从我的声音中解脱出来。一个人说话时不会出现恐慌
到部门主席，甚至是一个相对贫困的部门
像统计数据。 “是什么让你认为你不能发送邮件超过
500英里？“
“这不是我认为的*，”主席回答道。 “你看，什么时候
几天前我们首先注意到了这种情况 - “
“你等了几天？”我打断了声音，震颤了我的声音。 “和
你不能一直发送电子邮件？“
“我们可以发送电子邮件。只是 - 不超过 - ”
“ - 500英里，是的，”我为他说完，“我知道了。但为什么没有
你早点打电话？“
“好吧，我们没有收集足够的数据来确定发生了什么
直到现在。“是的。这是*统计*的主席。”无论如何，
我请其中一位地质统计学家研究它 - “
“Geostatisticians ......”
“ - 是的，她制作了一张地图，显示了我们能够达到的半径
发送电子邮件略超过500英里。有很多
我们无法到达的那个半径范围内的目的地
零星地，但我们永远不会发送比这半径更远的电子邮件。“
“我明白了，”我说，把头埋在我的手中。 “这是什么时候开始的？
几天前，你说过，但你的系统做了什么改变
那时？”
“好吧，顾问进来修补了我们的服务器并重启了它。
但我打电话给他，他说他没有碰到邮件系统。“
“好的，让我来看看，我会给你回电话，”我说，几乎没有
相信我在玩耍。这不是愚人节。一世
试图记住是否有人欠我一个恶作剧。
我登录了他们部门的服务器，并发送了一些测试邮件。
这是在北卡罗来纳州的研究三角，并测试邮件
我自己的帐户顺利交付。同上一个发送到
里士满，亚特兰大和华盛顿。普林斯顿（400英里）的另一个
工作。
但后来我尝试向孟菲斯（600英里）发送电子邮件。它失败了。
波士顿，失败了。底特律失败了。我拿出了通讯录并开始了
试图缩小范围。纽约（420英里）工作，但普罗维登斯
（580英里）失败了。
我开始怀疑自己是否失去了理智。我试着给他发电子邮件
住在北卡罗来纳州的朋友，但他的ISP在西雅图。
谢天谢地，它失败了。如果问题与地理位置有关
我认为我会有人类收件人，而不是他的邮件服务器
泪流满面。
确定了 - 令人难以置信的 - 报告的问题是
是的，可重复的，我看了一下sendmail.cf文件。它看起来
相当正常。事实上，它看起来很熟悉。
我把它与我主目录中的sendmail.cf区分开来。它没有
改变了 - 这是我写的sendmail.cf。而且我相当肯定
我没有启用“FAIL_MAIL_OVER_500_MILES”选项。不知所措，我
telnet到SMTP端口。服务器愉快地回应了SunOS
sendmail横幅。
等一下......一个SunOS sendmail横幅？那时，孙还在
使用其操作系统发送Sendmail 5，即使Sendmail 8是
相当成熟。作为一名优秀的系统管理员，我已经标准化了
Sendmail 8.还是一名优秀的系统管理员，我曾写过一篇
sendmail.cf使用了很好的长自记录选项和变量
Sendmail 8中提供的名称，而不是神秘的标点符号
已在Sendmail 5中使用的代码。
这些碎片一下子落到了位置，我又一次在渣滓上呛到了
我现在冷的拿铁咖啡。当顾问“修补服务器”时，他说
显然升级了SunOS的版本，并且这样做
*降级* Sendmail。升级有助于离开sendmail.cf
单独，即使它现在是错误的版本。
它恰好发生在Sendmail 5上 - 至少是Sun发布的版本，
有一些调整 - 可以处理Sendmail 8 sendmail.cf，如
大多数规则在那时保持不变。但新的
长配置选项 - 它看起来像垃圾，并跳过。和
sendmail二进制文件没有为大多数编译的默认值，所以，
找不到合适的设置
邮件原文：http://web.mit.edu/jemorris/humor/500-miles
From: Trey Harris
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."
Trey Harris
--
I'm looking for work. If you need a SAGE Level IV with 10 years Perl,
tool development, training, and architecture experience, please email
me at [email protected]. I'm willing to relocate for the right opportunity.
