送信ドメイン認証技術の歴史-1

SPF への道

電子メールを受信する際に、メールの送信者が名乗っている情報 (メールアドレス) が正しいのかを確かめることができれば、なりすましメールを見破ることができるようになります。また、なりすまされていないことが明確であれば、送信者のメールアドレス (送信者情報) から受け取るべきメールかどうかを判断しやすくなります。

こうした送信者情報を確かめることが、送信ドメイン認証であり、認証するための仕組みが送信ドメイン認証技術*1となります。この送信ドメイン認証技術は、2003年頃から既存のメール配送の仕組みを変えずに機能を新たに追加する形でいくつかの技術*2 が検討され始めました。これらの技術は、主にメールの配送手順上での認証を目指したものですが、その中で現在も利用されているのが SPF (Sender Policy Framework)*3 です。

さらに SPF は、IETF*4 の MARID WG*5 の場で標準化作業を行う際、マイクロソフト社が提案した Caller ID for E-mail*6 との統合を目指しました。SPF は、認証する送信者情報としてエンベロープ情報を利用するのに対して、Caller ID for E-mail では、メールヘッダ上の送信者を認証します。それぞれ認証する情報は違いますが、ドメイン単位でメールの出口を DNS 上に表明すること、メール受信時に送信元を DNS を参照することで確認するといった仕組みは同じでした。また、エンベロープ情報は、受信したメールを自動転送する際に変更されない場合が多いのですが、転送先の受信サーバからみると送信元のメールサーバが送信元と異なってみえるため、認証が失敗するという課題もありました。これが、いわゆる SPF の転送問題です。

Caller ID for E-mail では、メールのヘッダ情報から決められた順番*7 で送信者情報を取り出します。メール転送をする際に、より優先度の高い送信者情報欄に転送元のメールアドレスを設定すれば、転送先でも受信したメールの送信元 (メールサーバ) と、転送元の送信者情報とが一致するので、正しく認証することができるようになります。メールシステムの仕組みでは、既に設定されたヘッダ情報や本文を変更することを極端に嫌う傾向があります。しかし、新たにヘッダを追加することについては、あまり抵抗がありません。例えば、受信したメールのヘッダ情報、特に Received:ヘッダ を参照してみてください。Received:ヘッダ は、メールサーバが受信する度に追加されますので、利用しているメールサービスによっては、多数の Receivedヘッダ が記載されていることが確認できると思います。

SPF と Caller-ID for E-mail を統合した Sender ID は、DNS と送信元メールサーバの出口情報を利用するという共通の仕組み、さらに SPF の転送問題の解決への期待などもあり多くの関係者が標準化されることを期待していました。しかしながら、マイクロソフト社が Sender ID の送信者情報を取り出す PRA の仕組みについて、知的所有権 (IPR:Intellectual Property Right) を主張したことで混乱が生じました。マイクロソフト社は、利用については無料であることを説明しましたが、これによる将来的な影響などが不透明であることなどから、大きな反発を生みました。こうした混乱もあり、2004年9月に MARID WG は解散することになり、SPF と Sender ID、問題となった PRA 部分はそれぞれが実験的な (Experimental) RFC として公開されることになりました。その後 SPF の RFC は、標準化に向けて仕様の見直しを行い、2014年4月に RFC7208 として改定されました。