スパムと闘う9つの方法
アドレス改変
スパマーは、メールアドレスを探し求めてネットサーフィンを行うボットを利用して、メールアドレスの採取を行う。Webに公開するときに何らかの形でメールアドレスを隠蔽した場合は、ボットがそのアドレスを見逃すことがある。アドレス改変（address munging）とは、アドレスの隠蔽または偽装を行う処理のことを言う。たとえば、”name [AT] domain [DOT] com”のようにアドレスを記述することができる。また、アドレスを表示した画像を作成したり、ASCII文字でアドレスを記述したりする場合もある。たとえばHTMLコードで@と書けば、ブラウザが@に変換してくれる。
コンテンツベースフィルタ
メールアドレスをスパマーに取得されると、闘いの場はメールサーバと受信ボックスへと移る。スパムを減らす簡単な方法として、各メッセージのコンテンツのフィルタリングがある。コンテンツフィルタは、”Viagra”や”free money”といったトリガワードを探しながらメッセージ本文のスキャンを行い、こうしたキーワードが1つまたは複数見つかると、そのメッセージはスパムとしてのマーク付けが行われる。一部の実装では「スパムか、スパムでないか」という識別結果の代わりに、スコア（スコアが高いメッセージほどスパムである可能性が高い）が得られる場合があり、その場合は若干のカスタマイズが可能である。
この手法の大きな難点は、しばしばスパマーがこうした認識を回避するために単語を誤ったスペルや不明瞭な形で記述することだ。さらに、大量のトリガワードを用いると、普通のメールを誤ってスパムと判断してしまうケースが増えるおそれがある。
こういった手法を実質的に進化させた手法では、スパムをより適応的なやり方で認識するために、メッセージのコンテンツに対する統計解析（通常はベイズ識別器）を利用している。ベイジアンフィルタリングを採用したメールクライアントの場合、ユーザがメッセージに対してスパムかそうでないかのマーク付けを行い、時間をかけてフィルタにメッセージの善し悪しを学習させていく。この手法は、Mozilla Thunderbirdのようなソフトウェアを用いるクライアント側と、SpamAssassinのようなパッケージを用いるサーバ側のどちらでも利用できる。
ベイジアン手法はコンテンツベースのフィルタにおける限界の一部を打破しようとするものだが、それでもスパム以外のものをスパムと判断してしまう誤認識が起こり得る。さらに、スパマーはフィルタリングをすり抜けるために、メッセージを画像内にカプセル化したり、テキストを加工したりする場合がある。
Sender Policy Framework
スパマーは多くの場合、偽装されたアドレスからメールを送信する。Sender Policy Framework（SPF）と呼ばれるシステムでは、Domain Name System（DNS）を使って、いつメッセージの拒否または受理を行うべきかを判断する。
この手法を実装するには、特殊な構文を用いてドメインのDNSにTXTフィールドを追加しなければならない。その生成には、SPFのホームページにあるウィザードが利用できる。このフィールドは、どのホストおよびIPアドレスがドメインからメールを送信できるかを指定するものだ。その結果、メールサーバはname@domain.comからメッセージを受け取ると、domain.comに対するDNSクエリを生成してSPFレコードの探索を行う。SPFレコードが見つかった場合、メールサーバは、メッセージ送信者のホストが許可されたリストに存在するかどうかを調べる。存在しない場合、そのメッセージは拒否される。
また、SpamAssassinはSPFを実装できるオープンソースのアプリケーションである。多くの著名なメッセージングサーバはSPFの実装を直接行っているか、パッチやプラグインを適用することで行っている。
SPFは優れた手法だが、欠点が2つある。1つは、SPFレコードが広く利用されていないため、SPFレコードを持たないドメインでは、SMTPサーバがどんなメッセージでも受理してしまうことである。もう1つは、所与のドメインを送信側として用いてメールを送信できるホストがどれかの判断が難しいことである。
リアルタイムブラックリスト
リアルタイムブラックリスト（RBL）と呼ばれる、サーバ側で用いられる別の手法では、スパム配信の実績が知られている信用できないIPアドレスのリストを持つ中央のデータベースを使用する。SMTPサーバはメッセージを受け取ると、こうしたリストの1つまたは複数に対して必ず問い合わせを行い、送信者のIPアドレスがリスト中にないか調べる。見つかった場合、メッセージは拒否される。
利用できるリストは数多く存在し、SorbsとSBLの2つが広く用いられている。
この手法は十分に機能するが、リストのなかには制限の厳しすぎるものや緩すぎるものもある。こうしたリストはスパム以外のメールの拒否にもつながるおそれがある。もし誰かの所有する（動的IPアドレスを持つ）ホームサーバが誤ってリストに追加されてしまうと、その人からメッセージを受け取れなくなってしまうのだ。
Greylisting
サーバ側で用られる別の手法として、スパマーによるSMTPサーバの使われ方をあてにしたものがある。送信先のメールサーバが利用できない場合、送信側サーバはしばらくたってからメッセージの再送を試みる。スパマーが利用するサーバの多くはもっと単純で、メッセージがすべて届いたかどうかよりもどれだけ多くのメッセージを送信できるかを重視するため、スパマーのSMTPサーバは配信途中でエラーが生じると、再送を行わずにそのメッセージの送信をあきらめる。
Greylistingを用いた送信先のメールサーバは、未知のIPアドレスからのメッセージをすべて一時的なエラーによって拒否する。通常のメールサーバであれば後で再送を試みるので、メッセージはそのときに受理されることになる。この手法では、後でそれと認識してそのメッセージを受理できるように受信側サーバが送信者のIPアドレスを保存しておく必要がある。
この手法の主な欠点は、メッセージ受信の遅延時間が大きくなることだ。しかしこの問題は、信用できるサーバをホワイトリスト化しておくなどの手法によって改善することができる。
Greylistingの興味深い改良版として、送信者がRBL手法のリスト（通常はきわめて厳選されたもの）に載っている場合に限って上述の手法を用いるものがある。このやり方だと大多数のメッセージはすぐに届き、それ以外のものは少し遅れて届くことになる。
Vipul’s Razor
Vipul’s Razorは、ユーザどうしの協力を促進することによってスパムに対抗するものだ。Cloudmarkはスパムメッセージに対するハッシュのようなもの（実際には小さなフィンガープリント）を収集する集中型データベースを管理している。ユーザがメッセージを受信すると、このソフトウェアはこれらの集中型サーバに問い合わせてそのメッセージのハッシュを探す。一致するものがあれば、そのメッセージは拒否される。一致するハッシュは存在しないがとにかくそのメッセージが迷惑なものである場合は、そのハッシュを（手動または自動で）こうした集中型サーバに送信することが可能だ。ハッシュバスター注入（hashbuster injection、ハッシュを変えてしまうデータの追加）を回避するため、このシステムでは一時的な署名（ephemeral signature、メッセージのランダムな部分だけのハッシュを計算）を用いている。
この方法には、主に次の3つの欠点がある。
- スパムメールのなかには、システムに問い合わせても該当ハッシュ値がデータベースに存在しないものがある。
- 2つのまったく異なるメッセージが同一のハッシュを持つ可能性がある。そのような場合は非常にまれだが、誤認識を見積もる際には考慮に入れなければならない。
- このシステムはユーザの協力がなければ機能しないが、ユーザによってはスパムでないメッセージまでスパムだと判断する者が存在しうる。最近のバージョンではTruth Evaluation System（ユーザの評価システムのようなもの）によってこの点が改善されているが、誤認識を見積もる際にはやはり、この問題を考慮に入れる必要がある。
Distributed Checksum Clearinghouse
Distributed Checksum Clearinghouse（DCC）は、Razorによく似た形で機能する。この手法もまた、メッセージに対するハッシュのようなもの（チェックサム）を利用し、すべてのチェックサムを持つ集中化されたサーバに問い合わせを行う。ただしこの手法では、ユーザどうしの直接的な協力はなく、システムが全体の処理を自動的に行う。メールサーバ/クライアントは、ユーザとのインタラクションを一切行わずに、中央のサーバにすべてのメッセージのチェックサムを送信する。この中央システムは、すべてのチェックサムについてその発生回数をカウントし、その回数があるしきい値を超えると、そのメッセージにスパムとしてマークを付与する。この方法では、同じ内容のメッセージが多数のユーザに届く場合、そのメッセージはおそらくスパムであろうと判断するわけだ。ハッシュバスター注入を回避するために、ファジー論理という統計的手法が使われている。
この手法では膨大な帯域幅が必要になることはないが、すでに過負荷状態にあるメールサーバの処理速度を低下させる可能性がある。大規模な組織では、1台のマスタサーバを利用するのではなく、ローカルのDCCサーバを別に用意する必要があるだろう。
DomainKeys Identified Mail（DKIM）
やはりサーバ側で用いられるこの手法は、非対称な暗号化を利用し、メッセージの整合性も保証する。メッセージを送信するメールサーバは、メッセージコンテンツのデジタル署名を含むヘッダをメッセージに追加する。またこの送信側サーバは、サーバの公開鍵（SPFに類似）を持つ特殊なDNSレコードを追加しておく必要がある。受信側メールサーバは送信者のドメインを解析し、DNSクエリを用いてその公開鍵を取得する。このとき、受信側サーバは公開鍵と暗号化アルゴリズムを用いることで、メッセージが信用できるドメインから送られたものかどうか、またメッセージが送信途中で変更されていないかどうかを検証することができる。
このシステムの主な欠点は、あまり普及していないことだ。Yahoo!のような大企業はこの手法を実装しているが、小さなサーバではほとんど利用されていない。
ホワイトリスト/ブラックリスト
ホワイトリストおよびブラックリストは厳密にはスパム対策の手法ではないが、ほとんどすべての手法と併用できる追加の管理手段である。ホワイトリストによる手法では、信用できる一連のアドレスまたはドメインを指定することができる。送信者がホワイトリストに載っている場合、すべての管理手段はスキップされ、遅延が生じたり誤認識のリスクを発生させるたりすることなくメッセージの受信が行われる。
ブラックリストとは、ユーザがそこから送られるメールは受信したくないと考えるアドレスを集めたものだ。実装に応じて、こうしたアドレスから送信されたメッセージは、拒否されるか何らかの形でマーク付けがなされる。
まとめ
それでは、最適なスパム対策の手法はどれなのだろうか。その答えは、受け取るスパムの種類や量によって変わってくる。たとえば、それほど多くのメールを受け取らない場合は、まったく誤認識のないシステムがおそらく適しているだろう。また、複雑なインフラストラクチャを管理したくないメール管理者は、学習が必要なVipul’s Razorやコンテンツフィルタの使用を控えるべきだ。
複数の手法を組み合わせたり、好きなようにカスタマイズしたりすることも可能だ。
Lorenzo Simionato氏はベニス大学（University of Venice）でコンピュータサイエンスを専攻、ここ1年間は同大学でLinuxユーザグループのシステム管理者をしている。
NewsForge.com 原文
