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

一、環境情況

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通訊組接收外部郵件的一個解決方法。