郵件服務器無法連接故障及解決方法

摘要:該文從解決網絡故障的一般思路出發，闡述如何解決郵件服務器無法連接的故障，著重講解如何防范垃圾郵件及DNS緩沖錯誤的解決方法，并分析故障產生的原因。

關鍵詞:郵件服務器;垃圾郵件;DNS

中圖分類號:TP393文獻標識碼:A文章編號:1009-3044(2010)21-5764-02

我校郵件服務器是采用Windows 2003+exchange 2003搭建的，客戶端使用Outlook 2003，通過防火墻與互聯網相連，實現校內外郵件互訪，學校教職工通過該郵件系統實現信息、資料的傳遞，系統建成后，一直平穩運行。

前一段時間，筆者接到多個用戶的申告，稱打開outlook2003后無法連接到郵件服務器，不能收發郵件，但可以訪問互聯網。將該用戶的本地連接先禁用，再啟用，可以訪問郵件服務器，使用一段時間后，又無法訪問郵件服務器。筆者開始從以下幾個方面開始排查。

1 查outlook2003設置

筆者首先懷疑這些用戶的outlook2003設置有問題，打開“控制面板”—“郵件”，查看郵件設置，發現exchange服務器名為我校郵件服務器名，用戶名為該用戶名，其余的設置也是正確的，說明并不是outlook2003的設置問題。

2 查病毒

由于不能訪問的用戶總是特定的一些用戶，筆者懷疑是不是由于病毒引起的，但全校所有用戶都裝了卡巴斯基網絡版殺毒軟件，統一升級，為何其他用戶不會出現這故障，對這些用戶進行殺毒，沒有發現病毒。為了確定這些用戶是否由于網絡病毒造成發送大量數據，筆用Netrobocop軟件查看這些用戶的數據包，遠低于警戒水平，說明并沒有大量占用網絡帶寬，由此可見，不能連接郵件服務器并不是由病毒引起的。

3 查交換機

由于我校使用的交換機為低端型號，性能一般，有一些交換機使用年限較長，部分端口有問題，不能使用，筆者懷疑是交換機出現故障，負載太大所致。于是購買了新的交換機，將一些較舊的交換機替換掉，期望能夠解決問題，但事與愿違，新交換機換上后，前幾天出現同樣故障的用戶少了，一段時間后，又恢復到原先樣子。

4 查垃圾郵件

由于學校郵件系統有接至互聯網，用戶經常有收到垃圾郵件，筆者懷疑是否由于垃圾郵件太多導致線路阻塞，于是同時使用以下兩種方法在exchange2003中設置反垃圾郵件。

4.1 使用RBL來部署Exchange 2003 反垃圾郵件

因為SMTP IETF標準的局限性，為了有效地拒絕來自惡意的垃圾郵件來源站點和被利用的垃圾郵件來源站點所發來的垃圾郵件，最直接和有效的辦法就是拒絕該來源的連接。那么獲取到這些垃圾郵件的地址列表并有效的拒絕這些列表發來的郵件是一種可行的方式。

首先進入中國垃圾郵件聯盟(http://anti-spam.org.cn)的網站來查看CBL地址為:cbl.anti-spam.org.cn

打開Exchange系統管理器，打開–〉“全局設置”–〉右鍵 “郵件傳遞” -〉“屬性” ，在“連接篩選”標簽中選擇“添加”阻止名單服務配置，按照圖1的配置進行操作。

在完成“郵件傳遞”的配置后，我們需要在SMTP服務器上本啟用此篩選。打開Exchange系統管理器 在“服務器” – “協議” – “SMTP” – “默認的SMTP服務器”右鍵“屬性” 在“常規”標簽的“IT地址”后點“高級”，然后“添加”，編輯并勾選“應用連接篩選器”后“確定”完成所有的操作。

4.2 用智能郵件篩選器篩反垃圾郵件

智能郵件篩選器，IMF (Intelligent Message Filter)是微軟使用Microsoft Research技術通過對郵件進行掃描然后判定SCL(Spam Confidence Level:垃圾郵件信任級別)分值來判斷郵件是否為UCE(unsolicited commercial e-mail:非請求商業電子郵件)從而達到減少垃圾郵件的目的。IMF內部有一個字典庫，在掃描郵件的過程中通過對比字典庫來判斷郵件的SCL值，SCL值從0到9，(也有-1的時候，組織內之間相互傳送的郵件SCl值為-1)SCL值越高意味著就越近似一封垃圾郵件，就目前的效果來看IMF不愧為智能郵件篩選器，判斷SCL值得準確率非常高。

在Exchange 2003 SP2之后智能郵件篩選器是默認安裝的，我們可以在Exchange管理器中的全局設置-郵件傳遞-智能郵件篩選中啟用它。(如圖2)

從上面我們可以看到兩個閥值的設置選擇和一個處理方式的選擇。

阻止SCL分級大于或者等于以下值得郵件是指當IMF通過對郵件的掃描判定的SCL值大于或者等于你這里選擇的數值的時候該郵件將被阻止;移動SCL分級大于或等于以下值的郵件，是指將這個分值范圍內的郵件傳送至用戶的“垃圾郵件文件夾”。需要注意的是用戶的客戶端是使用MAPI方式的Outlook 2003或者OWA才可以。

注:此處設置的分值必須小于上面設置的阻止分值。

需要在Exchange 網關服務器的SMTP虛擬服務器上啟用智能郵件篩選才能發揮功效。如圖3。

以上就上完成了對Exchange Server的IMF基本設置。

另外，發件人篩選、收件人篩選和連接篩選由于不符合我校的使用情況，就沒有進行設置。

使用以上設置后，用戶反映outlook2003中收到的垃圾郵件少了很多，這也算是無意得到的一項收獲，但個別用戶無法連接郵件服務器的故障依然存在。

5 查DNS設置

以上問題都不是，那么問題出在哪里呢?筆者查看郵件服務器的事件查看器，發現在系統有一個錯誤，如圖4。

通常，記錄這些錯誤信息的原因是:Netlogon 服務未從擁有正在注冊的記錄所在區域的 DNS 服務器那里收到“success”消息。Netlogon 服務接收不到“success”消息的原因有以下幾個:

1)域控制器配置:域控制器的傳輸控制協議/Internet 協議 (TCP/IP) 屬性中的 DNS 服務器項未正確配置。

2)連接:此域控制器與擁有這些記錄要在其中進行注冊或取消注冊的區域的 DNS 服務器之間不存在 Internet 協議 (IP) 連接或傳輸控制協議/用戶數據報協議 (TCP/UDP) 連接。

3)DNS 服務器配置:如 Request For Comments (RFC) 2136 規范中所述，DNS 服務器無法接受動態更新或者未配置為接受動態更新。如果域控制器使用的 DNS 服務器對于 Netlogon 服務嘗試在其中注冊或取消注冊的區域不具有權威，則該 DNS 服務器必須能夠(向此域控制器)提供對于受影響區域具有權威的 DNS 服務器的 IP 地址。

難道是DNS設置有誤，查看DNS的正向查找區域及反向查找區域中的記錄，主機名都是正常的校內用戶名，重新設置好郵件交換器(MX)，重啟服務器，故障依舊。再次查看DNS設置，發現在根提示中服務器列表中有一些空服務器名，將其刪除;消除DNS緩存，步驟如下:在菜單中選擇“查看”，高級—〉右擊“緩存的查找”—〉選擇“清除緩存”; 設置 DNS區域的動態更新，步驟如下:右擊選擇DNS上區域—〉選擇“屬性”—〉選擇“常規”中的“允許動態更新”，選是— 〉然后按 “確定”—〉在本機的DHCP服務器中—〉右擊選擇DHCP服務器—〉選擇“屬性”—〉選擇“DNS”—〉選擇“為不支持動態更新的DNS客戶啟用更新”。針對netlogon服務出錯，將netlogon服務重新啟動，再次檢查出故障的客戶端，發現故障己排除。

6 尋根問底查原因

故障雖然解除，但是為什么會出現這樣的現象呢?筆者查閱了一些資料，發現該故障主要是由于DNS緩存出錯引起的，在win2000以上的MS系統中，系統會自動的將從DNS服務器上的查詢結果保存在本地的DNS緩存中(每次啟用DNS緩存時，Hosts文件中記錄也會被載入緩存中)，那么下次再有重復的查詢請求，系統會優先查詢本地緩存，如果已有對照的條目則不再向DNS服務器發起請求，緩存中無記錄時才查詢DNS服務器。本來設定此DNS緩存的目的是為了能減少DNS服務器的負荷，不用為同一個域名解析多次，也同時能加快客戶主機上的訪問速度。在DNS緩存中記錄條目每隔一段時間將被更新一次，長時間不用的條目將被丟棄，這個時間間隔稱為生存時間(TTL)。默認情況下，得到肯定響應的條目TTL為86，400 秒(1天)，否定響應的TTL win2000下是300秒(5分鐘)，在winXP和2003中 是 900 秒(15分鐘)。正是由于這個否定響應的TTL時間存在，所以才造成了故障主機在得到一次否定的DNS解析之后一段時間內無法再到DNS服務器上查詢，只有等TTL時間過后，這條否定的記錄被清除，才能恢復。同時根提示中服務器名中有一些空服務器名列表，用戶在使用DNS服務時，從根提示上獲取的服務器地址不能正確響應，用戶電腦不斷發出請求，造成緩存溢出錯誤。

通過這次故障排查，我們認識到，網絡的結構類型復雜多變、構成網絡的設備繁多、基于網絡的應用也千差萬別，因此網絡的故障診斷與排除沒有明確的規章可以遵循，要建立一個完整的故障管理日志記錄機制:1) 記錄并定義故障，按照故障卡的形式進行記錄。2) 充分收集信息，了解網絡過去、當前的狀態和運行情況，信息的充分與否依靠以往網絡文檔備案工作是否詳盡。3) 確定可能的原因，根據故障的表象，結合自身經驗或以往故障卡以往的記錄，判定故障發生的可能原因。4) 制定方案，制定故障排除方式，應充分考慮該方案對網絡正常運行部分的影響。5) 執行方案，方案執行前進行相應的數據或設置備份，為了避免不必要的反復以及能對所做的改動復員，一定要認真仔細的記錄的每一步對網絡或設備造成的變化情況。6) 分析結果，對網絡的運行進行驗證，故障是否消失，有無對網絡其它部分造成影響，如果結果沒有解決繼續制定、執行方案。7) 故障總結，對故障產生原因、排除過程進行總結，并記錄于故障卡。

參考文獻:

[1] 于存江.李克明Windows Server中DNS的層次結構和名稱解析的實現[J].長春大學學報，2008(2).

[2] 徐春華.網絡故障的幾種有效排除方法[J].微型電腦應用，2004(12).

[3] 龔偉，張本成.Internet抗垃圾郵件技術研究[J].甘肅科技，2006(8).