Postfix 3.10：アップデート、TLSRPT、そして 3.11 への道

Postfix 3.10 の正確なリリース時期を把握する

2026年10月20日時点の調査では、Postfix 3.10は現在の安定版ブランチではありません。その役割を担っているのはPostfix 3.11です。開発元は3.10を レガシーブランチ、ただし、引き続きバグ修正やセキュリティ修正を提供し続けている。公式発表によると、2026年9月7日付けのPostfix 3.10.14が、このブランチで確認できる最新のパッチバージョンとして挙げられている。

この分類により、2つの異なる決定が区別されます。例えば3.10.8から新しい3.10パッチへのメンテナンスアップデートは、選択した機能ブランチを維持したまま、その修正内容を適用します。 一方、3.11へのアップグレードは開発ブランチを変更することになるため、変更された機能、設定の互換性、拡張機能、および運用手順について検証を行う必要があります。メジャーバージョンおよびマイナーバージョンのアップグレードが、すべての本番システムにとって自動的に適切な措置であるとは限りません。

Linuxパッケージについては、表示されているPostfixのバージョンに加え、パッケージのメタデータ、変更履歴、およびOSベンダーのセキュリティ情報も確認してください。そこで、その特定のパッケージにどのような修正が含まれているか、またベンダーがバックポートを文書化しているかどうかを確認してください。 一方、アップストリームの発表はPostfixのリリースについて記述しているものであり、ディストリビューションの一般的なバックポート方針を示すものではありません。

メンテナンス計画においては、まずインストール済みのパッケージのバージョン、リポジトリチャネル、およびローカルでのカスタマイズ内容を記録します。その後、OSベンダーがこのパッケージに対してどの修正を公開しているかを確認します。この照合を行って初めて、未適用の Postfixのアップデート 3.10 内で必要となるのか、あるいは 3.11 への移行を計画することで、技術的なメリットがさらに得られるのか。なお、3.10.14 は上流の参照ポイントであり、特定の Linux システム向けのインストール手順ではありません。

MTAの役割、SMTPポート、およびシステムの制限

Postfixは、 メール転送エージェント (MTA)。PostfixはSMTP経由で電子メールを受信し、ルーティングおよびポリシーの設定に基づいてその後の処理を決定し、メッセージを他のメールサーバーやローカルの配信パスに渡します。このように、PostfixはLinux上のメールサーバーにおけるトランスポート層を形成しています。 しかし、その設定によって、ユーザーがメールボックスをどのように閲覧するか、あるいは不審なコンテンツがどのように評価されるかが自動的に決定されるわけではありません。

IMAP または POP3 サーバーは、メールプログラム向けにメールボックスを提供するものであり、SMTP 転送とは別のコンポーネントです。 同様に、Postfixの機能は、完全なスパムやウイルス対策ソリューションの代わりにはなりません。そのようなシステムは、必要に応じて適切に連携させ、保守・監視を行う必要があります。この区別は実用上重要な意味を持ちます。なぜなら、SMTPテストが成功したとしても、それがメールボックスの受信やコンテンツチェックの品質を保証するものではないからです。

ポート25は通常、メールサーバー間のSMTP通信、つまりパブリックMXの運用に使用されます。 一方、ポート587および465は、メールクライアントからの送信用に割り当てられており、多くの場合、認証と独自のサービス定義が設定されています。Postfixは、これらの役割を組織的な観点から区別するだけでなく、一部の設定については、すべてのSMTPサービスに一律に適用してはならない、あるいは適用すべきではないものもあります。

変更を行うには、管理者権限、Postfix 設定の復元可能なバックアップ、およびキュー、配信期限、連携アプリケーションに合わせて確保されたメンテナンス時間が必要です。また、サーバーが送信を行うのか、パブリック MX として受信を行うのか、あるいはクライアントへの受信提供を行うのかについても確認しておいてください。これら 職務の分離 これにより、Submission にとって適切なプライバシー設定が、誤って一般に公開されているポート 25 を変更してしまうことを防ぎます。

TLSRPTが安全なメール配信機能を補完

Postfix 3.10 では、SMTP クライアントにおいて TLSRPT のサポートがオプションとして提供されています。ドメインは、DNS を通じて集約された TLS レポートの受信先を公開できます。RFC 8460 では、電子メールアドレスおよび HTTPS エンドポイントが許可されています。 Postfix はこの際、TLS ハンドシェイクの成功または失敗のみを報告し、SMTP 接続ごとに最大 1 つの最終ステータスを報告します。接続確立の失敗や、TLS ハンドシェイクの前後で発生した接続の中断は記録されません。

ただし、バージョン番号が3.10であるという事実だけでは、インストールされたPostfixパッケージが実際にTLSRPTを利用できるとは限りません。この機能を利用するには、PostfixがTLSRPTをサポートするクライアントライブラリと、ビルドオプション USE_TLSRPT が作成されました。そのため、構成の計画を立てる前に、パッケージのドキュメント、記載されているビルド特性、および利用可能な追加パッケージを基に、お使いのディストリビューションにこの機能が組み込まれているかどうかを確認する必要があります。

TLSRPTは、配信におけるTLS保護に実際に影響を与えるプロトコルを補完するものです。STARTTLSは、トランスポート層の暗号化のネゴシエーションを可能にします。DANEはTLSAエントリを利用し、そのセキュリティ上の前提としてDNSSECを必要とします。MTA-STSは、期待されるTLSの特性に関するポリシーを公開します。 拘束力のあるDANEまたはMTA-STSの要件が満たされない場合、TLSRPTはそうしたエラーに関する情報を下流に通知することができます。ただし、TLSRPT自体は暗号化や証明書検証を有効にするものではありません。

この際、2つの役割を区別する必要があります。受信側のドメインは、 ruaエンドポイント また、その監視付き受信および受信レポートの分析を自ら運営するか、あるいは委託しています。 一方、レポートを送信するMTAには、適切に構築・有効化されたPostfixに加え、イベントを収集・取得・集約し、レポートを送信するための独立したインフラストラクチャが必要となる。これら2つの役割は組織的に分離される場合があり、レポートを発行するドメイン所有者が、必ずしも同一のシステム上でTLSRPTレポートを自ら生成する必要はない。

したがって、TLSポリシープラグインは、必ずしもすべてのTLSRPTレポートチェーンに含まれるわけではありません。Postfix自体はDANEをサポートしています。特に、送信側のMTAがMTA-STSポリシー情報を smtp_tls_policy_maps を組み込みます。Postfix 3.10 では、このようなプラグインの応答に TLSRPT 関連の属性が追加されていますが、だからといって、すべてのインストール環境でプラグインが必要になるわけでも、すべての 3.10 パッケージに TLSRPT が組み込まれているわけでもありません。

また、TLSRPTはリアルタイムの監視機能ではありません。Postfixのマニュアルでは、エラー通知が届くまでに平均で約12時間かかると記載されており、そのため、このレポート機能は緊急の障害監視とは明確に区別されています。 現在発生している配信の問題については、キューの確認、ログの分析、およびアラート通知が依然として必要です。TLSRPTは、主に、多数の配信試行にわたって繰り返されるパターンやポリシー上の問題を可視化するのに役立ちます。

3.10ブランチでのPostfixのアップデート準備

Postfix 3.10 内のアップデートは、状況が明確なメンテナンス作業です。既存のレガシーブランチを、ディストリビューションが提供するパッチの状態に更新します。作業を行う前に、Postfix の設定をバックアップし、メンテナンスの時間を確保してください。 また、サーバーが送信メールの配信、MXトラフィック、またはSubmissionを提供しているかどうかを確認してください。これらは、状況の把握や復旧計画の策定に大きく影響するからです。

まず、インストールされている、あるいは起動したプログラムによって確認されたPostfixのバージョンを特定し、それを明示的に main.cf 設定されたパラメータ。最初の2つのコマンドは、現状を把握するためのものです。 postfix check 一方、これは管理用のメンテナンスコマンドです。特にファイルやディレクトリの所有権やアクセス権を確認し、存在しないディレクトリを作成することもできます。したがって、ファイルシステムが確実に変更されていないと仮定して実行するのではなく、所定の管理権限で実行してください。

postconf mail_version
postconf -n
postfix check

の出力は postconf mail_version 呼び出されたPostfixプログラムベースのバージョンを指定します。 postconf -n 明示的なパラメータを表示します name=value-「」内の項目 main.cf. これには、現在インストールされているデフォルト設定と値が一致する設定も含まれる可能性があるため、出力結果だけでは、実際にデフォルト設定から逸脱していることを確実に証明するものではありません。また、バージョン変更後にデフォルト値が変更される場合がありますが、その際、以前に設定された項目はそのまま残ります。

また postfix check これは、メールサーバーの設定に対する完全な検証ではありません。 このコマンドは、ディレクトリやファイルの権限に関する問題を報告したり、存在しないディレクトリを生成したりすることがありますが、すべてのパラメータが技術的に正しいかどうかを包括的に評価するものではありません。証明書チェーン、外部マップ、DNS依存関係、フィルタ、認証、および連携サービスの統合については、別途検証する必要があります。

パッケージの更新には、お使いのディストリビューションでサポートされている更新方法を使用してください。そのパッケージのメタデータ、変更履歴、セキュリティ情報などを確認し、そのパッケージにどのような修正やバックポートが含まれているかを確認してください。 これらの情報をアップストリームの発表内容と照らし合わせてください。バージョン番号の一部が省略されているという理由だけで、パッチが適用されていないと推測しないでください。

Postfixのドキュメントに記載されている、プロセス更新に関する特別な要件は、古い開発ブランチからPostfix 3.10.0へのアップグレードに関連しています。内部の配信エージェントプロトコルの変更により、それ以降は少なくとも postfix reload あるいは、一旦停止してから再始動する必要がある。そうしないと、配達員が予期せぬ事態に直面する可能性がある。 smtputf8-属性「警告」。この根拠は、3.10以降のすべてのパッチアップデートに一律に当てはまるわけではありません。

3.10ブランチ内のメンテナンスアップデートについては、代わりに、パッケージ管理ツールがディストリビューションの仕様に従ってサービスを再読み込みまたは再起動済みかどうか、また実行中のプロセスが更新後の状態に対応しているかどうかを確認してください。そうでない場合は、ディストリビューションおよびパッケージで用意されている再読み込みまたは再起動機能を使用してください。 その後、パッケージの動作とは無関係に特定の有効化コマンドを前提とするのではなく、メンテナンスウィンドウ内のキューとログを確認してください。

DNS およびレポートインフラストラクチャを用いた TLSRPT の計画

TLSRPT では、レポートを受信するドメインの役割と、レポートを送信する MTA の役割を別々に設定する必要があります。自身のインフラへの配信に関するレポートを受け取りたいドメインは、 ruaエンドポイント DNS内に登録され、その受信、保護、保存、および解析が確実に管理されるようにします。したがって、TXTレコードは、他の送信元MTAが集計レポートをどこに送信すべきかを指定するものです。

TLSRPTレポートを独自に生成するMTAには、それとは別に、TLSRPTクライアントライブラリと USE_TLSRPT が構築されました。「Postfix 3.10」という表記は、その機能がどのブランチから利用可能になったかを示すだけであり、特定のバイナリパッケージのビルド特性を証明するものではありません。したがって、この機能を計画する前に、ディストリビューションのパッケージドキュメント、ビルド情報、および利用可能な追加パッケージを確認してください。

参加している各Postfixシステム上で、ローカルの コレクター 組み込まれたTLSRPTライブラリからローカルのUnixドメインソケットを介して渡されるイベントを受け取ります。これとは別に、フェッチャー、中央集約システム、およびレポート生成システムを運用することができます： これらは収集されたデータを取得し、所定の要約を作成して、受信ドメインが公開している宛先にレポートを送信します。これらの下流コンポーネントは他のシステムに集中化される可能性がありますが、各Postfixシステム上のローカルコレクターはそれによって置き換えることはできません。

A ポリシー・プラグイン 特定の送信側シナリオにおいてのみ、追加で必要となります。MTAがMTA-STSポリシー情報を smtp_tls_policy_maps、そのために使用されるプラグインは、TLSRPTに関連する属性をサポートしている必要があります。DANEはPostfix自体がサポートしています。したがって、受信ドメインのDNSエントリも、適切に構築されたMTAによるレポート処理も、一律にMTA-STSプラグインを前提とするわけではありません。

以下の項目では、レポートの受信者に関するDNS構文についてのみ説明しています。 example.invalid これは意図的に非生産的なドメインであり、そのまま転用してはなりません。このタグ v=TLSRPTv1 この手法の特徴は； rua ここでレポートの送信先を指定します。RFC 8460 では、電子メールに加えて HTTPS エンドポイントも許可されています。

_smtp._tls.example.invalid. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

TLSRPT レポートの場合、Postfix 3.10 ではヘッダーを次のように定義しています TLS-Required: no、これにより、レポートの送信時にTLSのセキュリティレベルが「may」に低下できるようになります。 この厳格に限定された例外措置は、エラー報告が厳格なTLS要件によって阻まれることを防ぐものです。これは、通常のビジネスメールやユーザーメールに対するTLS要件を緩和するよう指示するものではありません。

提出データを保護し、TLSオプションを的確に評価する

セッティング smtpd_hide_client_session これは、認証済みのメールクライアントからの送信を対象としています。この機能が有効になっている場合、SMTPサーバーはクライアントセッションからの情報を含まない「Received:」ヘッダーを生成します。 セッションによっては、これにより、クライアントのホスト名やIPアドレス、TLSセッションデータ、SASLログイン情報、およびSMTPログの詳細などがヘッダーから除外される場合があります。

これらを並べ替えてください プライバシー保護機能 ポート587または465専用のサブミッション・サービス定義を割り当てるのではなく、グローバルに一括して main.cf を有効にする。パブリックポート25のMTAは、サーバー間転送において別の役割を担っています。Postfixのドキュメントでは、RFC 5321の要件を満たすために、この設定をデフォルト値にしておくよう求めています。

したがって、この決定はプライバシーだけでなく、追跡可能性やサービスの範囲にも影響を及ぼします。 認証済みクライアントに対しては、不要なメタデータを削減することが適切である場合もある。しかし、パブリックMXサーバーにおいて、同じ設定を行うと、Received:情報に対する文書化された期待に反することになる。したがって、一律のグローバルルールではなく、個別のサービスやリスナー、およびそれぞれのパラメータを検討すべきである。

Postfix 3.10.0 には、OpenSSL 3.5 およびポスト量子暗号化のためのそのグループ構文に対応する調整も含まれています。グループの選択を、中央で管理されている OpenSSL の設定に完全に委ねる場合は、 tls_eecdh_auto_curves そして tls_ffdhe_auto_groups 両方が空に設定されている必要があります。この共通の設定がなされて初めて、OpenSSLが選択を行うようになります。Postfix自体は、新しいOpenSSLの構文を再現しません。

両方の自動パラメータを空にすることは、 特殊なケース 一元管理される暗号設定向けであり、一般的な強化の推奨事項ではありません。 これは、有効なOpenSSLの設定が判明しており、バージョン管理され、テストされている場合にのみ適しています。こうした管理が行われていない場合、選択の委譲によって設定ミスが隠蔽されたり、予期せぬTLSの挙動が生じたりする可能性があります。その場合は、Postfixの明示的な設定の方が追跡しやすくなります。

パッチの適用状況と既知の不具合を確認する

バージョン番号「3.10」だけでは、統一された技術的状態を示すものではありません。重要なのは、具体的なパッチバージョン、ディストリビューションパッケージの変更履歴、および必要に応じてバックポートされた修正内容です。 Postfix 3.10.14は、2026年9月7日に、他のメンテナンスされているブランチとともにレガシー版として発表されました。しかし、それをもって、すべてのLinuxパッケージがすでにこのアップストリームの状態を含んでいるとは限りません。

具体的な例として、Postfix 3.10.6 が挙げられます。このリリースでは、以下の問題に関する修正が行われました。 TLS必須：いいえ およびクライアント側のTLSラッパーモード。 以前の実装では、このような接続に支障をきたす可能性がありましたが、今回の修正により、これらは「encrypt」のセキュリティレベルで処理されるようになりました。したがって、SMTPSラッパーモードを使用している場合は、「3.10」の動作から同様の挙動を推測するのではなく、パッチの適用状況や実際に使用されている通信経路を確認する必要があります。

3.10.14のリリースノートには、smtpd_proxy_filterに関連するSMTPスマグリングの脆弱性に対する修正や強化などが記載されています。 これは、すべてのメールサーバーが影響を受けるという一概な主張ではありません。このパラメータはデフォルトで無効になっており、影響の有無はローカルの設定や、上流または連携しているフィルタアーキテクチャによって異なります。したがって、まずこの機能が実際に有効になっているかどうかを確認してください。

配信に異常が見られる場合、トラブルシューティングには適切な手順があります。まず、有効な逸脱と設定の検証を確認し、次にアップグレード後のリロードが正常に行われたかを確認します。 その後、キューやログを調査し、TLS、接続、またはDeferredに関するメッセージが繰り返し発生していないかを確認します。これに関する体系的な手順は、 Postfixログの分析 キューIDと配信試行を個々のイベントに紐付けるのに役立ちます。

警告： バージョンの変更は、原因分析の代わりにはなりません。リロードを行っても、無効な証明書チェーンやDNSエラー、不適切なルーティングルールは解決されません。逆に、アップグレード後にリロードを行わないと、運用中の変更されたプロセスや設定が隠れてしまう可能性があります。 したがって、パッチの適用状況、パッケージのソース、有効化日時、および観測されたログメッセージをまとめて記録しておく必要があります。

TLSRPTレポートを運用において適切に評価する

TLSRPTレポートは遅延が生じるため、リアルタイムの監視に代わるものではありません。Postfixのドキュメントによると、エラーレポートが届くまで平均で約12時間かかるとされています。 Postfix では、記録される結果は TLS ハンドシェイクに関するものであり、ハンドシェイクの前後で発生する接続確立エラーや切断は記録されません。緊急のインシデントに対しては、キューの監視、ログの分析、およびアラート通知が依然として必要です。

再利用もカウントを制限します。再利用された SMTP 接続では、追加の TLS ハンドシェイクは発生しません。 TLSセッションが再開された場合、Postfix 3.10ではデフォルトでカウントがスキップされます。これについては、smtp_tlsrpt_skip_reused_handshakesの設定が適用されます。 したがって、レポートの集計値は、すべてのSMTP接続の完全な数でも、メッセージや配信率でもありません。エラーの種類、受信者ドメイン、期間、および繰り返されるパターンを、サーバーのログと併せて評価してください。

レポートを技術的に配信しただけでは、まだ何のメリットもありません。事前に、RUAの受信者を誰が担当するか、誰がレポートを受け取って保存するか、そしてデータをどのくらいの期間保存するかを明確に決めておきましょう。 レポートにはTLSセッションに関する情報が含まれる可能性があるため、アクセス権限、データ保護に関する規定、および削除手順を運用計画に盛り込む必要があります。また、エラーが繰り返し発生した場合のエスカレーションルールも設けておくべきです。

したがって、この分析は2つのレベルを結びつけています。TLSRPTは一定期間にわたる集約された傾向を示す一方、メールサーバーのログは個々の配信試行の具体的な経過を提供します。継続的な監視については、 Postfix ログ監視の実践ガイド エラーメッセージやキューを分類する方法に関するレポート。自動アラートは、受信したTLSRPT集計データではなく、リアルタイムの運用データに基づいて反応すべきである。

責任ある受信者、保護された保管場所、および定期的な評価が確保されていない場合は、TLSRPTの公開を、性急に有効化するのではなく、まずは計画的に進めるべきである。 報告責任 これはセキュリティ機能の一部です。エラーを管轄部署に割り当てることで初めて、MTA-STSポリシーの有効期限切れやTLSAデータの問題などに対して、追跡可能な対応が可能になります。

3.10 を維持するか、3.11 に移行する

パッチによるメンテナンスとブランチの変更のどちらを選ぶかは、現状と運用目標によって決まります。調査時点において、Postfix 3.10 は引き続きサポートされているレガシーブランチであるのに対し、3.11 は安定した開発ブランチとなっています。 したがって、既存のインストール環境においては、3.10 内の定期的な修正パッチの適用が有効ですが、これらは 3.11 への機能アップグレードと同等とはみなされません。

3.11への移行は、その機能や長期的な目標状態が必要とされる場合に、特に合理的な根拠があります。REQUIRETLSや特定の管理ツールのJSON出力は、新しいブランチの特徴として文書化されており、Postfix 3.10の機能として計画に含めてはなりません。 ブランチを切り替える前に、設定パラメータ、接続されたフィルター、認証、および自動化機能の互換性を確認する必要があります。

新しい機能が必要ない、安定した3.10システムを実現するには、 継続的なパッチ管理 即座に適切な措置です。とはいえ、バックアップ、パッケージの検証、妥当性確認、プロセス起動の確認、および監視といった、管理された手順が必要です。一方、ブランチの切り替えには、技術的な理由と計画されたメンテナンスウィンドウが必要です。バージョン番号が高いという理由だけでは、十分な決定基準とはなりません。