6月6日の日記「HTMLメールマガジンをどうするか」で予告していた、メールマガジンをHTMLメールで流すことの危険性、つまり、勝村氏が指摘するソフトウェアの欠陥の話以外の、セキュリティ上のより本質的な問題点について書く。
メールはWebに比べて偽物を作りやすい。メールのヘッダの「From:」は、元々自由記述するところなので、発信者が偽でないかを確認するには全く当てにならない。「Received:」を見れば偽の可能性を知ることができる場合もあるが、本物の場合に、それが必ずしも発行者のドメインと一致しているとは限らない（メールマガジン配送業者に委託されているかもしれない）ので、偽物か本物かの区別は一般の人には難しいだろう。メールに電子署名することでこの問題は解決するのだが、現状では全く行われていないと思われる。
Webでは、ブラウザのアドレスバーに表示されるURLを目視確認することで、閲覧者は、自分が今、本当に期待しているサイトを見ているのかを絶えず確認する習慣になっている。（万が一に発生するかもしれない、通信路上でのパケットすり替えや、DNSスプーフィング攻撃の心配を払拭したいときには、「https:」で同じサイトにアクセスしてみれば、本物であることを確認できる。）
プレインテキスト形式のメールマガジンでは、読者は、気に入った情報があれば、マガジン中に記載されたURLにアクセスすることになる。このときのURLは、テキストでそのまま書かれているのだから、読者はドメイン名を見て、それがいつもの信頼しているサイトであるかどうかを無意識のうちに確認しているだろう。それに対し、HTMLメール形式のメールマガジンでは、読者は、画像や、任意の文字列にマークアップされたリンクをクリックして、目的のページにジャンプするのだから、そのときにドメイン名を確認することを普通はしない。
HTMLメールからリンクをたどったときに、Webブラウザのウィンドウで開くようになっている場合には、ジャンプ後のブラウザのアドレスバーを見ることで、信頼しているドメインにアクセスしているかどうかを確認できる。しかし、アドレスバーを隠したポップアップウィンドウが現れる場合はどうか。
6月2日の日記にも書いたように、日経システム構築の調査によると、インターネットバンキングのログイン画面を、アドレスバーを隠したポップアップウィンドウにしている銀行が、32行も存在するという。「ITコマースの脆弱な現実と危機回避に向けた展望」の3.2節「なりすましに無警戒な銀行のログイン画面」では次のように指摘されている。
もしこの銀行を装った偽のウィンドウを出現させる悪意のあるサイトが存在していたらどうだろうか．「こちらは○○銀行です．只今キャンペーン実施中です．今ログインして頂いた方には粗品を差し上げます．」といった電子メールやバナー広告に誘われて，指定のサイトにアクセスしたときに，同じデザインのウィンドウが現れるといったことはあり得るだろう．このとき，日頃から図4のウィンドウに慣らされているユーザは，「右クリック＋プロパティ」によってそのウィンドウのURL のドメインを確かめようとするだろうか．これを確かめることなく，偽のウィンドウに口座番号とパスワードを入力してしまえば，それは悪意ある者によって収集されてしまう．
こうした偽のウィンドウを出す偽メールマガジンは、それがHTMLメール形式だと騙されやすいものとなる。リンクの部分が、任意の文字列や画像になっているからだ。より騙されやすいリンクとして、本物のURLが書かれているように見せかけて、リンク先は別のサイトになっているという罠もあり得る。たとえば次のようなコードだ。
<a href="http://example.com/doom.html">http://www.cyberpolice.go.jp/</a>
どうにもこう、アドレスバーを隠したポップアップウィンドウがやたらと不用意に使われているという実態がある。警察庁ですら警戒が足りないようで、警察庁の「@police」サイトの中央下に並んでいる「topics」というところの「重要」情報のリンクをクリックすると、アドレスバーを隠したポップアップウィンドウが現れる。この画面に見慣れている人は、「平成１５年６月１０日 警 察 庁」とさえ書かれていれば、本物と信じてしまう習慣が身についているかもしれない。このような「重要なお知らせ」を、ポップアップで出す意義がいったいどこにあるのだろうか。誰の判断なのか。実装業者がなんとなく見た目のデザインで決めたのか、発注時にこのような画面設計が指定されていたのか、それは知らないが、騙され難さを重視するなら、このような画面設計はやめるべきだ。どのくらいの騙されやすさがあるのか、知られていないのかもしれないので、実演してみることにする。以下をクリックするとどうなるだろうか。
本日の重要なお知らせ （平成１５年６月１３日）
普段からHTMLメールでメールマガジンを受け取っていると、こうした成りすまし攻撃に騙されやすくなってしまうといえる。メールマガジンの案内でアクセスする先が、クレジットカード番号や、パスワードや、個人情報を入力する画面を持つならば（たいていのメールマガジンはそうした画面に案内するものだろう）、こうした成りすましに警戒することは欠かせない配慮であるはずだ。特に、本物サイトでポップアップウィンドウを使っているところでは、すでに危険な状態にあるといえる。
これに対し、6月6日の日記で提案したように、HTMLマガジンをWebサーバに置いて、プレインテキスト形式のメールで最新号発刊の通知だけを送信するならば、購読者は、メール中のURLを目で見て、本物のドメインかを確認するので、騙されやすさを低く抑えられる。
HTMLメールのこの危険性のことはあまり知られていないのだろうか。小島さんの「セキュリティホールmemo」では5月30日付けのコメントでふれられているが、勝村氏の「HTMLメールはやめよう」では言及されていない。勝村氏は徹底してHTMLメールの問題を列挙したかったはずなのにだ。読者コメントにも無かったように記憶している。特にひどいのは、6月7日の日記で紹介した、高橋智明氏の@ITの記事「HTMLメール普及を狙う広告業界」だ。そこには次のように書かれている。
また、フォームで購入注文を受けつけたり、アンケート調査を行ったりしたい場合など、テキストメールではいったんURLをクリックしてもらい、所定のWebサイトに誘導する必要があるが、HTMLメールならメール本文にフォームを表示できる。そのため、ユーザーは直接入力して返信することが可能だ。たかがワンクリックと思われるかもしれないが、このワンクリックを省略できることでアンケートの回答率や購入率が飛躍的に上がるという。
そんな、どこに送信するのか得体の知れないフォームに、やすやすと入力させるとは、著しく見識を疑う。「所定のWebサイトに誘導する必要がある」からこそ、本物の情報だと確認できるのだ。
責めてばかりなのでフォローしておくと、高橋氏の記事には優れたものもある。同じ@ITのシリーズの「銀行界を震撼させたネットバンキング不正送金 拡大するインターネットバンキングに暗雲」と、「銀行は事態の深刻さを認識しているか？ ネットバンキング不正利用事件の問題の本質」という記事は、言うべきことを言っている貴重な記事だと思っている。こうした、セキュリティに意識の高いはずのIT記者にさえ、HTMLメールの本当の危険性が理解されていないことに、問題の深刻さが見える。
メールマガジン発行者は、自社のドメイン名を信頼の基点としてもっとアピールすべきではなかろうか。テキストメール形式のメールマガジン中にドメインを記述し、それが本物であることを確認するよう購読者に促してはどうだろうか。
あるいは、偽メールの危険性を重視して、メールマガジンに電子署名するようにしてはどうだろうか。認証局方式の署名付きメールは今ひとつ普及していないが、これは、署名に必要な証明書が有料であるため、個人ではあまりコストに見合っていないためと思われる。メールマガジンは事業者が発行するのであるから、https: 用のサーバ証明書を購入するのと同じように、メールマガジンのFrom:アドレスに対応するメール署名用証明書を購入して使用してはどうだろうか。信頼性に重きをおく事業者であるとアピールできるばかりでなく、これによって署名メールの一般への普及も促進されるかもしれない。なお、プレインテキストメールにも署名した方がよいだろう。
これまではあえて論点をオプトイン方式のメールマガジンに絞ってきたが、それ以外について考えてみる。
HTML形式のspamメールは、Webバグを挿入することによって、有効なメールアドレス（到達して開封される「新鮮な」アドレス）の抽出を行うことが可能だ。つまり、何百万ものでたらめなメールアドレスを生成してシリアルナンバを振り、それをWebバグとして埋め込んだHTMLメールを送信すれば、Webサーバのアクセスログに記録されるシリアルナンバーから、新鮮なメールアドレスのリストを得ることができる。実際にそうしたWebバグを含むspamメールが多数流れている。<img>だけでなく、<iframe>と<ilayer>を使ったものも見つかる。他にもいくつかのタグで同様のことが可能だろう。
これは、もはや致命的な欠陥と言えよう。この脅威から逃れるには、HTMLメールを表示しない設定にするか、外部への参照をロードしない設定にするしかない。6月7日の日記に書いたように、Mozillaでは、「Privacy & Security - Images - Image Acceptance Policy」の設定項目で「Do not load remote images in Mail & Newsgroup message」をチェックしておけばよい。Netscape 7では、「プライバシーとセキュリティ - 画像 - 画像受入証書」の「Mail & Newsgroupメッセージにリモート画像を読み込まない」という翻訳となっている（「受入証書」は訳が変だなあ）。セキュリティホールmemoの6月9日のコメントの追記に、この機能に関連する話題が集められている。また、Office 2003のOutlookでは、デフォルト設定で外部コンテンツの参照が遮断されるという話が、ZDNetの「Office 2003――6つ（あるいはそれ以上！）の版のどれを選ぶか」に書かれている。引用すると、
これはつまり、Microsoftから送られてくるものを含め、私が受信するほぼすべての電子メールニューズレターがグラフィックスなしで表示されるということだ（AnchoeDeskのニューズレターのグラフィックスも遮断される）。
この機能はスパム対策の1つとされるものだが、これでは受け手が実際に受信したいコンテンツもめちゃくちゃになってしまう。この機能がOffice 2003のファイナルビルドで採用されようとされまいと、大量のジャンクメールをメールボックスに送りつける不届き者がその行為をやめることはないだろう。あまり役立ちそうにないこの機能をめぐって、私は今、Microsoftにかけあっている。結果は今後のコラムで報告しよう。
この人は、新鮮なアドレスが抽出される仕組みを知ってて言っているのだろうか。（原文記事のTalkBackを見てみると、「HTML Email Blocker is easy to turn off」と言っている人が……。）
そうした防衛が当たり前のものになってくると、現在のHTMLメールマガジンは、まともに内容を表示できなくなる。しかし、このことはマルチメディアメールを否定するものではない。MHTML (MIME-encapsulated HTML) 形式を使えばよい。MHTMLは、RFC 2557で定義されており、一通のメールにHTMLとそのリンク先オブジェクト（画像など）をまとめて送信できるようにする形式だ。Internet ExplorerでWebページを「名前を付けて保存」するとき、「ファイルの種類」を「Webアーカイブ、単一のファイル (*.mht)」を選ぶと、このMHTML形式で保存される。MHTMLの肝は、MIMEメール中のパートにContent-IDを付け、HTMLから「cid:」のURIで参照できるようにした点にある。ちなみに、2001年9月に大流行したNimdaワームは、この「cid:」を使ってウイルス本体をHTMLから起動する仕掛けになっていた。（ただし、起動してしまうのはIEのバグに原因があったのであり、MHTMLの欠陥ではない。）
1999年3月にリリースされたこのRFC 2557では、「Security Considerations」の章で、次のように述べられている。
HTML-formatted messages can be used to investigate user behaviour, for example to break anonymity, in ways which invade the privacy of individuals. If you send a message with a inline link to an object which is not itself included in the message, the recipients mailer or browser may request that object through HTTP. The HTTP transaction will then reveal who is reading the message. Example: A person who wants to find out who is behind an anonymous user identity, or from which workstation a user is reading his mail, can do this by sending a message with an inline link and then observe from where this link is used to request the object.
MHTMLメールを使えばこのプライバシー侵害がなくなるわけではない。MHTML中に外部サーバへの参照を書くことはできてしまう。メーラの設定で外部参照のダウンロードを止めた上で、マルチメディアコンテンツの必要があればMHTML形式で送ればよいという話だ。
では、メールマガジンでMHTML形式は使われるだろうか。当面それはないと思われる。MHTML形式にするとメールサイズが大きくなる。参照する画像のすべてを含ませるので、一通が500Kバイトくらいになるのではなかろうか。今のHTMLメールマガジンでも、画像はいずれにせよダウンロードするわけであるが、その場合は後で必要に応じてダウンロードするのに対して、MHTMLメールとして最初に全部をダウンロードせざるを得ないのは、次のメールの取得が遅れるという点で消費者は不快に思うだろうし、メールスプールが溢れてしまうという問題がある。やはり、HTMLマガジンは全部Webサーバに置けばいい。
実家の両親にWindowsマシンをプレゼントしていたのだが、ある日からメールがHTMLでやってくるようになった。「送信」の設定を「テキスト形式」にしておいたはずなのに、自力で設定を変えたらしい。帰省したとき尋問してみると、なにやら「夢メール」というものが「メル友」達との間で流行っているのだという。
「夢メール」とは、JavaScriptを使って画像に動きを与えた、「かわいいメール」のようだ。うちの両親は、知人から送られてきたメールでこれのことを知ったそうで、知人が言うには絵が動くはずなのに、自分の画面では絵が動かないと嘆いていた。これは、Outlook Expressのセキュリティ設定で「制限付きサイトゾーン」から「インターネットゾーン」に切り替えれば、絵が動くようになる。設定を変えて見せてやると、2人はいたく感激して、今までにもらったメールを全部読み返し、喜び勇んで「メル友」たちに新たなメールを送っていた。
この様子を眺めて私は、設定を元に戻すべきかに悩まされた。なにしろ、彼らは、動くメールや、色つきのメールを、旅先で知り合った「メル友」とやりとりすることくらいしか、「パソコン」の楽しみ方を知らないのだ。（ダイヤルアップ接続であるため、Webサーフィンを楽しめていないということはあるようだが。）
こういった人たちに対して、「HTMLメールはWebサーバに置けばいい」とは言えない。ホームページなんか持っていない人たちだからだ。
ナンバーディスプレイ機能のなかった時代の電話を思い出すと、かかってきた電話は基本的に信用できないもので、自分からかける電話はそれなりに信用できるものだというのは、誰でも直感的に知っていただろう。訪問販売で買わされるより、自ら出向く買い物の方が信用できることも皆知っている。（電子署名されていない）メールは、かかってくる電話や訪問販売と同様に、信用のアンカーとなるものがない。または希薄だ。HTMLメールは、見た目こそWebページと同じだが、信用のレベルは全く異なる。アドレスバーが隠されて、プロパティの確認もできないようにされた、得体の知れないWebサイトに等しい。Outlook Expressのデフォルト設定が「インターネットゾーン」から「制限付きサイトゾーン」に変更されたのは、理にかなっている。あるいは、もうひとつ別のゾーンとして「未信頼ゾーン(Untrusted zone)」を設けて、メールは未信頼ゾーンとすると、よりしっくりくるかもしれない。外部から認証なしで受け取るタイプのメディアは、未信頼のゾーンにある。
電話を折り返しかけなおしたり、訪問販売員の身分を確認するのと同様に、メールマガジンの購読者には、「未信頼ゾーン」から「信頼済みゾーン」（あるいはそこそこ信頼できる「インターネットゾーン」）へと移行するステップが必要なはずだ。プレインテキスト形式のメールマガジンでは、マガジン中のURLを開く操作がそれに相当するが、HTMLメール形式だと、そのステップの存在があやふやになってしまいかねない。この重要なステップのことを忘れて、見た目だけWebページ風のマガジンを発行するのは、（オプトイン購読してくれているという）顧客からの信頼を、蔑ろにしてしまっているとさえ言える。