Zimbraの送信メール遅延を修正：「接続タイムアウト ポート25」
ポート25におけるZimbra送信メールの遅延エラーを診断します。キュー、MX DNS、ファイアウォール、プロバイダブロックを確認し、承認済みのSMTPリレーを設定してください。
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 verboseUFWは、受信トラフィックだけでなく送信トラフィックも管理できます。送信ポリシーが制限的な場合は、番号付きルールを確認し、リモートポート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接続を完了するまで待機する時間を制御するものです。タイムアウトを長くしても、ブロックされたルートが機能するわけではなく、配信試行の待ち時間が長くなる可能性があります。また、症状を隠すためにキュー内のメッセージを削除したり、キューの有効期間を変更したりすることも避けてください。メッセージが設定されたバウンス有効期間に近づいたら、影響を受けるユーザーに配信が遅れていることを伝え、ルートを復元する間、キューの証拠を保持してください。
公式資料
Raspberry Pi 4 に Conduit を使用して Matrix サーバーをセットアップする方法
Raspberry Pi 4上に、Conduit、Docker、NGINX、HTTPS、登録制御、フェデレーション、およびチェック機能を備えた軽量なMatrixホームサーバーをセットアップします。
スケーラブルなマルチサーバー構成向けにJitsi Videobridgeを設定する方法
共有の Jitsi Meet 環境に Jitsi Videobridge サーバーを追加し、登録とファイアウォール アクセスを設定し、ブリッジの選択を確認し、Octo が必要となるタイミングを把握します。
Zimbraサーバーに商用SSL証明書をインストールする方法
Zimbraに商用SSL証明書を安全にインストールするには、CSRを作成し、CAチェーンを構築し、鍵と証明書を検証し、展開し、サービスを再起動し、HTTPSを確認します。
BigBlueButtonのインターフェースとロゴをカスタマイズする方法
BigBlueButtonのデフォルトロゴを変更したり、個々の会議にロゴを追加したり、より広範なインターフェースブランディングにカスタムクライアント構築が必要な場合を理解したりします。
How to Clear Zimbra Audit Logs to Free Up Disk Space Safely
Learn how to identify, archive, compress, and remove old Zimbra audit logs, when to avoid truncating audit.log, and how to verify that disk space and logging recover correctly.
Kopano Dagentの「ストレージサーバーへの接続に失敗しました」エラーを修正する
Kopano dagentストレージサーバーへの接続障害のトラブルシューティングを行うには、サーバーの状態、server_socket、Unixソケットの権限、リモートリスナー、および制御された配信テストを確認します。
ownCloudのファイルロック「ロックメカニズムタイムアウト」エラーを修正する方法
トランザクションロックを特定し、ロックストレージをRedisに移動し、クラスタをチェックし、安全に再テストすることで、ownCloudのファイルロックタイムアウトエラーを修正します。
How to Fix Matrix Synapse Running Out of Memory During Sync
Troubleshoot Matrix Synapse OOM problems during /sync by checking memory pressure, tuning caches carefully, isolating initial sync, and monitoring workers.
Nextcloudでパフォーマンスへの影響を最小限に抑えつつサーバーサイド暗号化を有効にする方法
マスターキーモード、APCu、Redis、またはValkeyによるロック、そしてパフォーマンスへの影響を最小限に抑える段階的な導入により、Nextcloudのサーバー側暗号化を安全に有効化します。