それぞれ仕組みが異なる送信者認証
2004年になると，メールの送信者を認証するための技術／仕様への取り組みが本格的に始まった。当初，米Microsoftの「Caller ID for E- Mail」，米Yahoo!の「DomainKeys」，米PoboxのMeng Wong氏が開発し，米AOLが担いでいた「SPF（Sender Policy Framework）」――この3つが主な送信者認証技術として注目されていた。
この中ではSPFの歴史が最も古い。「迷惑メールに苦しんでいたせいもあるが，AOLの取り組みは早かった」（インターネットイニシアティブ（IIJ）システム技術部の山本功司課長。IIJは，迷惑メール対策の業界団体「MAAWG（Messaging Anti-Abuse working Group）」に国内で唯一参加している）。米Microsoftが先日公表したプレス・リリースによると，SPFは6万サイトで使われているという。
これら3種類の仕組みを簡単に説明すると次のようになる。まず，Caller ID for E-MailとSPFは，メールを送信しようとしているメール・サーバーのIPアドレスをもとに，そのサーバーが「嘘をついていないかどうか」を調べる。
メールを送信しようとしているメール・サーバーと，受信しようとしているメール・サーバーの間では，「SMTP（Simple Mail Transfer Protocol）」と呼ばれるプロトコルを使ってメールの送受信が行われる。
送信側は，まず，SMTPの「HELO（EHLO）」コマンドで受信側にアクセスする。受信側が「OK」を返すと，送信側は「MAIL FROM」コマンドでメール送信者のアドレスを，「RCPT TO」コマンドでメール受信者のアドレス（送信先アドレス）を受信側のサーバーへ送信する。受信側が「OK」を返すと，送信側は「DATA」コマンドを使ってメールの本文を送信する。本文には，メール・ソフトに「送信者」として表示される「Fromヘッダー」や，「宛先」として表示される「Toヘッダー」といったヘッダー情報も含まれる。
さて，この一連のやり取りで，受信側のサーバーが知り得る送信側の情報としては，（1）送信サーバーのIPアドレス，（2）MAIL FROMコマンドで送られた送信者のメール・アドレス，（3）メール本文に含まれる（DATAコマンドで送られる）Fromヘッダーのメール・アドレス――の3つが挙げられるだろう。このうち，（1）については偽ることが難しいが，（2）と（3）は容易に詐称できる。そこで，（1）を使って（2）および（3）をチェックするのが，それぞれSPFおよびCaller ID for E-Mailである。
SPFやCaller ID for E-Mailを使ったチェックを可能にするには，送信側も準備が必要である。具体的には，送信側ドメインのDNSサーバーに，そのドメインで利用する送信用メール・サーバーのIPアドレスを登録しておく。アドレスを登録するレコードは「SPFレコード」と呼ばれる。受信用メール・サーバーのIPアドレスを登録しておく「MXレコード」の“送信用バージョン”といえる。
SPFでは，MAIL FROMで送られたアドレス（ドメイン）のDNSサーバーにアクセスする。そして，そのDNSサーバーのSPFレコードに，現在通信している相手のIPアドレスが記されていれば，相手はMAIL FROMのアドレスを詐称していないことになる。同様に，Caller ID for E-MailではFromヘッダーのアドレス（ドメイン）が詐称されていないかどうかをチェックする。
細かい点ではいろいろ異なる部分があるが，おおまかに言えば，SPFとCaller ID for E-Mailは，チェックするアドレスが異なるだけで，「DNSサーバーに格納した情報をもとに，現在SMTP接続している相手（メール・サーバー）が嘘をついていないかどうか」を調べる点では同じである。そこで2004年5月，両者は「Sender ID」として統合された。Sender IDを使えば，MAIL FROMの詐称も，Fromヘッダーの詐称もチェックできることになる。
MAIL FROMのチェックは，迷惑メール対策になる。迷惑メール送信者はMAIL FROMを詐称するからだ。「足がつかないようにするためと，エラー・メールが自分のところに送られてこないようにするためだ」（IIJの山本氏）。迷惑メール送信者は，実在するしないにかかわらず，多数のメール・アドレスに対して迷惑メールを送り付ける。実在しないあて先がRCPT TOで指定された場合，MAIL FROMのアドレスへエラー・メールが送信される。このエラー・メールを受け取らないために，MAIL FROMを詐称する。そもそも，通常のユーザー（サーバー）はMAIL FROMを詐称しない。このため，詐称しているということだけで，“怪しい”と判断できる。
Fromヘッダーのチェックは，フィッシングのようなオンライン詐欺対策に有効だ。前述のように，Fromヘッダーの内容は，本文の一部（DATA）として送られる。現状では，いくらでも詐称できる。それにもかかわらず，メール・ソフトには「送信者」として表示されるので，ユーザーをだますのに“効果的”だ。Sender ID（Caller ID for E-Mail）を利用すれば，この単純なだましをチェックできる。
一方，DomainKeysの仕組みは少々異なる。送信者ドメインのDNSサーバーを使う点では同じだが，アドレス（ドメイン）のチェックにはデジタル署名を利用する。具体的には，送信者ドメインのDNSサーバーに，そのドメインの公開鍵を格納しておく。メールの送信者（送信サーバー）は，送信時にメールの中身のハッシュ（メッセージ・ダイジェスト）を計算し，そのハッシュを前述の公開鍵に対応した秘密鍵で暗号化しておく。
そして，その暗号化データはメールのヘッダー情報の一つとして，メールに含めておく。メールの受信者は，メールのFromヘッダーに書かれたアドレス（ドメイン）のDNSサーバーへアクセスして，公開鍵を取得。その鍵で復号したハッシュと，受け取ったメールから計算したハッシュが一致すれば，そのドメインから送られてきたことが検証できる。
これら一連の作業は，改ざんを検出するために用いられる一般的な方法であり，S/MIMEのような暗号メールのプロトコルでも使われている。ただし，S/MIMEなどでは，公開鍵／秘密鍵がユーザー個人のものであるのに対して，DomainKeysではドメインで所有することになる。
二転三転するSender IDの標準化
次に，Sender IDの現状を見てみよう。Sender IDは，インターネット標準を決める組織であるIETFの「MARID（Mail Transfer Agent Authentication in DNS）」というワーキング・グループで議論され，標準化作業が進められた。標準化作業は「異例の速さで進められた」と，今回取材に応じてくれた関係者は口をそろえる（関連記事）。
「ワーキング・グループの作業はまもなく終わり，今秋にはRFC（Request for Comments）になる。そして，年内中には多くのドメインで実装が始まる」と予想していた人は多い。そのためマイクロソフト日本法人では，Sender IDに限らず送信者認証技術全般を普及するためのセミナーを9月10日に開催した。
ところがその直後，MARIDワーキング・グループはSender IDを標準仕様として採用しないことを決定した（関連記事）。米Microsoftは正式なコメントを出していない。各種報道や関係者への取材によると，Sender IDに含まれる特許とライセンスの“不明瞭さ”にあったようだ。「“最後の最後”で，ライセンスに関する問題で異論が出て頓挫したと聞く」（IIJの山本氏）。実際，ワーキング・グループの決定の前から，オープンソース陣営からは不支持表明が相次いだ。AOLは，SPFの下位互換性の問題から9月15日に不支持を表明した。
「驚いた。Sender IDをアテにしていたのに・・・」という声は，複数の関係者から聞かれた。しかもその後，9月22日にMARIDワーキング・グループは解散。「もともと，半年という短期間で仕様をまとめることを目的に作られたワーキング・グループだった。異論が出たことで，当初の目的が果たせないことが明らかになり解散したのだろう」
一気に暗礁に乗り上げたSender ID。
ところが，再び状況が変わった。MicrosoftがSender IDに変更を加えて，IETFに再提出したのだ。変更のポイントは，Mail Fromをチェックする方法を「Mail From」，Fromヘッダーをチェックする方法を「PRA」として切り分けたこと。一度統合したSPFとCaller ID for E-mailを，仕様上再びばらした格好だ。これで，従来のSPFとの下位互換性が確保されたとして，AOLは新しいSender IDを支持することを発表した。
今回の変更により，ライセンス問題は解決したのだろうか。「PRAを使わずに，MAIL FROMを使うだけならライセンスの問題は発生しないだろう。以前からSPFを使っている陣営からは，特に文句は出ていないようだ」（米Sendmailのアジア・パシフィック担当副社長であり，センドメール日本法人社長の小島國照氏）という見方がある一方で，「新しいSender IDでも，ライセンス問題は明確にはされていない。Microsoftが公開するFAQなどを見ても，『PRAを使わなければ大丈夫』とは明確に記載されていないので，勝手に判断できない。以前のSender ID同様，新しいSender IDもオープンソース陣営には支持されないのではないだろうか」（IIJの山本氏）という意見もある。加えて山本氏は，「現状では，Sender IDを実装しても問題がないかどうかは明確でない。一エンジニアとして，Microsoftには明確にしてもらいたいと思う」と続けた。
標準化についてはどうか。合意がとれずにワーキング・グループは暗礁に乗り上げて解散した。それにもかかわらず，Microsoftは再びIETFに仕様を提出し，RFC化を目指すという。それが可能なら，ワーキング・グループの意味は一体何だったのか。
今回取材した関係者の一人は，「戦略の変更があったのでは」と推測する。そもそも，“インターネットの標準仕様（文書）”とされるRFCは一種類だけではない。複数の種類（ステータス）が存在する。標準化作業中の「Standard Track」，参考情報を記した「Information」，実験的なプロトコル仕様の「Experimental」，過去に検討されたものの標準にはならなかった「Historic」――などがある。
Standard Trackでは，標準化作業中だが仕様は決定している「Proposed Standard」，相互接続可能な複数の実装が存在する「Draft Standard」，仕様の安定性が確認された「Standard」――がある。これらが，“真”のインターネット標準と呼べるだろう。これらを目指して，Sender IDについてもワーキング・グループで議論された。
ところが，ワーキング・グループで議論されて合意が取れたものはStandard Trackになるが，ある一社（一グループ）が提出したものはExperimentalにしかならない。「当初はStandard Trackを目指したものの，『とりあえず，RFCになるのならExperimentalでもかまわない。その後，デファクト・スタンダードにすればよい』という戦略に変えたのではないだろうか」と，前出の関係者は推測する。
結局，複数の送信者認証技術に関するRFCやインターネット・ドラフト，ホワイト・ペーパーが作られて，それぞれについて，“よかれ”と思う技術がそれぞれのベンダー／プロバイダで実装されていくことになりそうだ。
受信側のポリシーに合わせて選択，組み合わせができる
だが，「それでかまわない」という声がほとんどだった。というのも，「これらの技術は，『どれか一つを選択する』という類のものではなく，補い合うものだからだ」（ヤフー Y!BB事業部 企画室の佐藤正憲プロデューサー）。
「複数の方法があれば，複数のロジックが組める。例えば，『まずはSender IDで検証して，だめならDomainKeysで検証する。どれか一つでもOKならよしとする』あるいは『すべてでOKではないと信用しない』など，受信側のポリシーに合わせた認証方法を選択できる」（センドメールの小島氏）。実際，代表的なメール・サーバー・ソフトの一つである「sendmail」では，主要な送信者認証技術はすべてサポートする。
SPF（MAIL FROM）を使えば，MAIL FROMの詐称を防げる。だが，Fromヘッダーの詐称は防げない。Sender ID（PRA）を使えばFromヘッダーの詐称は防げるが，ライセンスの問題があるし，SPFと比較すれば，メール・サーバーの負荷は大きいだろう。また，SPFやSender IDは今やり取りしている相手（メール・サーバー）を認証するので，転送された場合などには，適切に認証できない場合が出てくる。
その点，DomainKeysは転送に強い。しかしながら，メール・サーバーの負荷は大きそうだし，転送途中でメールの本文（ヘッダー）に改変が加わると，デジタル署名の検証に失敗する可能性がある――。いずれも一長一短。万全の技術など存在しない。
「欠点にだけ注目して，『だめ』とは考えないでほしい。改良の余地はそれぞれあるし，そのための取り組みがなされている」（センドメールの末政延浩シニア コンサルタント）。今は，揚げ足を取ることよりも，それぞれの仕様が固まるのを見守る時期なのだ。「関係者はいろいろな“知恵”を出し合っている最中。可能性をつぶすべきではない」（センドメールの小島氏）
過度の期待は禁物
その一方で，関係者からは「一般の人たちは，送信者認証に期待し過ぎている」という声もよく聞かれた。送信者認証技術を，迷惑メールやフィッシングに対する“特効薬”あるいは“万能薬”だと思っている人が少なくないという。
「あるプロバイダの関係者から『Sender IDやDomainKeysを実装すれば，本当に迷惑メールはなくなるのか。せっかく実装しても効果がなければ困る。保証してくれるのか』と言われて答えに窮した」と，センドメールの小島社長は苦笑する。先に書いたように，送信者認証技術は，“嘘をつかれにくくする技術”にほかならない。迷惑メールやフィッシングを直接防ぐものではない。
IIJの山本氏も「送信者認証は“第一歩”に過ぎない」と強調する。以前，IT Proでは米MX Logicのリリースに基づいた「スパマーの16％がメール認証技術『SPF』を利用している」というニュースを公開した。例えば，これをもって「SPFは迷惑メール対策にならない」とするのは早計すぎる。「SPFを使うようになれば，MAIL FROMで嘘をつけなくなる。つまり，MAIL FROMの情報を使って，受信者側ではフィルタリングといった対策を施せるようになる。そのことに意味があるのだ」（山本氏）
MAIL FROMやFromヘッダーが正しいかどうかを検証するのが送信者認証。その後，受信側でどのような対策をとるのかは，「それぞれのユーザーのポリシーに任せられる」（ヤフーの佐藤氏）。ブラック・リストやホワイト・リストを用意して，受信の可否を決定することもありえるし，第三者が提供する「Reputation（評判）」サービスを使うという手もある。Reputationサービスとは，そのドメインの“評判”を提供するサービス。サービスを使えば，「評判が悪い送信者からのメールを拒否する」といった運用が可能となる。
「リストを使うにしても，Reputationサービスを使うにしても，MAIL FROMやFromヘッダーの情報が正しいことが前提である。正しいことを確認できるのが，送信者認証技術なのだ」（センドメールの末政氏）
送信者認証技術は，「嘘をついている相手を突き止める」だけの技術ではない。もちろんそれもあるが，「嘘をつかせない技術」なのだ。「嘘をついていない相手からのメールはすり抜けるので効果がない」のではなく，「嘘をつかせないので，相手のアドレスを信用して次の手を打てる」ことに意味がある。
まだまだ発展途上の送信者認証にケチをつけることはたやすい。だが，インターネット・メールの信頼性を向上させようとする有意義な試みであることは間違いない。「直接迷惑メール対策にならないとしても，（インターネット・メールのインフラを）ある程度信頼できる状況にできる。つまり，全体のセキュリティ・レベルを一段上げられる」（ヤフーの佐藤氏）
実際に使われるようになるまでは先は長い。MAAWGのミーティングなどにも参加して現状に詳しいIIJの山本氏に，送信者認証の今後を聞いてみた。「まずは実装のしやすさで，SPFが今以上に広まるだろう。ただ，送信者認証のチェックが有効になるまでには，あと1〜2年かかるだろう。そのチェックの結果を基に，Reputationサービスなどで迷惑メールなどを排除できるようになるには，さらに1〜2年かかるのではないだろうか」
とはいえ，送信者認証には，MicrosoftやYahoo!，AOLといった“メジャー・プレイヤー”のほとんどが力を入れている。このため一度実装が進めば，多くのユーザーが影響を受けるようになる可能性は高い。企業のシステム管理者は注目しておきたい。
インフラの話なので，一般ユーザーにできることは少ない。送信者認証に対応したメール・クライアント・ソフトが提供されるまでは，一般ユーザーが意識することはないだろう。だが，「送信者認証技術なんて意味ないよ」とは思わないでほしい。「『どうせまた，いたちごっこになるだけ』の声もある。そうかもしれないが，手をこまねいてはいられないのが現状だ」（ヤフーの佐藤氏）。「万全ではなくても，やらなくてはいけない状況になっている」
これまでもそうだったように，将来的には役に立つ技術も，最初は意味のないものに見えるものではないだろうか。もちろん，これとは全く逆の見方もあるだろう。皆さんはどのようにお考えだろうか。
