要約

どの「差出人」を調べるのか

受信箱に表示されるFromと、SMTPでサーバー同士がやり取りするMAIL FROMは別の場所にある。転送が入れば、表示上の差出人と実際に接続してきたサーバーの関係はさらに複雑になる。ドメインが「このサーバーには送信を許す」とDNSで宣言しても、受信側がどのドメイン名を検査するか決めなければ判定は始まらない。

IETFのMARID作業部会憲章は、From、Sender、SMTPのMAIL FROM、EHLOを候補として挙げ、最初の仕事を検査対象の選択と定めた。Sender IDはPRAという手順でヘッダーから責任を負うとみなすアドレスを求める。SPFはSMTPの身元を調べる。両方式がDNSに方針を置くからといって、同じ人物についての方針を読んでいるわけではない。

無償の許諾に残った配布の関所

2004年の公開書簡でApacheは、Microsoftの当時の無償特許ライセンスがApache License 2.0と両立しないという判断を示した。対象は迷惑メールを選別するSpamAssassinと、メールサーバーJAMESだった。Apacheは現行の条件でSender IDを実装も導入もしないと明記した。

指摘は抽象論だけではない。Apacheによれば、許諾された特許上の権利を後続の受領者へ再許諾する道が狭く、名称を変えて配布したり再配布したりする側はMicrosoftへ連絡する必要があった。オープンソースのコードは、開発者の手から配布者へ、さらに改変者へと移る。その都度、特許保有者の窓口に戻る設計なら、文書が公開されていても実装を運ぶ道は自由に開いていない。

この書簡でApacheが決められたのは自分のプロジェクトの採用方針までだ。他社のソフトウェアやメール事業者の選択を決めたわけではない。しかし公開仕様を発表する行為と、それを実行するコードを継続的に配れる状態を作る行為が、別の権限に属することははっきりした。

RFCの番号は衝突を消さない

2006年4月、IETFはSender IDとSPFの文書を同時にExperimentalとして公開した。IESGの注記は、一般的な技術的合意が得られず、両方式の調整も失敗したと書く。さらに、SPFのために公開されたDNSレコードへSender IDの判定を適用すると、正当なメールを届けられなくなる場合があると警告した。自動転送とResent-*ヘッダーも具体的な衝突点だった。

試験用の文書を二つ残した判断には価値がある。ただし「二つとも記録された」は「二つを同時に使って安全」という意味にはならない。誤った解釈の最終地点は委員会の議事録ではなく、受信者のもとへ届かないメッセージである。

2012年のIETF報告は、両方式の実装が存在した一方、Sender IDのPRAとSUBMITTERは広い利用集団を得ず、SPFは広く導入されたと結論づけた。利用できるソフトウェアの欠如が選択を阻んだわけではないとも明記している。報告は導入状況の観察であり、二つのアルゴリズムの絶対的な優劣を裁定したものではない。2014年にSPFは標準化路線へ進み、2020年にはSender IDの三つのRFCがHistoricへ移された。

Apacheの拒否は2004年に一つの実装経路を閉じた。後年の採用実績は、メール運用者がどちらを使ったかを示した。両者の間に置かれた2006年の警告が、この物語の技術的な芯である。一つのDNSレコードについて検査する差出人が一致しなければ、最も弱い立場にいるのは配送を待つメールそのものだ。