The tag ble end 小時 mage 發現 分析 判斷

前端時間處理過一個生產環境中的一個問題，該問題不是很復雜，但是如果不能理清思路是比較難找到方向的。下面我將問題處理過程大致分享一下。

一、環境情況

1、WIndows 2012 R2+Exchange 2016 CU2。
2、郵件流：Internet<——>郵件網關【Symantec SMG】<——>Exchange server。

二、問題現象
Exchange通訊組設置了發送郵件需要驗證【也就是說RequireSenderAuthenticationEnabled被設置為True】，但是第三方郵箱【例如：163或QQ】仍然能夠給Exchange通訊組發送郵件，並且通訊組中的組成員還會收到郵件。

三、問題處理過程

剛接到這個問題，第一反應就是，首先檢查一下通訊組的權限設置是否是開啟了RequireSenderAuthenticationEnabled，然後再判斷這種情況是個別通訊組還是全部通訊組均是這種情況。
1、首先檢查了所有通訊組的設置，均開啟了RequireSenderAuthenticationEnabled。並且測試了好幾個通訊組均是這種情況。

2、Exchange郵件傳輸都是通過傳輸代理Agent來實現的，使用命令Get-TransportAgent查看是否有Agent工作不正常，或者是有什麽其他Agent搞鬼。通過獲取結果看到，TransportAgent沒有任何問題。

3、接下來，有通過命令查看了發件人篩選，均沒有問題。

4、嘗試手動創建一個傳輸規則，規則內容是阻止任何外部用戶給特定通訊組發送郵件。通過測試結果仍然是外部用戶能夠給通訊組發送郵件。各種嘗試後，到這來開始懷疑是不是服務器問題或者傳輸服務出現問題。默認情況下，傳輸服務器在Exchange服務器上緩存時間是4個小時。接下來，重啟了傳輸服務，問題依然存在。
5、查看了服務器運行時間為570天，也就是說服務器長時間未重啟，懷疑是不是安裝了補丁沒有重啟。於是將數據庫副本切換到備用節點，然後逐一重啟服務器。重啟完成後測試，問題依然存在。

6、沒有辦法了，這個問題肯定是哪裏遺留掉了，或者說是產品Bug。通過查看Exchange 2016 CU3-CU11修復的問題列表中，根本沒有關於這個問題的描述。那麽就不應該是產品Bug。

7、最後沒有辦法了，只能看傳輸日誌了。之前對Exchange的傳輸過程研究過，正常情況下，當一封通訊組郵件發送到Exchange服務器時，Exchange服務器會進行一個Expand通訊組成員展開動作。如下：

而通過發送測試郵件，使用外部郵箱給通訊組發送測試郵件，然後使用命令查看郵件投遞記錄，發現在Exchange服務器上並沒有執行Expand組地址展開動作，而是直接將郵件投遞到了對應郵箱中。這說明什麽問題呢，大膽猜測通訊組郵件在到達Exchange服務器之前就將組成員展開了，這種情況下就會是發送給通訊組的郵件直接投遞到了組成員郵箱，從而繞過了通訊組驗證機制。
8、為了驗證我的猜測，目前大致方向能夠定位在是郵件網關上替Exchange幹了一個通訊組成員Expand的事情。於是接下來查看SMG的配置。在SMG的活動目錄集成裏面看到了SMG上啟用了“Enable Distribution Expansion”【啟用分發列表擴展】功能。

9、將SMG的啟用分發列表擴展功能，關閉後，然後測試給通訊組發送郵件，一切恢復正常。然後通過命令查看傳輸日誌也能夠正常捕獲到Expand動作。

四、建議
1、在使用郵件網關時，一定要註意關於通訊組方面的設置，設置不當會議導致垃圾郵件。
2、此案例反過來，可以作為一種解決讓Exchange通訊組接收外部郵件的一個解決方法。

外部用戶能夠給Exchange通訊組發送郵件排錯分析