要約

  • draft-ietf-emailcore-as-30 の6.5節は、受信側の実装が通信経路の機密性の有無にかかわらずメールを受け取れることを求める。ただし、個々の場面でどう振る舞うかは送受信者のローカル方針だと明記する。文書はまだIESGの「AD Followup」にあるInternet-Draftであり、RFCではない。
  • 第29版には、受信側は送信側に経路上の機密性を要求してはならないという別の文言があった。九月下旬の公開討議は、新しい「実装能力」の要件に意味があるかを争っており、承認済みの結論を示していない。

例えば、閉じた業務用リレーの管理者がTLSを使わない接続を拒絶する。その設定は当該リレーの入場条件を示すが、使われているソフトウェアが平文のSMTPを理解できない証明にはならない。相手の接続を拒むことと、製品に処理経路が存在しないことを混ぜると、規格が誰に何を求めているのかが見えなくなる。

EMAILCORE適用指針案の第30版は、その線を6.5節で引こうとしている。送信側には、機密性のある通信が利用可能で受信側にも受け入れられる場合、それを使うよう求める。受信側には、機密性があってもなくても受け取れる能力を求める。そして特定の状況で実際にどうするかはローカル方針に委ねる。第29版の受信側要件は、送信側に経路の機密性を要求してはならないという書き方だった。変更履歴はIESG審査中に第6節を書き直したと記す。これはTLSそのものの新機能ではなく、要件を向ける先の変更である。

書き換え後も審査は続く。Datatrackerの記録では第30版は有効な草案で、IESGの状態は「AD Followup」。投票画面にはDISCUSSが残り、旧版に対して出されたものもあれば、論点が平文受信だけではないものもある。9月18日のRoman Danyliw宛ての返信で、編集者John Klensinは一部の説明を個人としての見解と位置付け、作業部会でまだ審議していないと断った。9月28日にはEric Rescorlaが、追加的な意味のない規範要件なら削るべきだと論じた。Rob Sayreは実装能力と運用者の選択を分けて考える必要を説いた。どちらも発言者を明示して扱うべき意見で、IETF全体の合意ではない。

既存のRFC 3207も確認が必要だ。STARTTLSについて、公開参照されるSMTPサーバーはローカル配送にその使用を必須としてはならず、公開参照されないサーバーには必須にする余地があると規定する。対象となるサーバーと機構が限定された既存の相互運用規則であり、あらゆるサーバーが全ての平文接続を許さなければならないという意味ではない。EMAILCOREの審議では、その既存の線に加えて受信ソフトウェア全般の能力をどう表現するかが問題になる。

RFC 8689のREQUIRETLSも別の層にある。対応する中継を通る一通のメッセージについて、機密性が確保できなければ配送を断念する選択を送信側に与える。BTWはすでにそのメッセージ単位の仕組みを報じた。しかし、送信者の要求が受信製品にどの能力を搭載すべきかまで決めるわけではない。公開MXの基準、製品の能力、運用上の接続条件、メッセージごとの要求を一つの「暗号化ポリシー」にまとめてしまうと、責任の所在がぼやける。

適用指針が確定すれば、ベンダーの適合説明や調達時の確認にも使われ得る。「受け取れること」が「常に受け取ること」に読み替えられれば、運用者が決めるはずの拒否条件を誤って失う。一方、暗号化を通常の方針とするために製品から平文処理を完全に消せば、例外的な相互運用や復旧時には設定変更だけでは済まないかもしれない。草案と公開の議論は、そのどちらが実際に何件起きたかを示していない。現在確認できるのは、共通の実装要件と個別の運用裁量との境界が審査対象になっていることだ。

出典