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

SPF への道

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

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

さらに SPF は、IETF*4MARID 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 として改定されました。

*1

日本語では、送信ドメイン認証技術ですが、英語では Sender Authentication Technology です。これは、直訳すると送信者認証技術となるのですが、メール投稿時の認証技術である SMTP-AUTH と区別するために、日本語では認証する対象の「ドメイン」を付けて、送信ドメイン認証技術と言います。

*2

検討した技術については、LMAP (Lightweight MTA Authentication Protocol) という総称で表現され、ID (Internet Draft) の形で残されています。
https://tools.ietf.org/id/draft-irtf-asrg-lmap-discussion-01.txt

*3

2004年2月に Sender Policy Framework と名称が変更されるまで、当初は Sender Permitted From という名前でした。

*4

IETF (Internet Engineering Task Force) では、技術分野毎に WG (Working Group) を作成し、技術標準の議論を行います。合意された技術標準は、 RFC (Requests for Comments) という番号がつけられた文書として公開されます。

*5

MARID (MTA Authorization Records in DNS) Working Group

*6

仕様は draft-atkinson-callerid-00.txt という名称で参照することができます。

*7

取り出す順番は、Resent-Sender、Resent-From、Sender、From ヘッダといった順番で、これによって取り出されたものは PRA (Purported Responsible Address) と呼ばれます。