より良いベイジアンフィルタリング

2003年1月

(この記事は、2003年のスパム会議で行われた講演を元にしています。ここでは、スパム対策で解説したアルゴリズムの性能を改善するために行った作業と、今後の計画について説明します。)

ここで紹介したい最初の発見は、研究論文の遅延評価のためのアルゴリズムです。好きなように書いて、過去の研究を引用しないでください。すると、憤慨した読者が、引用すべきだった論文への参照をすべて送ってきます。このアルゴリズムは、「スパム対策」[1]がSlashdotに掲載された後に発見しました。

スパムフィルタリングはテキスト分類のサブセットであり、確立された分野ですが、ベイジアン・スパムフィルタリングに関する最初の論文は、1998年の同じ会議で発表されたPantelとLinによるもの[2]と、Microsoft Researchのグループによるもの[3]の2つであるようです。

この研究について聞いたとき、少し驚きました。もし4年前にベイジアンフィルタリングに取り組んでいた人がいたのなら、なぜ誰もがそれを使用していなかったのでしょうか？論文を読んで、その理由がわかりました。PantelとLinのフィルタは2つの中でより効果的でしたが、スパムの92%しか捕捉できず、誤検出率は1.16%でした。

ベイジアン・スパムフィルタを書いてみたところ、スパムの99.5%を捕捉し、誤検出率は0.03%未満でした[4]。同じ実験を試みた2人の結果が大きく異なるのは常に警戒すべきことです。特に、これらの2つの数値セットが反対の結論をもたらす可能性がある場合はそうです。ユーザーによって要件は異なりますが、多くの人にとって、92%のフィルタリング率で1.16%の誤検出率というのは、フィルタリングが許容できる解決策ではないことを意味し、99.5%で0.03%未満の誤検出率というのは、そうであることを意味すると思います。

では、なぜこれほど異なる数値が得られたのでしょうか？PantelとLinの結果を再現しようとはしていませんが、論文を読むと、その違いを説明できると思われる5つのことがわかります。

1つは、単純に、フィルタを非常に少ないデータでトレーニングしたことです。スパムメール160通と非スパムメール466通です。フィルタの性能は、それほど小さなデータセットではまだ上昇しているはずです。したがって、それらの数値は、一般的なベイジアン・スパムフィルタリングはもちろんのこと、アルゴリズムの性能の正確な尺度でさえもない可能性があります。

しかし、最も重要な違いは、メッセージヘッダーを無視したことだと思います。スパムフィルタに取り組んだことがある人なら、これは倒錯した決定だと思うでしょう。しかし、私が最初に書いたフィルタでも、ヘッダーを無視しました。なぜでしょうか？問題を整理しておきたかったからです。当時はメールヘッダーについてあまり知らず、ランダムなものでいっぱいのように思えました。ここにフィルタ作成者への教訓があります。データを無視しないでください。この教訓はあまりにも明白で言及するまでもないと思うかもしれませんが、私はそれを何度も学ばなければなりませんでした。

3番目に、PantelとLinはトークンをステミングしました。つまり、例えば、「mailing」と「mailed」の両方をルートの「mail」に縮小しました。コーパスのサイズが小さいため、そうせざるを得なかったと感じたのかもしれませんが、もしそうなら、これは一種の早まった最適化です。

4番目に、確率の計算方法が異なりました。彼らはすべてのトークンを使用しましたが、私は最も重要な15個のトークンのみを使用します。すべてのトークンを使用すると、誰かがマルチレベルマーケティングスキームで金持ちになった時点までの人生の物語を語るような、長いスパムを見逃す傾向があります。そして、そのようなアルゴリズムは、スパマーがだますのが簡単でしょう。スパム用語を相殺するために、ランダムなテキストの大きな塊を追加するだけです。

最後に、彼らは誤検出に対してバイアスをかけませんでした。スパムフィルタリングアルゴリズムは、フィルタリング率を犠牲にして誤検出率を下げるために調整できる便利なノブを備えているべきだと思います。私は、非スパムコーパス内のトークンの出現回数を2倍に数えることによってこれを行います。

スパムフィルタリングを単純なテキスト分類問題として扱うのは良い考えではないと思います。テキスト分類技術を使用できますが、解決策は、テキストがメールであり、特にスパムであるという事実を反映できるはずであり、また反映すべきです。メールは単なるテキストではありません。構造があります。スパムフィルタリングは単なる分類ではありません。誤検出は誤検知よりもはるかに悪いので、別の種類のエラーとして扱う必要があります。そして、エラーの原因は単なるランダムな変動ではなく、フィルタを打ち負かすために積極的に活動している生身の人間であるスパマーです。

トークン

Slashdotの記事の後で聞いたもう1つのプロジェクトは、Bill YerazunisのCRM114 [5]です。これは、私が今述べた設計原則の反例です。これは単純なテキスト分類器ですが、驚くほど効果的なため、それが何をしているのかさえ知らずに、ほぼ完全にスパムをフィルタリングできます。

CRM114の仕組みを理解すると、最終的には単語ベースのフィルタリングからこのようなアプローチに移行する必要があるように思えました。しかし、まず、単語でどこまでできるか試してみようと思いました。そして、その答えは、驚くほど遠くまでできるということです。

ほとんどの場合、よりスマートなトークン化に取り組んでいます。現在のスパムでは、CRM114に匹敵するフィルタリング率を達成することができました。これらの技術はほとんどBillのものと直交しています。最適なソリューションは両方を組み込むかもしれません。

「スパム対策」では、トークンの非常に単純な定義を使用しています。文字、数字、ダッシュ、アポストロフィ、ドル記号は構成文字であり、それ以外のものはすべてトークン区切り文字です。また、大文字と小文字も無視しました。

現在、トークンのより複雑な定義があります。

1. 大文字と小文字は保持されます。

2. 感嘆符は構成文字です。

3. ピリオドとカンマは、2つの数字の間にある場合は構成要素です。これにより、IPアドレスと価格をそのまま取得できます。

4. $20〜25のような価格範囲は、$20と$25の2つのトークンを生成します。

5. To、From、Subject、Return-Path行、またはURL内にあるトークンには、それに応じてマークが付けられます。例えば、Subject行の「foo」は「Subject*foo」になります。（アスタリスクは、構成要素として許可しない任意の文字にすることができます。）

このような対策は、フィルタの語彙を増やし、より識別力を高めます。例えば、現在のフィルタでは、Subject行の「free」のスパム確率は98%ですが、本文の同じトークンのスパム確率はわずか65%です。

現在の確率の一部を以下に示します[6]。

Subject*FREE 0.9999
free!! 0.9999
To*free 0.9998
Subject*free 0.9782
free! 0.9199
Free 0.9198
Url*free 0.9091
FREE 0.8747
From*free 0.7636
free 0.6546

「スパム対策」フィルタでは、これらのすべてのトークンは同じ確率.7602を持っていました。そのフィルタは約23,000個のトークンを認識しました。現在のものは約187,000個を認識します。

トークンのユニバースが大きいことの欠点は、見逃しの可能性が高くなることです。コーパスをより多くのトークンに分散させると、コーパスを小さくするのと同じ効果があります。例えば、感嘆符を構成要素と見なすと、2つの感嘆符が付いたfreeの確率が99.99%であることがわかっていても、7つの感嘆符が付いたfreeのスパム確率がない可能性があります。

この解決策の1つは、私が縮退と呼ぶものです。トークンの正確な一致が見つからない場合は、それよりも具体的でないバージョンとして扱います。終端の感嘆符、大文字、および5つのマークされたコンテキストの1つで発生することを、トークンをより具体的にすると見なします。例えば、「Subjectfree!」の確率が見つからない場合は、「Subjectfree」、「free!」、および「free」の確率を探し、.5から最も遠いものを選択します。

フィルタがSubject行に「FREE!!!」を表示し、その確率がない場合に考慮される代替案を以下に示します[7]。

Subject*Free!!!
Subject*free!!!
Subject*FREE!
Subject*Free!
Subject*free!
Subject*FREE
Subject*Free
Subject*free
FREE!!!
Free!!!
free!!!
FREE!
Free!
free!
FREE
Free
free

これを行う場合は、すべて大文字とすべて小文字だけでなく、先頭が大文字のバージョンも必ず考慮してください。スパムは命令形の文が多い傾向があり、それらの文では最初の単語が動詞です。したがって、先頭が大文字の動詞は、すべて小文字の場合よりもスパム確率が高くなります。私のフィルタでは、「Act」のスパム確率は98%で、「act」の場合はわずか62%です。

フィルタの語彙を増やすと、「同じ」という古い定義に従って、同じ単語を複数回カウントすることになる可能性があります。論理的には、それらはもはや同じトークンではありません。しかし、これがまだ気になる場合は、複数回カウントしているように見える単語は、まさにあなたが望んでいる単語であるという経験から付け加えておきます。

語彙が大きいことのもう1つの効果は、受信メールを見ると、.5から遠い確率を持つ、より興味深いトークンが見つかることです。メールがスパムかどうかを判断するために、最も興味深い15個のトークンを使用します。しかし、このような固定された数値を使用すると、問題が発生する可能性があります。最大限に興味深いトークンがたくさん見つかった場合、結果は、同じように興味深いトークンの順序を決定するランダムな要因によって決定される可能性があります。これに対処する1つの方法は、一部を他のものよりも興味深いものとして扱うことです。

例えば、トークン「dalco」は私のスパムコーパスに3回出現し、正当なコーパスには一度も出現しません。トークン「Url*optmails」（つまり、URL内の「optmails」）は1223回出現します。それでも、私がトークンの確率を計算するために使用していたように、両方とも同じスパム確率、つまり.99のしきい値を持つことになります。

それは正しいとは感じません。これらの2つのトークンに実質的に異なる確率を与える理論的な議論がありますが（PantelとLinはそうしています）、私はまだそれを試していません。少なくとも、一方のコーパスにのみ出現する15個を超えるトークンが見つかった場合は、多く出現するトークンを優先する必要があるようです。したがって、現在、2つのしきい値があります。スパムコーパスにのみ出現するトークンの場合、10回以上出現する場合は確率は.9999、それ以外の場合は.9998です。正当なコーパスにのみ見られるトークンの場合も、スケールの反対側で同様です。

後でトークンの確率を大幅にスケーリングするかもしれませんが、少なくともこのわずかなスケーリングにより、トークンが正しい方法でソートされることが保証されます。

もう1つの可能性は、15個のトークンだけでなく、特定の興味深さのしきい値を超えるすべてのトークンを考慮することです。Steven Hauserは、彼の統計的スパムフィルタ[8]でこれを行います。しきい値を使用する場合は、非常に高くしてください。そうしないと、スパマーはより多くの無害な単語でメッセージを埋め込むことによってあなたをだます可能性があります。

最後に、HTMLについてどうすればよいでしょうか？私はそれを無視することからすべてを解析することまで、オプションの全範囲を試しました。HTMLを無視するのは悪い考えです。便利なスパムの兆候でいっぱいだからです。しかし、すべてを解析すると、フィルタは単なるHTML認識ツールに退化する可能性があります。最も効果的なアプローチは、中間のコース、つまり一部のトークンに気付き、他のトークンには気付かないようにすることのようです。私はa、img、およびfontタグを見て、残りは無視します。リンクと画像は、URLが含まれているため、必ず確認する必要があります。

HTMLの処理についてもっと賢くなることができるかもしれませんが、これに多くの時間を費やす価値はないと思います。HTMLでいっぱいのスパムはフィルタリングが簡単です。より賢いスパマーはすでにそれを避けています。したがって、将来のパフォーマンスは、HTMLの処理方法に大きく依存するべきではありません。

パフォーマンス

2002年12月10日から2003年1月10日までの間に、約1750通のスパムを受け取りました。これらのうち、4通が通過しました。これは、約99.75%のフィルタリング率です。

見逃した4通のスパムのうち2通は、私の正当なメールで頻繁に使用される単語をたまたま使用していたために通過しました。

3番目は、安全でないCGIスクリプトを利用して第三者にメールを送信するものでした。ヘッダーが無害で、使用する単語に注意しているため、コンテンツだけに基づいてフィルタリングするのは困難です。それでも、通常はそれらを捕捉できます。これは、確率が.88で、しきい値の.9を下回ってかろうじて通過しました。

もちろん、複数のトークンシーケンスを見ると、簡単に捕捉できます。「以下は、フィードバックフォームの結果です」は、すぐにそれとわかります。

4番目のスパムは、私がスパムの未来と呼んでいるものでした。なぜなら、これがスパムが進化すると予想されるものだからです。完全に中立的なテキストの後にURLが続きます。この場合、誰かがついにホームページを完成させたと言って、それを見に行ってほしいと言っていました。（ページはもちろんポルノサイトの広告でした。）

スパマーがヘッダーに注意し、新しいURLを使用する場合、スパムの未来にはフィルタが気付くものは何もありません。もちろん、クローラーを送信してページを確認することで対抗できます。しかし、それは必要ないかもしれません。スパムの未来の応答率は低い必要があります。そうでないと、誰もがそれを行っているでしょう。それが十分に低い場合、スパマーがそれを送信する価値はなく、フィルタリングにあまり苦労する必要はありません。

さて、本当に衝撃的なニュースです。同じ1か月の期間に、_3通_の誤検出がありました。

ある意味で、誤検出が発生するのは安心です。「スパム対策」を書いたとき、私は誤検出がなかったので、それがどのようなものかわかりませんでした。いくつか経験した今、思ったほど悪くないことがわかって安心しました。統計的フィルタによって生成された誤検出は、スパムによく似たメールであることがわかり、これらは見逃しても最も気にならない傾向があります[9]。

誤検出の2つは、私が物を買った会社からのニュースレターでした。私はそれらを受け取るように頼んだことはありませんでした。したがって、それらはスパムであると言えますが、以前はスパムとして削除していなかったので、誤検出としてカウントします。フィルタがそれらを捕捉した理由は、1月に両方の会社が独自のサーバーからメールを送信する代わりに商用メール送信者に切り替え、ヘッダーと本文の両方がはるかにスパムっぽくなったためです。

3番目の誤検出は悪いものでした。それはエジプトの人からのもので、すべて大文字で書かれていました。これは、トークンを大文字と小文字を区別するようにした直接的な結果です。「スパム対策」フィルタはそれを捕捉しなかったでしょう。

全体的な誤検出率がどの程度であるかを言うのは困難です。統計的にノイズが多いからです。フィルタ（少なくとも効果的なフィルタ）に取り組んだことがある人は誰でも、この問題に気づくでしょう。一部のメールでは、スパムかどうかを判断するのが難しく、フィルタが本当に厳しくなったときに最終的に見ることになるのはこれらのメールです。例えば、これまでのところ、フィルタはタイプミスが原因で私のアドレスに送信された2通のメールと、私が誰か他の人であると信じて私に送信された1通のメールを捕捉しました。おそらく、これらは私のスパムでも非スパムメールでもありません。

もう1つの誤検出は、Virtumundoの副社長からのものでした。私は顧客のふりをして彼らに手紙を書き、返信がVirtumundoのメールサーバーを介して返ってきたので、想像できる最も罪を犯しているヘッダーがありました。おそらくこれも本当の誤検出ではなく、一種のハイゼンベルクの不確定性効果です。スパムフィルタリングについて書いていたからこそ、それを受け取ったのです。

これらを除いて、これまでに合計5つの誤検出がありました。約7740通の正当なメールのうち、率は.06%です。他の2つは、私が購入したものがバックオーダーになったという通知と、Eviteからのパーティーのリマインダーでした。

この数値は信頼できないと思います。一部にはサンプルが非常に小さいこと、一部にはこれらのいくつかを捕捉しないようにフィルタを修正できると思うからです。

誤検出は、誤検知とは異なる種類のエラーであるように思えます。フィルタリング率は、パフォーマンスの尺度です。誤検出は、バグのようなものだと考えています。フィルタリング率の向上を最適化として、誤検出の減少をデバッグとしてアプローチします。

したがって、これらの5つの誤検出は私のバグリストです。例えば、エジプトからのメールは、大文字のテキストがフィルタにナイジェリアのスパムのように見えたために釘付けになりました。これは本当に一種のバグです。HTMLと同様に、メールがすべて大文字であることは、実際には概念的に_1つ_の機能であり、各単語に1つではありません。大文字と小文字をより洗練された方法で処理する必要があります。

では、この.06%をどうすればよいでしょうか？あまりないと思います。サンプルサイズが小さいことを念頭に置いて、上限として扱うことができます。しかし、この段階では、ベイジアンフィルタリングの固有の誤検出率よりも、私の実装のバグの尺度です。

今後

次はどうでしょうか？フィルタリングは最適化の問題であり、最適化の鍵はプロファイリングです。コードが遅い場所を推測しようとしないでください。推測は間違っています。コードが遅い場所を_見て_、それを修正してください。フィルタリングでは、これは、見逃したスパムを見て、それらを捕捉するために何ができたかを理解することに変換されます。

例えば、スパマーは現在、フィルタを回避するために積極的に取り組んでおり、彼らが行っていることの1つは、フィルタがそれらを認識できないように、単語を分割してスペルミスすることです。しかし、これらのスパムを捕捉するのにまだ問題がないため、これに取り組むことは私の最優先事項ではありません[10]。

現在、フィルタリングに苦労しているスパムには2種類あります。1つは、女性からのメールを装って、チャットしたり、出会い系サイトで彼女のプロフィールを見たりするように誘うタイプです。これらは、セールストークを使用せずにできる唯一のセールスピッチであるため、通過します。彼らは通常のメールと同じ語彙を使用します。

フィルタリングに苦労しているもう1つの種類のスパムは、例えばブルガリアの企業からのもので、契約プログラミングサービスを提供しています。これらは、私もプログラマーであり、スパムが私の実際のメールと同じ単語でいっぱいであるため、通過します。

おそらく、最初に個人広告タイプに焦点を当てるでしょう。もっとよく見れば、これらと私の実際のメールの間に統計的な違いを見つけることができると思います。書き方は確かに異なりますが、それを捕捉するには複数単語のフィルタリングが必要になる可能性があります。また、URLを繰り返す傾向があることに気付きましたが、正当なメールにURLを含める人はそうしません[11]。

アウトソーシングタイプは捕捉するのが難しいでしょう。サイトにクローラーを送信したとしても、統計的な喫煙銃は見つかりません。おそらく、唯一の答えは、スパムで宣伝されているドメインの中央リストです[12]。しかし、このタイプのメールはそれほど多くないはずです。残りのスパムがブルガリアからの契約プログラミングサービスの未承諾のオファーだけである場合、おそらく私たちは皆、他の何かに取り組むことに移行できるでしょう。

統計的フィルタリングは実際に私たちをその地点に導くのでしょうか？わかりません。今のところ、私個人にとっては、スパムは問題ではありません。しかし、スパマーはまだ統計的フィルタをだますために真剣な努力をしていません。彼らがそうするとき、何が起こるでしょうか？

ネットワークレベルで機能するフィルタについては楽観的ではありません[13]。乗り越える価値のある静的な障害物がある場合、スパマーはそれを乗り越えるのに非常に効率的です。すでにAssurance Systemsという会社があり、Spamassassinを介してメールを実行し、フィルタリングされるかどうかを教えてくれます。

ネットワークレベルのフィルタは完全に役に立たないわけではありません。それらは、すべての「オプトイン」スパム、つまりVirtumundoやEqualamailなどの企業からのスパムを排除するのに十分かもしれません。これらの企業は、実際にはオプトインリストを実行していると主張しています。本文に何が書かれていても、ヘッダーだけに基づいてそれらをフィルタリングできます。しかし、ヘッダーを偽造したり、オープンリレーを使用したりすることをいとわない人は誰でも、おそらくほとんどのポルノスパマーを含め、ネットワークレベルのフィルタを通過するメッセージを取得できるはずです。（ただし、送信したいメッセージは決してありません。それは何かです。）

私が楽観的なフィルタの種類は、個々のユーザーのメールに基づいて確率を計算するフィルタです。これらは、誤検出を回避するだけでなく、フィルタリングにおいてもはるかに効果的です。例えば、メッセージ内のどこかにbase-64エンコードされた受信者のメールアドレスを見つけることは、非常に優れたスパムインジケーターです。

しかし、個々のフィルタの本当の利点は、それらがすべて異なることです。すべての人のフィルタの確率が異なる場合、スパマーの最適化ループ、つまりプログラマーが編集-コンパイル-テストサイクルと呼ぶものは、恐ろしく遅くなります。デスクトップにあるフィルタのコピーを通過するまでスパムを調整するだけでなく、調整ごとにテストメールを送信する必要があります。インタラクティブなトップレベルのない言語でプログラミングするようなものであり、私はそれを誰にも望みません。

注記

[1] Paul Graham。「スパム対策」。2002年8月。http://paulgraham.com/spam.html。

このアルゴリズムの確率は、ベイズの定理の縮退したケースを使用して計算されます。2つの簡略化された仮定があります。特徴（つまり、単語）の確率は独立していること、およびメールがスパムである事前確率については何も知らないことです。

最初の仮定は、テキスト分類で広く使用されています。それを使用するアルゴリズムは、「ナイーブベイズ」と呼ばれます。

2番目の仮定は、受信メールのスパムの割合が日々（実際には、時間ごと）に大きく変動するため、全体的な事前比率が予測因子として価値がないように思われたためです。P(スパム)とP(非スパム)の両方が.5であると仮定すると、それらは相殺され、式から削除できます。

スパムと非スパムの比率が常に非常に高い、または（特に）非常に低い状況でベイズフィルタリングを行っている場合は、事前確率を組み込むことでフィルタのパフォーマンスを向上させることができるでしょう。これを正しく行うには、スパムと正当なメールのボリュームの両方に明確な毎日のパターンがあるため、時刻ごとに比率を追跡する必要があります。

[2] Patrick PantelとDekang Lin。「SpamCop--スパム分類および組織化プログラム」。AAAI-98テキスト分類学習ワークショップの議事録。

[3] Mehran Sahami、Susan Dumais、David Heckerman、Eric Horvitz。「迷惑メールをフィルタリングするためのベイズアプローチ」。AAAI-98テキスト分類学習ワークショップの議事録。

[4] 当時、約4,000通の正当なメールのうち、誤検出はゼロでした。次の正当なメールが誤検出である場合、これは.03%になります。これらの誤検出率は信頼できません。後で説明します。ここで数値を引用するのは、誤検出率が何であれ、1.16%未満であることを強調するためだけです。

[5] Bill Yerazunis。「スパースバイナリ多項式ハッシュメッセージフィルタリングとCRM114識別子」。2003年スパム会議の議事録。

[6] 「スパム対策」では、.99と.01のしきい値を使用しました。コーパスのサイズに比例したしきい値を使用するのは正当化されるようです。現在、各タイプのメールが約10,000通あるため、.9999と.0001を使用します。

[7] ここに修正する必要がある欠陥があります。現在、「Subjectfoo」が単に「foo」に縮退する場合、それは、マークした行以外の本文またはヘッダー行での「foo」の出現に関する統計を取得していることを意味します。私がすべきことは、「foo」全体の統計と特定のバージョンの統計を追跡し、「Subjectfoo」から「foo」ではなく「Anywhere*foo」に縮退することです。大文字と小文字についても同様です。大文字から小文字ではなく、任意の大文字と小文字に縮退する必要があります。

価格についてもこれを行うのはおそらく有利でしょう。例えば、「$129.99」から「$--9.99」、「$--.99」、および「$--」に縮退します。

単語から語幹に縮退することもできますが、これはコーパスが小さい初期段階でのみフィルタリング率を向上させる可能性があります。

[8] Steven Hauser。「統計的スパムフィルタは私にとって有効です」。http://www.sofbot.com。

[9] 誤検出はすべて同じではなく、スパムを阻止するための手法を比較する際にはこれを覚えておく必要があります。フィルタによって引き起こされる誤検出の多くは見逃しても気にならないニアスパムであるのに対し、例えばブラックリストによって引き起こされる誤検出は、間違ったISPを選択した人からのメールにすぎません。どちらの場合も、ニアスパムメールを捕捉しますが、ブラックリストの場合、近さは物理的であり、フィルタの場合、テキスト的です。

[10] スパマーがトークンを曖昧にするのが十分に上手になり、これが問題になる場合、空白、ピリオド、カンマなどを削除し、辞書を使用して結果のシーケンスから単語を選択するだけで対応できます。そしてもちろん、元のテキストに表示されなかったこの方法で単語を見つけること自体がスパムの証拠になります。

単語を選択するのは簡単ではありません。単語の境界を再構築するだけでは済みません。スパマーは文字を追加（「xHot nPorn cSite」）および省略（「P#rn」）します。人間の視覚がそのようなトリックが近づく限界であるため、視覚研究がここで役立つ可能性があります。

[11] 一般に、スパムは通常のメールよりも反復的です。彼らはそのメッセージを家に持ち帰りたいと思っています。現在、上位15個のトークンに重複を許可していません。送信者がたまたまいくつかの悪い単語を複数回使用した場合、誤検出が発生する可能性があるためです。（現在のフィルタでは、「dick」のスパム確率は.9999ですが、名前でもあります。）少なくとも重複に気付くべきであるように思えます。したがって、Brian BurtonがSpamProbeで行っているように、各トークンを最大2つまで許可することを試みるかもしれません。

[12] これは、スパマーがメッセージ内の他のすべてを生成するためにマッドリブ技術を使用するようにプッシュされると、Brightmailのようなアプローチが退化するものです。

[13] ネットワークレベルでフィルタリングに取り組むべきだと主張されることがあります。なぜなら、それがより効率的だからです。人々がこれを言うとき、通常意味することは、現在ネットワークレベルでフィルタリングしており、最初からやり直したくないということです。しかし、ソリューションに合わせて問題を指示することはできません。

歴史的に、希少リソースの議論は、ソフトウェア設計に関する議論で負けている側でした。人々は他の理由で行われた選択（特に不作為）を正当化するためにそれらを使用する傾向があります。

感謝 Sarah Harlin、Trevor Blackwell、Dan Giffinに、この論文の草稿を読んでくれたことに感謝します。また、Danに、このフィルタが実行されるインフラストラクチャのほとんどを提供してくれたことに感謝します。

関連: