版元ドットコム

ご他聞にもれず、仕事のメールアドレスに着信する大量のスパムに悩む日々であります。だいたい10分に一回くらいの頻度でメールチェックしているんですが、仕事のメールはなくとも、ほぼかならずスパムを一通以上受信します。メールがくれば着信通知音を出したり、該当メールボックスを開いたりと、見落としのないように多少騒々しく動作するように設定してあるので、当然そちらに意識が行きます。つまり10分に一度は仕事への集中を中断されるわけで、ポットでは半年くらい前からかなり深刻な問題になっていました。

「スパムメールを防ぐ」ということは、私の中では次の4つに階層化されています。

1. ●メールの発信源を突き止め、送信をやめさせる
2. ●メールサーバにスパム対策ツールをしかけ、個々のアカウントにスパムメールが配信されないようにする
3. ●メールサーバとメーラーの間にプロキシの形でスパム対策ツールを置く
4. ●メーラーのスパム対策機能を利用する

1から始まって、徐々に「対症療法的」なアプローチになっているのですが、1とそれ以外はそのアプローチのラディカルさにおいて明確な違いがあります。
スパムメールが来る、ということは発信している人間がいるわけで、「ヤツらに天誅を！」を思うのは自然の理、すなわち1の方法がもっとも「望ましい」対処のように思えます。
しかし、ヤツらは発信源をうやむやにするためにあの手この手を使ってきており、かなりしつこく調べたのですが、「確実に発信源をつきとめ、発信をやめさせる方法」を見つけることはできませんでした。
スパム業界ではメールアドレスの名簿を転売すること自体がビジネスになっている、という説もあり、ひとつの発信源をつきとめても結局他の業者からすぐメールが来る、といういたちごっこ状態なのでひとつ潰しても殲滅にはほど遠く、また、つきとめた後のオーソドックスな対処は「発信しているサーバなり回線なりをサービスしている ISPに連絡してやめさせる」なのですが、そもそもISP自体がスパム業者とつるんでいるケースもあるらしい、さらに、最近はワームのバラマキでオープンリレー作っているらしい……。と、とにかく敵が巨大かつ複雑すぎて1の方法は労力に見合わない、という結論に達しました。

となると、次はツールによる防衛です。私は会社のメールサーバを管理しているので、「全員に対して有効」というモデルを必要としていました。当然、2の「サーバで防御」パターンが望ましいわけです。SpamAssassinというツールの存在を知り、また、ほぼ同時期に「ベイズ理論」にもとづいた「ベイジアンフィルタ」というツールが主流となっていることを知りました。従来のスパム対策ツールが、たとえば「表題に『未承諾』と入っていればスパム」といったルールをひたすら追加して対策するのに対し、ベイジアンフィルタはメールに含まれている単語の統計をとり、「このパターンでこの単語を含むものは（多分）スパム」といった判断をしていきます。SpamAssassinはどちらかというと旧世代のツールなのですが、途中からこのベイジアンフィルタを実装しており、またVine Linuxでパッケージされていることもあり、迷わず導入しました。
サーバ全体に対してフィルタするように設定したので、全員のメールがうまくフィルタリングされるようになりました。しかし、どういうわけか肝心の振り分け率がふるわず、評価はいまひとつでした。

さらに、SpamAssassinには致命的な問題がありました。それは「ベイジアンフィルタの管理インターフェースがないに等しい」という点です。ベイジアンフィルタは、その性質上振り分けを間違える可能性が常にあるので、どんなに振り分け精度が上がっても、なんらかの形で人間が目でチェックできる必要があります。また、振り分け間違いに対しては即座にその修正を人間が指示してフィルタを「成長」させることも必要です。

この問題点を解消するため、メールサーバを置いてあるマシン上でスパム教育用のアカウントをつくり、さらにサーバ上でGUIメーラー（Sylpheed）を動かしてそこにVNCでアクセスしてスパムの振り分けをし、スパム確定したものを定期的に学習ツールで学習させる……といった地味な努力をしてみたりもしたのですが、肝心のスパム検挙率がまったく上がらず（最終的に、スパム捕捉率は3割程度でした）、「やはりメーラーごとに防衛するしかないのか……」という結論にたどり着こうとしていました。

そんな折、ふと最近あちこちで話題になっているPOPFileをメールサーバ上で使う、というアイディアが閃きました。このアプリは主にWindows上でカンタンに使える（POPFile自体はPerlスクリプトなんで、Perlとその周辺ライブラリが動けば、どんな環境でも動きます。念のため）、という点が喧伝されており、個人個人が自分のマシンにインストールして使うことを想定しているものなのですが、結局メーラーとサーバの間にあればいいわけだから、サーバに置い「ても」いいのでは、と思ったのです。ポート番号の競合やPerlのバージョンなど、いくつかの問題点はありましたが、Web上の先人たちの知恵に助けられ、うまく動作させることができました。最初に出した階層化で言うと、「かなり2に寄った3」といったところです。

このアプリが優れている点は、「呼ばれるまで何もしない」という設計思想と、必要にして十分なWeb経由による「教育」ができるところです。POPFile自体にはメールのアカウント情報などを入れる必要すらなく、ひとたび動作する状態にしてしまえば、あとはメーラーから呼び出すだけで「どこのメーラーからも、どのメールアカウントに対しても」使えます。このシンプルさは、サーバとぎちぎちに連動するタイプのスパム対策ツールにはない利点です。そして、振り分けミスについては「コントロールセンター」と呼ばれるWebインターフェースにアクセスすれば、すぐに間違いを「指摘」して「再教育」することができます。フィルタが賢くなってくると、そうそうコントロールセンターに行く必要もなくなるのですが、そんな時でもメールのヘッダに書いてあるURLをクリックすれば即座にコントロールセンターに飛ぶことができます。メールを受信した後、思考を「サーバ管理者モード」に切り替えることなくメールの再教育ができるわけです。

「ベイズ」の挙動を見ていると、人間の「判断」を数量化するとこうなるのか、と気づかされることも多く、なにやら機械同士（スパム送信ツール対フィルタ）が代理戦争をしているようでもあり、なかなか興味深いものがあります。

こういったツールに対して、「トラフィックは変わらないのだから根本的な対策ではない」等の批判もありますが、メール総通数の半分以上がスパム、という現状では、まず第一に「必要なメールを埋もれさせない」ことが求められるのであって、トラフィック云々への対策については残念ながら優先順位を下げざるを得ません。それに、こういったツールの利用が常道になれば、あるいはスパム業界自体が弱体化するのではないか、という期待もあります。

POPFile は「手元」で動くことを想定して作られているので、サーバでの利用（共有）ができません。（まあ、もう十分にフィルタは鍛えることができたし、所詮会社のアカウントですから、メールが覗かれることもアリ、を前提に全員で共有してもいいんですが。）サイトのロードマップによると、2004年の1月頃には「とりあえず」、5月には「ちゃんと」複数ユーザーで使用できる（たぶん、コントロールセンターに個別にログインできるとかそんな感じなのではないかと）ようになるそうです。

こういった優秀な設計とインターフェースを持ったアプリケーションを使うと、「世の中にはエラい人はいるもんだなあ」と謙虚な気持ちになります。今の私にできることといったらその優秀さを喧伝するくらいのもの、というわけで、メーラーと動作環境を選ばない POPFile、しつこいスパムにPOPFile、今一番のおすすめです。