<前の日記(2003年06月05日) 次の日記(2003年06月07日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 56   昨日: 2967

2003年06月06日

HTMLメールマガジンをどうするか

先週から日経IT Proの「記者の眼」で、HTMLメールの是非の議論がヒートアップしていた。

前者は、「HTMLメールを拒否する人は少数に」なったので「HTMLメールに期待をかける事業者が急増している」という内容。これに、読者コメントが猛反発した。予想されていたことなのか記事の末尾には「来週,セキュリティの観点からも再度取り上げる予定」と予告されていた。その予告記事が後者の「HTMLはやめよう」だ。書いた記者が異なる。後者の著者は、IT Proでセキュリティ脆弱性の話題を追いかけてきた勝村幸博氏だ。すると、後者の記事にも反発コメントが寄せられた。代表的なコメントは、

このHTMLメールに対する批判は、非常に感情的で幼稚で間違ったものだと思います。企業は商業主義ですから、効果的なものを選ぶのが当然ですし、そこれそが資本主義の要です。それなのに、企業はHTMLメールの危険性を考慮するべきだ、とは、あまりに意味がなさ過ぎる提案です。時代は移り変わります。いつまでもHTMLメールを否定しているようでは、それこそ頭が堅いのではないでしょうか。

というもの。同趣旨のコメントが他にも複数見られる。

ここで注意したいのは、この議論はあくまで「HTMLメールマガジン」が対象という点である。つまり、個人間のHTMLメールのやりとりのことは議論の対象外だ。spamではなく、メールマガジンなので、オプトイン方式(受信者が望んで受け取っているもの)であるとする。

HTMLマガジンはWebサーバ上に置けばいい

さて、先に結論を述べておく。メールマガジンに視覚的な表現力を求めるなら、Webサイト上に(HTMLで書いた)マガジンを置けばいい。メールには、マガジンのURLだけ簡潔に紹介すればいい。たとえばこんな感じだ。

From: weekly-magazine@style.example.com
Subject: スタイルドットエグザンプル マガジン 第34号 

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
       スタイルドットエグザンプル マガジン 6月7日号      
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第34号のメールマガジンをお届けします。
http://style.example.com/mag/0034.html

―――――――――――――――――――――――――――――
発行・編集: スタイルドットエグザンプル株式会社
配信の停止はこちら: http://style.example.com/unsubscribe.html
―――――――――――――――――――――――――――――

内容をこれだけにする。余計なことは書かない。

「こんなのメールマガジンじゃないじゃないか」と言われるかもしれないが、URLをクリック(ないしダブルクリック)すればマガジンを読める。「クリックしてもらえなかったら困る」と言われるかもしれないが、これだけ内容が簡潔だと、普通クリックするだろう。なにしろ、オプトインで受信しているのだから、無視することはないはずだ。マガジンのその回の表題をメールに書いてないところが重要だ。へたに表題を書くと、クリックしてもらえない可能性が増す。何も書いてないと、とりあえずクリックしてみるはずだ。クリックせずに捨てる人は、本来購読をやめているはずの人だ。

こう書くと、こう反論されるかもしれない。「わざわざクリックして見に行くはずがない。メールマガジンは受信し終えたものを、そのまま読むから効果的なのだ。ナローバンドのダイヤルアップ接続の購読者が、わざわざ回線をつないでアクセスしてくれるとは考えられない」と。

ちょっと待ってほしい。今はHTMLメールのことを話しているはずだ。ダイヤルアップ接続の人は対象としていない。HTMLメールマガジンのほとんどは、画像データをメール中に含めておらず、サーバ上の画像ファイルへのリンクを書いたHTMLを送信している(メールのデータサイズを小さくするためにそうなっている)。そのため、HTMLメールマガジンをメーラ上で表示させるとき、回線がつながっていないと画像が表示されない。HTMLメールマガジンは、購読者がブロードバンド常時接続環境であることを前提としているのだ。このことは、「HTMLメールが急増中」でも次のように書かれている。

こうした変化に大きく関係しているのが,ブロードバンドの普及である。平均的なHTMLメールのデータ容量は,100K〜150Kバイトと言われているが,ブロードバンドならば問題ない。また,HTMLメールでは画像をWebサーバーに置き,開封時にダウンロードするのが普通。オフラインでは画像が表示できないが,常時接続を実現するブロードバンドでは問題にならない。こうした回線環境の変化が,HTMLメールに対するユーザーの意識を変えたのである。

「こうした回線環境の変化」があるのだから、上の簡素なメールのURLをクリックすることなど、ごく自然に手が動くはずであろう。

そもそも、通常のWebサイト並の視覚的表現力を必要とする「チラシ」を、なぜわざわざメールで送ろうとするのか。そのままWebサイト上に掲示すればよいではないか。個人間メールと違って、チラシの内容は読者全員に同じ内容なのだから。メールは、チラシの最新号ができ上がったことを通知するためだけに使えばよい。メールで宣伝文句を送ろうなどというのは、ダイヤルアップ接続時代の都合で生まれた過去の遺物でしかない。

ここまでの議論で、「どっちでもよい」ということになる。あとは、HTMLメールでマガジンを配信することの問題点を示せばよい。

プライバシー問題

HTMLメールはやめよう」の記事では、やめるべきとする理由として、主に「ウイルスの温床」を挙げている。Outlook Expressなどで、プレビューするだけで添付ファイルが起動してしまうことが問題だとしている。残念ながらこの根拠は弱い。それは仕様ではないからだ。

これはIEのセキュリティホールが原因なのであり、プログラムを修正すればその問題は解消する。この筆者は、修正していないユーザが現実に多いのだからと主張を続けるが、テキストメールでも、プレビューしただけで添付ファイルが起動してしまうセキュリティホールはあり得る。バッファオーバーフローが原因のものだ。事実、いくつかのメーラにはそうしたセキュリティホールが発覚している。たまたまそれを悪用したウイルスがさほど流行していないだけだ。

それでも現実にHTMLメールによるウイルスが多いのだから、HTMLメールをやめるべきだということなのだろう。私もそれに賛成だが、HTMLメールを否定する根拠としては弱い。

HTMLメールが否定される本物の根拠は、プライバシー問題である。「Webバグ」あるいは「Webビーコン」と呼ばれる問題のことだ。「HTMLメールはやめよう」の筆者の勝村氏は、このことについて次のように書いている。

HTMLメールにはウイルスの問題だけではなく,プライバシの問題もある。HTMLメール中にイメージ・タグを記述して,画像データを事業者のサーバーからダウンロードさせるようにすれば,サーバーのログからメールを“開封”したかどうかが分かる。ログからは,そのユーザーのIPアドレスが分かるだけだが,何らかの方法でユーザーの個人情報とひも付けることも可能だろう。

これには驚いた。あれだけセキュリティ問題を追いかけてきた勝村氏でさえ、Webバグのことを正しく理解していない。

Webバグの仕掛けられたメールをオンライン状態で表示したとき、発信元に通知されるのは、IPアドレスだけではない。受信者のメールアドレスが通知されるのである。実例で具体的に見てみよう。「HTMLメールが急増中」で取り上げられていた、「ファミマ・ドット・コム」のメールマガジンを早速購読してみたところ、HTMLメールの末尾部分は以下のようになっていた。

<img src="http://61.194.36.188/get_info.php?id=fami0602&send_id=b5b2...7934a&uid=4104"></HTML>

ここに私のメールアドレスは含まれていないが、「uid=4104」は私の会員番号だろう。このように、HTMLメールマガジン(のうち「Webバグ」を含むもの)は、送信先の相手ごとに異なる内容のメールを送っているのだ。メールを読むと会員番号が通知される。会員番号を通知することは、メールアドレスを通知しているのと同等である。

セキュリティ専門記者の勝村氏にさえこのことが知らされていないのだから、一般消費者は、99.9パーセント以上がこのことを知らないまま騙されているだろう。

これは、軽い道義的問題という程度のものではない。財団法人日本情報処理開発協会プライバシーマーク事務局の、「プライバシーマーク申請から利用までの流れ」に、次のように書かれている。

3. 現場での実施状況の確認

  • オンライン特有の処置
    • 個人情報保護方針の掲載
    • 収集時の SSL の使用
    • サービス、業務毎の“同意文言”
    • Cookie などのウェブバグの利用の有無
    • クロスサイトスクリプティング(CSS)などのセキュリティ対策

Webバグを使っていないかは、SSLの使用やクロスサイトスクリプティング対策と同列に重要なチェック項目とされているのだ。購読者の同意を得ずに密かにメールにWebバグを埋め込んでいる企業は、プライバシーマークを取得できない。ファミマ・ドット・コムのプライバシーポリシーに、「Webバグ」ないし「Webビーコン」についての説明は見当たらない。会員登録画面のメールマガジン要否選択の部分にも説明がない。

隠された本当の意図

実は、事業者がメールマガジンをHTMLメールで発行したがる本当の理由は、このWebバグによる情報収集にある。「[memo:6011] メールマガジン中のジャンプ先URL上の謎のID文字列の能力」には、事業者がそうした情報収集をはっきりと意思を持って行っていることが示されている。[memo:6011]の事例では、プレインテキストのメールマガジンであるため、IDによって追跡を行っている様子が目に見えている。[memo:6011]から引用すると、事業者は以下のように回答している。

ご指摘のとおり、この「ユニークな文字列」は配信されるメールごとに異なりますので、詳細な調査を行えば、それがどのメールアドレス宛てに配信されたものかを特定することは可能です。 ただし現時点では、この「ユニークな文字列」は、配信されるメールごとに固有のURLの一部として割り振られているだけで、お客様のメールアドレスと明確に 「関連付け」てはおりません。また、ダウンロードの有無によらず、どのお客様がアクセスされたか、という情報について確認および記録等の行為は行っておりません。つまり、現時点でこの仕組みから弊社が得ているのは、あくまでも「統計的データ」ということになります。

つまり、「統計的データ」を得るという意思を持って、こうした仕組みをわざわざ付けているのである。さらには、

将来的には、どのアドレスに送ったメールからアクセスがあったのかということを、メールを利用したマーケティング手法の一つとして把握する必要が出てまいります。その際には配信対象者へ必要な情報を開示し、承諾を得ながら実施いたします。

という考え方も存在しているようだ。

日経インターネットソリューションの小川弘晃氏は、「HTMLメールが急増中」の中で、なぜこの強力なマーケティング手法のことを書かないのだろうか。日経インターネットソリューションの記事は、多くの人がコメントしているように、マーケティングの立場から書かれた記事だ。HTMLメールのメリットとして、「ビジュアルな表現が可能」ということしか挙げていない。専門誌のくせに、Webバグマーケティングのことを知らないのだろうか。それとも、知っているが(お客様に余計な心配をかけないよう)あえて説明しないでおいているのだろうか。「説明による同意」ではなしに、「騙し騙し路線」で行くつもりなのか。

日本の事業者は、「説明による同意」ということがどうにも不得手のようだ。プライバシーポリシーの書き方として、何をどうするという説明をせずに、ただひたすら「お客様の個人情報は万全に管理して第三者に渡しません」とだけ書いて、あとは信じろという態度をとることが多い。事業者当人がいくらちゃんとやっているつもりであっても、何が起きているのかを本当にきちんと把握できているのかどうかだ。たとえば、先のファミマ・ドット・コムのWebバグ部分を見てみよう。

<img src="http://61.194.36.188/get_info.php?id=fami0602&send_id=b5b2...7934a&uid=4104"></HTML>

アクセス先のアドレスが、「famima.com」ではなく「61.194.36.188」となっている。逆引きしてみるとこれは「vmm.rootcom.jp」というホストだ。いったいどういう素性のサーバなのか。どうしてわざわざ数値形式のIPアドレスで書いているのか。「famima.com」以外に送信している事実を目立たなくしたいからなのか。なぜ目立たなくする必要があるのか。ファミマ・ドット・コムはこの事実を把握できているのか。プライバシーポリシーにこういうことをやっている事実説明が書かれていないだけに、もしかするとファミマ・ドット・コムの責任者も知らないのかもしれない。メールマガジンマーケティング会社の言うなりにアウトソースしているだけで。

マーケティングとプライバシーの両取りは可能では?

「説明による同意」は実施するとすれば、事業者にとってHTMLメールマガジンは有益なマーケティングツールとなる。私は冒頭で、HTMLマガジンはWebサーバ上に置けばよいとした。あの方法では、Webバグマーケティングが働かない。しかし、プレインテキストメールでも、IDを埋め込むことはできるので、次のように改良すればよい。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第34号のメールマガジンをお届けします。
http://style.example.com/mag/0034.html?userid=24312
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

こうすることで、HTMLメールを使わずにしてマーケティング能力も温存できる。もはや、HTMLメールを使う意義は全くない。それどころか、プレインテキスト中にIDを記入したので、より透明性の高い「説明による同意」を達成できているという点で、こちらの方が優れている。

このようにユーザ番号がはっきり見えていると、購読者が毛嫌いするのではないかと心配する声もあるかもしれない。事業者としては統計的データだけを抽出しているのに、購読者が個人追跡をされていると誤解することが心配かもしれない。

ならば、統計的データしか得られないようにすればいいのだ。つまり、

http://style.example.com/mag/0034.html?hash=312

のようにする。「312」は「24312」の下3桁だけを取り出したものだ。こうすると、個人を特定せずに最初から統計的データだけを得ることになる。これでは不十分なのか。どのみち有効桁2桁程度の値しか使う気がないのなら、これで十分じゃないのか。そういったことをきちんと検討したことがそもそもあるのかと問いたい。

つづく――次回予告: HTMLメールのもうひとつの危険性

訂正

「「uid=4104」は私の会員番号だろう」と書いたが、「HTMLメールが急増中」によると、ファミマ・ドット・コムは「会員20万人」とあるので、つい最近登録した私の会員番号が「4104」ということはないか。

もう一度WebバグのURLを見てみると、

http://61.194.36.188/get_info.php?
id=fami0602&
send_id=b5b21eab18ce6428c7ba87a2b9f7934a&
uid=4104
という構成になっている。このサーバはメール配信業者のもので、おそらく、複数の顧客(メールマガジン発行主体)のメールマガジンを一手に扱っていると考えられる。「uid」はメール配信業者にとっての顧客番号なのかもしれない。「send_id」がおそらくメール1通ごとに割り当てられたIDで、これが送信先アドレスと対応付けられていると考えられる。IDと送信先アドレスとの対応表を保存しているかどうかは、説明されていないので不明。ちなみに、このメールマガジンは、Webバグ(見えない画像)だけでなく、通常のリンク先のURLも以下のように、同じ形式で管理している。
http://61.194.36.188/get_click.php?
url_id=3&
id=fami0602&
send_id=b5b21eab18ce6428c7ba87a2b9f7934a&
uid=4104
「id」がメールマガジンの名称と発行番号、「url_id」がジャンプ先ページの番号で、「send_id」が購読者ごとに別々の番号、「uid」が契約者番号といったところか。

検索

<前の日記(2003年06月05日) 次の日記(2003年06月07日)> 最新 編集

最近のタイトル

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|
<前の日記(2003年06月05日) 次の日記(2003年06月07日)> 最新 編集