ネット・PC

「500マイルを超えた宛先にメールが送れない」という謎の不具合を解決した話

2015.04.17 17:56 by chaka

Eメールには送る距離の制限はない。ごくごく当たり前の話なのですが、その昔500マイル（約800km）を超える宛先にメールが送れないというトラブルが発生したことがあったそうです。起こるはずがないトラブルなのですが、いったいどのようにして解決したのでしょうか。

これは、当時ノースカロライナ大学チャペルヒル校のシスアドであった、トレイ・ヒル氏が、Usenix協会の技術グループ、SAGEのメーリングリストに投稿したもの。年代は明記されていませんが本人によれば1994年から1997年の間におこった出来事とのこと。技術的・数学的に「？」なディティールもあるのですが、実際の事件を元に脚色したものということです。

「500マイルEメール事件」

これはありえないような問題の話だ……この話は飲み会で大ウケするだろうから、こうして広く公開するのをためらってもいる。このお話は関係者を保護するため少し変更され、無関連でつまらない細部は省略し、そして全体的にエンタテイメント分を増してある。

何年か前、大学のメールシステムを管理していたころ、統計学部の学部長から連絡があった。

「メールを外部に送る時に問題が出るのですが」

「どんな問題ですか？」と私は聞いた

「500マイル（約800km）以上先にメールを送ることができないのです」学部長は説明してくれた。

私はラテを喉につまらせた「なんですって？」

「ここから500マイル以上先の宛先にメールを送ることができないのです」彼は繰り返した。「実際はもうちょっと…… そうですね、520マイルでしょうか。それ以上先に送れないのです」

「ええっと…… メールというのはそういうものではないのですが……」私はパニックになりそうなのを抑えて言った。学部長の前では誰もが平静を保つものだ。それがたとえ統計学のような斜陽の学部の長であっても。「なぜ500マイル先に送れていないとお考えなのでしょう」

「これは『考え』ではないのですよ」学部長の返事にイラツキがこもる。「問題に気づいたのは数日ほど前のことだったのですが……」

「数日前ですって？」さえぎる声が震えてしまう。「その間ずっとメールを送れていなかったんですか？」

「メールを送ることはできましたしかしその距離が……」

「……500マイル以内と」後を引き継ぐ「分かりました。しかしなぜもっと早くご連絡いただけなかったのですか？」

「ああ、何が起こっているのか理解するのに十分なデータがなかったものですから」そうだった。彼は「統計学」の学部長なのだ。「とにかく、地球統計学者に調査をお願いしたのです」

「地球統計学」

「そしてメールを送ることができるのが半径500マイルちょっと先までだということが彼女の調査で分かったのですよ。もちろんその内側にも送ったり送れなかったりする宛先がいくつも存在するのですが、とにかく500マイルを超えることはできなかったのです」

「なるほど」私は頭を抱えてしまった。「問題が起きたのはいつ頃からですか？数日前とおっしゃいましたが、その頃に何かシステムを変更しませんでしたか？」

「そうですね…コンサルタントが来てサーバーに何かパッチを当てて再起動しましたね。彼にも聞きましたが、メールシステムには触っていないと言っていました」

「分かりました。すぐ調べてご連絡します」ひょっとしたら担がれているのでは、と思いながら私は電話を切った。その日はエイプリル・フールではなかった。誰かが私にイタズラを仕掛けている可能性も考えたが、そうでもなさそうだった。

私は学部のサーバーにログインし、テストメールを送信してみた。ローリー・ダーラム・チャペルヒル広域都市圏のネットワークは、わずかの間もなくメールを送ってきた。リッチモンド、アトランタ、ワシントンへの送信も成功。プリンストン（400マイル）も成功。

次にメンフィス（600マイル）に向かって送ってみた。失敗。ボストン、失敗。デトロイト、失敗。私はアドレス帳を取り出し、この距離を絞り込んでいった。ニューヨーク（420マイル）は成功したがプロビデンス（580マイル）は失敗した。

私は気が狂ったのではないだろうかと思い始めた。次にプロバイダはシアトルにあるが自身は同じノースカロライナにいる友人にメールを送ってみた。結果は失敗。ありがたい。もし問題がサーバーの位置ではなく、受信する人間の位置が原因だったとしたら、私は泣き崩れていたところだ。

信じられないことにこの問題は実際に存在し、再現性もある。次に私はSendmail.cfを調べてみた。特に問題は見られない。実際、ごくごく当たり前の内容だった。

試しに手元にあったsendmail.cfとの差を調べてみる。まったく変更されていない……私が以前設定したままのsendmail.cfだった。もちろん「FAIL_MAIL_OVER_500_MILES（500マイル以上で送信失敗）」のオプションをオンにもしていない。少しがっかりしたあと、私はSMTPサーバーにTELNET接続した。サーバーは調子よくSunOS sendmailのバナーを返してくる。

……バナーを返してくる？それは変だ。当時、すでにSendmail 8が一般化していたが、SunはSendmail 5をインストールしたサーバーを出荷していた。私もよきシステム管理者として、Sendmail 8に統一していた。さらによきシステム管理者として、暗号めいた記号で記述するSendmail 5形式ではなく、セルフ・ドキュメント機能と変数名が使えるsendmail 8形式で設定ファイルを記述していた。

一瞬にしてパズルのピースがあるべきところに当てはまる。そして今はもう冷たくなってしまったラテを再び喉につまらせてしまった。つまりサーバーにパッチをあてたコンサルタントは、SunOSのバージョンを上げたもののSnedmailを古いものにしてしまった。このアップグレードによって、私が書いたsendmail.cfに影響はなかったが、sendmailのバージョンと適合しなくなったのだ。

Sendmail 5は……少なくともSunによってTweakされてから出荷されるものは……Sendmail 8の設定ファイルの内容のうち、古いオプションを読むことができた。しかし新しいものについては、意味不明としてスキップされてしまったのだ。そしてSendmailのバイナリは、こうした新しいオプションに関するデフォルト値が設定されておらず、すなわちこれらをすべてゼロに設定してしまったのである。

ゼロにされた中にはSMTPサーバーとの接続のタイムアウト時間があった。いくらかの実験の結果、タイムアウトがゼロに設定されていた場合、実際に接続を中止するまでに3ミリ秒かかるということが分かった。

当時、大学のネットワークを通るパケットは100％スイッチされていた。このため外部に向かうパケットは、POPサーバーから目的のルーターに届くまで、ルーターによる遅延の影響を受けない。つまりこのネットワークにおいては、リモートホストへの接続時間は、光速によって決定されるのだ。

私はめまいを感じながら、シェルを開いてこう打ち込んだ。

$ units
1311 units, 63 prefixes

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

なるほど「500マイル、実際はもうちょっと」だ。

トレイ・ハリス