當然，幾乎每個網絡管理員都對“開放中繼”的概念、它有什么壞處以及典型的解決方案等非常熟悉，這些解決方案有諸如對某些IP地址的限制性中繼服務或者需要認證等實現方式。但是許多網絡管理
員也許沒有沒有意識到現在的垃圾郵件發送者已經變得更加老謀深算了。

　　作為一個測試演練，我上周和這周設立了幾個郵件服務器，既使用了微軟的Exchange也使用了一些免費的SMTP/POP3服務器軟件，并且建立了我自己的協議分析器（ClearSight）以便于我能夠觀察發生的情況，面對發生的情況，我必須承認我感到相當震驚。

　　正如你可能想到的那樣，他們很快就發現了我的服務器，即使我要求對中繼請求進行認證，我很快就開始看見成千上萬包含虛假源地址的郵件源源不斷的通過我的Exchange服務器，我甚至看不到任何郵
件進入我的本地文件夾。同時，我還發現他們已經發現并利用了一個系統Bug（可能與SQL服務器相關），這樣就導致我的服務器自動產生他們需要的郵件——都不需要進行轉發了。

　　所以我拋棄Exchange并開始使用其他的免費服務器軟件，然而，這讓我的監控過程變得更加有趣，也使我對攻擊的多樣性感到震驚。盡管中繼轉發的企圖最初總是遭遇到服務器發出的“503-This
mail server requires authentication（這個郵件服務器要求認證）”的返回信息，我還是很快再次看到垃圾郵件蜂擁而至，他們甚至猜到了“Postmaster(郵箱管理員)”帳號的密碼并且使用郵箱管理員身份
發送郵件。

　　我將“Postmaster(郵箱管理員)”帳號禁用后，我仍然看到了許多利用偽造的SMTP命令進行登陸、使用錯誤Email源地址以及其他諸如在一個會話中傳送幾個RSET命令這樣的事情發生（因為許多服務器都允許你使某些命令失效）。這時，我意識到這很可能就是我的服務器時常斷開某個連接的原因所在了，因為它已經被設置成當接收到指定數目的錯誤命令后，就會斷開這個連接，所以我就將這個值（指定數目）設置得非常低。

　　我還注意到多數的中繼轉發嘗試都來自同一個IP地址，所以我就在我的防火墻中封掉該IP地址，幾分鐘后，我收到了從另一個不同地點的另一個不同的IP地址發來的同樣內容的垃圾郵件，我再次將此IP地址阻塞掉，垃圾郵件再次從第三個源頭發送過來。非常明顯，在它們之間還保持連接的時候，它們似乎非常樂意接收到認證失敗的通知，但是一旦它們不能在25端口上建立一個TCP連接，它們將馬上轉換源地址。

　　當我選擇拒收所有來自非法域內的郵件的時候，我發現了一個非常有趣的副作用，雖然拒收這些郵件看起來仿佛對于我來說是件好事情，因為這些成千上萬的垃圾郵件都是來自一個充滿ASCII碼垃圾的Email地址。

　　然而，我所發現的是，即使我的認證要求阻斷了垃圾郵件的中繼企圖，我的服務器仍然為這些垃圾郵件發送者的域名發送DNS（域名服務）請求，結果就造成了大量的DNS請求，更糟的是，它們源源不斷地產生DNS請求，然后突然每分鐘發送幾千個請求，幾乎是對DNS服務器的DoS攻擊（拒絕服務攻擊），在這種通信狀況下，我只好取消了拒收這些郵件的設置。

　　如果你正在監管郵件服務器，我建議你定期花費幾分鐘，使用Sniffer工具確保你的服務器沒有中招，我也鼓勵你經常給你的系統打補丁，重命名或禁用所有標準帳號，全面了解你的服務器支持的安全特性。垃圾郵件傳播者（spammer）變得越來越狡猾，我們必須變得更有經驗，千萬不要僅僅依靠身份認證或者IP尋址來抵御垃圾郵件的侵襲。