より優れたベイジアンフィルタリング

2003年1月

(この記事は、2003 年の Spam Conference で講演として発表されました。A Plan for Spamで説明されているアルゴリズムのパフォーマンスを向上させるために私が行った作業と、今後の計画について説明しています。)

ここで紹介したい最初の発見は、研究論文を怠惰に評価するためのアルゴリズムです。好きなことを書いて、先行研究を一切引用しないと、憤慨した読者が、引用すべきだったすべての論文の参考文献を送ってくるでしょう。私はこのアルゴリズムを、Slashdot に「A Plan for Spam」[1] が掲載された後に発見しました。

スパムフィルタリングは、十分に確立された分野であるテキスト分類のサブセットですが、ベイジアンスパムフィルタリング自体に関する最初の論文は、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'' and 「mailed」の両方をルート「mail」に短縮したということです。コーパスのサイズが小さいため、そうせざるを得ないと感じたのかもしれませんが、そうだとすれば、これは一種の時期尚早な最適化です。

4 番目に、確率の計算方法が異なっています。彼らはすべてのトークンを使用しましたが、私は最も重要な 15 個だけを使用します。すべてのトークンを使用すると、マルチ商法で金持ちになるまでの人生の物語を語るタイプの長いスパムを見逃す傾向があります。そして、そのようなアルゴリズムは、スパム業者が簡単に偽装できます。スパム用語と釣り合うように、ランダムなテキストを大量に追加するだけで済みます。

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

スパムフィルタリングを単なるテキスト分類の問題として扱うのは得策ではないと思います。テキスト分類の手法を使うこともできますが、解決策はテキストが電子メール、特にスパムであるという事実を反映する必要があります。電子メールは単なるテキストではなく、構造を持っています。スパムフィルタリングは単なる分類ではありません。誤検知は誤検知よりもずっと悪いため、別の種類のエラーとして扱う必要があります。また、エラーの原因は単なるランダムな変化ではなく、フィルターを破ろうと積極的に活動する生身の人間のスパマーです。

トークン

Slashdot の記事の後で私が耳にした別のプロジェクトは、Bill Yerazunis のCRM114 [5] です。これは、私が今述べた設計原則の反例です。これは単純なテキスト分類器ですが、非常に効果的なもので、スパムをフィルタリングしていることに気付かなくても、ほぼ完璧にフィルタリングすることができます。

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

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

「A Plan for Spam」では、トークンの定義が非常にシンプルになっています。文字、数字、ダッシュ、アポストロフィ、ドル記号がトークンを構成する文字で、それ以外はすべてトークンの区切り文字です。大文字と小文字も無視しています。

ここで、トークンの定義はより複雑になります。

ケースは保存されます。

感嘆符は構成文字です。

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

20 ～ 25 ドルのような価格帯では、20 ドルと 25 ドルの 2 つのトークンが生成されます。

To、From、Subject、Return-Path 行内、または URL 内に出現するトークンは、それに応じてマークされます。たとえば、 foo'' in the Subject line becomes 。(アスタリスクは、構成要素として許可されていない任意の文字にすることができます。)

このような対策により、フィルターの語彙が増え、識別力が向上します。たとえば、現在のフィルターでは、件名に「free」が含まれている場合、スパムの可能性は 98% ですが、本文に同じトークンが含まれている場合、スパムの可能性は 65% しかありません。

現在の確率のいくつかを以下に示します[6]。

件名FREE 0.9999 free!! 0.9999 宛先free 0.9998 件名free 0.9782 free! 0.9199 Free 0.9198 URL free 0.9091 FREE 0.8747 From*free 0.7636 free 0.6546

Plan for Spam フィルターでは、これらすべてのトークンの確率は同じ .7602 でした。そのフィルターは約 23,000 個のトークンを認識しました。現在のフィルターは約 187,000 個のトークンを認識します。

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

これに対する解決策の 1 つは、私が退化と呼んでいるものです。トークンの完全一致が見つからない場合は、それをより限定的でないバージョンとして扱います。末尾の感嘆符、大文字、および 5 つのマークされたコンテキストのいずれかに出現することは、トークンをより限定的なものにすると考えます。たとえば、「Subject*free!」の確率が見つからない場合は、「Subject*free」、「 free!'', and 「free」 Subject*free!'', I look for probabilities for 、.5 から最も遠いものを取得します。

フィルタが件名に「FREE!!!」を見つけ、その可能性がない場合に考慮される代替案[7]は次のとおりです。

件名無料!!! 件名無料!!! 件名無料! 件名無料! 件名無料! 件名無料! 件名無料件名無料件名無料無料!!! 無料!!! 無料!!! 無料! 無料! 無料! 無料! 無料無料

これを行う場合は、すべて大文字とすべて小文字のバージョンだけでなく、先頭が大文字のバージョンも考慮してください。スパムには命令形の文が多く含まれる傾向があり、その場合、最初の単語は動詞です。そのため、先頭が大文字の動詞は、すべて小文字の場合よりもスパムの可能性が高くなります。私のフィルターでは、 Act'' is 98% and for 62% しかありません。

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

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

たとえば、トークンdalco'' occurs 3 times in my spam corpus and never in my legitimate corpus. The token Url*optmails」(URL 内の「optmails」を意味する) は 1223 回出現します。それでも、トークンの確率を計算するときに使用したように、どちらも同じスパム確率、しきい値 .99 になります。

それは正しくない気がします。これら 2 つのトークンに大幅に異なる確率を与えるという理論的な議論がありますが (Pantel と Lin はそうしています)、私はまだ試していません。少なくとも、どちらかのコーパスにのみ出現するトークンが 15 個以上見つかった場合は、頻繁に出現するトークンを優先するべきであると思われます。したがって、しきい値は 2 つあります。スパムコーパスにのみ出現するトークンの場合、10 回以上出現する場合は確率が .9999、そうでない場合は .9998 です。正当なコーパスにのみ見つかったトークンの場合も同様です。

後でトークンの確率を大幅にスケーリングする可能性がありますが、このわずかなスケーリングにより、少なくともトークンが適切にソートされることが保証されます。

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

最後に、HTML についてはどうすればよいでしょうか。無視することからすべてを解析することまで、あらゆるオプションを試しました。HTML を無視するのはよくありません。有用なスパムサインがたくさんあるからです。しかし、すべてを解析すると、フィルターが単なる HTML 認識機能に堕落してしまう可能性があります。最も効果的なアプローチは、一部のトークンに注意し、他のトークンには注意しないという中道のようです。私は a、img、およびフォントタグを確認し、残りは無視します。リンクと画像は URL を含んでいるので、必ず確認する必要があります。

おそらく HTML の扱いをもっと賢くできるでしょうが、これに多くの時間を費やす価値はないと思います。HTML でいっぱいのスパムは簡単にフィルタリングできます。賢いスパマーはすでにそれを避けています。したがって、将来のパフォーマンスは HTML の扱い方にあまり左右されないはずです。

パフォーマンス

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

私が見逃した 4 通のスパムのうち 2 通は、たまたま正規の電子メールによく出てくる単語が使われていたため、通過してしまいました。

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

もちろん、複数のトークンシーケンスを見れば簡単にわかります。「以下はフィードバックフォームの結果です」と表示されれば、すぐにバレてしまいます。

4 番目のスパムは、私が未来のスパムと呼んでいるものです。なぜなら、これがスパムの進化形であると予想しているからです。つまり、完全に中立的なテキストの後に URL が続くものです。この場合、それは、ようやくホームページが完成したので見てほしいという誰かからのものでした。(そのページは、もちろんポルノサイトの広告でした。)

スパマーがヘッダーに注意し、新しい URL を使用する場合、将来のスパムにはフィルターが気付くようなものはありません。もちろん、クローラーを送信してページを調べることで対抗できます。しかし、それは必要ないかもしれません。将来のスパムの応答率は低いに違いありません。そうでなければ、誰もがそれを実行するでしょう。応答率が十分に低ければ、スパマーが送信しても利益は得られず、フィルタリングにそれほど力を入れる必要もありません。

さて、本当に衝撃的なニュースですが、同じ 1 か月の間に、私は3 回の誤検知を受けました。

ある意味、誤検知があると安心します。私が「スパム対策計画」を書いたときは、まだスパムがなかったので、どんなものか知りませんでした。今では、実際にいくつかスパムが来て、心配していたほどひどくないことがわかって安心しています。統計フィルターによって生成された誤検知は、スパムによく似たメールであることが判明しており、見逃しても構わないメールである傾向があります [9]。

誤検知のうち 2 つは、私が商品を購入したことがある会社からのニュースレターでした。私はニュースレターの受信を依頼したことがないので、スパムであると言えるかもしれませんが、以前はスパムとして削除していなかったため、誤検知としてカウントしています。フィルターがニュースレターをキャッチした理由は、1 月に両社が自社のサーバーからメールを送信するのではなく、商用のメール送信者に切り替えたため、ヘッダーと本文の両方がスパムっぽくなったためです。

しかし、3 番目の誤検知はひどいものでした。エジプトの誰かから送られてきたもので、すべて大文字で書かれていました。これはトークンの大文字と小文字を区別するようにしたことによる直接的な結果であり、Plan for Spam フィルターでは検出できなかったでしょう。

統計的には、私たちはノイズの中にいるので、全体的な誤検出率を言うのは難しいです。フィルター (少なくとも、効果的なフィルター) に取り組んだことがある人なら、この問題に気付くでしょう。一部のメールは、スパムかどうか判断するのが難しく、フィルターを非常に厳しくすると、最終的にこのようなメールに目を向けることになります。たとえば、これまでのところ、フィルターは、タイプミスで私のアドレスに送信された 2 つのメールと、私が別の人だと信じて送信された 1 つのメールをキャッチしました。おそらく、これらは私のスパムでも、非スパムのメールでもないのでしょう。

もう 1 つの誤検知は、Virtumundo の副社長からのものでした。私は顧客のふりをして彼らにメールを送りましたが、返信は Virtumundo のメールサーバーを経由して返ってきたので、考えられる限り最も有罪を示すヘッダーが付いていました。おそらくこれも本当の誤検知ではなく、ハイゼンベルクの不確定性効果の一種です。スパムフィルタリングについて書いていたため、この誤検知に遭遇しただけです。

これらを除くと、これまでに受け取った正規のメール約 7740 通のうち、誤検知は合計 5 件で、割合は 0.06% です。他の 2 件は、購入した商品がバックオーダーになっているという通知と、Evite からのパーティーのリマインダーでした。

この数字は信頼できるとは思えません。サンプルが非常に少ないことと、フィルターを修正してこれらの一部が捕捉されないようにできると思うからです。

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

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

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

未来

次は何をするのでしょうか? フィルタリングは最適化の問題であり、最適化の鍵はプロファイリングです。コードのどこが遅いのかを推測しようとしないでください。間違った推測をすることになります。コードのどこが遅いのかを調べて、それを修正します。フィルタリングでは、これは次のように変換されます: 見逃したスパムを調べて、それをキャッチするために何ができたかを考えます。

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

私が現在困っているスパムには 2 種類あります。1 つは、チャットに誘ったり、出会い系サイトでプロフィールを見ようと女性からメールを装ったものです。これらはセールストークを使わずにできる唯一のセールストークなので、問題なく届きます。通常のメールと同じ語彙が使われています。

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

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

アウトソーシング型は捕まえるのが難しいでしょう。サイトにクローラーを送っても、統計的に決定的な証拠は見つからないでしょう。おそらく唯一の答えは、スパムで宣伝されているドメインの中央リストです [12]。しかし、このタイプのメールはそれほど多くないはずです。残っているスパムがブルガリアからの契約プログラミングサービスの一方的なオファーだけであれば、私たちはおそらく他の仕事に移ることができるでしょう。

統計フィルタリングによって、実際にそこまで到達できるでしょうか? わかりません。今のところ、私個人としては、スパムは問題ではありません。しかし、スパマーはまだ統計フィルタを偽装する本格的な取り組みを行っていません。そうなったらどうなるでしょうか?

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

ネットワークレベルのフィルタは、まったく役に立たないというわけではありません。Virtumundo や Equalamail などの企業から送られてくる、実際にはオプトインリストを運用していると主張する「オプトイン」スパムをすべて排除するには十分かもしれません。本文の内容に関係なく、ヘッダーのみに基づいてフィルタリングできます。ただし、ヘッダーを偽造したり、オープンリレーを使用したりしようとする人 (おそらくポルノスパマーのほとんどを含む) は、希望すれば、ネットワークレベルのフィルタを通過できるメッセージを取得できるはずです (ただし、送信したいメッセージではないことは確かです)。

私が期待しているのは、各ユーザーのメールに基づいて確率を計算するフィルターです。こうしたフィルターは、誤検知を回避するだけでなく、フィルタリングにおいてもはるかに効果的です。たとえば、メッセージのどこかに受信者のメールアドレスが Base64 でエンコードされていることがわかれば、スパムであることを示す非常に優れた指標となります。

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

注記

[1] ポール・グラハム「スパム対策計画」2002年8月 http://paulgraham.com/spam.html

このアルゴリズムの確率は、ベイズの法則の退化したケースを使用して計算されます。単純化のための仮定が 2 つあります。特徴 (つまり単語) の確率は独立しており、電子メールがスパムである事前確率については何もわかっていないということです。

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

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

スパムと非スパムの比率が一貫して非常に高い、または (特に) 非常に低い状況でベイジアンフィルタリングを実行している場合は、事前確率を組み込むことでフィルタのパフォーマンスを改善できる可能性があります。これを適切に行うには、スパムと正規のメールの量はどちらも日ごとに異なるパターンを持っているため、時間帯ごとに比率を追跡する必要があります。

[2] Patrick PantelとDekang Lin。「SpamCop - スパムの分類と整理プログラム」AAAI-98テキスト分類の学習に関するワークショップ議事録。

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

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

[5] ビル・イエラズニス「スパースバイナリ多項式ハッシュメッセージフィルタリングとCRM114ディスクリミネータ」2003年スパムカンファレンス議事録。

[6] 『スパム対策計画』では、閾値として .99 と .01 を使用しました。コーパスのサイズに比例した閾値を使用するのが妥当と思われます。現在、各タイプのメールが 10,000 通程度あるため、閾値として .9999 と .0001 を使用しています。

[7] ここで、おそらく修正すべき欠陥があります。現在、 Subject*foo'' degenerates to justと、 foo'' in the body or header lines other than those I mark. What I should do is keep track of statistics for 、 Subject*foo'' not to ``Anywhere*foo'' に退化することです。大文字と小文字についても同様です。大文字から小文字ではなく、任意の大文字に退化する必要があります。

価格についても同様にすると、たとえば$129.99'' toから「$--9.99''」、 $--.99'', and 、おそらく有利になるでしょう。

単語からその語幹に退化することもできますが、これによってフィルタリング率が向上するのは、コーパスが小さい初期の段階のみである可能性が高いでしょう。

[8] スティーブン・ハウザー「統計的スパムフィルターは私にとっては効果的です。」http://www.sofbot.com

[9] 誤検知はすべて同じではありません。スパムを阻止する技術を比較する際には、この点に留意する必要があります。フィルターによって発生する誤検知の多くは、見逃してもかまわないスパムに近いものですが、ブラックリストによって発生する誤検知は、たとえば間違った ISP を選択した人からのメールです。どちらの場合も、スパムに近いメールをキャッチしますが、ブラックリストの場合、近さは物理的なものであり、フィルターの場合、それはテキストです。

[10] スパマーがトークンを難読化することに長けてこれが問題になるようになれば、空白、ピリオド、カンマなどを削除し、辞書を使って結果のシーケンスから単語を拾い出すだけで対応できます。もちろん、この方法で元のテキストには表示されていなかった単語を見つけること自体がスパムの証拠になります。

単語を拾い出すのは簡単ではありません。単語の境界を再構築するだけでは不十分です。スパマーは文字を追加したり ( xHot nPorn cSite'') and omit ( P#rn'') します。人間の視覚はこのようなトリックが近づく限界であるため、視覚の研究がここで役立つ可能性があります。

[11] 一般的に、スパムは通常の電子メールよりも繰り返しが多いです。スパムはメッセージを徹底的に伝えたいのです。現在、私は上位 15 個のトークンの重複を許可していません。送信者がたまたま悪い言葉を複数回使用した場合に誤検知が発生する可能性があるためです。(現在のフィルターでは、「dick」のスパム確率は .9999 ですが、これは名前でもあります。) ただし、重複は少なくとも認識する必要があるようですので、Brian Burton が SpamProbe で行っているように、各トークンを最大 2 つまで許可するようにしてみます。

[12] スパマーがマッドリブ技術を使ってメッセージ内の他のすべてのものを生成するよう強制されると、Brightmailのようなアプローチはこのような状態に退化します。

[13] より効率的であるため、ネットワークレベルでのフィルタリングに取り組むべきだという議論が時々あります。人々が通常これを言うとき意味しているのは、現在ネットワークレベルでフィルタリングを行っており、ゼロからやり直したくないということです。しかし、自分の解決策に合うように問題を指定することはできません。

歴史的に、希少資源に関する議論は、ソフトウェア設計に関する議論では負ける側でした。人々は、他の理由による選択（特に不作為）を正当化するためにのみ、希少資源に関する議論を使用する傾向があります。

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

関連している：

件名FREE 0.9999 free!! 0.9999 宛先free 0.9998 件名free 0.9782 free! 0.9199 Free 0.9198 URL free 0.9091 FREE 0.8747 From*free 0.7636 free 0.6546