汚し飯

_ [spam] SpamAssassinに関する雑記

ここ数年に渡り考えて来た、SAに関する私なりの考えを記します。
SAの運用やルールの作成等の参考になれば幸いです。

SAを使っている人の多くは、「SAは機能が豊富である」と言われます。
また、「SAは調整次第で精度が上がる」とも言われます。
ただ、何がSAの核なのか、という問に対する答えを明確に持っている方は余り多くないように見受けます。
SAの本質は、ヒューリスティックなルールベースのフィルタです。
ベイジアンも、DNSBL/URIBL/Razor2等/SPF他も、手作業で作成されたルールを補完する要素でしかない、と、私は思っています。
勿論、スコアリングを調整して、ヒューリスティックルールを全部殺して、ベイジアンとDNSBL/URIBL/Razor2等/SPF他だけの組合せにしようと思えばできなくもないでしょう。
しかし、SA開発グループは sa-update というコマンドを定期的に実行することを推奨しています。
このコマンドによって、新たなspamに対抗する新しいルールが追加され、古くなったルールは破棄されます。また、一部のルールではスコアリングの調整も行われます。
したがいまして、本家ルールの大部分がヒューリスティックルールで構成され、これが頻繁に更新される以上、手元でルールを作成し、調整する行為を否定する発言は的を得ていません。SAの本質を見誤っている見解であると思います。

本家ルールは殆どが非日本語圏に属する開発メンバーの手で構成されており、日本特有の事情がルールに反映されていないことは明白です。
ここで私が言いたいのは、「だから松田作tlecルールを使え」ということではありません。
本家ルールを無調整で使う行為は、少なくとも日本特有の事情が反映されていないspamフィルタを使うことと同義であり、自分の手元に適応させるための、何らかの微調整を行うのが好ましい、と、私は主張します。
この「日本特有の事情」は、何も日本語spamだけを指すのではありません。
一例を示します。
日本のISPではOP25Bが普及し、この1〜2年の間に、国内ISPから発されるspamが激減しました。
現在、私の手元で確認する限りにおいて、spamの最大の供給源は、中国CNCGROUPです。
CNCGROUPが発するspamの量は、米国全体のspamを遥かに凌駕します。
以下、タイLOXINFO、中国HUARUI、韓国XPEED(POWERCOM)、中国SGATHERと続きますが、CNCGROUPとこれ以下とでは、spam被弾数が桁違いです。
以下のリストは、先程40日分のspamを集計した結果の一部抜粋です。

    453  1.5 SGATHER_CN             [CN]Beijing HeJu ShuZi Telecom Engineering Co.Ltd.
    458  1.5 XPEED_KR               [KR]POWERCOM
    469  1.5 HUARUI_CN              [CN]Langfang Development Area Huarui Xintong Network
    650  1.5 LOXINFO_TH             [TH]Loxley Information Company Ltd.
   4893  1.5 CNCGROUP               [CN]Japanese spammer's footstool: CNCGROUP

恐らく、この傾向は、非日本語圏の住民の場合では異なる可能性が大きいと思います。
事実、米国発spamの場合、ケーブルTV系ISP発spamが上位を占めています。
こういった、spam発信源の傾向を考慮してルールを工夫する方策は、無意味ではないと思います。

拙作ルールは、国内ISPとアジア系ISPのIPアドレスのリストが多くを占めています。
DNSBLがあるのに何故無駄なことをするのか、と思う方も多いかと思います。
このような、第三者から見れば無謀とも無駄とも思えることを実行し続けている理由を説明します。
「大石オブジョイトイspam」の頃、日本語spamをどう引っかけるかで悩んでいた時です。
当時、日本語キーワードの選定に物凄く悩んでいました。
spamに現れる特有のキーワードは、日常会話でも良く使うものが多く含まれています。
更に、キーワードに対するルールマッチングはいたちごっこであり、実際にルールを反映させた翌日には対策されていた、などという経験を何度もしてきました。
かといって、キーワードを多く登録すればする程、 false positive 、つまり誤検出を多く頻発してしまい、どうにもなりません。

ところで、これらspamはその殆どが動的IPからダイレクトに受信側MTAに送信されます。
spamが発されると、これを受信した人の中で、ボランティア活動をしている人が、DNSBLにそのspamの発信源IPアドレスを登録します。IPが登録されると、以降のDNSBLユーザはspam発信源IPであることを知ることができます。
しかし、動的IPは接続/切断を繰り返すことで容易に変えることができます。
つまり、DNSBLを待っていても、spamを被弾する可能性は高いのです。逆に言えば、DNSBLは動的IPに対して無力とも言えます。
そこで私は考えました。
ならばいっそのこと、最初から動的IPであるか否かを判断できるようにすればいいんじゃないか。
キーワード自体のスコアは低く設定しておく。
動的IPであるか否かの判断のスコアも低く設定しておく。
動的IPから発されたspamのキーワードのスコアはmetaルールで嵩上げする。

問題は、動的IPの判断です。
最初は、「阻止率99%〜」のやり方に近い方法、つまり正規表現で動的IPのFQDNを引っかける方法を模索しました。
しかし、この方法はYahoo!JapanのMTAが送信元IPのFQDNを逆引きしてくれないことが判明し、すぐに破綻しました。
私は、あくまでも個人ユーザの目線で、できるだけ多くの人が使えるルールの提供を目的としています。
自分でMTAを運用することの難しさを見聞きし、自分がその実力に至らないことや、時間的経済的余裕がないことも考慮して、自分専用MTAを構築していません。
spamを避けるために自分専用のドメインを取得し、自宅サーバをMTAに仕立てて、MTAでspamを弾くような、極少数派の人達にのみ適合するようなルールを書くつもりはありません。
以上のような経緯で、送信元IPアドレスそのものを正規表現で引っかけるしか手立てがない、という結論に至りました。
動的IPのリストをISP毎に登録したのは、ISPによって対策がまるで違う、という話が広まっていたことと、長い正規表現を書くのは非常に大変で、まとめることは好ましくないと判断したこと、ISP毎の集計ができると後で面白いだろうと考えたことに因ります。
登録するISPを国内とアジア圏に絞ったのは、流石に全世界のISPを登録するのは無理だろうと思ったこと、日本語spammerの傾向に、特定のISPを繰り返し使っていることが判明したことに因ります。つまり、ルールを書き始めた当初、日本語spammerはまだspambotを多用しておらず、律義に現地ISPと契約してspam発信を行っていたと思われる傾向があったのです。
そして、その殆どが近隣のアジア圏ISPに集中していました。
結果として、この試みはうまく行きました。
DNSBL未登録のIPアドレスから発された日本語spamを、効果的に引っかけることに成功しました。

暫くルールを運用しているうちに、この動的IP検出ルールは、キーワードに留まらず、他のルールとのmetaルールにも応用できる、ということが判って来ました。
Razor2やURIBLとのmetaは勿論、普通のヒューリスティックなルールにもmetaして、スコアを上げることができることが判りました。
更に、DNSBLにも応用できることも。
動的IP検出ルール自体は、かなり乱暴でメンテナンスも乱雑なDNSBLと同じように見えますが、「spamらしさ」を示す一定のスコアを与えることができます。それ単体が微々たるスコアであっても、他の視点で登録されたDNSBLとmetaすれば、「spamらしさ」が格段に向上します。
これら現象を基に考えるうちに、私は一つの結論を導きました。
「「spamらしさ」というスコアは、実は加算ではなく、乗算ルールである」と思います。
SAのuser_prefs或はlocal.cfでDNSBLを複数登録する行為は、「spamらしさ」を判断する観点を複数導入することと同義であり、この点において無駄ではないと思います。

DNSBLの話で、一つ思い出したことがあります。
DNSBLのスコアを単独で高めに設定する行為は危険であるとも思います。
そのDNSBLがどんなに運営体制が素晴らしく、評判の良いものであったとしても、です。
実際に、本家ルールが新しいDNSBLを高いスコアで導入し、誤検出を招いた事例が、私の手元でありました。
よほどのことがない限り、一つのルールに高めのスコアを与える行為は危険です。
DNSBL/URIBL/Razor2のような、有象無象のコントリビュータによって登録されるデータであるなら尚更です。

しかしながら、以上の試みはあくまでアジア圏発のspamが幾つかのルールに引っかかったときに有効であり、そうでないspamは見事にすり抜けてしまいます。その特徴は:

• 日本語spam「ではない」
• アジア圏発spam「ではない」(ARIN|RIPE_NCC|LACNIC|AFRINIC)
• DNSBL/URIBL/Razor2等に登録されていない
• その他、ヒューリスティックなルールに引っかからない

以上の条件を全て満たすspamは、拙作ルールでは対処できません。
一番これに該当するのが、spambotを用いた英語圏spamです。
今の私には、これに対抗する抜本的な対策案を持っておりません。
仕方がありませんので、これについては私の場合、bogofilterをSAの後続に配することで、何とか誤魔化しているところです。

「SAのベイジアンのスコアを上げればいいじゃん」と思う方もいらっしゃるかも知れません。
しかし、私はSAのベイジアンフィルタはあまり信用していません。
むしろ、あってもなくても変らないのではないかとさえ思っています。
周知の通り、ベイジアンフィルタは学習アルゴリズムです。
「spamらしさ」「hamらしさ」を、スコアで決定します。
学習サンプルは、spamと、非spam、つまりhamです。
学習アルゴリズムは、真偽を示すある現象(目的変数)を持つサンプルが、それぞれおおよそ同数近くあることを前提にしています。
もし、hamが極端に少なく、spamを大量受信するような状態が続くと、ベイジアンフィルタはどうなるでしょうか。
素人考えでも、学習結果が大幅にspam側に偏ってしまい、hamを誤検出する可能性が却って高まってしまう虞があります。
事実、私の手元のSAのベイジアンエンジンは、しょっちゅう false positive を出力してしまいます。
spamを大量に捕捉して分析するために、約700通/日、時には900通以上のspamを被弾する私の場合、もはやSAの false positive を改善することは、件数的に無理です。
ベイジアンフィルタは、実は手間の掛かるフィルタであり、その仕組み自体が誤検出の危険性を潜在的に孕んでいるフィルタであると思います。

SAのベイジアンフィルタについては、もう一つ問題点があると思います。
それは、メイルから抽出した単語の、文字コード及び言語が学習の対象(説明変数)から外れている、という点です。
一例を挙げます。
日本語spamの場合、ISO-2022-JP(いわゆる7bitJIS)のspamがある一方で、Shift_JISのspamをかなり多く見かけます。
同じキーワードであっても、Shift_JISの場合、spamの確度が極めて高い、と言えます。
同じことは、ヘッダのSubject:にも言えます。
ところが、異なる文字コードをUTF-8で正規化してしまうと、spamの確度に大きな影響を及ぼす文字コードの情報が失われてしまいます。
学習の要素には、単語の文字コードと言語を含めて、学習すべきだと思います。

SAについてもう一つ問題点を挙げるなら、AWL(Auto White List)があります。
自分が自分宛に出したメイルを誤検出し、これを是正しようとすると、逆に From: に自分のメイルアドレスが記述された spam を素通ししてしまいます。
AWLは暫く試行錯誤しましたが、全く改善されませんでした。
AWLを切ったら、全く問題点は出なくなりました。
つまり、From:やTo:はspam判別には全く役に立たないばかりか、下手に判別要素に組み入れると却って判断を狂わせるのです。
断言します。
SAのAWLは百害あって一利ありません。
AWLは切って運用することをお薦めします。

SAの開発体制にも、幾つか不満に思うことがあります。
一つは、SandBoxと呼ばれる、ルールのテストシステムです。
以前、私は本家にルールを提案したことがあります。
しかし、それはスコアが低く出てしまいました。
false positiveが多い、とのことでした。
どのようなメイルでfalse positiveが発生したのか、そのメイルを見せて欲しいと申し出ましたが、却下されました。
どうやらSandBoxは有志の手によって集められたメイルの集合体であるようで、中身を見せる訳には行かないようです。
しかし、ならば何故最初から見せても良いメイルを集めなかったのでしょうか。
false positiveを防ぐには、その原因をトレースできなければデバッグができません。
慣れない英語のメイルのやり取りが続き、読み解くのに疲れ果て、それ以上追求するのを諦めざるを得ませんでした。
その一方で、明らかに思慮の足りないルールが本家ルールとして上がって来るケースも散見します。
私は、本家はSandBoxの運用を見直すべきだと思います。

本家MLに何度か投稿したことがあるのですが、どんな内容であっても、英語が駄目だとことごとくスルーされるようです。
こればかりは悔しいと言わざるを得ません。

本家webサイトですが、良く見ますと、文書関係は殆ど更新されていません。
一例を挙げますと、MS-WindowsにSAをインストールすることを記述したInstallingOnWindowsという文書ですが、SAwin32の記述が未だになされていません。
3.2.5がリリースされたのは2008年6月12日のこと。既に半年以上を経過しています。
開発の中心メンバーは、意欲を失いつつあるように見受けます。

既にお気付きの方も一部にはいらっしゃるかと思いますが、SAとは別のユーザコミュニティで、SAのルールを更新して提供するサイトがありました。「SpamAssassin Rules Emporium」というサイトです。
ここですが、いつの間にか更新を停止しています。
運用当初は玉石混合のルールではあるものの、システマチックに運用しており、叶わないなぁなどと思っていたのですが、続かなかったんですね。
自慢する訳ではありませんが、私のような酔狂でないと、いつまでも終りのない更新作業を続けることはできないのでしょう。

spamフィルタは、SAは、もう限界でしょうか。これ以上の発展は望めないのでしょうか。
私は、少なくとも一つは方策があると思っています。
一つは、学習フィルタの改良です。
これには二つのアプローチがあります。
一つは、ベイズ推定に代わるアルゴリズムの採用です。
今、一番可能性が高いのが、サポートベクタマシン回帰です。
少ない教師データで、高い推定精度を出力してくれる、とのことです。
もう一つは、学習対象となる単語に、属性情報を追加することです。
現時点では、メイルから切り出した単語にはヘッダか本文かを示す属性情報しかない筈です。
この属性情報に、更に言語コードと文字コードとを追加するのです。
できれば、文字コードの正規化を止めて、あくまでも生のメイルに近いデータを学習データベースに格納する方が望ましいと思います。

_ [spam] SpamAssassinに関する雑記・追記(2009.03.20)

SAに関する情報は少なく、一通り使えるようになるまでに試行錯誤し、更に今の user_prefs を書き上げるまでに試行錯誤を続けて来ました。
自分がやっていれば、自分の user_prefs に不満を持つ誰かが意を決して、もっと良い user_prefs / local.cf を書き上げる人が出て来るだろう、そうしたらその人の成果物をそのまま頂くとしよう、そう目論んで、更新作業を続けて来ました。
ところが、2002年に書き始めて既に7年を経過した今でも、 user_prefs / local.cf を書いて更新し続けてくれる人或は団体が現れる気配がありません。
また、拙作 user_prefs を面と向かって批判する人も現れません。
なお、ここで批判とは、具体的に問題点を指摘し、代替案を提示する言論を指します。
明確な根拠のない誹謗中傷は除外します。
唯一、私の作業にチャチャを入れた人は「俺はそんな非生産的なことは続けたくない」と言いました。
彼程の技術を持つ人なら、その主張は至極当然でありましょう。
逆に言えば、私は彼程の技術力を持ち合わせておらず、故にこの程度のことしかできないのです。
日々の生活の、ホンのちょっとの隙間時間でできる作業です。
大体、毎週末には少し時間を取って更新しますが、それでも長くて2時間程度です。

どなたか、やってみませんか。
私の代わりに、或は私に対抗して、user_prefs / local.cf を作成し、更新し続ける作業。
必要な要件は以下の通り:

• Linux / FreeBSD 等、 POSIX 系 OSが稼働する環境。
• grep / awk 等のフィルタを使いこなすスキル。
• テキストエディタを自由に使えるスキル。
• Perl の正規表現を一通り読み書きできるスキル。
• 終りのない作業を「終りのないRPG」と解釈し、 spammer とのバトルを楽しむ心の余裕。

メイルに限らず、 トラックバック spam 等を含む広義の spam は、ネット上で商活動ができる以上、なくならないと思います。
メイルの spam に限って言えば、現状の SMTP が永続する限りなくならないと思います。
少なくとも、最低5年は、今の SMTP の仕組みが根本的に全く別のものに代わることはあり得ないでしょうから、 spam はなくなりません。
でも、減らすことはできるでしょう。
既に日本国内の ISP から送信される spam は、 OP25B の普及で激減しました。
もはや個人が思い付きで手を染める程簡単には、 spammer にはなれません。
後は、受信しても影響がないようにする環境の普及です。
一つは、受信した内容に引っかからないようにすること。
spammer 及びその背後組織に利益をもたらさないようにすること。
それが詐欺的内容である、という啓蒙活動です。
もう一つは、受信した内容に振り回されないようにすること。
spam によって精神衛生を害されないようにすること。
つまり、 spam フィルタリングです。
未だフィルタリングの手法は決定的なものが現れるには至っていません。
しかし、日本語 spam に限って言えば、だいぶ追い込めたと、私自身は思っています。
より改善されたフィルタリング技術が提案され、普及して欲しいと思います。