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でインターネットメールを受信する一般的な代替手段ではありません。

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ホストが存在する場合があります。受信者のWebサイトサーバーがメールを受け付けると決めつけるのではなく、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ルートがない場合、IPv4は機能するのにIPv6の試行が失敗する可能性があります。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の管理者ガイドには、DNSベースの配信が有効になっていない場合は、リレーホストを設定する必要があると記載されています。

多くのプロバイダは、STARTTLSを使用したポート587での認証済み送信を提供していますが、リレーのドキュメントが正式な情報源となります。リレーによっては、ポート465、IPアドレスの許可リスト、またはプロバイダ固有のコネクタが必要となる場合があります。ポート587が常に開いている、あるいは任意のパブリックSMTPサーバーをリレーとして使用できると想定しないでください。認証情報はサポートされている保護された構成に保管し、閲覧できるユーザーを制限し、サポートチケットやシェル履歴にリレーのパスワードを記載しないでください。

リレーの設定後、管理対象のメールボックスにテストメッセージを送信してください。Zimbraのメールログで、接続がリレーホストと想定されるポートに正しく確立され、必要に応じてTLS/認証が成功し、リレーがメッセージを受信していることを確認してください。SMTPエラーが返された場合は、ポート25のタイムアウトではなく、認証、送信者ポリシー、TLS、またはリレー権限の問題として、その応答をトラブルシューティングしてください。

遅延キューを再試行すべきタイミングはいつですか？

根本原因が修正され、宛先またはリレーへの直接テストが成功したら、キューの再試行を要求します。Zimbraアカウントから、postqueue -fPostfixにキュー内のメッセージの配信を試行するように指示します。

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接続を完了するまで待機する時間を制御するものです。タイムアウトを長くしても、ブロックされたルートが機能するわけではなく、配信試行の待ち時間が長くなる可能性があります。また、症状を隠すためにキュー内のメッセージを削除したり、キューの有効期間を変更したりすることも避けてください。メッセージが設定されたバウンス有効期間に近づいたら、影響を受けるユーザーに配信が遅れていることを伝え、ルートを復元する間、キューの証拠を保持してください。