高木浩光＠自宅の日記

■ メールのFrom:には複数のアドレスを書けるがS/MIME署名は？

メール本体のヘッダにある「From:」フィールド（Outlook Express日本語版では「送信者」として表示される）には複数のアドレスを記述できる。この仕様のことはあまり知られていないかもしれない。（なしにろ、そもそもFrom:が自由記述する場所だと知らない人も少なくないくらいなのだから。）

From:に複数のアドレスを書くのがどういうときかというと、たとえば、結婚する2人が連名で披露宴の案内メールを出す場合など*1だ。新郎と新婦のメールアドレスをコンマで区切って並べて書く。そして、実際に送信を行う者のアドレスをSender:に書く（ここには1つのアドレスしか書けない仕様になっている）。

From: "新婦の名前" <shinpu@example.com>, "新郎の名前" <shinro@example.jp>
Sender: "新郎の名前" <shinro@example.jp>

さて、この場合に、S/MIME署名をするとどうなるか。

新郎が新郎のコンピュータ上で電子署名しようとしたとき、新郎の秘密鍵入り証明書がコンピュータ上に登録されていれば、shinro@example.jp を署名者アドレスとして署名することになる。これを送信して、Outlook Expressで受信するとどうなるか。

結果は、以下のようになった*2。

From:のアドレスを逆順にして

From: "新郎の名前" <shinro@example.jp>, "新婦の名前" <shinpu@example.com>

として、新郎 shinro@example.jp で署名すると、正常な署名として扱われた。どうやら、複数のメールアドレスがFrom:にある場合は、先頭のアドレスを「送信者」として扱い、署名者と比較しているようだ。

この挙動は、はたして仕様なのだろうか？

署名者と送信者の一致確認について、RFC 2632 - S/MIME Version 3 Certificate Handlingは、次のように規定している。

3. Using Distinguished Names for Internet Mail

（略）

Receiving agents MUST check that the address in the From or Sender header of a mail message matches an Internet mail address in the signer's certificate, if mail addresses are present in the certificate. A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details.

RFC 2632 - S/MIME Version 3 Certificate Handling

MUAは、ヘッダのFromかSenderのアドレスと、署名者証明書のアドレスが一致することをチェックしなければならないとされているが、Fromが複数ある可能性については書かれていない*3。

では、ひとつのメールに複数の署名者で署名する（新郎と新婦で署名する）ことはできるのだろうか。まだ調べていないのでわからない。

ところで、8月29日の日記では、

Becky! 2.11.02 に付属の「Becky! S/MIMEプラグイン Ver.1.01」では、以下の図のように、「正当性が検証されました」と表示されるだけで、From: のアドレスとの一致検査は行っていないようだ。ユーザが自力で目視確認する必要がある。これは改善の余地があると言える。

と書いたが、RFCによれば一致検査はMUSTだとされているのだった。

また、RFC 2632を置き換えるRFC 3850 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handlingが今年の7月に出ており、一致検査の部分は少し詳細な記述になっている。

3. Using Distinguished Names for Internet Mail

（略）

Receiving agents MUST check that the address in the From or Sender header of a mail message matches an Internet mail address, if present, in the signer's certificate, if mail addresses are present in the certificate. A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details.

A receiving agent SHOULD display a subject name or other certificate details when displaying an indication of successful or unsuccessful signature verification. RFC 3850 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling

■ 「Sender ID」はphishing詐欺防止に効果をもたらすか

From:に複数のアドレスが書けるという話は、最近話題になっている「Sender ID」にも関係してくるはずだと思い、Sender IDについて勉強してみた。

• 「Sender Policy Frameworkはスパムには効かないものの，フィッシングには有効」, 日経IT Pro, 2004年9月1日
• 「送信者認証は“スパム対策”ではなくて“フィッシング対策”」――マイクロソフト, 日経IT Pro, 2004年9月6日

これらの記事のように、当初はspam対策だとされてきたSender IDが、最近ではフィッシング詐欺対策だと宣伝されている。

Sender IDとはようするに簡単に言うと次のようなものらしい。

• メール本体のヘッダの発信者等アドレス、すなわち「From:」または「Sender:」もしくは、「Resent-From:」ないし「Resent-Sender:」のアドレスを確実なものにする。

「確実なものにする」というのは、送信元を偽った送信でないかを、DNSを使って調べるようにし、偽っている場合には受信を拒否できるようにするというものだ。

Sender ID対応のMTAは、メールを受信するとき、送信元のMTAが送ってくる「MAIL FROM:」コマンドのアドレス（エンベロープのFROMアドレス）のドメイン名から、DNSを検索して、そこに登録されているドメインのMTAから接続されているかどうかを検査する。一致しなければ、偽りのメールであると判断（本物以外のサイトから発信されたメールであると判断）して受信を拒否する。

この仕組みが機能するためには、人々が次のように行動する必要がある。

-ドメイン名を保有する組織のDNS管理者は、自分の組織のものとして使うメールアドレスの発信元MTA（SMTPサーバ）のIPアドレスを列挙して、DNSに登録する。 -メール発信者は、自分の組織がSender IDに対応している場合（DNSに上の登録をしている場合）、指定されている（登録されている）SMTPサーバ以外からのメール送信をしないようにする。（そうしないとSender ID対応の受信MTAに拒否されてしまう。）

後者の点は、メール送信者の行動に次の制約をもたらすことになる。たとえば、これまでならば、会社のメールアドレスをFrom:とするメールを、ISPのSMTPサーバに接続して送信することもできたが、会社のDNS管理者がそのISPのSMTPサーバをDNSに登録していない限り、それができなくなる。

そこで、Sender IDでは、SMTPを拡張して「MAIL FROM」コマンドの後ろに「SUBMITTER」パラメータを追加できるようにする。会社のアドレス（example.co.jp）をFrom:として、ISP（example.net）のアカウント（POP before SMTPとかで）から送信する場合、ISPのMTAは、以下のコマンドで送信するようにするらしい。

MAIL FROM: <takagi@example.co.jp> SUBMITTER=takagi@example.net

（少し話がわき道にそれるが）このままだと、せっかく会社のFrom:アドレスで送信しているのに、ISPのアカウントのメールアドレスを送信先に知らせることになってしまうので、こんな仕組みに従うのは嫌だと思われるかもしれない。そこで、ISPなどがゲストサービスとしてこれを提供するということが想定されているようだ。つまり、

MAIL FROM: <takagi@example.co.jp> SUBMITTER=guest@mail.example.net

のようにSUBMITTERを指定するよう、ISPのMTAが振舞うことで、その問題を解決できるということのようだ。（以下、本題に戻す）

このとき受信者側のMTAは、SUMITTERアドレスのドメインがexample.netなので、それでDNSを検索し、そこに登録されているIPアドレスのSMTPサーバからの接続なのかを調べるというわけだ。

ということは、From:を偽ってどこからでも送信できてしまうということになる。これでは何の対策にもならないように思えるが、ここで、MTAがメール本体のヘッダに、Sender:やResent-From:を強制的に追加するところがミソのようだ。

受け取ったメールのヘッダに、Resent-From:ないしSender:があれば、それは（Sender ID対応の）MTAによって本物であることが確認されていることになる。

これがspam対策になるとされてきた理由は、Sender:やResent-From:などのアドレスを、spamフィルタのフィルタリング条件判断の入力とすることによって、より効果的なフィルタリングができるということらしい。その程度の効果しかないというわけだが、おそらく、Hotmailなどように大規模にメールユーザを抱えていて、膨大なspamの攻撃に遭っているところにとっては、大きな意義があるのだろう。

一般の組織にとってのspam対策効果は、現時点でははっきりしない。正規のメールまでspamとして扱ってしまう可能性も残るspamフィルタを、会社として導入するというのは難しい面もあるだろう。Hotmailのようなサービスでは、spamフィルタリングするという方針のもとでユーザを募ればよいのだし、Webメールでは、フィルタしたものを直接ユーザに見せるインターフェイスを提供できるのでうまくいくという面があるし、なによりも、spam攻撃の標的になっているために便益がに大きい。今後、企業がMTAで導入できる確かなspamフィルタソフトが普及してくれば、一般の組織にとっても意義が出てくるかもしれないというものだろう。

なので、Microsoft等が「Sender IDでspam対策を！」と主張しても、「なんでおまえらのために俺達が対応しないといけないんだ」という反応になってしまう。そこで、最近はフィッシング詐欺対策なのだという説明方法に転向してきているのだと思われる。

日経IT Proの記事にはこう書かれていた。

同氏によると，インターネットを使ってBtoCのサービスを提供している企業の多くは，フィッシングに名前を使われることを心配しているという。「フィッシングを企む偽メールの送信者に名前を使われると，エンドユーザーにはその企業がフィッシングに加担していると思われる可能性がある。企業はそのことを心配している。信用問題にかかわるからだ」（同氏）

名前を使われることを防ぐ方法の一つが，Sender IDなどの送信者認証を利用すること。もちろん，名前をかたられることを心配する企業側だけでなく，メールの受信者側でも対応しなければ，送信者が偽装されているかどうかは検証できない。しかし，企業側では，ある程度の説明責任を果たすことができる。

「送信者認証は“スパム対策”ではなくて“フィッシング対策”」――マイクロソフト, 日経IT Pro, 2004年9月6日

「偽メールの送信者に名前を使われる」のを防ぐといっても、SUBMITTERがキモであるので、From:アドレスを偽られることは防止できない。

「メールの受信者側でも対応しなければ」とあるのは、ようするに、From:を見てもだめで、Sender:ないしResent-From:などをユーザが目視確認するようにならないと、意味がないということなのだと思われる。

現在のMUAのほとんどは、メールの送信者としてFrom:だけを表示しているだろう。Sender:やResent-From:も同時に表示するようにして、皆がそれを意識して見るようにならないと、フィッシング対策にはならない。

この点について、Sender ID提唱者のInternet Draftは、次のように述べている。

7.5 MUA Implementers

When displaying a received message, an MUA SHOULD display the purported responsible address as defined by this document whenever that address differs from the RFC 2822 From address. This display SHOULD be in addition to the RFC 2822 From address. When a received message contains multiple headers that might be used for the purported responsible address determination, an MUA should consider displaying all of them. That is, if a message contains several Resent-From's, a Sender and a From, an MUA should consider displaying all of them.

J. Lyon and M. Wong, Sender ID: Authenticating E-Mail, Draft Specification, Internet Draft: draft-ietf-marid-core-03.txt, 2004年8月

これはフィッシング詐欺対策としてどの程度の効果があるだろうか。たしかに、これまででも、到着したメールが（From:が本物アドレスでも）本物かどうか疑わしいときは、ヘッダを表示させて、Received:フィールドをジロジロ見て調べるのが基本だった。ただ、そのようなことができるのは一部の詳しい人だけであり、普通の人にはできないことだった。これが、Sender IDの導入により、やりやすくなるということだと言える。

これまでは、Received:フィールドのSMTPサーバのIPアドレスから判断していたのが、（Sender ID対応サイトからの発信であれば）Sender:やResent-From:などに書かれた、メールアドレスから判断できるようになる。

しかし、全部のサイトがSender ID対応になるわけではないので、From:やSender:が書かれているからといって、それが確認されたものであるとの確証は得られない。

この点に対しては、Sender IDで確認済みとのことを示すフラグをMTAがヘッダに挿入して、その情報をMUAが表示するようにする必要があるだろう。もしそうしないのであれば、ユーザは、今見ているメールの送信者になっている会社がSender ID対応の会社であることを覚えていなくてはならない。

この仕組みはようするに、From:が自由記述の部分である（From:は送信者ではなく著者である）というインターネットメールの特性を残しつつ、それとは別に送信者アドレスをきちんと意識して使おう――ということなのだと思う。それはとても正論だと思う。

15年前のMUAユーザは、メールのヘッダを全部見ていた。ところが、ヘッダに余計なものがいっぱい挿入されるようになるにつれ、一部だけしか表示しないのが普通になっていった。それでも、10年前、EmacsのMUAでメールを読んでいたころの私は、Sender:は表示する設定にしていたと記憶している。

ところが、GUIのMUAが普及すると、From:しか表示しないのが普通になってしまった。それどころか、MicrosoftのOutlook Expressなんかは、メールアドレス本体さえ表示しないで、氏名（メールアドレスのコメント欄）だけを表示する。

さらには、日本語版Outlook Expressにいたっては、英語版では「From」と表示されている部分が「送信者」と翻訳されてしまっている*4。Sender ID Frameworkの根底の考え方にあるように、本来、インターネットメールにおいては、From:とSender:の違いがキモであるにも関わらず、日本語版Outlook Expressは、両者を区別しないパープリン翻訳従事者によって作られている。

こういうおバカ仕様のMUAを普及させたことを反省して、本来の姿に戻ろうというのが、この「Sender ID Framework」の本質なのだと言える。

さて、信頼ある企業のとるべきフィッシング詐欺対策という観点で見ると、長期的にはたしかにSender ID Frameworkは有効であるし、本来の姿なのだろうけれども、中途半端にしか普及しそうにないものが普及するのを待つまでもなく、今すぐ電子署名すればよいのであるし、元々そうするべきである。