虛擬 SMTP 伺服器不中繼郵件
在我們的 LAN 中，我們有一個裝有 IIS 7 的開發盒，其中安裝了 SMTP 虛擬伺服器。所有開發應用程序都將外發郵件發送到這個虛擬 SMTP 伺服器，然後它又將郵件中繼到我們的內部 Exchange 2007 伺服器。或者，至少它曾經如此。我們的網路工程師最近用另一台更換了我們的 Exchange 伺服器，現在郵件不再中繼。
奇怪的是，在我們的生產環境中，我們有類似的設置。所有出站郵件都發送到虛擬 SMTP 伺服器（相同版本的 IIS），該伺服器僅通過 Internet 將郵件中繼到同一 Exchange 伺服器。出站郵件正在生產環境中工作。我已經嘗試在我們的開發機器上鏡像每一個設置，包括將智能主機更改為 Exchange 機器面向 Internet 的主機名，並且郵件繼續在隊列中徘徊。
開發框能夠成功解析智能主機的名稱，我可以通過該框的 25 埠連接到 Exchange 伺服器。
由於完全不熟悉 Exchange 並且對 SMTP 不太熟悉，我對如何解決此問題一無所知。網路工程師也無法弄清楚。什麼可能導致這不起作用？
這是我的虛擬 SMTP 伺服器設置。
在傳遞選項卡下，SMTP 伺服器的出站安全對話框中，選擇“集成 Windows 身份驗證”，並輸入有效的使用者名和密碼。使用者名以 Windows 域 (domain\username) 為前綴。選擇 TLS 加密。
在傳遞選項卡的高級對話框下，我們有以下設置：
- 偽裝域：mycompany.com（我試過刪除它無濟於事）
- 完全限定域名：mycompany.local（我也試過 mycompany.com）
- 智能主機：myexchangeserver.mycompany.local（我也試過它的公網域名）
- 直接傳遞和反向 DNS 查找選項被禁用
就 Exchange 設置而言，我不確定要查找什麼，但我可以訪問該框，並且可以在必要時發布其相關設置。
與其戳黑盒子並想知道它為什麼不起作用，不如在 SMTP 中繼機器上安裝“網路監視器”或 Wireshark 並嗅探一些 SMTP 流量。您將在大約 30 秒內找出您的郵件被拒絕的原因。這將是你阻力最小的道路。盒子想告訴你哪裡出了問題，你只需要看看。
你的“網路工程師”應該早點找到嗅探器，IMO。嗅探線路上的流量對某些人來說似乎是“禁忌”，但這通常是在 SMTP 等人類可讀協議中找出問題根源的最佳方法。