要約

  • STARTTLS が保護するのは一回の SMTP 接続であり、キューに保存されたメールはその後も複数の中継を渡る。RFC 8689 の REQUIRETLS は、認証済み TLS と条件の再伝達を一通ごとの処理義務にした。
  • 条件を満たす MX がなければ、中継は平文配送へ戻らず、不達通知を生成する。これはエンドツーエンド暗号ではない。信頼された MTA の連鎖において、失敗を正当な安全動作として明示した仕組みである。

最初に考えるべき場所は、TLS ハンドシェイクではなくメーリングリストである。

受け取った一通が百の宛先へ展開される。いくつかの宛先は強い TLS 経路を持ち、別の宛先は古い中継しか持たない。元の送信者が「平文にしてまで届けないでほしい」と決めていたなら、その決定はどこまで新しい百通に残るのだろうか。

通常の SMTP リレーなら、入ってきた封筒の条件をキューに保存し、次の封筒へ移せる。しかしメーリングリストはしばしば新しいメッセージを起草する。差出人やヘッダーが変わり、受信者も増える。接続にだけ存在した安全条件は、この境界で消えてしまう。

この問題は、電子メールが一続きの通信路ではないことから生まれる。SMTP は受け取り、保存し、後で別の相手へ渡す。ソケットよりメッセージの寿命が長い。2019 年の REQUIRETLS は、安全上の意思にも同じ寿命を与えようとした。

STARTTLS は現在の二者関係を作り直した

1999 年の RFC 2487 は SMTP に STARTTLS を加えた。公開 MX は世界中の不均一なサーバーからメールを受ける。暗号化を即座に必須にすれば相互運用性が失われるため、配送を優先する余地が残された。

2002 年の RFC 3207 は手続きを改訂した。平文の EHLO で STARTTLS を見つけ、命令と 220 応答の後にハンドシェイクへ入る。完了したら、双方は暗号化前に得た知識を捨て、クライアントは EHLO をやり直す。攻撃者が書き換えられる能力表を保護区間へ持ち込まないためである。

この再出発は重要だが、対象は一接続である。サーバーがメールを受け入れてディスクに置いた瞬間、次の配送判断は別の接続、別の時刻、別の管理主体へ移る。最初の TLS が成功しても、後の中継が平文へ戻らない保証にはならない。

受信側のドメイン方針は後に強化された。RFC 7672 の SMTP DANE は DNSSEC で認証された TLSA を使う。RFC 8461 の MTA-STS は HTTPS で取得しキャッシュする方針に、許容 MX と証明書検証を記す。どちらも受信ドメインが「自分への配送」を規律する仕組みであり、送信者が特定の一通だけに異なる失敗条件を与える仕組みではなかった。

REQUIRETLS は新しい動詞ではなかった

RFC 8689 が登録したのは、EHLO の REQUIRETLS 能力と MAIL FROM の値なしパラメーターである。新命令はない。

MAIL FROM:<sender@example> REQUIRETLS

封筒に置いたのは偶然ではない。ヘッダーはメッセージ内容の一部だが、封筒は現在の転送条件を決める。送信側は、TLS を確立し、MX の正当性と証明書を検証し、暗号化後の二回目の EHLO で相手が REQUIRETLS を再広告した場合にだけ、このパラメーターを付けられる。

受信側はメールを受理すると、REQUIRETLS 処理が必要だと内部で印を付ける。キューファイルの形式やデータベース列は規格の対象外である。規格が要求するのは、後で送信側へ回ったときに同じ制約を再現することだ。

ローカル別名によって複数アドレスへ分かれた場合も、全インスタンスが同じ印を持つ。これにより、セッションの一時的な能力交換が保存物の継続的な責任へ変わる。

次ホップを信用するまでの証拠

キューから印付きメールを取り出した MTA は、単に暗号化を開始するだけでは足りない。まず RFC 5321 の配送規則で相手を選ぶ。MX 応答が DNSSEC で認証されていなければ、MTA-STS によって許容名を確かめる。TLS を確立し、公開鍵信頼連鎖か DANE で証明書を検証する。さらに保護区間内の EHLO で REQUIRETLS を確認する。

それぞれは別の証明である。暗号は盗聴を防ぐ。証明書や DANE は接続先の身元を結ぶ。DNSSEC や MTA-STS は、どの MX が受信ドメインを代表できるかを縛る。最後の能力広告は、相手がメッセージの印を保存し、さらに先へ運ぶ意思を示す。

「TLS 使用済み」という一項目では、代替された MX への暗号化接続と正しい配送を区別できない。有効な証明書だけでも、次の中継が制約を覚えることは証明できない。

すべての MX を試しても駄目なら送らない

第一順位の MX が暗号化後に REQUIRETLS を広告しなければ、送信側はその試行を終え、別の MX へ進む。同じサーバーへ通常メールを送ることは可能である。制約はドメイン全体の恒久評価ではなく、その一通に付く。

候補を尽くしても条件が成立しなければ、メールをそのドメインへ送ってはならない。RFC 8689 は、拡張非対応に 5.7.30、TLS セッション確立不能に 5.7.10 という拡張状態を推奨し、元のリバースパスへ不達通知を返す。

ここで失敗の意味が反転する。機会的 TLS では、交渉失敗が平文配送の入口になり得た。REQUIRETLS では同じ事実が送信権を消す。届かなかったことは可用性の損失だが、条件を破って届くことより正確な結果になる。

証明書の期限切れや一台の未対応 MX が、到達可能なメールを止める。その摩擦は欠陥ではなく選択の価格である。規格は安全と配送が常に両立すると装わず、どちらを優先したかを可視化した。

不達通知にも元メールの影がある

バウンスには元メールのヘッダーや診断が含まれる。正方向だけ暗号化しても、件名や宛先を引用した通知が平文で戻れば情報が漏れる。このため REQUIRETLS メールから生じた不達通知は、失敗原因が TLS 以外でも REQUIRETLS を使わなければならない。

引用量も制限される。DSN の RET=HDRS が指定されたものとして扱い、RET=FULL が同時にあっても無視する。診断のために原文全体を別経路へ複製しない設計である。

ところが戻り道は往路と同じではない。バウンスはループ防止のため空のリバースパスを使い、それ自身が失敗しても新しいバウンスを作れない。送信元ドメインまでの経路に REQUIRETLS 対応がなければ、通知が失われる可能性もある。したがって、通知が届かないことは原メールの到着を証明しない。

TLS-Required: No は故障を知らせるための逃げ道だった

同じ RFC は TLS-Required: No というヘッダーも定義した。これは平文を要求する命令ではない。受信ドメインの DANE や MTA-STS 方針に問題がある場合、送信側中継へ「その方針のためだけに配送を失敗させないでほしい」と伝える。壊れた証明書を管理者へ報告するメールが、その壊れた証明書によって遮断される逆説を解く用途がある。

STARTTLS は可能なら試す。No が変えるのは失敗後の判断である。受信サーバー自身が暗号化なしのメールを拒否すれば、その入口方針が優先する。送信者は相手に平文受理を強制できない。

封筒の REQUIRETLS とヘッダーが同居した場合、封筒が優先し、ヘッダーは処理上無視される。複数の同名ヘッダーも許されない。保護済みの転送条件を内容側から弱められないようにした。

メーリングリストは責任の境目を露出させた

通常のリレーは同じメッセージを次へ渡す。メーリングリスト、Sieve、転送サービス、自動応答は、新しいメッセージを起こす場合がある。RFC 8689 は、可能な範囲で元の REQUIRETLS 選択を新しいメールにも適用するよう求める。

ただし完全な継承は約束できない。多数の宛先のうち一つでも非対応なら、その宛先だけ失敗させるのか、展開全体を止めるのかという運用判断が残る。利用者側のフィルターは SMTP の内部印を知らないこともある。

ここに技術だけでは閉じない境界がある。誰が単なる運搬者で、誰が新しい発信者なのか。新しい発信者は元の意思をどこまで引き受けるのか。REQUIRETLS は問いを隠さず、再起草の瞬間に表へ出した。

中継を信頼しない脅威には届かない

REQUIRETLS はホップごとの暗号化である。各 MTA は TLS を終端し、メッセージを読んでから次の TLS を始める。悪意ある中継は対応を偽り、印を消せる。規格は、その MTA がすでに平文を任されているため、これを脅威モデル外とする。

守れるのは、受動盗聴、STARTTLS 広告の除去、偽 MX、誠実な実装による偶発的な降格である。人間の著者を認証せず、保存中データを暗号化せず、全経路の実行を一回の成功から証明もしない。

IANA の SMTP 登録簿 に REQUIRETLS が載っていることは、名前と仕様の割り当てを示すだけで、普及率や遵守率を示さない。

この拡張の歴史的な芯は、接続より長く生きる判断である。メールはキューに残り、組織をまたぎ、新しい接続を作る。そのたびに「暗号化を試す」だけでなく、「条件を守れなければ送らない」を再現する。配送失敗は、ここでは通信の敗北ではない。元の意思を改変しなかった証拠になり得る。