Postfixの再送設定

今回は弊社のサポートサービスをご利用のお客様からのお問い合わせについてのご紹介です。
「Postfixの再送設定(メールキュー)の条件適用」についてというお問い合わせで、とても興味深いものでしたので検証した結果をお伝えしたいと思います。

概要

Postfixの再送設定について記載します。

Postfixはメールが何かしらの問題で送信できなかった場合、再送を試みる設定があります。
どういうパラメータが影響してどのように再送されるのかを検証してみました。

環境

OSRHEL7.5
MTApostfix-2.10.1-6.el7.x86_64

再送設定について

再送設定パラメータ

再送設定の主要パラメータはこちらです。
※パラメータの設定値はデフォルト値です。

queue_run_delay = 300s
minimal_backoff_time = 300s
maximal_backoff_time=4000s
maximal_queue_lifetime=5d
bounce_queue_lifetime=5d

Postfix Configuration Parameters

再送の流れ

まずは結論から言いますと、この設定で再送される場合は下記のような処理になることが分かりました。

  1. メールを作成
  2. キューがactiveになる
  3. 何らかの原因で送信失敗後、deferredキューに入る
  4. キューマネージャーが起動してからqueue_run_delay(300秒)の間隔でdeferredキューを確認
  5. 確認したキューが再送失敗からminimal_backoff_time(300秒)以上経過してる場合は再送を試みる
  6. 2~4を繰り返し、minimal_backoff_timeの倍(600秒)の条件で5を実施
  7. 2~4を繰り返し、minimal_backoff_timeの倍々(1200秒)の条件で5を実施
  8. 経過時間がmaximal_backoff_time(4000秒)になるまで再送を試みる
  9. 送信失敗してからキュー内の時間がmaximal_queue_lifetimeに達した場合、配達不能とみなす
  10. 送信失敗してからキュー内の時間がbounce_queue_lifetimeに達した場合、配達不能とみなしてバウンスメール(エラーメール)を返す

検証

実際に検証した設定がこちらになります。

再送設定値を決める

5分間隔でチェックして、1回目5分、2回目10分、3回目20分で再送。
3回目で失敗したら諦める設定です。
もし滞留しているキューがある場合、Postfixが再起動されると再起動後の設定が適用されますので、お気を付けください。

queue_run_delay = 300s
minimal_backoff_time = 300s
maximal_backoff_time=1200s
maximal_queue_lifetime=1800s
bounce_queue_lifetime=1800s

設定記述

main.cfにこれらの設定値は記述されてないので、設定ファイルの末尾に追記します。

# vi /etc/postfix/main.cf

サービス再起動

Postfixサービスを再起動します。

# systemctl restart postfix

Postfixサービスの状態を確認します。

# systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
~省略~
   Active: active (running)
~省略~

検証

Postfixの設定を適用するために再起動し、telnetコマンドで送信できないメールを作成し、/var/log/maillogの中身を見ながら確認していきます。
「どのくらい時間が経過しているのか」が重要になるので、時間を中心に据えてログの状況を見ていきます。

15:46:26 再起動

15:47:38 [maillog]telnetコマンド実行時にログ出力された一番最初の時刻
15:48:15 [maillog]rcpt toを打った時刻
15:49:00 [maillog]dataで「.」を打った時刻
15:49:XX postqueueコマンドでキューが存在することを確認
15:50:00 [maillog]送信失敗(status=deferred)
 
15:56:26 [maillog]再送1回目処理開始
15:57:26 [maillog]再送1回目失敗(status=deferred
15:57:XX /var/spool/postfix/deferred/配下に左記の時刻でディレクトリ作成されていることを確認

16:11:26 [maillog]再送2回目処理開始
16:12:26 [maillog]再送2回目失敗(status=deferred)
16:12:XX /var/spool/postfix/deferred/配下に左記の時刻でディレクトリ作成されていることを確認
 
16:36:26 [maillog]再送3回目開始
16:37:26 [maillog]再送3回目失敗(status=deferred)、送信者にメール送信
16:37:XX postqueueコマンドでキューが存在しないことを確認
16:37:XX /var/spool/postfix/deferred/X/の中身がないことを確認

この結果でわかるのは、queue_run_delayの間隔は送信に失敗してからの経過時間ではなく、キューマネージャーが起動した時間(今回の場合はPostfix再起動時)からqueue_run_delay単位でチェックしていることです。
実際にログには出力されていませんが、キューマネージャーがチェックしているであろう時間を入れるとこうなります。

15:46:26 再起動

15:47:38 [maillog]telnetコマンド実行時にログ出力された一番最初の時刻
15:48:15 [maillog]rcpt toを打った時刻
15:49:00 [maillog]dataで「.」を打った時刻
15:49:XX postqueueコマンドでキューが存在することを確認
15:50:00 [maillog]送信失敗(status=deferred)
 
15:51:26 キューマネージャー確認
 
15:55:00 再送失敗(15:50:00)からminimal_backoff_time(300秒=5分)経過
 
15:56:26 キューマネージャー確認
15:56:26 [maillog]再送1回目処理開始
15:57:26 [maillog]再送1回目失敗(status=deferred)
15:57:XX /var/spool/postfix/deferred/配下に左記の時刻でディレクトリ作成されていることを確認
 
16:06:26 キューマネージャー確認

16:07:26 再送失敗(15:57:26)からminimal_backoff_timeの倍(600秒=10分)経過
 
16:11:26 キューマネージャー確認
16:11:26 [maillog]再送2回目処理開始
16:12:26 [maillog]再送2回目失敗(status=deferred)
16:12:XX /var/spool/postfix/deferred/配下に左記の時刻でディレクトリ作成されていることを確認
 
16:16:26 キューマネージャー確認
16:21:26 キューマネージャー確認
16:26:26 キューマネージャー確認
16:31:26 キューマネージャー確認
 
16:32:26 再送失敗(16:12:26)からminimal_backoff_timeの倍々(1200秒=20分)経過
 
16:36:26 キューマネージャー確認
16:36:26 [maillog]再送3回目開始
16:37:26 [maillog]再送3回目失敗(status=deferred)、送信者にメール送信
16:37:XX postqueueコマンドでキューが存在しないことを確認
16:37:XX /var/spool/postfix/deferred/X/の中身が存在しないことを確認

キューマネージャーがチェックする間隔が伝わりましたでしょうか。


再送設定のパラメータやなんとなくの動きは分かっていても、実際にどのような動きになるのかは検証してみて初めて理解できることが多くあるかと思います。
皆さんも是非検証してみてください。

技術情報

商標について

関連サービス

OSS構築支援
OSS保守サポート

お気軽にお問い合わせください。応対時間 9:30-17:30 [ 土・日・祝日除く ]

お問い合わせ
  • X