修復 Zimbra 郵件佇列積壓：安全地清除 Postfix 並驗證投遞情況

Zimbra 的郵件佇列刷新操作會指示 Postfix 重試已排隊的郵件。它不會清除佇列、修復 DNS 或網路問題，也不會保證遠端伺服器會接收每封郵件。一個有效的結果是可以衡量的：佇列不再成長，延遲的郵件數量減少或變成成功投遞，並且新郵件可以透過 MTA 發送。

請以管理員身分在 Zimbra 伺服器上執行下列步驟。不同 Zimbra 版本之間的指令和路徑可能有所不同。執行指令前，請檢查主機上的可執行檔路徑；切勿誤用作業系統隨附的 Postfix 安裝。

1. 檢查積壓工作量有多大

使用您網站已批准的管理方法連接到伺服器並切換到 Zimbra 帳戶。隊列摘要實用程式通常安裝在 [此處應填入安裝路徑] /opt/zimbra/libexec/zmqstat。 Zimbra 的佇列文件顯示，它會報告已保留、已損壞、已延遲、已活動和已傳入郵件的數量。

sudo /opt/zimbra/libexec/zmqstat

根據 sudo 配置，請使用 Zimbra 帳戶執行命令，或使用為伺服器配置的精確權限方法。範例摘要可能顯示deferred=240和active=3。這些是計數，並非證明有 240 條訊息永久卡住。幾分鐘後再次比較，並注意哪個類別發生了變化。

接下來，檢查各個佇列條目。許多目前版本使用 ` common/sbin<path>` 路徑；較舊的版本可能使用 `<path>` 路徑postfix/sbin。請使用伺服器上實際存在的路徑。

/opt/zimbra/common/sbin/postqueue -p

如果該路徑不存在，請檢查您的安裝是否包含/opt/zimbra/postfix/sbin/postqueue該路徑，然後將完整路徑替換到以下命令中。 Zimbra 的文檔描述了佇列摘要和詳細postqueue -p清單。佇列 ID 結尾可能帶有星號（表示正在嘗試投遞郵件）或感嘆號（表示郵件已被暫緩）。請參閱 Zimbra 的 Postfix 佇列參考文件。

2. 找出訊息等待的原因

查看 Zimbra 日誌中記錄的最舊訊息的年齡和投遞狀態。延遲訊息正在等待再次嘗試投遞；延遲的原因可能是遠端伺服器、DNS 查詢、網路逾時、TLS 協商或本地路由或中繼設定問題。準確的狀態文字比單獨的佇列計數更有用。

grep -E 'status=(deferred|sent|bounced)|connect to|TLS|SASL|relay=' /var/log/zimbra.log | tail -n 50

請結合上下文解讀這些行。重複與相同目標伺服器連線逾時表示有連線問題或遠端伺服器問題。名稱解析錯誤指向 DNS 伺服器。遠端臨時拒絕或速率限制可能需要等待或聯絡收件人提供者。身份驗證或 TLS 錯誤可能表示本機設定問題。status=sent此條目表示下一跳已接受郵件；但這並不代表收件者已閱讀郵件或郵件已送達收件匣。

如果佇列迅速成長，請在反覆重試之前查找是否有高流量寄件者或被盜用的帳戶。 Zimbra 的反垃圾郵件故障排除指南建議將佇列內容與寄件者和身分驗證活動關聯起來，然後鎖定垃圾郵件來源，最後清除不需要的郵件。請查看 Zimbra 的佇列和垃圾郵件調查步驟。

3. 在要求 Postfix 重試之前，請先修復根本原因。

使用日誌證據來判斷問題是暫時性的還是本地性的。驗證伺服器是否具有正常的網域名稱解析功能，以及受影響郵件目標的出站網路存取權。如果日誌指向遠端限流回應，請避免向該提供者重複刷新郵件；重試無法覆寫其策略。如果多個網域出現相同的本機錯誤，請在變更設定之前檢查相關的 Zimbra MTA 配置和服務運作狀況。

標示為「暫存」的郵件需要特別注意：普通的刷新操作並不會釋放暫存郵件。在釋放任何郵件之前，請先檢查其被暫存的原因以及郵件的合法性。標記為「損壞」或「退回」的郵件也需要單獨處理；重試並不會將永久退回的郵件轉換為成功投遞。調查期間，請保留佇列 ID 和相關的日誌條目。

Zimbra 的故障排除資料指出，/var/log/zimbra.log它是排查 MTA 問題的主要途徑，並列出了諸如 `git queue` 和 `git queue` 之類的佇列實用程式postqueue。zmqstat特定的服務佈局和可執行檔位置取決於版本，因此在重新啟動服務或編輯配置之前，請查閱已安裝版本的文件。請參閱 Zimbra 的 MTA 故障排除工具。

4. 清空 Postfix 佇列

確認佇列中的郵件合法有效，並已修正或瞭解阻塞原因後，請要求執行佇列。請將路徑替換為您伺服器上的現有路徑：

/opt/zimbra/common/sbin/postqueue -f

對於使用舊路徑的安裝，請改用/opt/zimbra/postfix/sbin/postqueue -fZimbra 佇列參考文件postqueue -f中的 flush 指令。此請求會提示 Postfix 嘗試處理已排隊的郵件；它並非刪除操作。此操作可能不會顯示明顯的成功訊息，因此請根據後續的佇列計數和投遞日誌來判斷結果，而不是僅憑命令的簡短輸出。

在短暫的網路中斷或臨時配置問題解決後，進行刷新操作是合理的。但如果 DNS、路由、中繼、TLS 或遠端接收伺服器仍然不可用，則刷新操作不太可能有所幫助。快速重複執行此指令可能會產生雜訊和額外的重試流量，而無法解決故障。

5. 核實結果並選擇下一步

在短暫的投遞嘗試間隔後，重複佇列匯總並檢查最近的日誌條目：

sudo /opt/zimbra/libexec/zmqstat
tail -n 100 /var/log/zimbra.log

同時觀察以下幾個跡象：延遲郵件數量呈下降趨勢、較舊的佇列條目消失、status=sent受影響目的地出現新記錄，以及新延遲郵件數量減少。正常運作期間，佇列可能保持非空狀態。一次成功投遞並不代表所有收件者網域都運作正常。

如果數量下降且交付日誌顯示已接受：繼續監控，直到積壓恢復到正常水平。
如果相同的訊息再次延遲：請依照重複出現的錯誤文字修復底層 DNS、網路、TLS、中繼或接收方問題。
如果計數持續上升：請調查是否有發送循環、大量郵件或帳戶被盜用的情況，並在重試之前阻止新的垃圾郵件。
如果仍有已保留或損壞的計數：請單獨查看這些訊息；一般的清除操作並不能清理這些類別。

不要僅僅為了清空佇列而刪除所有郵件。如果確認某封郵件是不需要的或無法投遞的，且政策允許刪除，請保留其佇列 ID，並在使用對應的佇列管理流程之前進行檢查。 Zimbra 明確警告刪除操作可能會影響用戶，並建議在刪除郵件之前記錄佇列詳細資訊。避免直接從 Postfix 假脫機目錄中刪除檔案；這樣做會繞過佇列管理，並可能損壞郵件狀態。

一次成功的沖洗能告訴你什麼，又不能告訴你什麼？

成功的恢復是指郵件流的持續改善，而不僅僅是某一時刻郵件計數歸零。 Postfix 可能會繼續將發送至不可用或暫時拒絕連線的遠端目標的郵件排隊。 flush 指令會啟動重試；但它無法保證郵件送達，也無法釋放有意保留的郵件，無法修正格式錯誤的配置，也無法確定收件者的系統是否在 SMTP 交接之後接受了郵件。

截至 2026 年 10 月 6 日，引用的 Zimbra 技術中心頁面記錄了此處使用的佇列和故障排除命令，但並未提供適用於所有 Zimbra 版本的統一路徑。在執行命令之前，請務必確認伺服器上的二進位檔案位置和權限行為，尤其是在較舊或自訂部署中。