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パスが使用されていますが、古いインストールでは が使用されている場合があります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

これらの行は文脈に沿って解釈してください。1つの宛先への接続タイムアウトが繰り返される場合は、接続性またはリモートサーバーの問題が考えられます。名前解決エラーはDNSの問題を示しています。リモートでの一時的な拒否またはレート制限の場合は、待機するか、受信側プロバイダに問い合わせる必要があるかもしれません。認証エラーまたはTLSエラーは、ローカル構成の問題を示している可能性があります。status=sentエントリが存在するということは、次の配信ホップでメッセージが受け入れられたことを意味しますが、受信者がメッセージを読んだことや受信トレイに届いたことを証明するものではありません。

キューが急速に拡大している場合は、再試行を繰り返す前に、送信量の多い送信者または侵害されたアカウントを探してください。Zimbraのスパム対策トラブルシューティングガイドでは、キューの内容を送信者および認証アクティビティと関連付け、不要なメールを削除する前に送信元を特定することを推奨しています。Zimbraのキューとスパム調査の手順を確認してください。

3. Postfixに再試行を依頼する前に原因を修正してください。

ログの証拠に基づいて、問題が一時的なものかローカルなものかを判断してください。サーバーが、影響を受けるメール宛先に対して、名前解決と送信ネットワークアクセスが正常に機能していることを確認してください。ログがリモートのスロットリング応答を示している場合は、そのプロバイダに対して繰り返しフラッシュを実行しないでください。再試行によってプロバイダのポリシーを上書きすることはできません。複数のドメインで同じローカルエラーが発生する場合は、設定を変更する前に、関連する Zimbra MTA の構成とサービスの状態を確認してください。

保留とマークされたメッセージには特別な注意が必要です。通常のフラッシュは、保留されたメールを解放するコマンドではありません。解放する前に、保留された理由と正当なメッセージかどうかを確認してください。破損またはバウンスとマークされたメッセージも個別に処理する必要があります。再試行しても、永続的な拒否が正常な配信に変わるわけではありません。調査中は、キューIDと関連するログエントリを保存してください。

Zimbra のトラブルシューティング資料では/var/log/zimbra.log、MTA の問題を調査する主要な場所として が挙げられており、postqueueやなどのキューユーティリティがリストされていますzmqstat。正確なサービスレイアウトと実行可能ファイルの場所はバージョンによって異なるため、サービスを再起動したり構成を編集したりする前に、インストールされているリリースのドキュメントを確認してください。Zimbraの MTA トラブルシューティングツールを参照してください。

4. Postfixキューをフラッシュする

キューに登録されたメールが正当であることを確認し、ブロック条件を修正または理解したら、キューの実行を要求します。サーバー上に存在するパスに置き換えてください。

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

古いパスを使用するインストールの場合、/opt/zimbra/postfix/sbin/postqueue -f代わりに を使用してください。Zimbra キューのリファレンスドキュメントpostqueue -fでは、フラッシュ コマンドとして記載されています。このリクエストは Postfix にキュー内のメールを試行するように促すものであり、削除操作ではありません。劇的な成功メッセージが表示されずに終了する場合があるため、コマンドの簡潔な出力ではなく、後続のキュー数と配信ログから結果を判断してください。

短時間のネットワーク障害後や一時的な設定の問題が解決された後には、フラッシュを実行するのが適切です。しかし、DNS、ルーティング、リレー、TLS、またはリモート受信サーバーが利用できない状態が続いている場合は、フラッシュを実行しても効果は期待できません。コマンドを短時間で繰り返し実行すると、ノイズが発生し、障害解決に繋がらないまま再試行トラフィックが増加する可能性があります。

5. 結果を確認し、次のステップを選択します。

配達試行のための短い間隔を設けた後、キューの概要を再度確認し、最近のログエントリを調べます。

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

複数の兆候を総合的に確認してください。例えば、延期件数が減少傾向にあること、古いキューエントリが消えていること、status=sent影響を受ける宛先に新しいレコードが追加されていること、そして新たに延期されるメッセージが少なくなっていることなどです。通常の運用中は、キューが空にならない場合があります。1件の配信が成功したからといって、すべての受信ドメインが正常であるとは限りません。

• カウントが減少し、配信ログに承認が表示された場合は、バックログが通常のレベルに戻るまで監視を継続してください。
• 同じメッセージが再び遅延する場合は、繰り返されるエラーメッセージに従って、根本的なDNS、ネットワーク、TLS、リレー、または受信側の問題を修正してください。
• カウントが上昇し続ける場合は、送信ループ、大量メール、またはアカウントの侵害を調査し、再試行する前に新たな迷惑メールを遮断してください。
• 保留または破損したカウントが残っている場合は、それらのメッセージを個別に確認してください。これらのカテゴリに対して、一般的なフラッシュはクリーンアップ操作ではありません。

キューの表示を空にするためだけに、すべてのメッセージを削除しないでください。特定のメッセージが不要または配信不能であることが確認され、ポリシーで削除が許可されている場合は、そのキューIDを保存し、該当するキュー管理手順を実行する前に確認してください。Zimbraは、削除によってユーザーに影響が出る可能性があると明示的に警告しており、メッセージを削除する前にキューの詳細を記録することを推奨しています。Postfixスプールディレクトリからファイルを直接削除することは避けてください。これはキュー管理をバイパスし、メールの状態を損なう可能性があります。

洗浄が成功した場合、何がわかるのか、何がわからないのか

正常な復旧とは、メッセージフローが持続的に改善されることであり、単に一時的にカウントがゼロになることではありません。Postfixは、利用できない、または一時的に接続を拒否しているリモート宛先へのメールをキューに保持し続ける場合があります。flushコマンドは再試行を開始しますが、配信を保証したり、意図的に保留されたメッセージを解放したり、不正な設定を修正したり、SMTPハンドオフ以降、受信者のシステムがメッセージを受け入れたかどうかを判断したりすることはできません。

2026年10月6日現在、引用されているZimbraテクニカルセンターのページには、ここで使用されているキューおよびトラブルシューティングコマンドが記載されていますが、すべてのZimbraリリースで保証される単一の最新パスは提供されていません。特に古い環境やカスタマイズされた環境では、コマンドを実行する前に、ご自身のサーバー上のバイナリの場所と権限の動作を確認してください。