SPAMリレーサーバ(postfix)の運用と、再送間隔、エラーに至るまで

linux
2022.06.16

この前SPAMリレー用のメールサーバを使ってメールを配送しようとしたら、受付けてから送信処理するまで数分かかっていることに気づいた。なので、設定値の見直しをすることにした。SPAMリレー用メールサーバってどういうことやねん！！は項目１で説明m(_ _)m

  1. メール環境について
  2. メール配送状況
  3. 問題点の洗い出し
  4. postfixの設定見直し
  5. 設定時の挙動

メール環境について

メール配送経路

  • 内部メールサーバは外部メールサーバと直接やり取りせず、メールゲートウェイを中継している
  • メールゲートウェイは内部メールサーバから配信されたメールでSPAM判定されたものを外部に直接配送せずにSPAM判定送信用メールサーバを経由して配送している

配送経路を分けている理由

  • 運用の都合上、内部メールサーバからSPAMが配信されたとしても誤検知等などもあり得るため、自環境内で削除やエラー処理をすることができない
  • メールゲートウェイからSPAMメールを大量に配送するとメールゲートウェイのIPが汚れてしまう恐れがある
  • メールゲートウェイのIPが汚れて通常のメールが送れなくなると問題が大きくなるので、SPAM判定となったメールは別のサーバに身代わりになって配送してもらおう

メール配送経路概略図

メール配送状況

メールゲートウェイ

  • IPが汚れることも無く綺麗に配送処理をしてくれている

SPAM判定送信用メールサーバ

  • 世界的にブラックIPに認定されていた（おめでとうｗｗｗ）
  • 外部メールサーバのIPレピュテーション機能によってそれなりにRejctされてる
  • 4系のエラー（一時エラー）が多いせい（？）でメールキューがアホほど溜まってる
  • メールキューが溜まりすぎているせいで、新規で受け付けたメール配送の処理が遅れている

SPAM判定送信用メールサーバに送られてきている時点で99%SPAMメールであることは間違いないので、メールの配送が遅れたからといって問題になることは無い。（ちなみに3年ほど運用してきて、百万近いユーザーいるが問い合わせが来たことは無い。素晴らしい！！）

このメールサーバで受け取っているメールの種類はザックリ下記のようなもの

  • 誤検知による正常メール（1%以下だと思われる）
  • ID,PASSが流出して乗っ取られたメールアカウントから、リアルなSPAMメール
  • 外部から受信したSPAMメールを、さらに外部へ転送している転送SPAMメール

問題点の洗い出し

誤検知による正常メール

  • メール自体は正常なものなので大量のキューによって配送遅延が発生してしまうのは避けたい
  • SPAM配送専用サーバといえ、誤検知による正常メール配送も発生してしまうため、極力ブラックリストに乗らないように善処したい

リアルなSPAMメール／転送SPAMメール

  • SPAMを配送する用なので仕方ないが、一時エラーとなった場合しつこく配送を試みるので、ブラックリスト判定になる要因の一つだと思っている。そのため、再送処理回数を少なくすることでブラックリストに乗りにくい環境にしたい（想定なので改善するかは不明）

postfixの設定見直し

現行の設定値とその意味

queue_run_delay        = 300s         ## キューされたメールチェック間隔
minimal_backoff_time   = 300s         ## 再送するまでの間隔(2回目は600s、3回目は900s)
maximal_backoff_time   = 1200s        ## 再送する間隔の最大値(4回目は1200s,5回目も1200s…)
bounce_queue_lifetime  = 1d           ## 送信元にエラーを返す期間
maximal_queue_lifetime = 1d           ## 再送を諦める期間
delay_warning_time     = 4h           ## キューに入ったまま送信されずに残っているメールを送信元に警告で返す

文章だと分かりにくいので、時系列で並べてみる

00:00:00  Queue
00:05:00  QueueのCheck　＋　再送処理(300s経過)
00:10:00  QueueのCheck
00:15:00  QueueのCheck　＋　再送処理(600s経過)
00:20:00  QueueのCheck
00:25:00  QueueのCheck
00:30:00  QueueのCheck　＋　再送処理(900s経過)
00:35:00  QueueのCheck
00:40:00  QueueのCheck
00:45:00  QueueのCheck
00:50:00  QueueのCheck　＋　再送処理(1200s経過)
00:55:00  QueueのCheck
01:00:00  QueueのCheck
01:05:00  QueueのCheck
01:10:00  QueueのCheck　＋　再送処理(1200s経過)
01:15:00  QueueのCheck
01:20:00  QueueのCheck
01:25:00  QueueのCheck
01:30:00  QueueのCheck　＋　再送処理(1200s経過)
　：
　：
03:50:00  QueueのCheck　＋　再送処理(1200s経過)
03:55:00  QueueのCheck
04:00:00  QueueのCheck　＋　送信元への警告メール
　：
　：
24:00:00  QueueのCheck　＋　再送の諦め　＋送信元へのエラーメール

こんな感じのようなので、とりあえず警告メールは要らんな。再送諦めるのももっと短くしよう。このような感じに変更。

queue_run_delay        = 300s         ## 現状維持
minimal_backoff_time   = 300s         ## 現状維持
maximal_backoff_time   = 600s         ## 2回目から10分間隔に変更
bounce_queue_lifetime  = 1h           ## 1時間に変更
maximal_queue_lifetime = 1h           ## 1時間に変更

## 行削除 or 0h
delay_warning_time     = 0h           ## 削除すると0hで無効と同義

正直、再送なんかせずにキューすらさせないでも良いような気はするけど、まぁ一応。。。
とりあえずコレで数万通キューが残って、配送処理自体が遅延してしまう。というような状況は避けれるだろう。

設定時の挙動

もともとキューしてたメールはどう処理されるのか

  • A：再起動（config再読み込み）時に全部バウンス処理される（※負荷が心配）
  • B：設定前のMax_queue_lifetime=1dまで保持される
  • C：再起動（config再読み込み）後に、設定後のmaximal_backoff_time=600sでバウンス処理される
  • D：再起動（config再読み込み）後に、設定前のmaximal_backoff_time=1200sでバウンス処理される

答えは「D」でした。

コメント