- ある大学の統計学科のメールサーバーが、ある時点から約500〜520マイルより遠い宛先へメールを送れなくなり、問題が地理的な半径として再現された
- 学科長は数日間データを集め、地理統計学者に分析を依頼し、到達可能な半径とその半径内の例外的な宛先を地図化した
- 管理者がテストしたところ、North Carolina Research TriangleからRichmond、Atlanta、Washington、Princeton、New Yorkへは成功したが、Memphis、Boston、Detroit、Providenceへは失敗し、受信者の所在地ではなくメールサーバーの所在地が基準であることが明らかになった
- 原因は、サーバーのパッチ適用中にSunOSがアップグレードされ、Sendmail 8からSendmail 5へ実質的にダウングレードされ、既存のSendmail 8用
sendmail.cfにある長い設定名をSendmail 5が無視したことにあった
- その結果、接続タイムアウトが0に設定され、そのマシンでは約3ミリ秒後に接続が切断され、
unitsでの計算上、約559マイルという観測値と一致した
「500マイル以上メールが届かない」という報告
- キャンパスのメールシステムを運用していたところ、統計学科の学科長から「学科の外へメールを送るのに問題がある」と連絡があった
- 問題の核心は「ここから500マイルより遠い場所へメールを送れない」というもので、学科長は実際の境界は「もう少し先、約520マイル」だと付け加えた
- 管理者は、メールは普通そのようには動作しないと答えたが、学科長は数日間にわたって十分なデータを集めたうえで連絡してきていた
- 統計学科は地理統計学者に確認を依頼し、メールを送れる範囲が500マイルより少し大きい半径であることを示す地図を作成した
- 半径内でも到達できない、または断続的にしか到達しない宛先があった
- 半径の外へはメールが決して配送されなかった
- 同じ時点でコンサルタントがサーバーにパッチを適用して再起動していたが、メールシステムには手を触れていないと説明した
再現テストと地理的な境界
- 管理者が学科サーバーにログインしてテストメールを送ると、問題は実際に再現可能だった
- 当時の所在地はNorth CarolinaのResearch Triangleで、近い宛先は正常に動作した
- 自分のアカウントへ送ったテストメールは正常に配送された
- Richmond、Atlanta、Washingtonへ送ったメールも成功した
- Princetonまでの約400マイルのテストも通った
- より遠い宛先では失敗が続いた
- Memphis 約600マイル 失敗
- Boston 失敗
- Detroit 失敗
- New York 約420マイル 成功
- Providence 約580マイル 失敗
- North Carolinaに住む友人のアカウントへ送ったメールは失敗したが、そのアカウントのISPがSeattleにあったためだった
- 問題は人の実際の所在地ではなく、メールサーバーの地理的な所在地に関係していることが確認された
正常に見えたSendmail設定
sendmail.cfファイルは概ね正常に見え、管理者が以前に作成したファイルと同一だった- 管理者は、自分が
FAIL_MAIL_OVER_500_MILESのようなオプションを有効にした覚えはないと判断した
- SMTPポートに
telnetで接続すると、サーバーはSunOS sendmailのバナーを返した
- 当時Sunは、オペレーティングシステムにSendmail 5を含めて配布しており、Sendmail 8はすでに成熟した状態だった
- 管理者はSendmail 8で標準化しており、Sendmail 8の長い自己説明的なオプション名と変数名を使う
sendmail.cfを作成して運用していた
- Sendmail 5は、より古い句読点中心の暗号のような設定コードを使っていた
アップグレードが生んだダウングレード
- コンサルタントがサーバーに「パッチ」を適用する際にSunOSのバージョンを上げ、その過程でSendmailはSendmail 5へ下がった
- オペレーティングシステムのアップグレードは既存の
sendmail.cfをそのまま残したが、実行中のSendmailのバージョンとは合わないファイルになった
- Sunが配布したSendmail 5のバージョンは、Sendmail 8用
sendmail.cfの多くのルールを処理できた
- 問題はSendmail 8の長い設定オプションで、Sendmail 5はそれらをゴミ値のように見なして読み飛ばした
- Sendmailバイナリにはこれらのオプションのデフォルト値がほとんどコンパイルされておらず、設定ファイルからも値を見つけられなかったため、結果的に0に設定された
3ミリ秒のタイムアウトと558マイル
- 0に設定された値の1つが、リモートSMTPサーバーへ接続する際に使う接続タイムアウトだった
- 実験の結果、そのマシンと一般的な負荷条件では、0タイムアウトは
connect呼び出しを約3ミリ秒強で中断させた
- 当時のキャンパスネットワークは100%スイッチングされていた
- 外部へ出ていくパケットはPOPに到達して向こう側のルーターに会うまで、ルーターによる遅延を受けなかった
- 近いネットワーク上の負荷が低いリモートホストへ接続する時間は、付随するルーター遅延よりも光速による距離の影響を大きく受けていた
- 管理者が
unitsで3 millilightsecondsをmilesに変換すると、結果は558.84719マイルだった
- 学科長が言った「500マイル、またはもう少し」という観測と計算結果はほぼ一致した
1件のコメント
Hacker News のコメント
1998年にオーストラリアの小さな会社でITサポートをしていたとき、リモートオフィスの社員から「スクリーンセーバーがモニターから落ちてキーボードのキーを押し、端末がロックされた」と電話があった
最初はあり得ないと思ったが、実は当時よくあった物理的な CRT用グレア防止フィルターを「スクリーンセーバー」と呼んでいたのであり、そのフィルターが落ちて Scroll Lock を押したままにしていた
https://dylbs6e8mhm2w.cloudfront.net/productimages/500x500/E...
こういう話は好き。絶対に起こるはずがないと確信していた現象が、実は光速のような物理法則のせいで起きていたと分かる瞬間がある
最初の職場の一つで、CRTモニターが微妙にちらつく問題に遭遇したが、モニター、ケーブル、電源コード、コンピューターまで交換しても変わらなかった
結局、コンピューターとモニターをカートに載せて廊下へ出したところ問題が消え、原因はそのオフィスの電気的シールド不良だった
後になって、より大きなテレビを入れたあと近くに置きすぎたために静電気がたまり、そのような効果が起きていたと分かった。修理店に着く頃には十分に放電され、しばらくは問題なく動いていたらしい
コンピューターを販売したところ、使うとブルースクリーンになると言うので持ち帰ってテストすると何の問題もなく、オフィスで30分一緒に使っても大丈夫だった
ところがその人がマウスに触れた瞬間にコンピューターがブルースクリーンになり、マウス交換で問題は解消した
誰かが安定器を入れると、近くの CRTモニター が一瞬ゆがみ、ちらつき、色がおかしくなった。壁際の席は影響が少なかったが頭痛がひどく、その会社には6か月しか持たなかった
この話で一番いいところは、サーバーにパッチを当てたコンサルタントがHacker Newsにいること
本人が担当した部分をここでコメントしている: https://news.ycombinator.com/item?id=23775404
関心のある人のために
/highlightsにも入れておいた: https://news.ycombinator.com/highlightsおそらく「罪人を守るために話を少し変えた」という箇所はこの部分なのだろう
数年ごとにこの話がまた上がってくるが、そのたびに笑顔になる
最後の 3ミリ光秒 は片道距離なので、正しいはずがない
2007年に大手ISPで複数サービスの二次サポート技術者として働いていたとき、ADSLはまだ一般的で、銅線ベースだったため安定して動作できる最大距離があった
一部の顧客はその距離を2〜3kmほどさらに延ばす特別料金プランを使っていたが、実際にはかなり不安定で、Webブラウジング程度がかろうじて可能なレベルだった
ある夏、ある顧客から、日中にIPTVが1か月近く途切れ、インターネットも時々氷河のように遅いと問い合わせがあった。測定してみると最寄りの電話局から非常に遠く離れており、暑い日中には線が膨張して距離の限界をわずかに超え、不安定になっているのだろうと結論づけた
助けられることはほとんどなく、銅線網が懐かしいとは思わない
15〜20年ほど前に修理店で働いていたとき、ある人が「毎日午後5時になるとテレビがスペイン語に切り替わる」と言って持ち込んできた
地上波を見ていて、テレビの設定にはメニュー言語しかなかったが、実際に午後5時になるとテレビの音声がスペイン語に変わった。さらに数チャンネル見てみると、1つか2つを除いてすべてスペイン語だった
調べてみると、一部の放送局は複数言語で音声を送出しており、一部のテレビでは優先言語を変更できることが分かった。残念ながら、その人が買った中古テレビはスペイン語圏の国から来た製品で、その優先設定を変更する方法がなかった
数日前、中国で製造・購入されたロボット掃除機を家に入れたところ、初回起動直後にサーバーにぶつかって電源を引き抜いてしまった
なので、国家支援型サイバー攻撃の可能性も排除できない
真の漏れた抽象化の母のような事例だ
メールを送ろうとした瞬間、相対論的宇宙の実際の下位転送プロトコルが露呈したわけだ
今日の昼食時にちょうど Sendmail の話をしたが、断言するがかなり珍しいことだ
1991年か1992年に初めてSendmailを設定した頃を思い出した。bat bookを見ながら、1週間ほとんど髪をかきむしるようにして、ようやく最初の設定を成功させた
後にはm4設定を理解し、ある程度認めるようになったが、90年代半ばにqmailとpostfixへ移ってからは二度と振り返らなかった
こういう記事は2002年ではなく 1997年 と表示すべきな気がする。ただ、Trey 本人も覚えていないようだ: https://www.ibiblio.org/harris/500milemail-faq.html
関連記事。ほかにもあるだろうか？
The case of the 500-mile email (2002) - https://news.ycombinator.com/item?id=29213064 - 2021年11月（93コメント）
We can't send email more than 500 miles (2002) - https://news.ycombinator.com/item?id=23775404 - 2020年7月（135コメント）
500 miles (2002) - https://news.ycombinator.com/item?id=18675375 - 2018年12月（32コメント）
The case of the 500-mile email (2002) - https://news.ycombinator.com/item?id=14676835 - 2017年7月（56コメント）
The 500-mile email (2002) - https://news.ycombinator.com/item?id=9338708 - 2015年4月（139コメント）
The case of the 500-mile email - https://news.ycombinator.com/item?id=2701063 - 2011年6月（18コメント）
The case of the 500-mile email - https://news.ycombinator.com/item?id=1293652 - 2010年4月（24コメント）
The case of the 500-mile email - https://news.ycombinator.com/item?id=385068 - 2008年12月（28コメント）
The case of the 500-mile email - https://news.ycombinator.com/item?id=123489 - 2008年2月（7コメント）