木曜日, 5月 31, 2007

日経コミュニケーションに載った

 「日経コミュニケーション」2007年6月1日号の贈呈誌をいただいた。p.66~71にS25R方式の記事が載っている。タイトルは、

企業を熱くする最新テクノロジ S25R
無料で使える迷惑メール対策 疑わしき通信をシャットアウト

 S25R方式について、わかりやすく正確に解説していただけた。記事の中で、サイバー大学の園田道夫准教授から「迷惑メールを入り口でシャットアウトできるうえに、メールの中身まで解析しなくても済む」とのコメントをいただいている。
 なお、一部誤植があった。

p.70 第2段組 2行目
エンド・サーバーのパソコン → エンド・ユーザーのパソコン

火曜日, 5月 29, 2007

「バウンシングバック認証」で検索上位

 5月14日「バウンシングバック認証という無茶なやり方」が、5月29日時点で、「バウンシングバック認証」のGoogle検索で1位になっている。「バウンシングバック」の検索でも上位にある。マスコミサイトでは画期的な技術ともてはやされる風潮の中で、バウンシングバック認証方式について調査しようとする人たちの目にとまりやすくなったことをうれしく思う。
 私は決して、S25R方式だけが良いスパム対策方式でほかの方式はだめだと言いたいのではない。ただ、すべての善良なインターネットユーザーがスパムの被害から救われてハッピーになってほしいのである。バウンシングバック認証方式が本当にすべての善良なユーザーをハッピーにするのかどうかを考えていただきたい。
 私が書いてきた懸念が杞憂であるなら、それはそれでよい。しかし、バウンシングバック認証方式を使ったアプライアンスやホスティングサービスの利用を考えている人は、ベンダーあるいはプロバイダが私の懸念に対して筋道立てて論駁できるのかどうかを確かめていただきたい。
 また、特に企業のネットワーク管理者や経営者は、“スパムの完全排除”の裏にひそむリスクを認識していただきたい。プロバイダは、貴社のお客様にバウンシングバック認証の手間をかけさせないためには「ユーザーがあらかじめホワイトリスト登録すればよい」と言う。しかし、貴社は全社員にそれを徹底し続ける自信があるか。「スパム対策のために客のメールを疑って客に手間をかけさせるのか」とお客様を不快にさせるおそれがないと言い切れるのか。
 貴社の製品に興味を持ってくれた、お客様になってくれるかもしれない人が、ウェブのフォームで問い合わせをしてきたとする。社員がそれにメールで回答した。問い合わせをした人が、さらにそのメールに返信した。正しく返信したのに、「認証手続きをしてくれなければあなたのメールを受けてあげません」と解釈される自動メールを送り付けられた(これは、回答メールを送った時に相手をホワイトリスト登録しておいても完全には避けられない。相手が受信用に開示したアドレスがエイリアスで、相手からのメールの送信者アドレスがそれとは異なることもあるから)。依頼文の書き方がどんなに丁寧でも、それは無礼なことではないのか。それで気を悪くさせてビジネスチャンスを失うリスクはないと言えるのか。そこを考えていただきたい。
 ついでに、バウンシングバック認証について調査しようとしてこのブログにたどり着いてS25R方式の名前を知った人は、すでにS25R方式がどれほど多くの人の注目を集め、どれほど多くの人に支持されているかを知っていただきたい。
 S25R方式にも、正当なメールを疑って受信を遅延させるというリスクはある。しかし、送信側からは、受信側の一時的なシステムトラブルだったかのようにしか見えない。正しく運用していれば、お客様に手間をかけさせることはないし、貴社のセキュリティポリシーがお客様に対して無礼なものだと思われる心配はない。
 良いことしか言わない商用アプライアンスとは違って、S25R方式を無償公開した私は、論文でその弱点をも初めから公表している(ただし、スパマーが弱点を突くには高いコストを強いられることも)。S25R方式の支持者は、それをわかって支持してくださっている。もちろん、ほかのスパム対策方式もある。セールストークを鵜呑みにせずにちゃんと調査し、何が良いのかを比較検討した上で決断していただきたい。

日曜日, 5月 27, 2007

バウンシングバック認証の破り方

 「バウンシングバック認証でスパムの阻止率100%。スパムを受信したら返金します」と豪語されると、スパマーは、なんとか破って鼻をあかしてやりたくなるだろう。
 もちろん、スパムに対するバウンシングバック認証メールをまともに受けて、手作業でキャプチャ認証を通過してスパムを送り込むことはできるが、そんなちまちました方法でなく、もう少し大がかりに破る方法がある。
 たくさんのPCにウィルスかスパイウェアかボットを仕掛けて、やり取りしているメールのアドレス情報を盗み出す。そして、From、To、CCから送信者と受信者の関係を解析する。そこから、白やぎさんと黒やぎさんが互いにメールをやり取りしていることを把握する(それは、第三者が保管していたメールからも知られうる)。そうしたら、白やぎさんのアドレスをかたって黒やぎさんへ、黒やぎさんのアドレスをかたって白やぎさんへ、たくさんのゾンビPCからスパムを送り込むのは、やりたい放題である。完璧に見える防御策は、弱点が見つかってしまえば案外もろいものである。
 ウィルス対策ソフトを使っているからウィルスやスパイウェアやボットは自分には無縁だと思っている人がいるかもしれない。しかし、悪意のあるウェブサイトにアクセスしただけでスパイウェアが仕込まれるおそれはある。それに、たくさんのPCがボットに感染してスパムの発信源になっている。それらのPCがやり取りしているメールのアドレス情報を、特定のサーバにアップロードさせるなどして収集すれば、それらのPCの使用者たちだけでなく、その知人、さらにそのもう一つ先の知人までメールのやり取りの関係を把握できてしまう。
 これに対抗するには、ホワイトリストに送信元サーバのIPアドレスも登録するという方法が考えられる。しかし、送信側サイトのメールサーバが複数あると、送信者は、自分を完全に認証してもらうまでに、送信サーバの台数と同じ回数だけバウンシングバック認証要求に応じなければならない。バウンシングバック認証をやっているサイトは不評を買うことになるだろう。
 バウンシングバック認証なんか使わない方がよい。まして、生半可な考えでインプリメントしてはならない
 もっとも、日本の企業や学校には広まりはしないだろう。良識あるメールシステム管理者や経営者なら、企業ではお客様やこれからお客様になってくれるかもしれない人に対して、学校では学外の偉い先生に対して、バウンシングバック認証のメールを送り付けて手間をかけさせるのは失礼だとわかるだろうから。

(7月1日追記)
 佐藤さんのブログ記事で、別の破り方が提案された。楽天、ヤフーオークション、まぐまぐなどのメジャーなショッピングモールやメールマガジンサービスからメールを受信している人は少なくないと見込んで、それらの送信者アドレスをかたったスパムを送り込むという方法。メールマガジンなどを受信するには、バウンシングバック認証なしで受信するための別アドレスであるエクスパンションアドレスを使う方法があるが、そんな巧妙な方法よりも、ペンディングキューからメールを拾い出してホワイトリスト登録する単純な方法を選ぶユーザーが多いだろう。そういうユーザーが標的になる。グッドアイデアだと思う。

バウンシングバック認証の実装がヘボだと…

 「やぎさんゆうびん問題」は、「自サイトのユーザーがスパムを受けなくてすむためには、他サイトのユーザーに手間をかけさせてもかまわない」という身勝手どうしがぶつかり合うとどうなるかと考えて書いたお話である。白やぎさんと黒やぎさんがともに相手からの手紙を食べてしまったという童謡「やぎさんゆうびん」になぞらえて、双方が同じことをすることによって互いに情報が伝わらなくなるという問題をこのように名付けた(英訳は「the Goats' Mail problem」とでもしようか)。
 実際のところ、白やぎさん、黒やぎさんともにペンディングキューに気を付けていれば、やぎさんゆうびん問題は起こらない。しかし、白やぎさんが、個人間のメールのやり取りを始めたばかりの初心者だったら、ペンディングキューに落ちているバウンシングバック認証メールに気付かないということは十分にありうる。また、黒やぎさんも初心者だったら、白やぎさんからのメールがペンディングキューに落ちているのに気付かないかもしれない。かくして、やぎさんゆうびん問題は起こる。
 これを防ぐために考えられることは、バウンシングバック認証メールはpostmaster、mailer-daemon、または空アドレス(<>)を返送先アドレス(MAIL FROMコマンドで通知されるアドレス、すなわちReturn-Path)として送信するものとして、それらを返送先アドレスとするメールはバウンシングバック認証にかけずに通過させることである。そうすれば、宛先誤りのエラーリターンに気付かないというトラブルも避けることができる。しかし、そのことを知ったスパマーは、それらを返送先アドレスとするスパムを大量に送り込んでくるだろう。
 ところで、「やぎさんゆうびん問題」のお話を書いた時、私は、暗黙のうちに仮定を置いていた。バウンシングバック認証メールはpostmaster名で送信され、それに対するバウンシングバック認証メールはpostmaster宛になり、postmaster宛のメールはバウンシングバック認証にかけずに受けるという仮定である。しかし、postmaster宛のメールもバウンシングバック認証にかけるというヘボな実装をしていると、大変なことが起こる。

「黒やぎさんへ、白やぎです。」
「黒やぎさんちの郵便局の局長ですが、黒やぎさんにメールを送ったのは、本当に白やぎさん、あなたですか?」
「白やぎさんちの郵便局の局長ですが、白やぎさんにメールを送ったのは、本当に黒やぎさんちの郵便局の局長さん、あなたですか?」
「黒やぎさんちの郵便局の局長ですが、私にメールを送ったのは、本当に白やぎさんちの郵便局の局長さん、あなたですか?」
「白やぎさんちの郵便局の局長ですが、私にメールを送ったのは、本当に黒やぎさんちの郵便局の局長さん、あなたですか?」
「黒やぎさんちの郵便局の局長ですが、私にメールを送ったのは、本当に白やぎさんちの郵便局の局長さん、あなたですか?」

メールループが起こって、ディスク容量の余裕が少ない方のサーバがダウンするまで続く。さらに言えば、ダウンのタイミングによっては、立ち直った後、ダウンしなかった方のサーバからメールが吐き出されてメールループが再開する。手動で止めるしかない。
 まさかとは思うが、バウンシングバック認証メールの返送先アドレスをpostmasterなどでなく受信者本人のアドレスにするというヘボな実装だったとしたら、やはり大変なことになる。

「黒やぎさんへ、白やぎです。」
「黒やぎですが、私にメールを送ったのは、本当に白やぎさん、あなたですか?」
「白やぎですが、私にメールを送ったのは、本当に黒やぎさん、あなたですか?」
「黒やぎですが、私にメールを送ったのは、本当に白やぎさん、あなたですか?」

ディスク容量の余裕が少ない方のサーバがダウンするまで繰り返される。さらに言えば、ダウンのタイミングによっては、立ち直った後、ダウンしなかった方のサーバからメールが吐き出されてメールループが再開する。手動で止めるしかない。
 これを避けるためには、白やぎさんが黒やぎさんにメールを送った時に、白やぎさんのサーバで自動的に黒やぎさんのアドレスをホワイトリスト登録すればよいというアイデアが浮かぶが、それは浅知恵である。たとえば、私が自分のサイトで公表している連絡先アドレスが「webmaster」、自分が送信するメールの送信者アドレスが「deo」であるように、送信者が宛てるアドレスとそれに対する返信の送信者アドレスが異なる場合がある。エイリアス展開した後のアドレスを返送先アドレスとしてバウンシングバック認証メールを送るというヘボな実装だと…

「ダンディー黒やぎさんへ、白やぎです。」
(白やぎさんのサーバで「ダンディー黒やぎ」がホワイトリスト登録される。)
「黒やぎですが、私にメールを送ったのは、本当に白やぎさん、あなたですか?」
(白やぎさんのサーバでは「黒やぎ」はホワイトリスト登録されていないので…)
「白やぎですが、私にメールを送ったのは、本当に黒やぎさん、あなたですか?」
「黒やぎですが、私にメールを送ったのは、本当に白やぎさん、あなたですか?」

以下同文。ディスク容量の余裕が少ない方のサーバがダウンするまで続く。さらに言えば、ダウンのタイミングによっては、立ち直った後、ダウンしなかった方のサーバからメールが吐き出されてメールループが再開する。手動で止めるしかない。
 送信メールの返送先アドレスを自動的にエクスパンションアドレスに書き換えて送り出せば、それに対するバウンシングバック認証メールはエクスパンションアドレス宛になり、バウンシングバック認証にかからずに通過できる。この方法ならば、メールループは起こらない。しかし、エクスパンションアドレスの決め方が一定だと、スパマーに推測されて、エクスパンションアドレス宛のスパムが大量に送り込まれるおそれがある。だから、エクスパンションアドレスは時々変更しなければならない。作り込みがやっかいである。宛先サイトのサーバにホワイトリスト登録されるのがこのエクスパンションアドレスだとしたら、それを変更するたびにまたバウンシングバック認証メールが来る。
 身勝手どうしのぶつかり合いによるトラブルを避ける対処法を考えると、そこからまたスパマーに突かれる穴ができるような気がしてならない。あああ、頭いてえ…

バウンシングバック認証はやはりやっかい

 5月14日「バウンシングバック認証という無茶なやり方」で、バウンシングバック認証をやるとメーリングリストのメールやメールマガジンやオンラインショッピングの確認メールの受信に困ると述べた。しかし、それには解決法があることがわかった。エクスパンションアドレスという、バウンシングバック認証をかけないように登録した別アドレスで受信するという方法である。
 なるほど、グッドアイデア!…と思ったが、やはりやっかいな問題が残ることに気付いた。
 自動登録方式のメーリングリスト(たとえばBecky!のメーリングリスト)では、登録要求のメールを送ると、Fromヘッダのアドレスへ、登録の確認を求める自動返信メールが返される。それがバウンシングバック認証に引っかかる。それを避けるためには、Fromヘッダのアドレスをエクスパンションアドレスに変えて登録要求のメールを送る必要がある。ベテランのインターネットユーザーには何でもないことだが、初心者にはやっかいな作業だろう。なぜそんな巧妙なことをしなければならないのかを理解するのも、初心者には大変だろう。それに、バウンシングバック認証のメールは、メーリングリスト管理者にとっては“迷惑メール”である。
 そんな巧妙なことをしなくても、登録確認の返信メールを受けることはできる。バウンシングバック認証済みでないメールはペンディングキューに一定期間保管されるので、自分で取りに行けばよい。どのみち、正当なメールの送信者がバウンシングバック認証手続きをしてくれないかもしれないので、ベンディングキューを確認するのが受信者の日常作業として加わる。
 S25R方式では、正当なメールを受信できることはほぼ保証される(メールシステム管理者の手作業によって、またはtaRgreyなどの自動救済システムによって)。万一、来るはずのメールが来ないことがあっても、メールシステム管理者に言えば調査してもらえる。受信するスパムはゼロにはならないが、今まで一日100通のスパムを受けていた人の場合、素のS25R方式では3通程度、taRgreyでも7通程度(佐藤さんの発表に基づく)に減る。
 偽陰性判定された一日数通のスパムをメーラー上でごみ箱に捨てるか、正当なメールの偽陽性判定(バウンシングバック未認証)を心配して、メーラーの操作とは別の操作でたくさんのスパムの中から正当なメールを探し出す作業を毎日するか、ユーザーにとってはどちらが楽だろう?

月曜日, 5月 21, 2007

やぎさんゆうびん問題

 白やぎさんが黒やぎさんにお手紙を送りました。
 黒やぎさんちをサービスエリアとする郵便局ではバウンシングバック認証をしているので、局長さんが白やぎさんにお手紙を送りました。「黒やぎさんにお手紙を送ったのは、本当に白やぎさん、あなたですか?そうなら、ホワイトリスト登録手続きをしてください」。
 白やぎさんちをサービスエリアとする郵便局でもバウンシングバック認証をしているので、局長さんが黒やぎさんちの郵便局の局長さんにお手紙を送りました。「白やぎさんにお手紙を送ったのは、本当に黒やぎさんちの郵便局の局長さん、あなたですか?そうなら、ホワイトリスト登録手続きをしてください」。
 黒やぎさんちの郵便局の局長さんは、白やぎさんちの郵便局の局長さんからのお手紙を見落としてしまいました。自分が出したバウンシングバック認証のお手紙が宛先不明で差し戻されてくること(バウンシングバック)があまりに多く、その中にバウンシングバック認証のお手紙へのそのまたバウンシングバック認証のお手紙が混じっているとは思いもしなかったのです。
 黒やぎさんちの郵便局の局長さんは、白やぎさんちの郵便局に自分をホワイトリスト登録する手続きをしませんでした。だから、自分が白やぎさんに「黒やぎさんにお手紙を送ったのは、本当に白やぎさん、あなたですか?そうなら、ホワイトリスト登録手続きをしてください」と書いたお手紙は、白やぎさんに配達されませんでした。
 白やぎさんは、黒やぎさんちの郵便局の局長さんからの「ホワイトリスト登録手続きをしてください」というお手紙を受け取らなかったので、黒やぎさんちの郵便局に自分をホワイトリスト登録する手続きをしませんでした。だから、白やぎさんからのお手紙は黒やぎさんに配達されませんでした。

 白やぎさんからお手紙が来るはずなのに来ないので、変だなあと思った黒やぎさんは、白やぎさんにお手紙を送りました。
 白やぎさんちをサービスエリアとする郵便局ではバウンシングバック認証をしているので、局長さんが黒やぎさんにお手紙を送りました。「白やぎさんにお手紙を送ったのは、本当に黒やぎさん、あなたですか?そうなら、ホワイトリスト登録手続きをしてください」。
 黒やぎさんちをサービスエリアとする郵便局でもバウンシングバック認証をしているので、局長さんが白やぎさんちの郵便局の局長さんにお手紙を送りました。「黒やぎさんにお手紙を送ったのは、本当に白やぎさんちの郵便局の局長さん、あなたですか?そうなら、ホワイトリスト登録手続きをしてください」。
 白やぎさんちの郵便局の局長さんは、黒やぎさんちの郵便局の局長さんからのお手紙を見落としてしまいました。自分が出したバウンシングバック認証のお手紙が宛先不明で差し戻されてくること(バウンシングバック)があまりに多く、その中にバウンシングバック認証のお手紙へのそのまたバウンシングバック認証のお手紙が混じっているとは思いもしなかったのです。
 白やぎさんちの郵便局の局長さんは、黒やぎさんちの郵便局に自分をホワイトリスト登録する手続きをしませんでした。だから、自分が黒やぎさんに「白やぎさんにお手紙を送ったのは、本当に黒やぎさん、あなたですか?そうなら、ホワイトリスト登録手続きをしてください」と書いたお手紙は、黒やぎさんに配達されませんでした。
 黒やぎさんは、白やぎさんちの郵便局の局長さんからの「ホワイトリスト登録手続きをしてください」というお手紙を受け取らなかったので、白やぎさんちの郵便局に自分をホワイトリスト登録する手続きをしませんでした。だから、黒やぎさんからのお手紙は白やぎさんに配達されませんでした。

月曜日, 5月 14, 2007

バウンシングバック認証という無茶なやり方

 「ネオジャパンがスパム対策SaaSサービス,1通でもブロック漏れあれば返金」という情報を見つけた。韓国のヌリビジョンの「OptPlus」をサービス化したもので、スパム対策機能の一つとしてバウンシングバック認証というフィルタ機能を備えるという。
 バウンシングバック認証とは、初めてメールを送ってくる送信者に案内メールを返し、送信者がそれに従ってホワイトリスト登録手続きをすると受信者にメールが届けられるという仕組みだそうである。1月13日「厳しすぎる防御」で書いたmail.ruドメインのやり方に似て、無茶である。そりゃあ、ここまで無茶なスパム対策をすれば、「一通でもスパムを受信したら返金する」と豪語するほどの自信は持てるだろう。
 なぜ無茶か。メーリングリストや、メールマガジンや、オンラインショッピングの確認メールのことをちゃんと考えているとは思えないからである。
 メーリングリストの場合は、バウンスはメーリングリスト管理者へ行く。もしバウンシングバック認証を採用するサイトが増えたら、正当なメールを配信させるために、メーリングリスト管理者は大変な手間を強いられるだろう。メーリングリストの管理は相当神経を遣う仕事である。その上にさらに作業負担を強いられ、それが完璧にできなければ、配信を受けたかった受信者が受信できないことになる。
 メールマガジンの場合は、「このメールに返信されてもお答えできません」と断り書きがあることが多い。だから、バウンスを人が監視していないかもしれない。もしかしたら、バウンスを何度か受けたら自動的にアドレスをリストから削除してしまう仕組みのメールマガジンもないとは限らない。
 オンラインショッピングの確認メールの場合も同様である。確認メールの自動送信サーバの管理者が、バウンスを受けて一つ一つ手作業でホワイトリスト登録手続きをしてくれるとは期待できない。
 S25R方式にも、正当なメールを受け損なうリスクはある(2006年8月30日「リトライを短時間でやめるサーバ」、2006年9月1日「グレイリスティングを抜けられないサイト」)。しかし、そのようなまれなケースを除けば、送信者が追加の手作業をしてくれなければ受信できないということはない。正当なメールを救済する作業はもっぱら受信側で行うのがS25R方式のコンセプトだからである。
 S25R方式は、スパムの阻止率100%を達成することはできないが、正当なメールを受け損なうリスクの少なさにおいては、バウンシングバック認証よりもはるかにましである。

(この記事へ直接来られた方は、次の続編もご覧ください。)
やぎさんゆうびん問題
バウンシング・バック認証はやはりやっかい
バウンシング・バック認証の実装がヘボだと…
バウンシング・バック認証の破り方
「バウンシングバック認証」で検索上位
Opt Plusの機能を考える
「OptPlus」でも検索上位
バウンシング・バックはスパム受信を増やすかも
Opt Plusも失礼な受信拒否をしそうだ
バウンシング・バック認証のもう一つの穴
バウンシング・バック文例の問題点
バウンシング・バック認証に応じてもらえないケース
ペンディングキュー管理機能は使いやすいか?
メーリングリストはOpt Plusの鬼門
バウンシング・バック認証はタブーの技術
S25Rにもあるリスクだが…
Opt Plusの返金はない?
エクスパンションアドレスを設定していたら返金なし
Opt Plusの認証画面の脅し文句
Opt Plus売れていないんじゃないの?
(この記事を検索にかかりやすくするために、わざと「・」やスペースを挿入した題名に変えてあります。)

(関連記事)
日本の美徳
April fool

ブログ記事の正規表現も修正

 正規表現の間違いがあったので、このブログの過去の記事に書いた正規表現も修正した。

土曜日, 5月 12, 2007

ホワイトリストファイルを提供

 ホワイトリスト情報のページに正当なホストの許可条件を記述していたが、ある人からのご要望により、ダウンロード可能なプレーンテキスト形式のホワイトリストファイルを分離して提供するようにした。ホワイトリストファイルのURLは
http://www.gabacho-net.jp/anti-spam/white-list.txt
である。

月曜日, 5月 07, 2007

日経コミュニケーションに載るぞー

 日経コミュニケーションからS25R方式についての取材を受けた。6月1日発行号の「企業を熱くする最新テクノロジ」というコラムに載る予定である。どうぞお楽しみに。(^^)V

木曜日, 5月 03, 2007

正規表現の間違い

 「ドットでない文字」の正規表現を今まで「[^\.]」と書いていたが、ある人に指摘されて、間違いだったことがわかった。「[ ]」の内側ではメタ文字をエスケープする必要はなく、「[^.]」が正しい。「[^\.]」は、「\」でも「.」でもない文字という意味になってしまう。ただし、FQDNに「\」が現れることはないので、間違った正規表現のままでも支障はない。
 ということで、論文を書き直した。ついでに、次の修正を加えた。

●ボットについて言及。エンドユーザーコンピュータからのスパムが多いのは、ボットに感染させたエンドユーザーコンピュータをスパマーが操るからだということは、論文を公開した当初はよく知らなかった。

●ホワイトリスト作成前の偽陽性判定率が約13%と推定されることを付記。

●ホワイトリスト登録の自動化技術(Rgrey、Starpit、taRgreyのこと)が提供されていることを付記。

 それと、微妙に言い回しを変えたのは、動的IPアドレスを使ったメールサーバのホワイトリスト登録の問題である。今まで「許可は困難である」と書いていたが、「許可にはリスクが伴う」という書き方にした。S25R方式がOP25BやIP25Bと同じように動的IPアドレスのメールサーバを排除するものだという誤解を避けるためである。