help！我的电子邮件发不到 500 英里以外！

这是一个听起来几乎不可能的事情……我甚至有点后悔将它发到网上，因为它在一个会议上成了一则著名的酒后故事。这个故事略有改动，以保护故事中的人物，以及忽略了一些无关的细节使之更有趣一些。

几年前，当我接到统计系主任的电话时，我正在从事维护校园电子邮件系统的工作。

“我们从部门发送电子邮件时遇到了问题。”

“有什么问题？” 我问。

“我们不能发送超过 500 英里的邮件，”主任解释说。

“咳咳”，我被我喝的拿铁呛了一口，“您再说一遍？”

“我们不能发送距这里超过 500 英里的邮件，”他重复道。 “实际上，更远一点，是 520 英里，但不能更远了。”

“嗯……电子邮件真的不会这样，通常，”我说，试着让我的声音听起来不那么慌乱。我不能和一个系主任说话时显得慌乱，即使是一个像统计系这样的相对没钱的院系。 “是什么让你觉得你不能发送邮件超过 500 英里？”

“这不是我认为的，”主任有点急躁地回答道。 “我们首先注意到了这种情况是几天前。”

“你等了几天？” 我打断他，带点颤音说道。 “这段时间你一直你不能发送电子邮件？”

“我们可以发送电子邮件。只是不超过 ——”

“—— 500 英里，我知道，”我接过他的话，“我知道了。但为什么没有你早点打电话呢？”

“好吧，我们没有收集到足够的数据来确定发生了什么，直到现在。”没错，这是统计系的主任。“不管怎么说，我请了一位地理统计学家研究它 ——”

“地理统计学家……”

“—— 是的，她制作了一张地图，显示了我们发送电子邮件能够达到的半径略超过 500 英里。在那个半径范围内有零星的几个无法到达的目的地，但我们永远不能发送比这半径更远的电子邮件。”

“我明白了，”我说，把头埋在我的手中。 “这是什么时候开始的？几天前，你说过，但是那时你的系统做了什么改变？”

“嗯，服务顾问来给我们的服务器打了补丁，并重新启动了它。但我打电话给他，他说他没有碰过邮件系统。”

“好的，让我来看看，我稍后会给你回电话，”我说。我简直觉得我在做梦，这不是愚人节。我试着回想是不是有人恶作剧报复我。

我登录了他们系的服务器，并发送了一些测试邮件。在北卡罗来纳州的三角研究园（ Research Triangle Park），我自己的帐户的测试邮件顺利投递。发往里士满、亚特兰大和华盛顿的也是如此。发往普林斯顿（400 英里）的另一个邮件也正常。

但后来我尝试向孟菲斯（600 英里）发送电子邮件，失败了。波士顿，失败了。底特律，也失败了。我拿出了我的地址簿，开始试图缩小它的范围。纽约（420 英里）工作，但普罗维登斯（580 英里）失败了。

我开始怀疑自己是不是疯了。我试过给住在北卡罗来纳州的朋友发电子邮件，但他的 ISP 在西雅图。谢天谢地，它失败了。如果问题与收件人的地理位置有关，而不是他的邮件服务器，我想我要哭了。

已经确定！虽然令人难以置信，但所报告的问题是真实的、可重复的，我看了一下 sendmail.cf 文件。它看起来很正常。事实上，它看起来很熟悉。

我把它与我主目录中的 sendmail.cf 做了个对比。它没有被改过 —— 这是我写的 sendmail.cf。 而且我相当确定我没有启用某种 “FAIL_MAIL_OVER_500_MILES” 选项。我不知所措，我 telnet 到 SMTP 端口。 服务器愉快地回复了 SunOS sendmail 的横幅消息。

等一下……一个 SunOS sendmail 的横幅消息？当时，即使 Sendmail 8 已经相当成熟，Sun 公司在其操作系统中装的仍然是 Sendmail 5。作为一名优秀的系统管理员，我已经对 Sendmail 8 进行了标准化。并且作为一名优秀的系统管理员，我编写了一个 sendmail.cf，它使用了 Sendmail 8 中提供的很长的、具有自我描述意义的选项和变量，而不是 Sendmail 5 中使用的那种神秘的标点符号式配置选项。

这个细节一下子又回到了起点，我再次被我现在已经冷掉了的拿铁咖啡渣呛了。 当服务顾问“对服务器打补丁”时，他显然升级了 SunOS 的版本，并且这样做降级了 Sendmail。这次升级会将 sendmail.cf 单独留下，即使它现在是错误的版本。

事实上，Sendmail 5 —— 至少是 Sun 所带的版本，是有一些调整的 —— 它可以处理 Sendmail 8 的 sendmail.cf，因为大多数规则在那时保持不变。但新的长配置选项 —— 它被视为垃圾，并跳过。 并且 sendmail 二进制文件编译时没有针对其中大多数设置默认值，因此，在 sendmail.cf 文件中找不到合适的配置，它们被设置为 0。

被设置为 0 的配置之一是连接到远程 SMTP 服务器的超时选项。 一些实验证明，在具有典型负载的特定机器上，0 超时将在稍微超过 3 毫秒的时间内中止连接调用。

当时我们校园网络的一个奇怪的特点是它是 100％ 交换的。传出的数据包不会出现路由器延迟，直到命中 POP 服务器并到达远端的路由器。因此，连接到附近网络上的轻负载的远程主机的时间实际上主要取决于到目的地的光速的速度，而不是偶然的路由器延迟。

这让我有点晕，我在我的 shell 中输入：

“500 英里，或者稍微多一点点。”