救命!我的電子郵件發不到 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 服務器併到達遠端的路由器。因此,連接到附近網絡上的輕負載的遠程主機的時間實際上主要取決於到目的地的光速的速度,而不是偶然的路由器延遲。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章