スパムに対する計画

2002年8月

(このアーティクルでは、Arcを練習するために構築したスパムプルーフなウェブベースのメールリーダーで使用されているスパムフィルタリング手法について説明しています。より優れたアルゴリズムはBetter Bayesian Filteringで説明されています。)

私はスパムを止めることができると思っており、コンテンツベースのフィルターがそれを実現する方法だと考えています。スパマーの弱点はメッセージそのものです。彼らはあなたが設置した他のあらゆる障壁を回避することができます。少なくとも今のところはそうです。しかし、彼らはメッセージを配信しなければなりません。私たちがそのメッセージを認識するソフトウェアを書くことができれば、彼らがそれを回避する方法はありません。

受信者にとって、スパムは簡単に識別できます。メールを読んでスパムを捨てる人を雇えば、それを行うのは難しくありません。AIを使わずに、このプロセスを自動化するにはどのくらいの作業が必要でしょうか。

私は比較的単純なアルゴリズムで問題を解決できると思います。実際、個々の単語のスパム確率をベイズ的に組み合わせるだけで、現在のスパムを十分にフィルタリングできることがわかりました。以下で説明するように少し調整したベイズフィルターを使うと、1000件のスパムのうち5件しか見逃さず、偽陽性は0件です。

統計的アプローチは、一般的にスパムフィルターを書く人が最初に試すものではありません。ほとんどのハッカーの最初の本能は、スパムの個々の特性を認識するソフトウェアを書こうとすることです。スパムを見ると、「Dear Friend」で始まったり、大文字で書かれ感嘆符が8つ付いたりするメールを送ろうとするこの人たちの図々しさに腹が立ちます。そういった stuff は1行のコードでフィルタリングできるはずです。

そして実際にそうします。最初はうまくいきます。いくつかの簡単なルールでスパムの大部分を取り除くことができます。「click」という単語を探すだけで、私のスパムコーパスの79.7%のメールをキャッチでき、偽陽性は1.2%しかありません。

私はスパムの個別の特徴を探るソフトウェアを約6か月書いた後、統計的アプローチを試してみました。その結果、最後の数パーセントのスパムを認識するのが非常に難しくなり、フィルターを厳しくするほど偽陽性が増えることがわかりました。

偽陽性とは、誤ってスパムと判断された正常なメールのことです。ほとんどのユーザーにとって、正常なメールを見逃すことは、スパムを受け取ることよりも1桁悪いことです。つまり、偽陽性が発生するフィルターは、患者に死亡リスクがある治療薬のようなものです。

ユーザーがスパムを多く受け取るほど、スパムフォルダにある正常なメールに気づかなくなります。そして奇妙なことに、スパムフィルターが本当に良くなるほど、偽陽性が危険になります。なぜなら、フィルターが本当に良い場合、ユーザーはそれらをすべて無視するようになるからです。

私がこの統計的アプローチを長い間避けていた理由がよくわかりません。おそらく、スパマーとの競争ゲームのように、自分でスパムの特徴を見つけ出そうとしていたからだと思います。(非ハッカーの人は気づいていないことが多いですが、ほとんどのハッカーは非常に競争的です。)統計分析を試してみると、それが自分の方法よりもはるかに賢明であることがすぐにわかりました。「virtumundo」や「teens」などの用語がスパムの良い指標であることは当然ですが、「per」や「FL」、「ff0000」もスパムの良い指標であることがわかりました。実際、「ff0000」(赤色のHTML)は、ポルノグラフィックな用語と同じくらい良いスパムの指標になります。

統計的フィルタリングの概要は以下の通りです。スパムとノンスパムのメールの2つのコーパスから始めます。現在、それぞれ約4,000件のメッセージが含まれています。各メッセージのテキスト全体(ヘッダーや埋め込まれたHTMLやJavaScriptを含む)をスキャンします。現在、英数字、ハイフン、アポストロフィ、ドル記号をトークンの一部と見なし、それ以外をトークン区切りとしています(改善の余地があるかもしれません)。数字のみのトークンは無視し、HTMLコメントも無視しています(トークン区切りとしても扱いません)。

各コーパスでそれぞれのトークンが出現する回数をカウントします。この段階では、トークンと出現回数のマッピングを持つ2つの大きなハッシュテーブルができあがります。

次に、各トークンがスパムのメールに含まれる確率を計算するための3番目のハッシュテーブルを作成します。以下のように計算しています[1]:

(let ((g (* 2 (or (gethash word good) 0))) (b (or (gethash word bad) 0))) (unless (< (+ g b) 5) (max .01 (min .99 (float (/ (min 1 (/ b nbad)) (+ (min 1 (/ g ngood)) (min 1 (/ b nbad)))))))))

ここで、wordはその確率を計算するトークン、goodとbadは最初のステップで作成したハッシュテーブル、ngoodとnbadはそれぞれノンスパムとスパムのメッセージ数です。

コードで説明したのは、いくつかの重要な詳細を示すためです。偽陽性を避けるためにわずかにバイアスをかけたいと思っており、試行錯誤の結果、goodの数値を2倍にするのが良い方法だと分かりました。これにより、たまたま正常なメールに現れる単語と、ほとんど現れない単語を区別することができます。合計5回以上出現するトークンのみを考慮します(実際は倍増されるので、ノンスパムメールに3回出現するだけでも十分です)。また、一方のコーパスにしか現れないトークンにどの確率を割り当てるかという問題もあります。こちらも試行錯誤の結果、.01と.99を選びました。調整の余地はあるかもしれませんが、コーパスが大きくなれば自動的に調整されるはずです。

細かい人は気づくかもしれませんが、出現回数をカウントする際はコーパス全体を1つの長いテキストストリームとして扱いますが、確率を計算する際はメッセージ数を使っています。これにより、偽陽性を防ぐためのさらなるバイアスが加わります。

新しいメールが到着すると、トークンにスキャンされ、スパム確率が中立の.5から最も離れている15個のトークンが「興味深い」と判断されます。これらの15個の個別の確率を使って、そのメールがスパムである確率を計算します。probsをこれらの確率のリストとすると、以下のように計算します:

(let ((prod (apply #'* probs))) (/ prod (+ prod (apply #'* (mapcar #'(lambda (x) (- 1 x)) probs)))))

実践の中で生じる疑問の1つは、ハッシュテーブルの単語確率に現れない、つまり見たことのない単語にどの確率を割り当てるかということです。試行錯誤の結果、.4が良い数値だと分かりました。単語を初めて見たら、それはおそらく無害なものです。スパムの単語は余りにも馴染み深いものです。

実際のメールにこのアルゴリズムを適用した例が、末尾の付録にあります。

上記のアルゴリズムが.9を超えるスパムの確率を示した場合、それをスパムとして扱います。しかし実際には、この閾値をどこに置いても大差ありません。確率がその範囲の中間に収まることはほとんどないからです。

統計的アプローチの大きな利点の1つは、多くのスパムを読む必要がないことです。過去6か月間で、文字通り何千ものスパムを読んできましたが、それは本当に心が滅入るものです。ノーバート・ウィーナーは「奴隷と競争すれば奴隷になる」と言いましたが、スパマーと競争することにも同様の劣化感があります。個々のスパム特徴を認識するには、スパマーの心を理解しようとしなければならず、正直言って、スパマーの心の中に入り込む時間を最小限に抑えたいと思います。

しかし、ベイズ的アプローチの真の利点は、何を測定しているかがわかることです。SpamAssassinのようなフィーチャー認識フィルターは、メールにスパム「スコア」を割り当てます。ベイズ的アプローチは実際の確率を割り当てます。「スコア」の問題は、それが何を意味するかがわからないことです。ユーザーにもわかりませんし、フィルターの開発者にもわかりません。メールに「sex」という単語が含まれていたら、何点のスコアを与えるべきでしょうか。確率は間違えられる可能性はありますが、その意味や、証拠をどのように組み合わせて計算するかについては、ほとんど曖昧さがありません。私のコーパスに基づくと、「sex」はメールがスパムである.97の確率を示し、「sexy」は.99の確率を示します。そして、ベイズの定理は、他の証拠がまったくない場合でも、両方の単語を含むメールがスパムである確率は99.97%であると等しく明確に述べています。

確率を測定しているため、ベイズ的アプローチはメール内のすべての証拠、良いものも悪いものも考慮します。スパムでは相対的に稀に出現する単語(「though」や「tonight」、「apparently」など)は、「unsubscribe」や「opt-in」のような悪い単語ほど確率を上げるわけではありませんが、確率を下げることに貢献します。したがって、たまたま「sex」という単語を含む、それ以外は無害なメールがスパムとしてタグ付けされることはありません。

理想的には、確率は各ユーザーごとに個別に計算されるべきです。私は「Lisp」という単語を多く含むメールを受け取りますが(これまでのところ)、それがスパムであることはありません。したがって、そのような単語は私宛てのメールを送るためのパスワードのようなものです。以前のスパムフィルタリングソフトウェアでは、ユーザーがそのような単語のリストを設定できたので、それらの単語を含むメールは自動的にフィルターを通過していました。私のリストには「Lisp」や郵便番号などを入れていました。そうすれば(それ以外はかなりスパム臭い)オンラインの注文の領収書も通過できるようになりました。私はとてもスマートだと思っていましたが、ベイズ的フィルターが同じことをしてくれていることに気づきました。しかも、私が考えつかなかった多くの単語も発見してくれました。

最初に述べたように、私たちのフィルターは1000通につき5通未満のスパムを通過させ、誤検知はゼロだと言ったのは、私のメールに基づいてフィルタリングしたときの数値です。しかし、これらの数値は誤解を招くものではありません。私が提唱しているのは、各ユーザーのメールに基づいてフィルタリングするというアプローチだからです。つまり、各ユーザーには2つの削除ボタン、通常の削除とスパムとしての削除があるべきです。スパムとして削除されたものがスパムコーパスに、それ以外がノンスパムコーパスに入ります。

ユーザーには初期フィルターのシードを提供することはできますが、最終的には各ユーザーが受け取るメールに基づいた独自の単語確率を持つべきです。これにより、(a)フィルターがより効果的になり、(b)ユーザーが自分のスパムの定義を決められ、(c)何よりもスパマーがフィルターを回避するのが難しくなります。フィルターの大部分がユーザー個別のデータベースにある場合、シードフィルターに合わせてスパムをチューニングしても、個々のユーザーの訓練された高度なフィルターを通過できるとは限りません。

コンテンツベースのスパムフィルタリングは、ホワイトリストと組み合わせることが多いです。ホワイトリストとは、フィルタリングなしに受け入れられるメールの送信者リストです。そのようなホワイトリストを構築する簡単な方法は、ユーザーが今まで送信したことのあるすべてのアドレスを保持することです。メールクライアントに「スパムとして削除」ボタンがあれば、通常のごみ箱に削除したメールの送信者アドレスも追加できます。

私はホワイトリストの支持者ですが、それはフィルタリングの効率化のためであって、フィルタリングの改善のためではありません。以前は、ホワイトリストがフィルタリングを容易にすると考えていました。なぜなら、これまで連絡したことのない人からのメールだけをフィルタリングすればよく、初めてメールを送ってくる人は、あなたに何を言えるかが決まっているからです。すでに知っている人からメールが来ても「sex」について書いてくるかもしれませんが、初めてメールを送ってくる人がそうするとは考えにくいからです。しかし問題は、人が複数のメールアドレスを持っていることです。新しい送信者アドレスがあっても、必ずしも初めてメールを送ってきたわけではありません。ハッカーの友人が突然新しいアドレスからメールを送ってくることもよくあります。そのため、未知のアドレスからのメールを特に厳しくフィルタリングするのはリスクが高すぎます。

しかし、私のフィルターは、ある種のホワイトリスト(およびブラックリスト)を内包しているといえます。なぜなら、ヘッダーを含むメール全体に基づいているからです。そのため、信頼できる送信者やメールが私に到達する経路についても「知っている」のです。同様に、スパムについても、サーバー名、メーラーのバージョン、プロトコルなどを「知っている」のです。

現在のスパムフィルタリングのレートを維持できると思えば、この問題は解決したと考えるでしょう。しかし、現在のスパムの大部分をフィルタリングできるようになっただけでは意味がありません。なぜなら、スパムは進化し続けるからです。実際、これまでのアンチスパム手法は、単語ベースのシンプルなスパムフィルターを回避する新しい耐性のあるバグを生み出しただけでした。

ベイズ的フィルターについては、より期待が持てます。なぜなら、スパムとともに進化するからです。スパマーが単語ベースのシンプルなスパムフィルターを回避するために「c0ck」の代わりに「cock」を使い始めても、ベイズ的フィルターは自動的に気づきます。実際、「c0ck」の方が「cock」よりもはるかに悪質な証拠であり、ベイズ的フィルターはそれがどれほど悪質かを正確に知っているのです。

スパムフィルタリングの計画を提案する人は、スパマーが正確に何をしているかを知っていれば、どれだけうまくそれを回避できるかという質問に答えられなければなりません。例えば、チェックサムベースのスパムフィルタリングが深刻な障害となった場合、スパマーはメッセージ本文を生成するためにマッドリブ技術に切り替えるだけかもしれません。

ベイジアンフィルタを打ち破るには、スパマーがメールを一意にするだけでは十分ではありません。彼らは自分の通常のメールと区別がつかないようにしなければなりません。そうすれば、彼らの行動は大幅に制限されるでしょう。スパムはほとんどが販売促進なので、あなたの通常のメールがすべて販売促進でない限り、スパムは必ず性格が異なってきます。また、スパマーは当然、ヘッダーの外観も無害に見えるように変更し続けなければなりません。そうしないと、メッセージ本文を変更しても、ベイジアンフィルタにはいつも悪いように見えるでしょう。スパマーが使っているインフラストラクチャについてよく知らないので、ヘッダーを無害に見せるのがどれほど難しいかはわかりませんが、私の推測では、メッセージを無害に見せるよりもさらに難しいと思います。

ヘッダーの問題を解決できたとしても、未来のスパムはおそらく次のようなものになるでしょう:

こんにちは。次のサイトをチェックしてみてください: http://www.27meg.com/foo

なぜなら、これ以上の販売促進は、コンテンツベースのフィルタリングでは許されないからです。(実際、これさえも、フィルタを通すのは難しいでしょう。なぜなら、メール内の他のすべてが中立的な場合、スパムの確率はURLに依存することになり、それを中立的に見せるのに努力が必要になるからです。)

スパマーには、いわゆるオプトインリストを運営する企業から、ポルノサイトの宣伝のためにメールサーバーを乗っ取る者まで、さまざまな種類がいます。フィルタリングを使って、上記のようなメールしか送れなくなれば、「合法的」な側のスパマーはほとんど廃業に追い込まれるでしょう。なぜなら、彼らは各州の法律によって、自分のスパムがスパムではないことや、「購読」をキャンセルする方法を記載しなければならず、そのような文言は簡単に認識できるからです。

(以前は、より厳しい法律がスパムを減らすと信じるのは単純すぎると思っていました。今では、より厳しい法律は、スパマーが送るスパムの量を減らすことはできないかもしれませんが、受信者が実際に見るスパムの量を減らすのに役立つと考えています。)

スペクトラムのあらゆる場所で、スパマーが行える販売促進を制限すれば、必然的に彼らを廃業に追い込むことになります。この「ビジネス」という言葉を忘れないでください。スパマーはビジネスマンです。スパムを送るのは効果があるからです。反応率は最悪ですが(最高でも100万通に15通)、カタログメールの3000通に1通に比べると、彼らにとってのコストはほとんどゼロです。しかし、受信者にとっては膨大なコストがかかります。100万通のスパムを1秒で削除するのに5人週間かかります。しかし、スパマーはその代価を払う必要はありません。

スパムを送ることにはスパマーにもコストがかかります[2]。したがって、フィルタリングや、フィルタリングを使ってスパマーに販売促進を希薄化させることで、反応率をできるだけ低くすれば、スパムを送るビジネスに価値を見出す企業が減るでしょう。

スパマーが使う販売促進の手法は、反応率を上げるためです。これは、スパマーの心理を理解するよりも、スパムに反応する人の心理を理解するほうがさらに不快かもしれません。この人は、あまりにも単純な信用か、自分の性的関心を否定しているかのどちらかです。私たちから見れば醜悪や愚かに見えるスパムでも、彼らにとっては魅力的なのです。スパマーがこのようなことを言うのは、それが彼らにとって魅力的に聞こえるからです。一方、「次のサイトをチェックしてみてください」では、現在のスパマーが使っているような誘因にはほど遠いでしょう。結果として、刺激的な販売促進を含めることができなければ、スパムはマーケティングツールとしての有効性が低下し、企業がそれを使いたがらなくなるでしょう。

これが最終的な大きな勝利です。私がスパムフィルタリングソフトウェアを書き始めたのは、もうスパムを見たくなかったからです。しかし、スパムをうまくフィルタリングできるようになれば、それが機能しなくなり、スパマーは実際にスパムを送るのをやめるでしょう。

スパム対策のアプローチの中で、ベイジアンフィルタリングが最も効果的だと考えています。しかし、スパマーの行動を制限するあらゆる対策を講じれば、フィルタリングがより容易になると思います。コンテンツベースのフィルタリングの世界でも、同時に多様なソフトウェアが使われることが良いと考えています。フィルタが多様化すれば、スパマーがそれらを回避するのがより難しくなります。

フィルタリングの例

ここは、この記事を書いている最中に届いたスパムの例です。このスパムで最も興味深い15の単語は次のとおりです:

qvp0045 indira mx-05 intimail $7500 freeyankeedom cdo bluefoxmedia jpg unsecured platinum 3d0 qves 7c5 7c266675

これらの単語は、ヘッダーとメッセージ本文から混ざったものです。これはスパムの典型的な特徴です。また、これらの単語すべてが、私のデータベースでスパム確率0.99と判定されているのも、スパムの特徴です。実際、0.99の確率を持つ単語がこれ以上ありますが、ここでは最初の15個を示しました。

残念ながら、これはベイズの定理の使用例としては退屈な例です。確率の変化を見るには、こちらの、かなり典型的ではないスパムを見る必要があります。

このスパムで最も興味深い15の単語とその確率は次のとおりです:

madam 0.99 promotion 0.99 republic 0.99 shortest 0.047225013 mandatory 0.047225013 standardization 0.07347802 sorry 0.08221981 supported 0.09019077
people's 0.09019077 enter 0.9075001 quality 0.8921298 organization 0.12454646 investment 0.8568143 very 0.14758544 valuable 0.82347786

この時の証拠は良い面と悪い面が混在しています。「最短」のような単語は、「マダム」や「昇進」のような単語ほど有罪の証拠にはなりません。しかし、有罪の証拠の方が強いです。これらの数値をベイズの定理に従って組み合わせると、結果の確率は.9027になります。

「マダム」は明らかにスパムの冒頭の「拝啓」から来ています。そうした単語は非常に一般的ではありませんが、私の正規のメールには「マダム」という単語は一切出てきません。重要なのは比率なのです。

「共和国」は高得点になるのは、しばしばナイジェリアのスキャムメールに現れるためで、韓国や南アフリカを指すスパムにも1、2回出現します。これは偶然にそうなっているだけかもしれません。しかし、スパムの確率を調べていると、そうした偶然が多数あり、間違った方向ではなく正しい方向に働くことがわかります。この場合、「共和国」という単語がナイジェリアのスキャムメールとこのスパムに出現するのは完全な偶然ではありません。発展途上国に関わる疑わしい事業提案には、それが共和国であることを明示的に(実際には共和国ではないため)示す名称が付けられることが多いのです。[3]

一方、「enter」は完全な見落としです。主に購読解除の説明に現れますが、ここでは全く無害な使い方をされています。幸いにも統計的アプローチは比較的頑健で、かなりの見落としがあっても結果が大きく歪められることはありません。

比較のために、ここにフィルターを抜けてしまったまれなスパムの例があります。なぜかというと、偶然にも私の実際のメールに出現する単語ばかりで構成されているからです:


perl 0.01 python 0.01 tcl 0.01 scripting 0.01 morris 0.01 graham 0.01491078 guarantee 0.9762507 cgi 0.9734398 paul 0.027040077 quite 0.030676773 pop3
0.042199217 various 0.06080265 prices 0.9359873 managed 0.06451222 difficult 0.071706355

ここには2つの良いニュースがあります。まず、このメールは私がプログラミング言語に詳しく、モリスという良い友人がいるような人以外には通過しないでしょう。一般のユーザーにとっては、ここに挙げられている上位5つの単語はすべて中立的で、スパムの確率に寄与しないはずです。

次に、単語ペアでフィルタリングすれば(下記参照)、このメールを捕捉できるかもしれません:「cost effective」、「setup fee」、「money back」 -- かなり有罪っぽいですね。そして当然、私(あるいは私が所属するネットワーク)にさらにスパムが送られてくれば、「Hostex」自体がスパム用語として認識されるでしょう。

最後に、ここに無害なメールの例があります。その15の最も興味深い単語は以下の通りです:


continuation 0.01 describe 0.01 continuations 0.01 example 0.033600237 programming 0.05214485 i'm 0.055427782 examples 0.07972858 color 0.9189189
localhost 0.09883721 hi 0.116539136 california 0.84421706 same 0.15981844 spot 0.1654587 us-ascii 0.16804294 what 0.19212411

ここにある単語の大半は、このメールが無害であることを示しています。「color」(スパマーは色付きフォントが好き)と「California」(推奨文や申請フォームのメニューに現れる)という悪臭のする単語が2つありますが、「continuation」や「example」のような明らかに無害な単語に押し負けています。

「describe」がこれほど完全に無害とされるのは興味深いです。私の4000件のスパムデータには一度も出現していません。このデータには、そうした驚くべき発見がたくさんあります。スパムテキストを分析すると、スパマーが使う言語の範囲がいかに狭いかがわかります。この事実と、個々のユーザーのメールに特徴的な語彙の両方が、ベイズ型フィルタリングを有効にしているのです。

付録: その他のアイデア

まだ試していないアイデアの1つは、単語単独ではなく単語ペアや単語トリプルでフィルタリングすることです。これにより、確率の推定がより鋭敏になるはずです。例えば、現在のデータベースでは「offers」という単語の確率は.96です。単語ペアでフィルタリングすれば、「special offers」や「valuable offers」の確率は.99になり、一方「approach offers」(「this approach offers」のような使い方)の確率は.1以下になるでしょう。

私がまだこれを行っていないのは、単語単独でのフィルタリングでも十分うまくいっているからです。しかし、スパムが検出しにくくなった場合は、フィルタを強化する余地があるということです。(興味深いことに、単語ペアでのフィルタリングは、逆向きに動作するマルコフ連鎖テキスト生成器と同じ効果があります。)

特定のスパム特徴(to:フィールドに受信者のアドレスが見えないなど)も、スパムを認識する上で価値があります。これらを「仮想単語」として扱えば、このアルゴリズムに組み込めます。将来のバージョンでは、最も顕著なスパム指標のいくつかについてはこうした対応を行う予定です。特徴認識型のスパムフィルタは細部では正しいことが多いのですが、証拠を総合的に組み合わせる方法論に欠けています。

スパムではない特徴を認識することの方が、スパムの特徴を認識することよりも重要かもしれません。偽陽性は大変な問題なので、特別な対策が必要です。将来のバージョンでは、偽陽性を特に回避するための2段階目のテストを追加する予定です。このテストをクリアすれば、スパム確率が閾値を超えていても受け入れられるようにします。

この2段階目のフィルタリングはベイズ的ではないと思います。必然的に臨機応変で推測に頼らざるを得ません。なぜなら、偽陽性の数は十分大きくならず、パターンを見出せないからです。(主要システムと同じ技術に頼らないバックアップシステムの方が良いでしょう。)

今後試してみたいもう1つのアイデアは、メールの特定の部分に重点を置いてフィルタリングすることです。例えば、現在のスパムの約95%にはアクセスさせたいサイトのURLが含まれています。(残りの5%は電話番号への連絡、メールへの返信、あるいは特定の株式の購入を求めています。)そのURLだけで、そのメールがスパムかどうかをほぼ判断できるのです。

ドメイン名は(ドイツ語以外の)電子メールの本文とは異なり、しばしば複数の単語が組み合わされています。一般的に計算コストがかかりますが、それらを分解することが価値があるかもしれません。フィルターが「xxxporn」というトークンを初めて見た場合、個別のスパム確率は0.4ですが、「xxx」と「porn」はそれぞれ0.9889と0.99の確率で、合わせると0.9998の確率になります。

スパマーが徐々にメッセージの本文で不審な単語の使用を止めざるを得なくなるにつれ、ドメイン名の分解がより重要になると予想されます。(IPアドレスを含むURLは、ごく一部のシステム管理者を除いて、極めて不審な兆候です。)

スパマーが宣伝しているURLのリストを協力して維持することが良いアイデアかもしれません。Raph Levienが研究した種類の信頼度メトリックを使えば、悪意のある or 不適切な投稿を防ぐことができ、フィルタリングソフトウェアに大きな効果をもたらすでしょう。また、ボイコットの基盤にもなるでしょう。

疑わしいURLをテストする別の方法は、ユーザーがそのメールを見る前にクローラーを送り、サイトを見てみることです。Bayesianフィルターを使ってサイトを評価し、その結果をメールの確率計算に含めることができます。リダイレクトに導くURLは特に疑わしいでしょう。

本当に良いアイデアだと思うのは、巨大なスパムコーパスを蓄積することです。大規模で清浄なコーパスがあれば、Bayesianフィルタリングを効果的に機能させられます。Bayesianフィルターはそのコーパスを入力として使えるでしょう。しかし、そのようなコーパスは他の種類のフィルターにも役立つはずです。

そのようなコーパスを作ることには技術的な問題がありますが、悪意のある or 不適切な投稿を防ぐための信頼度メトリックが必要でしょう。また、個人情報(宛先やCCだけでなく、購読解除URLの引数など)を削除する方法も必要です。このプロジェクトに取り組む人がいれば、世界にとって良いことになるでしょう。

付録: スパムの定義

スパムとは何かについては大まかなコンセンサスがありますが、明示的な定義をすることが有用でしょう。中央のスパムコーパスを確立したり、スパムフィルタリングの効果を意味のある形で比較したりするためには、定義が必要です。

まず、スパムは「unsolicited commercial email」ではありません。近所の人が私が良質の中古ラリー3速自転車を探しているのを聞いて、それを売ると連絡してきたとしたら、それは商業メールでありかつ未承諾ですが、喜んで受け取るでしょう。スパムの決定的な特徴は、未承諾であることではなく、自動化されていることです。

また、スパムが通常商業的であるのは偶然の事柄でもあります。ある人が大量メールで政治的な主張を広めようとしても、それはポルノサイトを宣伝するメールと同じくらいスパムなのです。

私の提案では、スパムを「unsolicited automated email」と定義します。この定義には、多くの法的定義では除外されるメールも含まれます。法的定義は、ロビー活動の影響を受けて、「既存の関係」のある企業からのメールを除外する傾向にあります。しかし、オンラインストアで何かを注文しただけでは、その企業からの継続的なスパムを受け取ることを承諾したことにはなりません。それはスパムです。

スパムを送る企業は、「購読解除」する方法や「アカウント設定」でメールを止める方法を提供することがありますが、それだけではメールがスパムではなくなるわけではありません。オプトアウトではなく、オプトインが必要です。受信者が明確にラベル付けされた(デフォルトがノーの)チェックボックスにチェックを入れない限り、それはスパムです。

ある種の業務関係では、特定のメールを暗黙的に承諾しているといえます。オンラインで注文した場合、注文確認メールや発送通知を受け取ることを暗黙的に承諾しているといえるでしょう。ドメイン名の期限切れを警告するVerisignからのメールも(実際の登録事業者であれば)気にならないかもしれません。しかし、Verisignが「無料Eコマースサイト構築ガイド」を送ってきたら、それはスパムです。

注釈:

[1] この記事の例はCommon Lispに翻訳されていますが、信じられないことに、より広く理解されるためです。ここで説明されているアプリケーションは、まだリリースされていない新しいLisp方言 Arc をテストするために書いたものです。

[2] 現在の最低コストは100万通のスパムを送るのに約200ドルです。これは非常に安価で、1通あたり1/50セントにすぎません。しかし、スパムの95%をフィルタリングすれば、ターゲットに到達するコストが20倍になります。そのようなマージンを持つ企業は少ないでしょう。

[3] 国名の前に修飾語が多いほど、その国の統治者は腐敗していると言えるでしょう。「社会主義人民民主共和国のX」のような国は、おそらく世界で最も住みたくない場所でしょう。

謝辞 Sarah Harlinに原稿の草稿を読んでもらい、Daniel Giffin(同じくArc実装の制作にも携わっている)にフィルタリングやメールインフラについての多くの良いアイデアを提供してもらい、Robert Morris、Trevor Blackwell、Erann Gatにスパムについての多くの議論をしてもらい、Raph Levienに信頼度メトリックについてアドバイスをもらい、Chip ColdwellとSam Steingoldに統計についてアドバイスをもらいました。

このエッセイと他14本は [

Hackers & Painters

](http://www.amazon.com/gp/product/0596006624) に収録されています。

詳細情報: