![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
非倫理的なEメール発信者は、ほとんど、あるいはまったく費用をかけずに、メッセージを大量に送信しているにもかかわらず、普通のEメール・ユーザーは、詐欺まがいのメールや不要なメールをメールボックスから除去するのに手間暇をかけることを余儀なくされています。本稿では、勝手に送り付けられてくる宣伝メールやウィルス、トロイの木馬、ウォーム、あるいは電子的に行われる詐欺、その他、望まれない面倒なEメールを、プログラムを使って除去するための方法をいろいろと紹介したいと思います。ある意味では、スパム・メールを除去するための最終的で最善の解決策は、多分、法律が制定されることでしょうが、一方、公衆の不満が高まるにつれて法律が拡充され始めるまでは、この問題に対する暫定的な解決策として、プログラム・コードで対策を講じることが考えられます。
技術的に、といっても常識をも踏まえて問題を考えてみると、一般に「スパム」と呼ばれているものは、「勝手に送り付けられてくる宣伝メール」という分類よりも、いくぶん広い範囲を含んでいます。スパムには、われわれが望んでいないEメールや、ただ漠然とわれわれのもとに送られてくるEメールも、すべて含まれます。そのようなメッセージは、必ずしも宣伝目的のものばかりではなく、「求められている」という意味を拡大解釈しているものもあります。たとえば、われわれはウィルスを望んでいませんし (不注意な友達からであろうと)、通常、金銭を要求しないものであれ、チェーン・レターも受け取りたくありません。知らない人からの宗教勧誘のメッセージも嫌なら、ただただ人から金を騙しとろうとするメッセージも嫌です。いずれにせよ、通常、メッセージがスパムかどうかは曖昧ですが、非常に多くの人がその手のEメールを受けとっていることは確かです。
スパムで問題なのは、本当にほしいメールよりも圧倒的に多くのスパムが送られてきがちであるということです。私自身の経験では、2、3年前は、不適当なメッセージが送られてくるのは、毎日1、2回だったと思うのですが、今月は、毎日、正当なメールのやりとりの何倍も 多くのスパムをを受けとっています。平均して、多分、正当なEメール1個に対して10個のスパムを受けとっています。私は、ライターとして表立った活動をしていますので、ある意味では一般とは違い、広く知れ渡ったEメール・アドレスを使っています。それに、私の執筆内容やソフトウェア・ライブラリーについて、知らない人から、たくさんの便りをいただくことを歓迎もし、実際にいただいてもいます。残念ながら、知らない人からの手紙は、使われているE-メール・アプリケーションやOSや母国語などがわからないため、すぐには、それがどんな用件なのかがわかりません。そこでスパマーは、そんな曖昧さを隠れ蓑にして、彼らのメッセージを忍び込ませるのです。私にとってわずかな時間でも貴重であり、とくに四六時中何度も時間を割かざるを得ないときにはことさらです。
一部のEメール・ユーザーにとっては、単にEメール・アドレスをしっかりガードすることが、スパムを避けるための、非常に簡単ながら、合理的で、充分効果的な方法となります。このような人々の場合、Eメール・アドレスは、限定された信頼できる相手に対してのみに知らるので十分です。さらに予防措置をとるとすれば、Eメール・アドレスとして、簡単に推測できるような名前や辞書の見出し語は使わないようにすることでしょう。また、アドレスを公の場に示すときには、アドレスに変装を加えるという手もあります。Eメール・アドレスが <mertzHIDDEN@NOSPAM.gnosis.cx> とかecho zregm@tabfvf.pk | tr A-Za-z N-ZA-Mn-za-mというような形に抜け目なくコード暗号化 されているのを誰でも目にしたことがあることと思います。
アドレスを隠す他にも、秘密主義のメール発信者は、よく、「使い捨て」アドレスとして、無料のメール・アドレス・サービスを何個か使います。あまり信用できない相手との間でメールのやりとりをする必要があるときには、何日か一時的なアドレスを使い、その後、そのアドレスへのスパムが増えてくるようであれば、そのアドレスは捨てるといった方法を採用することもできます。本当に「信頼できる人だけ」のためのアドレスは、保護しておきます。
Webボード、メーリング・リスト、Usenetなどでのスパムに関する議論を私が個人的に調査したところによると、ある範疇のEメール・ユーザーでは、こうした基本的な予防策で充分な防護ができていることがわかりました。
しかしながら、私の場合、あるいは他の多くの人々にとっても、これらの方法を採用することは不可能です。私は、広く公開しているメール・アドレスを使っていますし、それを使い続けなければならないそれ相応の理由もあります。私は、実際、スパム・リークの出所を検出するために、私の管理しているドメインでいろいろなアドレスを利用しています。しかし、残念なことに、ほとんどのスパマーが、私がメールのやりとりを行っている相手と同じ方法で、私のメール・アドレスを入手しているというのが真実です。本稿のような記事の先頭に示してあるなど、私のアドレスを公開してあるところからです。
本稿では、ある特別な視点からフィルター・ソフトウェア (filtering software) を眺めてみたいと思います。つまり、いろいろな手法が、どれぐらい正しくスパムをスパムとして識別し、望ましいメッセージを正当なものとして識別するのかを知りたいと思うわけです。この疑問に答える目的では、フィルター・アプリケーションを各種のメール転送エージェント (MTA: Mail Transfer Agents) と連携させるための詳細な設定方法には、とくに関心はありません。Sendmail、QMail、Procmail、FetchmailなどのMTAを最善の形に設定することに関しては、秘密にされていてわからないことがたくさんあります。また、Eメール・クライアントの多くが、独自のフィルター・オプションやプラグインAPIを備えています。幸い、私が調べたフィルターは、ほとんどが、各種MTAに対する設定方法を説明した、かなり良質なマニュアルを添付しています。
私は、テスト用として、スパム・メールと正当なメールの2つの種類のメッセージ集合を用意しました。どちらのメッセージ集合も、私が実際に、この何ヵ月かの間に受けとったメールからのものですが、テストの範囲を広げるために、何年も前のメッセージも、重要だと思われるものを選択して、この中に含めました。来月どんなメールがくるのかを知ることはできませんが、過去は、その後がどうなるのかを知るための最善の手がかりとなります。不可解に聞こえるかもしれませんが、要するに、単語が数個とか語句が数個とか正規表現が数個というメールは、ごく最近の特徴かもしれず、私のいう2つの種類を一般化し損なうことになるかもしれないため、パターンをそのようなものだけに限定したくないということです。
この2つのメール集合の他に、スパム・メッセージと非スパム・メッセージを「学習する」ツールのために、トレーニング用のメッセージ集合も用意しました。トレーニング用の集合は、どちらも、テスト用の集合より大きく、一部、テスト用の集合には属さないものが含まれています。テスト集合は、2,000個弱のスパム・メッセージと、ほぼ同数の正当メッセージからなっています。トレーニング用の集合は、その約2倍です。
テスト方法について、一般的なことを強調しておきたいと思います。スパム・フィルターの見逃し (false negatives) とは、望まれないメッセージが受信トレイ (inbox) にたどり着いたことを意味します。良いことではありませんが、それ自身恐ろしいことではありません。誤検出 (false positives) とは、正当なメッセージがスパムとして誤って識別された件数です。正当なメッセージは、本来、重要なものであったり、緊急のものであったりすることもありますし、単なるおしゃべりのメッセージでも失くしたくないものもありますので、これは、非常に 好ましくない結果を招く可能性があります。ほとんどのフィルター・ソフトは、除外されたメッセージを一時的なフォルダーに入れ、チェックするまでは保存するようにしていますが、スパムがぎっしり詰まったフォルダーをチェックしなければならないというのでは、ソフトウェアの価値は、そのぶん低くなります。
私の使っているEメール・クライアントは、指定したヘッダー・フィールドやヘッダー全体、あるいは本文に含まれる単純な文字列で、受信されるメールを分類できるようになっています。これは非常に単純なもので、正規表現による一致すら利用できません。この程度のフィルター機能は、ほとんどすべてのEメール・クライアントが備えています。
ここ数ヵ月の間に、私は、テキスト・フィルターを何個か作成してみました。これら何個かの単純なフィルターは、私の受信するスパムの約8割を正しく捕捉しています。ただ残念ながら、誤検出率も比較的高く、ときどきスパム・フォルダーのいくつか を手作業で確認しなければならないくらいです。(私は、スパムの候補をいくつかのフォルダーに分類し、メッセージ集合を用意するために、それをすべて保存するようにしています。) 細かい点は、ユーザーごとに異なるでしょうが、一般的なパターンは、ほとんどの読者にとって有益な情報となることと思います。
- 集合1: ある人々や、メーリング・リストは、あるルールで識別できるようなしかけをヘッダーに施しています。私は、ヘッダー内の何か (通常は、From:) を調べて、それをホワイトリストに (INBOXかどこかに) 含めています。
- 集合2: 順不同で、以下のスパム・フィルターを実行します。
- 特定の悪徳送信者を識別する。
- From: ヘッダーを調べるために、<> を探す。
- ヘッダー内で @< を探す (どういうわけか、多くのスパムがこれを含めている)。
- Content-Type: audioを探す。私にとって望ましいメールは、どれもこれを含みません。含むのはウィルスだけでしょう (皆さんの場合の頻度は異なるかもしれませんが)。
- ヘッダーにeuc-krやks_c_5601-1987が含まれていないか調べる。私が読めるわけではありませんが、どういうわけか、大量の 朝鮮語のスパムが送られてきます。(もちろん、朝鮮人の読者の場合、これは適当なルールではありません)。
- 集合3: メッセージを、既知の正当なアドレスに分類して保存します。私は、そのようなルールをいくつか作成しましたが、全部、To: のフィールドの文字列そのままを照合するだけです。
- 集合4: ヘッダーに正当なアドレスが含まれているが、先のTo: フィルターで捕捉されなかったメッセージを探します。私のアドレスがBcc: フィールドにだけ含まれているときは、ほとんど必ずといってよいぐらい、アルファベット順に並べたアドレスのリスト (mertz1@...、mertz37@...、など) に勝手に送り付けられてきたメールです。
- 集合5: この時点で残っているものは、たいていがスパムです (多分、送信者が特定されないように、ヘッダーが偽造されています)。
スパムを選別するためのかなり強力な手法に、私が「ホワイトリスト＋自動照合 (whitelist plus automated verification)」法と呼んでいるものがあります。ホワイトリストと照合の組み合わせを実装しているツールには、いくつかのものがあります。TDMAは、マルチプラットフォーム、オープン・ソースのツールとして人気がありますし、ChoiceMailは、Windows用として商品化されているツールです。その他のものは、ほとんどがまだ正式版には到っていないようです。(各製品へのリンクは、稿末の参考文献 を参照してください。)
ホワイトリスト・フィルターは、MTAと連携して、明示的に承認された受信者からのメールだけを受信トレイに渡します。それ以外のメッセージの場合、特別な呼掛け応答が送信者に送られます。ホワイトリスト・フィルターの応答には、ハッシュやシーケンシャルIDなど、元のメッセージを識別するための何らかの一義的なコードが書き込まれます。この呼掛けメッセージには、ホワイトリストに登録するために返信してほしい旨の指示が、送信者に対して示されます (その応答メッセージには、ホワイトリスト・フィルターが生成したコードが含まれていなければなりません)。ほとんどすべてのスパム・メッセージは、返信アドレス情報を偽造していますので、この呼掛けは、通常、どこにも到着しません。また、たとえ有効な返信アドレスを提示しているスパマーであっても、この呼掛けに応答することはないでしょう。正当な送信者がこの呼掛けに応えた場合、そのアドレスはホワイトリストに登録され、その後同じアドレスからのメッセージは、自動的にフィルターを通過するようになります。
私自身は、これらのツールを実験的にしか使用したことがありませんが、ホワイトリスト / 照合フィルターは、スパム・メッセージをほとんど100%ブロックしてくれるだろうと思います。スパマーが呼掛け応答を彼らのシステムに登録し始めることも考えられますが、それに対しては、呼掛けを少し高度なものにすることで対策を講じることができるでしょう (たとえば、人手を使ってコードに少し変更を加えるように要求するなど)。また、応答してくるスパマーは、彼らに対して法的な手段に訴えようと考えている人々からすれば、追跡を容易にしていることになります。
ホワイトリスト / 照合フィルターが抱える問題は、正当な送信者に余分な負担をかけるという点です。送信者の中には、何らかの理由で呼掛けに応答し損なう人もいるでしょうから、この点では、誤検出の種類を増加させています。最善の場合には、正当な送信者に求められる余分な手間はわずかですが、次のような送信者は、その正当なメッセージを送り届けてもらえない可能性があります。すなわち、ISPが当てにできない、ファイアウォールに癖がある、複数のメール・アドレスを使っている、英語 (あるいは呼掛けの記述される言語) を母国語のようには理解できない、あるいは単に呼掛けを見落としたり、呼掛けに手間をかけることができない、などの人たちです。さらには、正当な「送信者」が人ではなく、呼掛けに応答することのできない自動応答システムであることもあります。ホワイトリスト / 照合フィルターでは、メーリング・リストへの参加、オンライン・ショッピング、Webサイト登録などの「ロボット通信」に対応するために、余分な手間がかかりそうです。
スパムは、その定義からして、ほとんど大量の受信者に向けて送信されます。また、実際問題として、個々の受信者ごとにスパム・メッセージをカスタマイズするということは行われません。これに対して、スパムの受信者は、前もってフィルターをかけていなければ、スパム・メッセージを除去するために自分で「削除」ボタンを押す必要があります。分散型ブラックリスト・フィルターは、一人のユーザーが削除ボタンを押すと、他の何百万ものユーザーに、そのメッセージがスパムであることを警告として知らせるようにできるというものです。
RazorやPyzorなどのツール (参考文献参照) は、判明済みのスパムの要約を保存しているサーバーと連携して作動します。メッセージがMTAで受信されると、分散型ブラックリスト・フィルターが呼び出され、そのメッセージが既知のスパムであるかどうかがチェックされます。これらのツールは、統計的手段を巧みに利用して要約を作成していますので、スパムをわずかに変化させたり、自動的に変化させたりしたとしても (あるいは単に配信ルートのせいでヘッダーが異なっていたとしても)、メッセージの識別を誤ることはありません。また、分散型ブラックリスト・サーバーの管理者は、しばしばスパム収集を目的とした専用の「蜜つぼ」アドレス (正当な通信用には決して使われない) を用意します。私がテストしたところでは、Pyzorがスパムを誤検出することはまったくありません でした。Razorなど他の同様のツールを使った場合でも、誤検出が発生することはないだろうと思います。
これは、ある程度理屈で理解できることです。悪意をもつ人がいて、正当なメッセージをスパムと誤診させようと思ったとしても、私 の正当なメッセージのサンプルを、わざわざサーバーに報告しようとはしないでしょう。通常、広く配布されるのはスパム・メッセージだけだからです。developerWorksのニューズレターなど、広く配信される正当なメッセージが、誤って報告されることも考えられます が、分散型ブラックリスト・サーバーの管理者は、ほぼ確実にこれを検出し、即座にそうした問題を修正することでしょう。
ただし、後出の一覧表 に示すように、分散型ブラックリストを使う場合、見逃しは、私のテストした他のどの手法の場合よりも、はるかによく起こります。Pyzorの作者たちは、このツールを、単一の防御線として使うのではなく、他の手法と連携させて 使用することを推奨しています。これは、理に適ったことではありますが、そのようにフィルターを組み合わせることで、実際に、他の手法だけの場合よりも、ずっと多くのスパムを識別できるようになるのかどうかははっきりしません。
また、分散型ブラックリストの場合、照合を行うためにサーバーとのやりとりを行う必要があるため、私のテスト集合に対するPyzorの実行速度は、他のどの手法よりも、はるかに遅いものでした。少しずつ流れるメッセージをテストする場合には、これは大した問題ではありませんが、大量のメッセージを扱うISPでは、これは問題となりかねません。また、照会1,000回につき何回かのネットワーク・タイムアウトが起こることもわかりました。そのため、私のテスト結果には、「スパム」または「正当」として識別されずに「エラー」となっているものがいくつかあります。
ルールに基づいてスパムを選別するためのツールとして最も人気の高い製品はSpamAssassin であり、他にかなりの差をつけています。他にもツールはありますが、この製品ほど広く使用されていませんし、活発な維持管理も行われていません。SpamAssassin (や同様のツール) は、対象メッセージに対して、数多くのパターン (ほとんどは正規表現) を評価します。あるパターンは、一致するとメッセージの得点を加算し、その他のものは減算します。メッセージの得点が一定の閾値を超えると、スパムとして選別されます。そうでなければ、正当なメールとみなされます。
ランキング・ルールの中には、時間の経過にかかわらず、ほとんど不変のものもあります。たとえば、偽造されたヘッダーや自動実行されるJavaScriptがあれば、ほとんどどんなときでも、スパムとみなされます。それ以外のルールは、スパマーが新たに開発する製品や手口の進化に合わせて、更新する必要があります。現在、ハーブ・バイアグラ (Herbal Viagra) やアフリカの独裁者の遺産相続に関するスパムが猛威を振るっていたとしても、明日には、蛇オイル薬とかポルノ関連の新手の話題を扱うスパムによって駆逐されてしまうでしょう。スパムの進化に伴い、SpamAssassinも、それに対応するべく進化する必要があります。
SpamAssassinのREADMEには、次のような非常に強い調子の宣伝文句が並べられています。
最新のテストで、SpamAssassinは、スパム・メールと非スパム・メールを99.94%の正確さで峻別しています。その後も、この正確さは、どんどん向上しています。
私が行ったテストでは、この成功率にはほど遠い結果が出ました。私のメール集合に対して、SpamAssassinは、約0.3%の誤検出を示し、なんと19%の見逃しを示しました。公正を期しておくと、これは、ルール・ベースのフィルターを評価しているだけで、オプションとして可能な分散型ブラックリストに対するチェックを評価したものではありません。また、私のスパム集合は、純粋なスパムではありません。その中には、ウィルスを含んでいるだろうと思われるメールも多数含まれています。(私は、それらのメールを開いて確認したわけではありませんが、私が正当だと認めたメッセージでないことは確かです)。SpamAssassinのFAQでは、ウィルスの検出には対応していないと断っていますが、以下で紹介する手法は、ウィルスの検出に、はるかに高い効果を発揮していますので、この断り書きは、それほど説得力がありません。
SpamAssassinは、ネットワーク・サーバーに照会する必要のある分散型ブラックリストよりも、はるかに高速に実行します。ただし、以下の統計モデル (インタープリター型Pythonで記述され、単純なデータ構造を使っている) と比べると、その非最適化バージョンと比べた場合でも、SpamAssassinの実行速度は、やはり非常に遅いほうです。SpamAssassinの長所・短所については、Stamp out spam with SpamAssassin (developerWorks、2002年9月) でも紹介されています。
Paul Grahamが、2002年8月に刺激的なエッセイを書いています。A Plan for Spam (稿末の参考文献参照) で、Grahamは、スパム単語と非スパム単語のベイズ確率モデルを構築することを提案しています。数学的な背景については、私が以下で行う説明よりも、Grahamのエッセイや統計・確率に関する一般的な教科書を読むほうがよいでしょう。
要するに、ある種の単語は、判明済みのスパムに高い頻度で出現するのに対して、別の単語は、正当なメッセージに高い頻度で出現する、ということです。よく知られている数学的方法を用いることで、各単語の「スパム指標確率 (spam-indicative probability)」を生成することができます。また、別の簡単な数学の公式を利用すると、新しいメッセージの全体的な「スパム確率」を、そのメッセージに含まれる単語集合に基づいて求めることができます。
Grahamの考え方には、いくつか注目すべき特長があります。
- 人手を使ってルールを作成しなくても、分類されたメッセージ集合から自動的にフィルターを生成することができる。
- それぞれのユーザーのスパム・メッセージと正当なメッセージの特徴に合わせて、カスタマイズすることができる。
- ごくわずかな行数のコードで実装することができる。
- 驚異的な効果を示す。
一見すると、SpamAssassinで使われるルールのような人手で丹念に作成したルールのほうが、自動化された手当たりしだいの方法よりも、スパムを正確に予測するだろうと考えるのが自然かもしれませんが、この推測は、まったくの誤りであるということになります。統計モデルは、基本的に、ルール・ベースの方法よりも優れた性能を示します。また、副次的な特長として、Grahamスタイルのベイズ・フィルターは、SpamAssassinよりも単純で高速です。
Grahamの記事が公表されるや数日のうちに、ひょっとしたら数時間のうちに、数多くの人々が一斉にこのシステムの実装にとりかかりました。私の行ったテストには、私とメールで意見交換をしているJohn Barhamという人が作成したPython版を使用しました。このプログラムを提供していただいたJohn Barhamに感謝します。といっても、数学的には非常に単純なもので、他のプログラムも、すべて、ほぼ同等の実装内容になっています。
データ構造とデータ保存の手法には、いろいろなツールの動作速度に関係してくる問題がいくつか存在します。ただし、実際の予測精度を左右するのは、ごくわずかな要因だけです。重要な因子は、多分、使用される単語の字句解析手法で、主にランダムに見える文字列を排除することに関係します。Barham版は、単に、小さな集合 (英数字と数個の文字) に含まれる比較的短い互いに素な文字列を検索するだけです。
単語モデルを基礎とするベイズ法は、かなり有効な働きをしますが、単語モデルの1つの欠点は、メールに含まれる「単語」数が、ほとんど無制限であるという点です。このことは、直観的にはわかりにくいかもしれません。ほとんどすべての英単語が含まれるようになれば、漸近線に達すると考えるのが、理屈に合っているように思われます。全文検索について私が以前に研究した結果によると、これは正しくないことがわかっています。「単語に似た」文字列の数は、ほとんど無制限に存在し、新しいテキストを扱うたびに、新しい文字列が生成され続けます。これは、Message-IDやコンテント区切り子、UUやbase64といったエンコード指定などのランダムな文字列を含んでいるEメールの場合には、とくにそういうことが言えます。モデルから単語を排除するのには、いろいろな方法があります (中でも最も簡単な方法は、出現頻度の充分に低い単語を排除するやり方です)。
私は、さらに一層明確にモデル・スペースを限定した場合、ベイズのスパム・フィルターで、それがどの程度有効なのかを調べることにしました。具体的には、確率モデルに「単語」ではなく三連文字を使用することにしました。もちろん、この考えは、まったく独自に考案したわけではありません。言語の認識 / 差異化 (differentiation)、英語の暗号書記法に関する特異性の隔たり (cryptographic unicity distances)、パターン頻度、その他関連する分野についてのさまざまな研究が、三連文字が適当な単位であることを強く示唆しています。
これを試すにあたって、私はいくつかのことを決定しました。最大の選択は、どんな三連文字にするかという点でした。三連文字は「単語」を識別するよりもいくらか単純ですが、3バイトのすべての (重複する) 順列を調べるというまったく素朴な方法は、最適とはいえません。とくに、上位ビット文字のことを考慮すると、これはマルチバイト文字セット (すなわちCJK) で比較的頻繁に起こることですが、ASCIIの範囲だけをカバーすればよい場合に比べ、はるかに大きな三連文字スペースが要求されることになります。三連文字のスペースを下位ビット文字よりもさらに制限したものにすると、スペースは小さくなりますが、全体的な結果は向上しません。
私は、三連文字分析を行うにあたっては、メッセージ分類ツール (message categorizers) として、最も高い効率で差異化を行う三連文字だけを利用しましたが、結局、「スパム」三連文字および「正当」三連文字に選択した数は、試行錯誤によってしか決定できませんでした。また、スパムのカットオフ確率は、かなり恣意的に選択しました。私は、「正当」集合に含まれるメッセージに、.99の範囲の2個の誤検出を除き、.0071以上のスパム確率が与えられることはないという面白い発見をしました。ただし、カットオフを最初の0.9～0.1よりも下げることで、「スパム」集合に含まれるメッセージを何個か多く捕捉できるようになりました。速度の面から、私は、各候補メッセージから「興味深い」三連文字を100個しか選択しませんでした。この100という数を変えると結果に若干の変動がみられます (が、明確な傾向は認められません)。
以上、テストの方法論を説明してきたところで、具体的なテスト結果を見てみることにします。速度に関して数量的なデータを示していませんが、表は、速度の速い順に並べてあります。三連文字が速く、Pyzor (ネットワーク検索) が遅いということです。すでに説明したように、各手法の評価では、誤検出は非常に悪い結果であり、見逃しは、少しだけ悪い結果であると考えます。各コマの数値は、正当なEメールの集合およびスパム・メールの集合に対して、それぞれの手法で正しく識別されたメッセージの数vs. 間違って識別されたメッセージの数を表しています。
表1. スパム・フィルター手法の数量化した精度
| 手法 |
正当なメッセージ集合
(正しく識別された数vs.誤検出の数) |
スパム集合
(正しく識別された数vs.見逃しの数) |
| 「実際の数」 | 1851 vs.0 | 1916 vs.0 |
| 三連文字モデル | 1849 vs.2 | 1774 vs.142 |
| 単語モデル | 1847 vs.4 | 1819 vs.97 |
| SpamAssassin | 1846 vs.5 | 1558 vs.358 |
| Pyzor | 1847 vs.0 (エラー4個) | 943 vs.971 (エラー2個) |
-
Tagged Message Delivery Agent については、TDMAのホームページに詳しい情報が示されています。
- DigitalPortal Software社のChoiceMail に関する詳しい情報。
-
Pyzor は、Pythonをベースにした分散型のスパム・カタログ / フィルターです。
- Vipul社のRazor は、非常に人気のある分散型スパム・カタログ / フィルターです。Razorは、SpamAssassinなどの他の数多くのフィルター・ツールから呼び出すこともできます。
-
SpamAssassin は、最も人気のあるルール・ベースのスパム・フィルターです。Stamp out spam with SpamAssassin (developerWorks、2002年9月) でも紹介されています。
- Paul GrahamのエッセイA Plan for Spam。
- Eric Raymondは、Paul Grahamのアイデアをbogofilter という名前の高速なソフトウェアとして実装しています。bogofilterは、データ表現やデータ保存にいろいろと効率のよい方法を採用している他、意味のある単語構成を判定するのに巧妙な方法を試しています。
- 私自身が開発した三連文字ベースの分類ツール群は、初期段階のアルファ版レベルあるいはプロトタイプ・レベルにすぎませんが、これを皆さんの開発の下敷きに利用していただければ幸いです。これらのツールは、私がdeveloperWorks の記事用に開発したすべてのツールと同様、パブリック・ドメインです。
- Lawrence Lessigは、彼が換喩法によって「西海岸のコード」と「東海岸のコード」と呼んでいるもの、すなわちワシントンD.C. (など) で制定される法律とシリコン・バレー (など) で記述されるソフトウェアを、洞察力あふれる方法で対比する数多くの書籍や記事を執筆しています。LessigのCode and Other Laws of Cyberspace について私が書いた短い書評も参考にしてください。これについてもっと深く考えてみたい方は、LessigのWebサイトを訪れてください。
- developerWorks のLinuxゾーンには、他にもLinux関係の記事が多数掲載されています。
