如何在 Zimbra 中按 IP 位址限制出站電子郵件中繼

若要限制哪些系統可以透過 Zimbra MTA 傳送未經驗證的出站郵件，請將該伺服器的zimbraMtaMyNetworks屬性設定為受信任 IP 位址或 CIDR 網路的短允許清單。保留環回位址，保留任何仍需要中繼的現有受信任主機，並刪除您不再打算信任的大範圍位址。然後重新載入 Postfix，並分別測試一個已批准的來源和一個未批准的來源。

此設定控制無需 SMTP 驗證即可轉接郵件的受信任 SMTP 用戶端。它不會阻止所有已通過身份驗證的 Zimbra 使用者發出的出站郵件，也不會設定下一跳郵件伺服器。如果您希望漫遊郵件用戶端進行身份驗證或限制特定使用者帳戶，請改用相應的身份驗證或郵件原則控制。

IP位址白名單控制什麼？

Zimbra 的郵件傳輸代理程式 (MTA) 使用 Postfix。在 Postfix 中，來源位址符合的用戶端mynetworks會被視為可信任轉送用戶端。 Zimbra 透過 `<host>` 標籤公開此清單zimbraMtaMyNetworks。清單中的主機無需身份驗證即可向外部目標發送郵件，因此每個條目都代表著一個有意義的信任決策。

不要將允許清單與中繼主機混淆zimbraMtaRelayHost。允許清單決定哪些 SMTP 用戶端可以透過此 MTA 進行中繼。中繼主機是 MTA 將非本地郵件轉送到的上游伺服器，例如當網路供應商要求使用智慧主機時。更改其中一個並不會改變另一個的功能。

Zimbra 技術中心頁面描述了此屬性和相關命令，但部分內容標記為正在開發中或已存檔。在套用變更之前，請根據您已安裝的 Zimbra 版本和部署設計確認其行為。以下範例使用 Zimbra 命令列工具作為zimbra服務帳戶，這與 Zimbra 的 MTA 指南一致。

更改設定之前

確定接收來自您計劃允許的系統的 SMTP 請求的 MTA 主機。在多 MTA 環境中，確定哪些 MTA 處理這些連接，並計劃在每個相關伺服器上進行變更。
找到 MTA 實際看到的固定來源 IP 位址。如果應用程式位於 NAT 之後，請使用其公用網路出口位址，而不是其私人 LAN 位址。如果 IP 位址頻繁更改，則需要持續維護僅包含 IP 位址的白名單。
記錄目前的 Zimbra 屬性和有效的 Postfix 值。在確認哪些服務依賴目前條目之前，請勿僅用新地址取代現有清單。
安排適合您郵件服務的維護窗口或變更窗口，並保留一份與原始值完全一致的回滾副本。

使用單主機 CIDR，例如/32IPv4 位址。例如，`1234.1234.1234.12344`198.51.100.25/32代表一個 IPv4 主機；此位址僅供文件參考，切勿將其複製為實際伺服器位址。更廣泛的範圍，例如 `1234.1234.1234.12344`，/24信任該子網路中的所有位址。請勿為了測試成功而新增公共網路或大型提供者範圍。

如何設定 Zimbra 中繼允許列表

1. 檢查配置值和有效值

登入 MTA 主機並切換到 Zimbra 服務帳戶。將 `<server name>` 替換mta.example.com為安裝zmhostname指令傳回的確切伺服器名稱。

su - zimbra
zmhostname
zmprov gs mta.example.com zimbraMtaMyNetworks
postconf mynetworks

第一個查詢讀取 Zimbra 伺服器物件儲存的值，postconf顯示有效的 Postfix 設定。保存這兩個輸出。如果 LDAP 屬性未設置，Postfix 可能使用預設值，因此不要假設空查詢意味著沒有受信任的網路。在繼續操作之前，請檢查有效值以及您的版本配置行為。

2. 建立最小完整列表

建立一個列表，其中包含回環位址以及所有真正需要未經身份驗證的轉送來源。例如，對於一個僅接受來自本機主機和一個固定應用程式主機的轉送的伺服器，清單格式如下：

127.0.0.0/8 198.51.100.25/32

將範例位址替換為 MTA 可見的真實位址。僅在確認需要後才包含伺服器必要的本機介面或其他受信任服務。如果只需信任一台伺服器，請避免保留範圍過大的辦公室子網路；盡可能將其簡化為主機條目。

3. 在正確的 MTA 上設定值

用於zmprov ms設定伺服器級屬性。此指令會取代原有值，因此請包含所有要保留的項目，包括回環位址：

zmprov ms mta.example.com zimbraMtaMyNetworks '127.0.0.0/8 198.51.100.25/32'

對於多個 IP 位址，請將完整的已核准清單放在帶有引號的值中，並以空格分隔。請勿直接執行範例命令。如果您的設定依賴全域值、伺服器級覆蓋、IPv6、多個 MTA 或特定版本行為，請在設定屬性之前驗證該部署中繼承和產生的 Postfix 配置是如何運作的。

4. 重新載入 Postfix 並確認活動設置

變更 Zimbra 設定後，使用 Zimbra 服務帳戶重新載入 Postfix，然後再次查詢生效值：

postfix reload
postconf mynetworks
zmprov gs mta.example.com zimbraMtaMyNetworks

輸出結果應與您預期的允許清單相符，包括環回位址。如果 Postfix 報告網路格式錯誤或值不一致，請先停止並解決該設定問題，然後再測試郵件流。 CIDR 項目必須使用正確的網路邊界；對於單一主機，請使用主機位址/32，而不是包含相鄰主機的網路遮罩。

如何驗證限制是否有效

使用與實際應用程式相同的網路路徑和 SMTP 監聽器，從受控的授權系統進行測試。向您控制的、位於 Zimbra 網域之外的郵箱發送郵件。確認授權主機可以提交郵件，且 MTA 日誌顯示郵件已成功接收或投遞。 Zimbra MTA 活動通常會被記錄/var/log/zimbra.log；請檢查相關的時間戳記和來源 IP 位址，而不僅依賴郵件用戶端的成功訊息。

然後從一台不在允許清單中且未經身份驗證的主機進行測試。預期結果是，當嘗試向非本地收件者發送郵件時，中繼請求會被拒絕。檢查 MTA 日誌，尋找被拒絕的連線以及 Postfix 偵測到的來源位址。未經身份驗證的用戶端可能仍可向本機 Zimbra 收件者發送郵件；這是正常的郵件接收行為，並不能證明它可以中繼出站郵件。

此外，還要測試先前清單中所有合法的應用程式。應用程式提交失敗通常意味著錯誤的來源位址被添加到了白名單中、舊的受信任依賴項被移除，或者應用程式需要 SMTP 身份驗證。如果用戶端在不同網路間漫遊或其出口 IP 位址不穩定，那麼基於 TLS 的 SMTP 驗證通常比重複更改 IP 白名單更容易管理。

如何回滾或檢查故障

如果已批准的應用程式停止發送，請恢復已儲存的確切值，而不是添加猜測的子網路。使用 `postfix apply` 指令套用更改zmprov ms，重新載入 Postfix，並使用 `postfix confirm` 指令確認生效值postconf mynetworks。檢查負載平衡器、NAT 閘道、容器主機或出站代理程式是否在到達 MTA 之前更改了來源位址。

回應Relay access denied也可能意味著客戶端未通過身份驗證，且其來源 IP 不在受信任清單中。對於普通電子郵件用戶，應在設定 SMTP 提交時啟用身份驗證，而不是將所有用戶網路都新增至允許清單zimbraMtaMyNetworks。範圍過廣的允許清單會擴大未經身份驗證的中繼面，如果受信任的網路中包含未管理的設備，則可能會使伺服器面臨被濫用的風險。

如果 MTA 值看起來正確但行為沒有改變，請確認您已編輯接受連線的伺服器，重新載入已成功，且沒有其他 Postfix 實例或網路裝置正在處理 SMTP。請勿直接編輯 Zimbra 產生的 Postfix 檔案作為永久解決方案；設定管理可能會重新產生這些檔案。當 LDAP 值和執行時間配置不一致時，請查閱您所在版本的 Zimbra 管理文件或聯絡支援管道，以取得特定於該版本的操作步驟。