ZimbraでIPアドレスによる送信メールリレーを制限する方法

Zimbra MTA を介して認証なしの送信メールを送信できるシステムを制限するには、そのサーバーのzimbraMtaMyNetworks属性を信頼できる IP アドレスまたは CIDR ネットワークの短い許可リストに設定します。ループバックはリストに残し、リレーが必要な既存の信頼できるホストはそのままにしておき、信頼しなくなった広範囲の範囲は削除します。その後、Postfix を再起動し、承認済みの送信元と承認されていない送信元の両方をテストします。

この設定は、SMTP認証なしでリレーできる信頼できるSMTPクライアントを制御します。認証済みのZimbraユーザーからのすべての送信メッセージをブロックするものではなく、ネクストホップメールサーバーを設定するものでもありません。ローミングメールクライアントに認証を必須にしたり、特定のユーザーアカウントを制限したりする場合は、適切な認証またはメールポリシー制御を使用してください。

IPアドレスの許可リストは何を制御しますか？

ZimbraのMTAはPostfixを使用しています。Postfixでは、送信元アドレスが一致するクライアントmynetworksはリレーの信頼できるクライアントとして扱われます。Zimbraはこのリストをを通じて公開していますzimbraMtaMyNetworks。リストに掲載されているホストは認証なしで外部宛先にメールを送信できるため、各エントリは意味のある信頼判断となります。

許可リストとリレーホストを混同しないでくださいzimbraMtaRelayHost。許可リストは、どの SMTP クライアントがこの MTA を介してリレーできるかを決定します。リレーホストは、ネットワーク プロバイダがスマートホストを要求する場合など、MTA がローカル以外のメッセージを転送するアップストリーム サーバーです。一方を変更しても、もう一方の機能は実行されません。

Zimbraのテクニカルセンターページには、この属性と関連コマンドの説明がありますが、一部の資料は作業中またはアーカイブ文書としてマークされています。変更を適用する前に、インストール済みのZimbraリリースとデプロイメント設計に対して動作を確認してください。以下の例では、zimbraZimbraのMTAガイダンスに従い、サービスアカウントとしてZimbraコマンドラインツールを使用しています。

設定を変更する前に

• 許可するシステムからSMTP送信を受信するMTAホストを特定します。複数のMTAが存在する環境では、それらの接続を処理するMTAを特定し、関連する各サーバーでの変更計画を立てます。
• MTAが実際に認識する固定の送信元IPアドレスを見つけてください。アプリケーションがNATの背後にある場合は、プライベートLANアドレスではなく、パブリックな送信元アドレスを使用してください。IPアドレスが頻繁に変更される場合は、IPアドレスのみの許可リストを継続的に管理する必要があります。
• 現在のZimbra属性と有効なPostfix値を記録してください。既存のエントリに依存しているサービスを確認するまでは、既存のリストを新しいアドレスだけで置き換えないでください。
• ご利用のメールサービスに適したメンテナンス期間または変更期間を設定し、元の値と全く同じ値に戻せるようにバックアップコピーを保管してください。

IPv4アドレスには、 のような単一ホストCIDRを使用してください/32。たとえば、198.51.100.25/32は1つのIPv4ホストを表します。このアドレスはドキュメント専用の例であり、実際のサーバーアドレスとしてコピーしないでください。 のようなより広い範囲を指定すると、/24そのサブネット内のすべてのアドレスが信頼されます。テストを成功させるためだけに、パブリックネットワークや大規模なプロバイダ範囲を追加しないでください。

Zimbraリレーの許可リストを設定する方法

1. 設定値と有効値を確認する

MTAホストにログインし、Zimbraサービスアカウントに切り替えます。mta.example.comインストールzmhostnameコマンドで返される正確なサーバー名に置き換えてください。

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

最初のクエリは、Zimbraサーバーオブジェクトに格納されている値を読み取り、postconf有効なPostfix設定を表示します。両方の出力を保存してください。LDAP属性が設定されていない場合、Postfixはデフォルト値を使用している可能性があるため、クエリが空だからといって信頼できるネットワークがないと決めつけないでください。先に進む前に、有効な値とご使用のバージョンの構成動作を確認してください。

2. 最小の完全なリストを作成する

ループバックアドレスと、認証なしのリレーを実際に必要とする各送信元を含むリストを作成します。ローカルホストと1つの固定アプリケーションホストからのみリレーを受け入れるサーバーの場合、リストの構成は次のようになります。

127.0.0.0/8 198.51.100.25/32

サンプルをMTAから見える実際のアドレスに置き換えてください。サーバーの必要なローカルインターフェイスや追加の信頼できるサービスは、必要であることを確認した後にのみ含めてください。信頼できるサーバーが1台だけの場合は、広範囲のオフィスサブネットをそのままにしておくことは避け、可能な限りホストエントリに縮小してください。

3. 正しいMTAに値を設定します

zmprov msサーバーレベルの属性を設定するために使用します。このコマンドは値を置き換えるため、ループバックを含め、保持したいすべてのエントリを含めてください。

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

複数のIPアドレスを指定する場合は、承認済みのIPアドレスリスト全体を引用符で囲み、スペースで区切って記述してください。サンプルコマンドは変更せずに実行しないでください。設定がグローバル値、サーバーレベルのオーバーライド、IPv6、複数のMTA、またはバージョン固有の動作に依存している場合は、属性を設定する前に、そのデプロイメントにおける継承と生成されたPostfix構成の動作を確認してください。

4. Postfixを再起動し、設定が有効になっていることを確認します。

Zimbraの設定を変更した後、PostfixをZimbraサービスアカウントとして再起動し、有効値を再度確認してください。

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

出力は、ループバックを含め、意図した許可リストと一致するはずです。Postfix が不正なネットワーク形式を報告したり、値が異なる場合は、メールフローをテストする前に、その設定の問題を解決してください。CIDR エントリは正しいネットワーク境界を使用する必要があります。単一のホストの場合は/32、隣接するホストを含​​むネットワークマスクではなく、ホスト アドレスに を付けて使用します。

制限が機能していることを確認する方法

実際のアプリケーションと同じネットワークパスと SMTP リスナーを使用する、管理された承認済みシステムからテストしてください。Zimbra ドメイン外にある、管理対象のメールボックスにメッセージを送信します。承認されたホストがメッセージを送信できること、および MTA ログに受信または配信が成功したことが示されていることを確認してください。Zimbra MTA のアクティビティは通常ログに記録されます/var/log/zimbra.log。メールクライアントの成功メッセージだけに頼るのではなく、関連するタイムスタンプと送信元 IP アドレスを確認してください。

次に、許可リストに登録されておらず、認証もされていないホストからテストを実行します。想定される結果は、ローカル以外の受信者に送信しようとしたときにリレーが拒否されることです。拒否された接続とPostfixが観測した送信元アドレスについて、MTAログを確認してください。認証されていないクライアントでも、ローカルのZimbra受信者への送信は許可される場合があります。これは通常のメール受信であり、送信メールをリレーできることを証明するものではありません。

また、以前のリストに掲載されていた正規のアプリケーションもテストしてください。アプリケーションの送信が失敗した場合、通常は送信元アドレスが誤って許可リストに登録されているか、古い信頼できる依存関係が削除されているか、アプリケーションにSMTP認証が必要であることを意味します。クライアントがネットワーク間を移動したり、送信元IPアドレスが不安定な場合は、IP許可リストを繰り返し変更するよりも、TLS経由のSMTP認証の方が一般的に管理が容易です。

ロールバックまたはトラブルシューティングの方法

承認済みアプリケーションが送信を停止した場合は、推測されたサブネットを追加するのではなく、保存された正確な値を復元してください。 で適用しzmprov ms、Postfix を再起動して、 で有効な値を確認してpostconf mynetworksください。ロードバランサー、NAT ゲートウェイ、コンテナホスト、またはアウトバウンドプロキシが、MTA に到達する前に送信元アドレスを変更していないか確認してください。

応答Relay access deniedは、クライアントが認証されておらず、その送信元IPアドレスが信頼済みリストに含まれていないことを意味する場合もあります。通常のメールユーザーの場合は、すべてのユーザーネットワークをに追加するのではなく、認証付きでSMTP送信を設定してくださいzimbraMtaMyNetworks。広範な許可リストは、認証されていないリレー領域を拡大し、信頼済みネットワークに管理されていないデバイスが含まれている場合、サーバーを悪用されるリスクにさらす可能性があります。

MTA の値が正しいように見えても動作が変わらない場合は、接続を受け入れたサーバーを編集したこと、リロードが成功したこと、および他の Postfix インスタンスやネットワーク アプライアンスが SMTP を処理していないことを確認してください。恒久的な解決策として Zimbra が生成した Postfix ファイルを直接編集しないでください。構成管理によってファイルが再生成される可能性があります。LDAP 値とランタイム構成が一致しない場合は、リリース固有の手順について、Zimbra の管理ドキュメントまたはサポート チャネルを参照してください。

成功した結果とはどのようなものか

• postconf mynetworksループバックアドレスと、意図された信頼できる送信元アドレスまたはネットワークのみを一覧表示します。
• 承認済みの認証不要アプリケーションは、外部のテスト用メールボックスにメールを送信できます。
• 認証されていない、承認されていないホストは、外部受信者に対してリレー拒否を受け取ります。
• 認証済みユーザーとローカル受信メールは引き続き正常に動作しています。
• 記録されたロールバック値と依存サービスの一覧は、今後の変更のために保持されます。

この方法は、送信元IPアドレスに基づいて認証されていないリレーを絞り込みます。SMTP認証、TLS、レート制御、アカウントセキュリティ、監視といった既存の機能を代替するものではなく、1つのパブリックNATアドレスを共有する個々のアプリケーションを区別することもできません。この方法は、特定の制御手段としてのみ使用し、ネットワークの送信やMTAの役割に変更があった場合は、必ず許可リストを確認してください。

情報源

• Zimbraテクニカルセンター：ZimbraMtaMyNetworks
• ジンブラ・テックセンター：ジンブラMTA
• Zimbraテクニカルセンター：メールフローの問題を特定して解決する
• Postfixマニュアル：mynetworks