修正 Zimbra 出站郵件延遲問題：“連線逾時，連接埠 25”

如果 Zimbra 報告connect to mx.example.net[203.0.113.25]:25: Connection timed out此錯誤，通常表示郵件已到達 Zimbra 郵件佇列，但伺服器尚未與收件者網域的郵件交換器建立 TCP 連線。首先檢查佇列、DNS 和出站網路路徑。在確定是哪個躍點阻塞了連線之前，請勿變更 Postfix 逾時設定或重複刷新佇列。

超時與 SMTP 拒絕不同。「550」之類的拒絕狀態碼表示遠端伺服器已回應並拒絕了郵件；「連線逾時」表示連線嘗試未及時收到回應。原因可能是本地防火牆、雲端或託管服務提供者的出站郵件策略、路由問題、目標地址無法訪問，或較少見的 DNS/地址族問題。

Zimbra 中「連線逾時，連接埠 25」是什麼意思？

Zimbra 使用其郵件傳輸代理程式 (MTA) 來路由外發郵件。當收件者位於組織外部時，MTA 會尋找該網域的郵件交換器，並使用 SMTP 協定連線到該交換器。 Zimbra 目前的 Daffodil 管理員指南將無法投遞的郵件描述為進入延遲佇列，系統會在該佇列中重試投遞。佇列條目和郵件日誌會標識目標位址和錯誤訊息，因此它們是最佳的初始證據。

在典型的郵件流中，公用郵件伺服器之間會透過 TCP 連接埠 25 交換電子郵件。連接埠 587 通常被經過驗證的郵件用戶端用於向出站中繼伺服器提交郵件。只有當您設定了為此目的而授權的中繼服務時，才能將 Zimbra 的中繼路徑切換到連接埠 587；這並不能完全取代透過連接埠 25 接收 Internet 郵件。

1. 該問題是否影響所有收件人，還是僅影響一個域？

在進行更改之前，請檢查延遲隊列。在 Zimbra MTA 主機上，以管理員身分執行下列帳戶命令zimbra：

su - zimbra
postqueue -p

尋找重複出現的逾時訊息，並記下收件者網域、目標 MX 主機名稱和解析後的 IP 位址。在 Zimbra 管理控制台中，開啟「監控」→「郵件佇列」，然後按錯誤類型和收件者網域檢查「延遲」佇列。具體的選單標籤可能因 Zimbra 版本而異。

如果故障集中在一個收件者網域或一個 MX 位址附近，則目標位址可能暫時無法訪問，或者您的伺服器正在過濾連線。如果多個不相關的網域都出現相同的 25 連接埠逾時故障，請先檢查 Zimbra 主機的出口路徑、提供者政策或防火牆。請記錄時間戳記和幾個具代表性的目標地址；尋求協助時，請勿發佈郵件正文或憑證。

2. DNS 是否能將收件者網域解析為可存取的郵件伺服器？

從 Zimbra 伺服器查詢收件者網域的 MX 記錄。替換example.net為故障的域：

dig MX example.net +short

使用傳回的 MX 主機名稱尋找其位址：

dig A mx.example.net +short
dig AAAA mx.example.net +short

一個網域可能擁有多個 MX 主機。請測試 DNS 解析後顯示的實際主機名，而不是假設收件者的網站伺服器接受郵件。如果 DNS 解析後未傳回可用的 MX 目標，請檢查該收件者網域的權威 DNS 設定；切勿在 Zimbra 伺服器上新增虛構的 MX 記錄。

接下來測試 TCP 連線。如果nc已安裝，請使用：

nc -vz -w 10 mx.example.net 25

或者，如果可用，也可以使用telnet mx.example.net 25。成功的 TCP 連線應該會顯示連線成功訊息；SMTP 伺服器隨後可能會顯示歡迎訊息。超時表示 TCP 握手未完成。「連線被拒絕」的結果則不同：遠端主機已回應，但未接受該位址和連接埠上的連線。

對每個 MX 目標重複測試，並在條件允許的情況下同時測試 IPv4 和 IPv6 路徑。如果主機名稱解析到 IPv6 位址，但伺服器沒有可用的 IPv6 路由，則 IPv6 嘗試可能會失敗，而 IPv4 則可能成功。在變更 Postfix 位址族設定之前，請先驗證路由和日誌；任何此類變更都應與版本和部署環境相關。

3. 防火牆或主機提供者是否阻止了出站 SMTP 通訊？

請先檢查伺服器的防火牆策略，不要進行任何變更。在使用 UFW 的系統上：

sudo ufw status verbose

UFW 可以管理出站和入站流量。如果出站策略較為嚴格，請檢查編號規則，確認是否拒絕了到遠端連接埠 25 的 TCP 連線。只有在符合您的安全性原則且伺服器已獲得直接發送郵件的授權時，才會新增範圍較窄的出站允許規則。

主機防火牆可能允許連接，但上游防火牆、雲端安全控制、網路存取控制清單 (ACL) 或託管服務提供者策略可能會阻止連線。請向服務提供者詢問此執行個體是否允許出站 TCP/25 連接，是否有帳戶層級限制，以及是否有發佈或審核流程。策略因服務供應商、帳戶、地區和產品而異，因此本地防火牆檢查通過並不能證明網路路徑暢通。

如果您控制網路防火牆，請檢查其出站規則和日誌，尋找 Zimbra 伺服器的來源 IP 位址、目標 MX IP 位址、協定 TCP 和目標連接埠 25。經驗豐富的管理員可以透過資料包擷取來區分未回應的 SYN 資料包和在返迴路徑上被封鎖的回應資料包，但請僅擷取相關的資料包頭，並保護所有操作資料。切勿以開放入站埠 25 來解決出站逾時問題；這是不同的流量方向。

4. 如果無法直接在 25 號港口交貨，您該怎麼辦？

如果服務提供者不允許直接發送出站 SMTP 郵件，請使用授權的智慧主機或出站中繼。請從中繼業者取得中繼主機名稱、連接埠、TLS 需求、驗證方法、允許的寄件者網域以及任何 IP 位址白名單要求。透過適用於您 Zimbra 版本的 Zimbra 管理方法配置中繼，或遵循您所在組織的 Zimbra 變更流程。 Zimbra 管理員指南指出，如果未啟用基於 DNS 的郵件傳遞，則必須設定中繼主機。

許多服務提供者支援使用 STARTTLS 透過 587 連接埠進行身份驗證提交，但中繼伺服器的文檔才是權威的。中繼伺服器可能需要使用 465 連接埠、IP 位址白名單或服務提供者特定的連接器。切勿假設 587 連接埠開放，或任何公共 SMTP 伺服器都可以用作中繼伺服器。請將憑證保存在受支援的受保護配置中，限制存取權限，並且切勿將中繼伺服器密碼寫入支援工單或 shell 歷史記錄中。

配置中繼後，向您管理的郵箱發送一封受控測試郵件。在 Zimbra 郵件日誌中確認連接已成功連接到中繼主機和預期端口，TLS/身份驗證（如果需要）成功，並且中繼已接收郵件。如果傳回 SMTP 錯誤，請將該回應作為驗證、寄件者原則、TLS 或中繼權限問題進行排查，而不是連接埠 25 逾時。

何時應該重試延遲隊列？

一旦根本原因得到修正，並且直接發送到目標位址或中繼的測試成功，請要求佇列重試。從 Zimbra 帳戶，postqueue -f請求 Postfix 嘗試投遞已排隊的郵件：

su - zimbra
postqueue -f

這可能會觸發大量郵件的投遞嘗試，因此請避免在服務中斷期間重複執行此操作。您也可以在可用時使用管理控制台的佇列控制功能。 Zimbra 文件指出，刷新操作會嘗試投遞延遲佇列、入站佇列和活動佇列中的郵件。之後請檢查幾封郵件，確認延遲佇列的郵件數量正在減少，且日誌顯示郵件已成功投遞或有新的、可操作的 SMTP 回應。

快速決策指南

觀察	可能是下次檢查
一個目標網域逾時	測試每個 MX 主機；檢查目標可達性和遠端過濾。
許多網域在 25 埠上逾時	檢查出站防火牆規則、路由和提供者限制。
TCP 連線成功後，SMTP 回傳 4xx 或 5xx 錯誤。	使用遠端 SMTP 回應來排查政策、信譽或收件人錯誤。
主機提供者已封鎖連接埠 25	請求存取權限或配置已批准的認證中繼。
Relay 接受了測試，但舊郵件仍然排隊等待處理。	查看日誌，重試佇列一次，然後監控投遞和退信通知。

如何確認問題已解決？

使用簡短的驗證步驟：確認 DNS 傳回目標 MX 記錄或中繼記錄；確認與設定的主機和連接埠建立的 TCP 連線成功；發送受控測試訊息；驗證遠端伺服器或中繼伺服器是否已接收該訊息；然後檢查延遲佇列和日誌中是否存在原始訊息。僅憑連線測試成功並不能證明收件者已接收訊息，中繼伺服器成功切換也無法保證訊息已送達收件匣。

不要透過增加 Postfix 的連線逾時時間來「修復」逾時問題。 Postfix 的此smtp_connect_timeout設定控制 SMTP 用戶端等待完成 TCP 連線的時間；延長此設定並不會使被阻塞的路由恢復正常，反而可能導致郵件投遞等待時間更長。此外，請避免刪除已排隊的郵件或更改佇列的生存期來掩蓋問題。如果郵件接近設定的退信生存期，請告知受影響的用戶郵件投遞延遲，並在恢復路由的同時保留佇列記錄。