500マイル以上離れた場所にメールを送れなかった理由（2002年）

• 米国のある大学の統計学科のメールサーバーで、500マイル以上離れた場所へメールを送れないという異常現象が発生
• 調査の結果、SunOSの更新過程でSendmailのバージョンがダウングレードされ、設定ファイルに互換性がなくなったことが原因と判明
• Sendmail 5がSendmail 8向けの設定ファイルの長いオプション名を認識できず、複数の既定値が0に設定された
• そのうちSMTP接続タイムアウトが0に設定され、約3ミリ秒以上かかるリモート接続がすべて失敗
• ネットワーク遅延が距離に比例して発生したため、結果として500マイル以上離れたサーバーへのメール送信が遮断される現象が起きた

---

問題の始まり

• 統計学科から「500マイル以上離れた場所にはメールを送れない」という報告が届いた
  • 520マイルまでは可能だが、それを超えると失敗する現象
  • 学科長は地理統計学者を動員してメールが到達可能な半径の地図を作成し、半径が約500マイルであることを確認
• システム管理者はテストメールを各地に送って問題を再現
  • 400マイル離れたPrincetonへは成功し、600マイル離れたMemphisへは失敗
  • New York（420マイル） は成功し、Providence（580マイル） は失敗

原因分析

• サーバーのsendmail.cf設定ファイルは正常に見え、作成者本人が作ったSendmail 8向けの設定ファイルだった
• しかしSMTPポートのバナーを確認すると、SunOS Sendmail 5が動作していた
  • サーバーのパッチ適用過程でOSが更新され、Sendmailが8から5へダウングレードされていた
  • 既存の設定ファイルはそのまま残っていたが、Sendmail 5はSendmail 8の長いオプション名を認識できなかった
• 認識されなかったオプションは無視され、該当項目の既定値は0に初期化された
  • とくにリモートSMTPサーバー接続タイムアウト値が0に設定され、接続試行は約3ミリ秒後に中断された

距離と速度の関係

• 当時のキャンパスネットワークは100%スイッチベースの構成で、ルーター遅延がほとんどなかった
  • そのため接続時間は**物理的距離（光の速度）**によって決まった
• 計算の結果、3ミリ秒は約558マイルの距離に相当
  • 実際に報告された「500マイル、またはそれより少し先まで」という現象と一致した

結論

• 問題の根本原因はSendmailのバージョン不一致による設定解析エラー
• タイムアウトが0に設定されたことで、物理的な距離制限があるかのように見えるネットワーク現象が発生
• この事例は、システム管理におけるバージョン互換性と設定検証の重要性を示す古典的な逸話として残っている

[GN⁺]

Hacker Newsのコメント

• 1990年代半ばごろ、オフィスのPCが毎朝起動しないという奇妙な問題があった。
  調べてみると、冬になるたびに小さなネズミがハードドライブのスロットから入り込んで暖を取り、そこで尿をして回路を短絡させていた。
  コンピュータがしばらく動いて熱を持つと乾いて、起動できるようになっていた。
  その後、空のドライブスレッドを買って塞いだところ、問題は完全になくなった。

  • 昔見たストロベリーアイスクリームの話を思い出した。車がバニラアイスを買うと始動するのに、ストロベリーだと始動しないという話だった。
    本当かどうかはともかく、こういう問題を追跡していく過程が面白い。
    関連リンク
  • 本当にコンピュータマウスの話だなんて笑ってしまう。
  • ネズミは鉛筆が通る程度の穴なら入れる。
    以前、私のCATケーブルにコウモリがぶら下がっていたこともあった。
    夜に窓を開けておくと帯域幅にも影響するかもしれない。
    開発者なら "Frog on Keyboard error" みたいなとんでもない状況にも備えるべきだ。
    関連投稿
  • 私のマウスはそんなことしない。
  • ほとんどdeadmau5の名前の由来みたいな話だ。

• 元記事では、会長が問題解決に必要な情報を集めた点が十分評価されていない気がする。
  そのデータがなければ、筆者は長いこと見当違いのサーバ問題を探していたはずだ。
  ただ「メールはそういうふうには動かない」と言うだけでは、次から誰もデータをくれなくなるか、誤った推測をするようになる。

  • 私もこの話が本当に好きだ。ユーザーがこうして再現手順を具体的に教えてくれたらどんなにいいかと思う。
  • 統計学者や地理統計学者が顧客なら、こういうデータ収集はずっと簡単そうだ。
  • いいコメントだ。完全に同意する。

• この記事は長年HNで繰り返し人気を集めてきた古典的な投稿だ。
  2023年、2020年、2015年など、さまざまな時期に再投稿されている。
  2023年版, 2020年版, 2015年版

  • こういう記事があるから、15年以上も毎日HNをチェックしている。
    今回は見逃さなくてよかった。謙虚さを失ってはいけないという教訓になる。
  • この記事は周期が長いので、読むたびになぜメールが届かなかったのかを忘れていて、また読み直してしまう。
  • 私も一覧を作っていたが、もう誰かが投稿していた。
    HNでは1年くらい経てば再投稿は問題なく、古典は新しいユーザーのために再び上がってくるのがよい。
    HN FAQ も参照。
    関連する各バージョンへのリンクもまとめてある。
  • いつかAI関連でも、こういう時代を超えた古典が出てきてほしい。
    そのときはAIの不具合をデバッグしながら笑える気がする。
  • 数か月後には私自身がそんな記事を投稿しているかもしれない。

• 昨夜VLCでTVエピソードを再生していたら、30秒ほどで電源が落ちた。
  3回とも同じ場所で落ちたのでおかしいと思った。もしかして映像自体が原因なのかと考えた。
  昔のJanet Jacksonの映像がハードドライブを壊した事例を思い出した。
  しかもそのエピソードがBlack Mirror S7E01だったので、なおさら奇妙だった。
  参考リンク

  • 正確に同じフレームで落ちるのか、それともだいたい同じ区間なのかが重要だ。
    後者なら発熱の問題である可能性が高い。
    コーデックごとにデコード負荷が違うので、特定の区間でシステムを過熱させることがある。
    別の位置から再生したり、その区間を飛ばしたりして試すことを勧める。
  • 古い電源ユニットがデコード負荷に耐えられない可能性もある。
    電源を交換するか、コーデックを変換してみるとよい。
    あるいは悪意を持って改変されたファイルの可能性もあるので、出所を確認すべきだ。
  • 原因がわかったらぜひ教えてほしい。

• この話はまるでSR-71 Blackbirdの速度チェック逸話のハッカー版みたいだ。
  見るたびに読み返してしまう古典だ。
  関連リンク

• 「バニラアイスクリームを買うと車が始動し、ストロベリーだと始動しない」という古典を思い出す。
  話へのリンク

  • 私にはこれがSR-71の速度チェックの話を思い出させる。
    関連リンク

• "Stalking the Wiley Hacker" のような話が、私をコンピュータの世界へ導いてくれた。
  だが業界で働くうちに、あの頃の純粋な楽しさが失われたのは残念だ。
  原文リンク

  • 昔、Cliff Stollに直接会ったことがある。
    キルト協会で発表していたのだが、テーマに関係なく本当に情熱的で魅力的な人だった。
    彼のエネルギーと好奇心にすっかり引き込まれた。

• 「メールをさらに500マイル先まで送ってみよう」という冗談を思い出す。
  "You had me at EHLO" という一文に笑ってしまった。

  • 昔Sendmailで働いていたとき、ポート25にtelnetで接続して直接SMTPコマンドを打ち込んでいた。
    当時はコマンドを全部覚えていたが、今は自信がない。

• 昔使っていたコンピュータが、私が席を外すと電源が落ちるという問題があった。
  調べると、古い建物の緩い床板が原因だった。
  立ち上がるときの振動が故障した電源ユニットを短絡させていたのだ。

• この記事を読んですぐに apt install units を実行した。本当にすばらしいツールだった。

  • 私もインストールしたが、すぐにバグを見つけた。
    units コマンドを使うと、計算結果が逆向きに出る。
    例: 1 mile → 1.609 km は正しいが、1 unit → 1.609 units のようにすると逆に計算される。
  • 残念ながらArch Linuxにはパッケージがなかった。