RFC 8689: SMTP TLS必須オプション
なぜこれが存在するのか
サーバー間のメール暗号化（STARTTLS経由）はデフォルトで機会的です。受信サーバーがTLSをサポートしていない場合、またはman-in-the-middleがSTARTTLS機能をストリップした場合、ほとんどの送信サーバーは平文配信にフォールバックします。メッセージは配信されますが、暗号化なしです。
MTA-STSやDANEなどのテクノロジーはドメインレベルでこの問題に対処します。受信ドメインが「我々へのすべてのメールはTLSを使用する必要があります」と宣言できます。しかし、それらは受信側のポリシーです。送信側は「このメッセージはすべてのホップでTLSが必要」と言う方法がありませんでした。
RFC 8689はこのギャップを2つの補完的なメカニズムで埋めます：
- REQUIRETLS SMTP拡張： SMTPQ封筒内のメッセージごとのフラグで、各リレーサーバーに「次のホップがTLS検証済み証明書をサポートしていない限り、このメッセージを配信しないこと」を伝えます。
- TLS-Requiredヘッダー： 同じ意図を示すメッセージヘッダーで、送信側がSMTP封筒を直接制御できない場合に使用可能です（例えば、MSAを経由して送信する場合）。
動作方法
REQUIRETLS SMTP拡張
送信側はSMTP トランザクション中にMAIL FROMコマンドにパラメーターとしてREQUIRETLSを追加して意図を通知します：
各ホップでの動作
リレーサーバーがREQUIRETLSフラグ付きのメッセージを処理するとき、転送前にこれらのルールを実行する必要があります：
- TLSは必須です。 次のホップへの接続はTLSを使用する必要があります。次のサーバーがSTARTTLSをサポートしていない場合、メッセージは配信されず、バウンスします。
- 証明書検証が必須です。 次のホップのTLS証明書は有効で、サーバーホスト名と一致する必要があります（DANE/TLSAまたはWeb PKI経由）。自己署名証明書またはホスト名が一致しない証明書はバウンスを引き起こします。
- REQUIRETLSフラグは伝播します。 リレーは次のホップもこの拡張をサポートする場合、REQUIRETLSパラメーターを次のホップに渡す必要があります。次のホップがREQUIRETLSをサポートしない場合、リレーはDANEまたはMTA-STSを通じてTLSを検証できれば配信できます。
TLS-Requiredヘッダー
MSAを経由して送信し、SMTPパラメーターを直接制御しない送信側のために、TLS-Requiredヘッダーは同じシグナルを提供します：
TLS-Required: Noヘッダーは特にオプトアウトメカニズムとして設計されています。これは送信MTA に「通常このメッセージにREQUIRETLSが適用される場合でも（例えば、ドメイン全体のポリシーのため）、この特定のメッセージに対しては強制しないこと」を伝えます。これはパスワードリセットや通知など、配信が暗号化の保証よりも重要なメッセージに役立ちます。
バウンス動作
REQUIRETLSが配信を防ぐと、送信サーバーは非配信報告（バウンス）を生成します。バウンス自体もTLS経由で送信される必要があります。REQUIRETLSはDSN（配信状態通知）メッセージにも適用されます。バウンスをセキュアに配信できない場合、元のメッセージに関する情報の漏洩を回避するために平文で送信されるのではなく、サイレントにドロップされます。
主要な技術詳細
MTA-STSとDANEとの関係
| メカニズム | ポリシー設定者 | スコープ | 検証方法 |
|---|---|---|---|
| MTA-STS | 受信ドメイン | ドメインへのすべてのメール | Web PKI（HTTPSフェッチ） |
| DANE | 受信ドメイン | ドメインへのすべてのメール | DNSSEC + TLSAレコード |
| REQUIRETLS | 送信サーバー/ユーザー | メッセージごと | 各ホップでのDANEまたはMTA-STS |
REQUIRETLSは競争ではなく補完的です。MTA-STSとDANEは受信ドメインのインバウンドメールを保護します。REQUIRETLSは特定のアウトバウンドメッセージを保護します。REQUIRETLSを持つメッセージは各ホップでDANEまたはMTA-STSを使用して検証されます。どちらもホップで使用できない場合、配信は失敗します。
TLSバージョン要件
REQUIRETLSはTLS 1.2以降が必要です。TLS 1.0または1.1を使用する接続はこの要件を満たしません。これはRFC 8996の古いTLSバージョンの廃止予定と一致しています。
拡張ステータスコード
| コード | 意味 |
|---|---|
5.7.30 |
REQUIRETLSサポートが必須だが次のホップで利用できない |
5.7.31 |
REQUIRETLSを実行できない（例えば、次のホップの証明書が無効） |
一般的な誤り
- REQUIRETLSが広く展開されていると仮定する。 採用はまだ限定的です。ほとんどのMTAはまだREQUIRETLS拡張をサポートしていません。すべてのメールに使用すると、多くの受信者へのバウンスが生じます。
- REQUIRETLSとSTARTTLSを混同する。 STARTTLSは接続をTLSにアップグレードするメカニズムです。REQUIRETLSはSTARTTLSが成功し、証明書が検証されることを義務付けるポリシーです。STARTTLS なしのREQUIRETLSは機会的です。REQUIRETLSはそれを必須にします。
- エンドツーエンド暗号化を期待する。 REQUIRETLSは各ホップでのTLSを保証しますが、メッセージはすべてのリレーサーバーで復号化および再暗号化されます。これはホップバイホップ暗号化であり、エンドツーエンド暗号化ではありません。真のエンドツーエンド暗号化の場合、S/MIMEまたはPGPを使用します。
- バウンスを処理しない。 REQUIRETLSは受信者のサーバーがTLSをサポートしていない場合、または証明書の問題がある場合、正当な配信エラーを引き起こします。アプリケーションはこれらのバウンスを処理し、REQUIRETLSなしで再試行するか、ユーザーに通知する必要があります。
-
TLS-Required: Yesを使用する。
TLS-Required: Yes値はありません。ヘッダーにはオプトアウト用のNo値のみがあります。肯定的なシグナルはヘッダー値ではなく、REQUIRETLS SMTPパラメーターです。 - バウンスについて忘れる。 REQUIRETLSはDSNメッセージにも適用されます。バウンスをTLS経由で配信できない場合、サイレントにドロップされます。元の送信者は配信に失敗したことを知らないかもしれません。
配信可能性への影響
- 配信率を低下させます。 すべてのメッセージに対してREQUIRETLSを有効にすると、TLSをサポートしていないサーバーまたは証明書の問題があるサーバーへの配信失敗が発生します。セキュリティが配信確実性より重要なメッセージに対して選択的に使用します。
- 高価値メッセージを保護します。 財務通知、法的文書、医療データ、またはコンプライアンス規制の対象となるメッセージについて、REQUIRETLSはメッセージが平文で送信されることがないことを保証します。
- MTA-STSを補完します。 ドメインがMTA-STSを公開し、受信者のドメインもMTA-STSまたはDANEを持っている場合、REQUIRETLSはドメインレベルのポリシーの上にメッセージごとの保証を追加します。この組み合わせはSMTPで利用可能な最強の転送セキュリティを提供します。
- バウンスメッセージも保護されます。 REQUIRETLSがDSNに適用されるため、バウンスメッセージ内の機密情報（元のメッセージの一部を含む可能性があります）も平文送信から保護されます。