Postfix、VPN、smarthost：キューはファイアウォールではない

VPN が上がるまでメールをキューに保持するのはスケジューリングの問題で、よくある解決策は Postfix を止め、main.cf を入れ替えて再度起動することです。それは動作しますが、配送をいつ試みるべきかと、どのネットワーク経路がそれを運べるかという二つの要件を混ぜているため、形が間違っています。後者はファイアウォールの決定であり、どの Postfix ディレクティブもそれを代行できません。二つを分ければ、それぞれに小さく検証可能な答えがあります。

リレーの宛先を安定させ、ネットワーク境界で直接配送を遮断し、待機はキューに任せます。

人が一つに混ぜてしまう二つの要件

リレーは Postfix にメールをどこへ渡すかを伝え、relayhost = [smtp.corp.example]:587 はホストとポートを指定し、角括弧はその次のホップで MX による選択を抑止します。経路はカーネルにパケットが行ける先を伝えます。経路制限のない正しい relayhost でも、ルーティングテーブルが許せば Postfix は直接インターネットに届いてしまい、relayhost が誤った正しいファイアウォールはメールを誤った場所へ送ります。どちらも他方を含意しません。

トランスポートマップ、送信者ごとの上書き、フォールバックリレーも同じ読み方が必要です。安定した relayhost は、設定されたすべての配送経路がそれを使う証拠ではなく、リレーを迂回するフォールバック経路は、より巧妙に偽装した同じ障害です。

defer_transports が実際に行うこと

defer_transports は指定されたトランスポート宛のメッセージを保持し、キューの実行がそれらに触れるまで配送を試みません。これはスケジューリングの制御であり、キューのフラッシュがそれを上書きするのは仕様であって欠陥ではありません。独自のトランスポートや別名のリレートランスポートは、そのプログラムが SMTP も話すという理由だけでは対象にならないため、master.cf の実際のトランスポート名を使ってください。通常の再試行は別の仕組みであり、fail-closed の経路では配送の試行が単に失敗してキューに残り、遅延ディレクティブは関与しません。

恒久的な失敗は礼儀正しく待ちません。不正な受信者や拒否された資格情報は、トンネルが現れるまで待つのではなく、バウンスするかハードエラーとして残るので、遅延メールでいっぱいのキューが自動的に安全なキューではありません。

ネットワーク層で経路を強制する

制限はローカル出力の境界か、分離されたネットワーク名前空間の内側に置くべきです。TCP 25 を遮断する規則は 587 や 465 のリレーには何の効果もないため、リレーの実アドレス、トランスポート、ポートを覆う必要があり、有効なら IPv6 も含みます。ループバックとローカル投入の経路は分けておき、キュー自体が動き続けるようにします。トンネルの経路が消えたり別のインターフェース名で再び現れたりしても、ポリシーは閉じたままにすべきです。

インターフェースが上がったという事象は、そこを通じてリレーに到達できる証拠ではありません。確認と配送試行の間にリンクは変わり得るため、リンクを確認してからフラッシュするフックは保証ではなく便宜です。

無害なメッセージ一つで証明する

VPN を落とした状態で無害なメッセージを一つ送り、遅延理由とキュー ID を postqueue -p で確認します。意図した経路を戻して制御されたキュー実行を要求し、メッセージが別の場所ではなくリレーを通って出るかを見ます。次に飛行中に経路を再び壊し、メッセージがキューに戻ることを確認します。ゼロ値は無制限の保持ではなく一度の試行を意味するため、障害がどれだけ続いてよいかを決める前に maximal_queue_lifetime を見直してください。

キューの古さとディスク使用量を監視します。VPN を待つポリシーは、金曜日からキューが増え続けていることに誰も気づかなければ、メール障害になります。

リレー、トランスポート、ファイアウォール規則、寿命をまとめて記録します。その四つが配置を説明し、どれか一つだけでは推測を説明します。