PR

 迷惑メールやフィッシング(オンライン詐欺の一種)対策の一つとして期待されるメールの送信者認証技術。米Microsoftなどによる「Sender ID」や米Yahoo!の「DomainKeys」が有名だ。特に,Sender IDは「まもなく“インターネット標準”になる」といわれ期待されていたものの,標準化が頓挫。と思ったら,再び標準化を目指してIETF(Internet Engineering Task Force)に提出されるなど,動きが目まぐるしい。

 そこで本稿では,関係者への取材やIT Proに掲載した記事を基に,送信者認証技術の基本から最新の動向までをまとめた。

それぞれ仕組みが異なる送信者認証

 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ワーキング・グループは解散。「もともと,半年という短期間で仕様をまとめることを目的に作られたワーキング・グループだった。異論が出たことで,当初の目的が果たせないことが明らかになり解散したのだろう」(IIJの山本氏)