入站郵件流由SMTP虛擬服務器接收的所有郵件和去往運行Exchange Server 2003 的本地服務器上的一個收件人組成。
對於最常被問到的關於入站郵件流的問題，下面的信息爲您提供了答案。
入站郵件流的基本處理過程是什麼?
入站郵件流通過一個Exchange 服務器以下面的方式展開：
1. 發送方SMTP服務器查詢DNS來查找收件人的SMTP郵件服務器的郵件交換記錄(MX)。該MX記錄被解析爲一個對應的主機(A)記錄，該A記錄解析爲收件人的SMTP郵件服務器的IP地址。
2. 發送方SMTP服務器發起收件人SMTP服務器的一個會話(使用25端口)。在一個Exchange 服務器網關上，收件人的SMTP服務器是Exchange 服務器上的SMTP虛擬服務器，該服務器接收入站郵件。
3. 如果該郵件去往它的SMTP郵件域的一個收件人，該SMTP服務器接受該入站郵件，像收件人策略定義的那樣。
4. 當郵件被接受後，該郵件承載在Exchange 服務器上的\Queue文件夾中。該SMTP虛擬服務器提交該郵件到高級隊列引擎，該引擎提交該郵件到郵件分類器。
5. 郵件分類器驗證郵件的收件人，檢查正確的收件人屬性，應用限制，將該郵件標記爲本地傳遞，然後將該郵件傳遞迴高級隊列引擎。
6. 高級隊列引擎提交該郵件到本地傳遞隊列。
7. Exchange 存儲從本地傳遞隊列中接收到該郵件。
8. 郵件消息被傳遞到客戶端(例如Outlook, Outlook Express, 或 Outlook Web Access)。
對於入站郵件流什麼是最小必要條件?
下面是最小必要條件對於入站郵件流來說：
· Exchange 服務器必須能夠訪問Internet在端口25上，該訪問不應該被防火牆或其他網絡設置阻止。匿名連接也應該被允許。
· Exchange 服務器SMTP虛擬服務器應該配置爲使用缺省的設置。
· 對於所有其他的Internet 域，您的公共DNS服務上配置的公共郵件交換資源記錄應該能夠被訪問。該MX記錄應該指向Exchange 服務器，在郵件能夠被髮送或者接收之前必須被驗證。
· 收件人策略必須配置並正確應用。收件人策略通過正確的電子郵件地址將SMTP虛擬服務器和收件人的郵箱連接起來。
如何確定一個問題的範圍?
郵件流問題經常被認爲是郵件不能被客戶端傳遞或接收。某些特定的問題的原因是不同的，例如，一個隊列可能會阻塞或者郵件可能以無法傳遞而返回。找到下面的問題的答案能夠幫助您確定您的Exchange 服務器組織中問題的範圍。
· 它影響一些或全部Exchange 服務器用戶?如果只有一些用戶受到影響，它們有共同的變量嗎?例如，它們是使用相同的客戶端應用程序或者它們都使用同一個本地Exchange 服務器?
· 它影響一個或多個Exchange 服務器?如果多個Exchange 服務器受到影響，這些Exchange 服務器上的核心的windows 服務器組件(像DNS)配置正確嗎?
· 它影響多個Exchange 服務器上的多個用戶嗎?您的Exchange 服務器上承載的所有的SMTP域都受到影響嗎?所有的的用戶都受到影響嗎?
· 該問題什麼時候開始發生?它發生在您第一次注意到該問題時還是已經發生了一段時間而沒有被注意到?
· 如果您目前遇到一個與Exchange 服務器某個特別功能或技術有關的問題，該功能或者技術曾經在您的部署中生效過嗎?如果是的話，它什麼時候停止工作?您知道它上一次正常工作是什麼時候?
· 您更改過什麼?如果它以前工作正常現在工作不正常，有一些設置被更改了。您移動一個或者多個郵箱嗎?創建一個或多個新的用戶?是路由失效了嗎?是某個服務沒有被運行?有隊列發生阻塞嗎?
· 您正在運行的Exchange 服務器的版本是什麼?安裝過哪些服務包或者更新?如果有的話，它們應用到您的組織中的所有同一版本的服務器上了嗎?
· 您有運行任何第三方軟件，像防病毒軟件?您執行過像自定義防病毒篩選那樣，使用事件接收這樣的自定義嗎?
·Windows 服務器組件像DNS、活動目錄、IIS和SMTP工作正常嗎?與這些服務關聯的Windows 服務器(Exchange 服務器必須的)在運行嗎?
· Exchange 服務器上的MX記錄配置正確嗎?
· 收件人策略配置正確嗎?
· 用戶能夠發送郵件嗎?
· 用戶能夠接收郵件嗎?
如果所有的用戶都受到入站郵件流的影響，我該如何做?
在所有的用戶都受到入站郵件流的影響的場景中，考慮下面這些：
防火牆 您有防火牆嗎?該防火牆的配置有沒有發生改變?如果您最近做過更改，加載以前保存的正確的配置。重啓該防火牆或者防火牆服務。如果ISA服務器的Message Screener 被啓用的話，驗證message screening 被正確配置。防火牆上打開了TCP 25端口嗎?(要讓Exchange 服務器郵件流正常工作端口25必須被打開。)郵件在防火牆後工作正常嗎?
Internet 域 Internet 域能發送郵件給您嗎?如果所有的外部域不能發送郵件，驗證Exchange 服務器上的MX記錄，確認和MX記錄像關聯的IP地址是Exchange 服務器或者防火牆的IP地址。如果有一些域無法發送郵件，您收到非送達報告(NDRs)了嗎?
Exchange 服務器承載的域 所有的域都受到影響嗎?如果是的話，檢查收件人策略並驗證對所有承載的域Exchange 服務器是權威的。端口25在防火牆上打開了嗎?檢查是否有發件人收到NDRs。如果有一些域受到影響，收件人策略顯示Exchange 服務器組織對於受影響的域來說是權威的嗎?有任何將阻止郵件到達受影響的域的收件人篩選被配置了嗎?
接收郵件 如果您過去能夠接收郵件，現在遇到問題，嘗試確定該問題什麼時候開始。什麼更改與該問題相關?新的軟件?新的配置?新的用戶?該問題是間歇性的嗎?如果是的話，有沒有一個模式?該問題發生的時候與特定的服務、組件或者第三方應用程序相關嗎?如果不是的話，檢查MX記錄，驗證25端口配置正確，能夠從網絡中的其他計算機識別Exchange 服務器的IP地址。
如果只有一些用戶受到入站郵件流的影響，我該如何做?
在只有一些用戶受到入站郵件流的影響的場景中，考慮下面這些：
服務 爲了保證入站郵件工作正常，下面這些Exchange 服務必須運行：
Microsoft Exchange System Attendant
Microsoft Exchange Information Store
Microsoft Exchange Routing Engine
Simple Mail Transfer Protocol (SMTP)
如果這些服務中的任何一個停止了，重新啓動它們。然後，檢查事件日誌確定該服務爲什麼停止。
隊列 有郵件堆在隊列中嗎?有關更多的信息，請參考該文章後面的問題“我應該監視哪些隊列”。
客戶端 經常地，當同一Exchange 服務器上的只有部分用戶遇到類似問題，原因可能是客戶端軟件。如果是的話，使用通常對他們來說可用的客戶端軟件，驗證用戶能發送郵件給他們自己(或者給同一服務器上其他用戶)。
管理選項 管理員在用戶的特定的組上配置了限制嗎?在入站的郵件上有大小限制嗎?在特定用戶的郵箱上有存儲限制嗎?受影響的用戶能從其他域接受郵件或者它是特定的一個域?使用消息跟蹤，併發送郵件到該用戶，跟隨發生在您的Exchange 服務器組織中的路徑。
我應該監視哪些隊列?
在發生入站郵件流的時候，郵件將經過下面這些隊列。如果隊列有問題，郵件也許不會被傳遞。考慮使用Exchange System Manager 中的隊列查看器來監視狀態和下面隊列的狀況。
郵件暫緩提交 也稱爲預提交隊列。該隊列包含被SMTP服務接受的郵件。該隊列中的郵件還沒有被郵件分類器處理。如果郵件堆積在該隊列中，它可能說明Exchange 服務器的性能問題，或它可能說明事件接收器的問題(像用來屏蔽防病毒的自定義SMTP處理代碼)。
等待目錄查找的郵件 也稱爲預分類隊列。該隊列包含已經過了預提交隊列並等待郵件分類處理的郵件。郵件將堆積在該隊列中，當郵件分類不能處理郵件時。導致郵件分類器不能處理郵件的原因如下：
· 郵件分類器不能訪問全局編錄服務器來獲得收件人信息。
· 全局編錄服務器執行速度很慢。
· 如果這是一個前端服務器，前端服務器上要求的郵箱存儲被禁用。
本地傳遞 包含去往位於本地Exchange 2003 服務器上的收件人郵箱的郵件。如果Microsoft Exchange Information Store 服務沒有接受郵件或者如果它有性能問題，郵件將堆積在該隊列中。
正在排隊等待稍後傳遞的郵件 包含排隊等待稍後傳遞的郵件。郵件位於該隊列有下面這些原因：
· 郵件由舊版本的Microsoft Outlook 發送(像Outlook 2000)。
· 郵件發送到一個已被移動的用戶郵箱。
· 用戶尚未創建郵箱，並且不存在對應於該用戶的主帳戶安全標識符 (SID)。
· SMTP郵件路由的不正確配置引起郵件循環(循環的郵件被移動到該隊列)
暫緩提交的 DSN 郵件 包含等待被Exchange 服務器傳遞的傳遞狀態通知。例如，NDRs也稱傳遞狀態通知 。郵件堆積在該隊列中有下面這些原因：
· Microsoft Exchange Information Store 服務不可用或沒有運行。
· 郵箱存儲沒有被加載。
· IMAIL Exchange 存儲組件存在問題
重試已失敗郵件的隊列 包含隊列提交失敗的郵件。有幾個原因能導致郵件失敗，包括如果郵件損壞或如果系統資源太低。如果郵件出現在該隊列中，檢查您的服務器配置，來判斷您是否有非Microsoft 程序或者安裝了能夠干涉郵件隊列的事件接收器(像病毒掃描器)。如果系統響應很慢，使用Windows 任務管理器來確認進程佔用的系統資源。重啓IIS也許可以臨時解決該問題，同時允許您有更多的時間去確認該問題的根本原因。
這裏只是我向大家推薦的一個思路