より良いベイズフィルタリング
Original2003年1月
(この記事は2003年スパム会議での講演として発表されました。 これは、A Plan for Spamで説明されているアルゴリズムの性能を向上させるために私が行った作業と、今後の計画について説明しています。)
ここで最初に紹介したい発見は、研究論文の遅延評価のためのアルゴリズムです。 ただ、あなたが望むことを書き、以前の研究を引用しないでください。そうすれば、憤慨した読者があなたが引用すべきすべての論文の参考文献を送ってくれます。私はこのアルゴリズムを、``A Plan for Spam'' [1]がSlashdotに掲載された後に発見しました。
スパムフィルタリングはテキスト分類のサブセットであり、これは確立された分野ですが、ベイズ的スパムフィルタリングに関する最初の論文は、1998年の同じ会議で発表された2つの論文のようです。1つはPantelとLinによるもので[2]、もう1つはMicrosoft Researchのグループによるものです[3]。
この研究について聞いたとき、私は少し驚きました。もし人々が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の記事の後に聞いた別のプロジェクトは、Bill YerazunisのCRM114 [5]です。これは、私が先ほど述べた設計原則の反例です。これは単純なテキスト分類器ですが、驚くほど効果的で、スパムをほぼ完璧にフィルタリングします。自分が何をしているのかを知らずに。
CRM114の動作を理解したとき、私は最終的に単語に基づくフィルタリングからこのようなアプローチに移行しなければならないのは避けられないことだと思いました。しかし、まずは、単語だけでどこまで行けるか見てみようと思いました。そして、その答えは驚くほど遠くまで行けるということです。
主に私はよりスマートなトークン化に取り組んでいます。現在のスパムに対して、私はCRM114に近いフィルタリング率を達成することができました。これらの技術は主にBillのものとは直交しています。最適な解決策は両方を組み込むかもしれません。
``A Plan for Spam''では、トークンの非常に単純な定義を使用しています。文字、数字、ダッシュ、アポストロフィ、ドル記号は構成文字であり、それ以外のすべてはトークンセパレーターです。私は大文字小文字も無視しました。
今、私はトークンのより複雑な定義を持っています：
大文字小文字は保持されます。
感嘆符は構成文字です。
ピリオドとカンマは、2つの数字の間にある場合は構成要素です。これにより、IPアドレスや価格をそのまま取得できます。
$20-25のような価格範囲は、2つのトークン、$20と$25を生成します。
To、From、Subject、Return-Path行内、またはURL内に出現するトークンは、それに応じてマークされます。例えば、Subject行のfoo''はSubject*foo''になります。（アスタリスクは、構成要素として許可しない任意の文字にすることができます。）
このような措置はフィルタの語彙を増やし、より選別的にします。例えば、現在のフィルタでは、Subject行の``free''は98%のスパム確率を持っていますが、本文中の同じトークンは65%のスパム確率しか持っていません。
現在の確率のいくつかは以下の通りです[6]：
SubjectFREE 0.9999
free!! 0.9999
Tofree 0.9998
Subjectfree 0.9782
free! 0.9199
Free 0.9198
Urlfree 0.9091
FREE 0.8747
From*free 0.7636
free 0.6546
Plan for Spamフィルタでは、これらのトークンはすべて同じ確率、0.7602を持っていました。このフィルタは約23,000のトークンを認識しました。現在のフィルタは約187,000のトークンを認識しています。
より大きなトークンの宇宙を持つことの欠点は、見逃す可能性が高くなることです。コーパスをより多くのトークンに広げることは、それを小さくするのと同じ効果があります。例えば、感嘆符を構成要素と見なすと、7つの感嘆符を持つfreeのスパム確率が得られない可能性がありますが、2つの感嘆符を持つfreeのスパム確率が99.99%であることは知っています。
これに対する1つの解決策は、私が「退化」と呼ぶものです。トークンの正確な一致が見つからない場合は、より一般的なバージョンとして扱います。私は、端末の感嘆符、大文字、5つのマークされたコンテキストのいずれかに出現することがトークンをより具体的にすると考えています。例えば、Subject*free!''の確率が見つからない場合、Subject*free''、free!''、free''の確率を探し、最も0.5から遠いものを取ります。
フィルタがSubject行で``FREE!!!''を見た場合に考慮される代替案は以下の通りです[7]：
SubjectFree!!!
Subjectfree!!!
SubjectFREE!
SubjectFree!
Subjectfree!
SubjectFREE
SubjectFree
Subjectfree
FREE!!!
Free!!!
free!!!
FREE!
Free!
free!
FREE
Free
free
これを行う場合は、すべての大文字とすべての小文字だけでなく、初期大文字のバージョンも考慮してください。スパムは命令形の文が多く、そこで最初の単語は動詞です。したがって、初期大文字の動詞はすべて小文字のときよりも高いスパム確率を持っています。私のフィルタでは、Act''のスパム確率は98%で、act''は62%です。
フィルタの語彙を増やすと、古い定義の「同じ」に従って同じ単語を複数回カウントすることになります。論理的には、それらはもはや同じトークンではありません。しかし、これがまだ気になる場合は、経験から言えることは、あなたが複数回カウントしているように見える単語は、まさにあなたが欲しい単語である傾向があるということです。
より大きな語彙のもう1つの効果は、受信メールを見たときに、確率が0.5から遠い興味深いトークンがより多く見つかることです。私は、メールがスパムかどうかを決定するために最も興味深い15個を使用します。しかし、このように固定された数を使用すると問題が発生することがあります。最大限に興味深いトークンがたくさん見つかると、結果は同じくらい興味深いトークンの順序を決定するランダムな要因によって決まる可能性があります。この問題に対処する1つの方法は、いくつかを他のものよりも興味深いと見なすことです。
例えば、トークンdalco''は私のスパムコーパスに3回出現し、私の正当なコーパスには一度も出現しません。トークンUrl*optmails''（URL内の``optmails''）は1223回出現します。それでも、トークンの確率を計算していたとき、両方は同じスパム確率、0.99の閾値を持っていました。
これは正しく感じません。これら2つのトークンに実質的に異なる確率を与える理論的な議論があります（PantelとLinはそうしています）が、私はまだそれを試していません。少なくとも、片方のコーパスにしか出現しないトークンが15個以上見つかった場合は、たくさん出現するものに優先順位を与えるべきだと思います。したがって、現在は2つの閾値があります。スパムコーパスにのみ出現するトークンの場合、10回以上出現する場合は確率が0.9999で、それ以外は0.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スクリプトを利用するものでした。内容だけに基づいてフィルタリングするのは難しいです。なぜなら、ヘッダーは無害であり、彼らが使用する単語には注意を払っているからです。それでも、私は通常それらを捕まえることができます。この1件は、確率0.88でぎりぎり通過しました。閾値0.9の直下です。
もちろん、複数のトークンシーケンスを見れば簡単に捕まえられます。``あなたのフィードバックフォームの結果は以下の通りです''は即座にスパムだとわかります。
4件目のスパムは、私が未来のスパムと呼ぶもので、これはスパムが進化すると思われるものです：完全に中立的なテキストの後にURLが続きます。この場合、誰かが自分のホームページをついに完成させたと言って、見に行ってくれないかと頼んでいました。（そのページはもちろん、ポルノサイトの広告でした。）
スパマーがヘッダーに注意を払い、新しいURLを使用する場合、未来のスパムにはフィルタが気づくものはありません。もちろん、ページを見に行くクローラーを送ることで対抗できます。しかし、それは必要ないかもしれません。未来のスパムの応答率は低いはずです。さもなければ、誰もがそれを行っているでしょう。もしそれが十分に低ければ、スパマーがそれを送るのは無駄であり、私たちはそれをフィルタリングするためにあまり努力する必要がなくなります。
さて、本当に衝撃的なニュースです：その同じ1か月の間に、私は3件の誤検知を受け取りました。
ある意味、いくつかの誤検知を受け取ることは安心です。``A Plan for Spam''を書いたとき、私は誤検知を一度も受け取ったことがなく、それがどのようなものか知りませんでした。今、いくつかの誤検知を経験したことで、彼らが私が恐れていたほど悪くないことがわかり、安心しています。統計的フィルタによって生じる誤検知は、スパムに非常によく似たメールであり、これらは見逃しても最も気にしないものです[9]。
誤検知のうち2件は、私が物を購入した会社からのニュースレターでした。私はそれを受け取るように頼んだことはありませんので、議論の余地はありますが、スパムと見なされるべきですが、私はそれを誤検知としてカウントします。なぜなら、以前はスパムとして削除していなかったからです。フィルタがそれらを捕まえた理由は、両方の会社が1月に自社のサーバーからメールを送信するのではなく、商業メール送信者に切り替えたためで、ヘッダーと本文がはるかにスパムっぽくなったからです。
ただし、3件目の誤検知は悪いものでした。それはエジプトの誰かからのもので、すべて大文字で書かれていました。これはトークンを大文字小文字を区別して扱うことの直接的な結果でした。Plan for Spamフィルタでは捕まえられなかったでしょう。
全体の誤検知率がどれくらいかは言い難いです。なぜなら、統計的にノイズの中にいるからです。フィルタに取り組んだことがある人（少なくとも、効果的なフィルタに）はこの問題を認識しているでしょう。いくつかのメールはスパムかどうかを判断するのが難しく、これらはフィルタを非常に厳しくしたときに見ることになるものです。例えば、これまでのところ、フィルタは私のアドレスに誤って送信された2通のメールと、私が他の誰かだと信じて送信された1通を捕まえました。議論の余地がありますが、これらは私のスパムでも非スパムでもありません。
別の誤検知は、Virtumundoの副社長からのものでした。私は顧客のふりをして彼らに書きましたが、返信はVirtumundoのメールサーバーを通じて返ってきたため、最も有罪のヘッダーを持っていました。議論の余地がありますが、これは本当の誤検知ではなく、ある種のハイゼンベルクの不確実性効果です：私はスパムフィルタリングについて書いていたためにそれを受け取ったのです。
これらを除くと、私はこれまでに約7740件の正当なメールの中で合計5件の誤検知を受け取りました。誤検知率は0.06%です。残りの2件は、私が購入したものがバックオーダーになったという通知と、Eviteからのパーティーのリマインダーでした。
この数字は信頼できるとは思いません。部分的にはサンプルが非常に小さいため、部分的にはフィルタを修正してこれらのいくつかを捕まえないようにできると思うからです。
誤検知は、私にとって誤陰性とは異なる種類のエラーのように思えます。フィルタリング率は性能の指標です。誤検知は、私はバグのように考えます。フィルタリング率の改善は最適化としてアプローチし、誤検知の減少はデバッグとしてアプローチします。
したがって、これらの5件の誤検知は私のバグリストです。例えば、エジプトからのメールは、大文字のテキストがフィルタにとってナイジェリアのスパムのように見えたために捕まえられました。これは本当にバグのようなものです。HTMLと同様に、メールがすべて大文字であることは、実際には1つの特徴であり、各単語ごとではありません。私は大文字小文字をより洗練された方法で扱う必要があります。
では、この0.06%をどう考えればよいでしょうか？あまり考えない方が良いと思います。これは上限として扱うことができますが、小さなサンプルサイズを考慮に入れてください。しかし、この段階では、これは私の実装のバグの指標であり、ベイズフィルタリングの本質的な誤検知率ではありません。
未来
次は何でしょうか？フィルタリングは最適化の問題であり、最適化の鍵はプロファイリングです。コードが遅い場所を推測しようとしないでください。なぜなら、間違った推測をするからです。どこが遅いのかを見て、それを修正してください。フィルタリングにおいて、これは次のように翻訳されます：見逃したスパムを見て、それらを捕まえるために何ができたかを考えます。
例えば、スパマーは現在、フィルタを回避するために積極的に取り組んでおり、彼らが行っていることの1つは、フィルタがそれらを認識できないように単語を分割したり、誤って綴ったりすることです。しかし、これに取り組むことは私の最優先事項ではありません。なぜなら、私はまだこれらのスパムを捕まえるのに問題がないからです[10]。
現在、私が問題を抱えているスパムには2種類あります。1つは、女性からのメールを装って、チャットに誘ったり、デーティングサイトでのプロフィールを見に行くように誘ったりするタイプです。これらは、販売トークを使用せずに行える唯一の販売ピッチのタイプであるため、通過します。彼らは普通のメールと同じ語彙を使用します。
もう1つのフィルタリングが難しいスパムは、例えばブルガリアの企業からの契約プログラミングサービスを提供するものです。これらは、私もプログラマーであり、スパムが私の本当のメールと同じ単語でいっぱいであるため、通過します。
私はおそらく、最初に個人広告タイプに焦点を当てるでしょう。もっと詳しく見れば、これらと私の本当のメールとの間に統計的な違いを見つけられると思います。文体は確かに異なりますが、それを捕まえるには多単語フィルタリングが必要かもしれません。また、彼らはURLを繰り返す傾向があり、正当なメールにURLを含める人はそうしないでしょう[11]。
アウトソーシングタイプは捕まえるのが難しいでしょう。たとえクローラーをサイトに送っても、決定的な統計的証拠は見つからないでしょう。おそらく唯一の答えは、スパムで宣伝されているドメインの中央リストです[12]。しかし、このタイプのメールはそれほど多くないはずです。もし残っているスパムがブルガリアからの契約プログラミングサービスの未承諾オファーだけであれば、私たちはおそらく他の何かに取り組むことができるでしょう。
統計的フィルタリングは本当にそのポイントに到達するのでしょうか？わかりません。今のところ、私にとってスパムは問題ではありません。しかし、スパマーはまだ統計的フィルタを偽造するために真剣な努力をしていません。彼らがそうしたとき、何が起こるでしょうか？
私はネットワークレベルで機能するフィルタに楽観的ではありません[13]。越える価値のある静的障害物があるとき、スパマーはそれを越えるのが非常に効率的です。すでに、あなたのメールをSpamassassinに通してフィルタリングされるかどうかを教えてくれる会社、Assurance Systemsがあります。
ネットワークレベルのフィルタは完全に無駄ではありません。彼らは、VirtumundoやEqualamailのような、実際にオプトインリストを運営していると主張する企業からの「オプトイン」スパムをすべて排除するのに十分かもしれません。彼らは、本文で何を言っても、ヘッダーだけに基づいてフィルタリングできます。しかし、ヘッダーを偽造したり、オープンリレーを使用したりすることをいとわない人々、つまりほとんどのポルノスパマーを含む人々は、望む場合はネットワークレベルのフィルタを通過させることができるはずです。（彼らが送りたいメッセージではありませんが、それは何かです。）
私が楽観的なフィルタは、各個人のメールに基づいて確率を計算するものです。これらは、誤検知を避けるだけでなく、フィルタリングにも非常に効果的です。例えば、メッセージ内のどこかに受信者のメールアドレスがBase-64エンコードされているのを見つけることは、非常に良いスパムの指標です。
しかし、個別のフィルタの真の利点は、すべて異なることです。もし誰もが異なる確率を持つフィルタを持っていれば、スパマーの最適化ループ、プログラマーが編集-コンパイル-テストサイクルと呼ぶものは、驚くほど遅くなります。彼らがデスクトップにあるフィルタのコピーを通過させるためにスパムを微調整するだけでなく、各微調整のためにテストメールを送信しなければならなくなります。それは、インタラクティブなトップレベルなしでプログラミングするようなもので、私は誰にもそれを望みません。
ノート
[1]
Paul Graham. ``A Plan for Spam.'' 2002年8月。
http://paulgraham.com/spam.html。
このアルゴリズムの確率は、ベイズの法則の退化したケースを使用して計算されます。2つの単純化された仮定があります：特徴（すなわち単語）の確率が独立であること、そしてメールがスパムである事前確率について何も知らないことです。
最初の仮定はテキスト分類で広く普及しています。これを使用するアルゴリズムは「ナイーブベイズ」と呼ばれます。
2つ目の仮定は、私の受信メールのスパムの割合が日々（実際には時間ごとに）非常に変動するため、全体の事前比率は予測として無価値に思えたために行いました。もしP(spam)とP(nonspam)が両方とも0.5であると仮定すると、それらは打ち消し合い、式から取り除くことができます。
スパムと非スパムの比率が一貫して非常に高いか（特に）非常に低い状況でベイズフィルタリングを行っている場合、事前確率を組み込むことでフィルタの性能を改善できるでしょう。これを正しく行うには、時間帯ごとに比率を追跡する必要があります。なぜなら、スパムと正当なメールのボリュームは、両方とも明確な日次パターンを持っているからです。
[2]
Patrick PantelとDekang Lin. ``SpamCop-- A Spam
Classification & Organization Program.'' AAAI-98
Workshop on Learning for Text Categorizationの議事録。
[3]
Mehran Sahami、Susan Dumais、David Heckerman、Eric Horvitz.
``A Bayesian Approach to Filtering Junk E-Mail.'' AAAI-98
Workshop on Learning for Text Categorizationの議事録。
[4]
当時、私は約4,000件の正当なメールの中でゼロの誤検知を持っていました。次の正当なメールが誤検知であった場合、これは0.03%を与えます。これらの誤検知率は信頼できません。後で説明しますが、ここで数字を引用するのは、誤検知率が1.16%未満であることを強調するためです。
[5]
Bill Yerazunis. ``Sparse Binary Polynomial Hash Message
Filtering and The CRM114 Discriminator.'' 2003年
スパム会議の議事録。
[6]
``A Plan for Spam''では、0.99と0.01の閾値を使用しました。コーパスのサイズに比例した閾値を使用することは正当化されるようです。現在、私はそれぞれのタイプのメールで約10,000件を持っているので、0.9999と0.0001を使用しています。
[7]
ここには修正すべき欠陥があります。現在、Subject*foo''がfoo''に退化すると、これは、私がマークした以外の本文やヘッダー行でのfoo''の出現の統計を取得していることを意味します。私がすべきことは、foo''全体の統計を追跡し、特定のバージョンだけでなく、Subject*foo''からfoo''ではなく``Anywhere*foo''に退化させることです。大文字小文字についても同様です：大文字から任意のケースに退化させるべきであり、小文字にはしないべきです。
価格についてもこれを行うことはおそらく有益です。例えば、$129.99''から$--9.99''、$--.99''、$--''に退化させることです。
単語をその語根に退化させることもできますが、これはおそらく小さなコーパスを持っていた初期の段階でフィルタリング率を改善するだけでしょう。
[8]
Steven Hauser. ``Statistical Spam Filter Works for Me.''
http://www.sofbot.com。
[9]
誤検知はすべて同じではなく、スパムを止めるための技術を比較する際にはこれを忘れないようにしましょう。フィルタによって引き起こされる多くの誤検知は、見逃しても気にしないようなスパムに近いメールですが、例えばブラックリストによって引き起こされる誤検知は、間違ったISPを選んだ人々からのメールです。両方の場合、スパムに近いメールを捕まえますが、ブラックリストの場合、近さは物理的であり、フィルタの場合はテキスト的です。
[10]
もしスパマーがトークンを隠すのが上手くなった場合、私たちは単に空白、ピリオド、カンマなどを削除し、辞書を使用して結果のシーケンスから単語を選び出すことで応じることができます。もちろん、元のテキストに表示されなかった単語をこの方法で見つけることは、スパムの証拠となります。
単語を選び出すことは簡単ではありません。単語の境界を再構築するだけでなく、スパマーは文字を追加（xHot nPorn cSite''）したり、省略（P#rn''）したりします。視覚研究はここで役立つかもしれません。なぜなら、人間の視覚はそのようなトリックが近づく限界だからです。
[11]
一般的に、スパムは通常のメールよりも繰り返しが多いです。彼らはそのメッセージを強調したいのです。現在、私は上位15トークンに重複を許可していません。なぜなら、送信者が悪い単語を複数回使用する場合、誤検知が発生する可能性があるからです。（私の現在のフィルタでは、``dick''のスパム確率は0.9999ですが、それは名前でもあります。）ただし、少なくとも重複を認識するべきだと思いますので、Brian BurtonがSpamProbeで行っているように、各トークンを最大2つまで許可することを試みるかもしれません。
[12]
これは、スパマーがメッセージ内の他のすべてを生成するためにマッドリブ技術を使用するように押し込まれた場合、Brightmailのようなアプローチが退化するものです。
[13]
ネットワークレベルでフィルタリングに取り組むべきだと主張されることがあります。なぜなら、それはより効率的だからです。人々がこれを言うとき、通常はこう言います：私たちは現在ネットワークレベルでフィルタリングしており、最初からやり直したくないのです。しかし、問題を解決策に合わせて調整することはできません。
歴史的に、資源が限られているという議論は、ソフトウェア設計に関する議論で負ける側でした。人々は、他の理由で行った選択（特に不作為）を正当化するためにのみこれを使用する傾向があります。
感謝
Sarah Harlin、Trevor Blackwell、Dan Giffinにこの論文の草稿を読んでいただき、Danにはこのフィルタが動作するためのほとんどのインフラを提供してくれたことに感謝します。
関連：
SubjectFREE 0.9999
free!! 0.9999
Tofree 0.9998
Subjectfree 0.9782
free! 0.9199
Free 0.9198
Urlfree 0.9091
FREE 0.8747
From*free 0.7636
free 0.6546
SubjectFree!!!
Subjectfree!!!
SubjectFREE!
SubjectFree!
Subjectfree!
SubjectFREE
SubjectFree
Subjectfree
FREE!!!
Free!!!
free!!!
FREE!
Free!
free!
FREE
Free
free