Spamassassin writingrules

新しいルールの作成とテスト

これはSpamAssassinのアドオンルールを書くためのわかりやすいガイドです。これは元々MattKettlerによって書かれました。

Why you don't need custom rules

First, this guide assumes you're already familiar with SpamAssassin and already have a working setup. If you don't yet have SpamAssassin running, I'd suggest starting off with the default ruleset. Custom rules are really more for tweaking SpamAssassin to better suit your personal email, and isn't something you generally need to worry about at the start. Most sites run just fine with the default ruleset and no custom rules at all. This guide also assumes you're relatively familiar with basic SpamAssassin configuration options, such as using blacklist_from and whitelist_to. I've tried to keep this guide very simple, and perhaps to a degree that makes it seem too easy. You should realize that this guide is covering material that should be treated as intermediate to advanced configuration, not something you do 2 days after you manage to get SA working for the first time.

カスタムルールが必要な理由

一般的にカスタムルールは必要ありません。デフォルトのSpamAssassinのルールセットは一般的なメールのサンプリングに調整されています。もしあなたのネットワークに来る典型的なメールの種類がコーパスに使われているものと大きく異なる場合、多くの偽陽性や偽陰性を得るかもしれません。ホワイトリスト、ブラックリスト、デフォルトのルールのスコアを調整することは助けになりますが、すべての場合において十分ではないかもしれません。

どこに追加するか

ルールを書き始める前に警告があります。 usr/share/spamassassin "にある.cfファイルにルールを追加しないでください。この警告の理由は簡単です。SAをアップグレードすると（そしてある程度定期的にアップグレードする必要があります）、"/usr/share/spamassin "内の既存のルールはすべて削除され、新しいデフォルトルールセットに置き換えられます。苦労してカスタマイズした内容はすべて失われてしまいます。これらのファイルに変更を加えるのは、次のバージョンのSAで修正されるであろうルールのバグを一時的に修正する場合だけです。 (例えば、CVSでタイプミスが修正された場合、それに合わせて.cfを編集するかもしれません）。では、/usr/share/spamassassinにないルールはどこに置くのでしょうか？ 2箇所あります。どの場所に置くかはSpamAssassinがどのようにセットアップされているか、ルールに何をさせたいかによります：

"/etc/mail/spamassassin/local.cf "はサイト全体にルールを適用するのに適しています。ここに置かれたルールはどのユーザがSpamAssassinを起動しても適用されます。

"~/.spamassassin/user_prefs "は、特定のユーザーがSAを実行したときだけルールを実行させたい場合に最適です。このユーザはSAを実行するユーザであって、メールの宛先To:を指定するユーザではないことに注意してください。 SAをsendmail milterから実行する場合、使用されるuser_prefsはsendmailが実行されるユーザー（通常はroot）のものだけです。サイト全体の設定をしている場合でも、user_prefsを使えば、別のユーザー・アカウントのuser_prefsにルールを追加して、local.cfに追加する前にコマンドラインを使ってテストすることができます。

注意: spamdを使う場合、user_prefsにあるルールはデフォルトでは無視されます。 local.cf "にallow_user_rulesオプションを追加すれば、spamdにルールを守らせることができます。ただし、このオプションを有効にする前に、セキュリティ上の理由からデフォルトでは無効になっていることを知っておいてください。理論的には、悪意のあるローカルユーザーが巧妙な正規表現を使ってspamdを悪用し、root権限を得ることができるかもしれません。現時点ではspamassassinにこの種の脆弱性はありませんが、その可能性はあります。ローカルユーザーがrootをハックしようとしないことを信頼できる場合のみ、この機能をオンにすることをお勧めします。

さて、何が、どこで、なぜ、そしてなぜそうでないのかはもう十分だ。ルールの書き方のメカニズムに話を移そう。

Writing basic rules

Body rules

最初のルールとして、最も単純なタイプのルール、基本的な「body」ルールから始めよう。これらのルールは、正規表現を使ってメッセージの本文を検索し、マッチした場合、対応するスコアが割り当てられます。本文ルールには、本文の最初の行に Subject も含まれます。DumpTextPlugin を参照してください。

基本的な架空のルールを見てみよう：

body LOCAL_DEMONSTRATION_RULE	/test/
score LOCAL_DEMONSTRATION_RULE 0.1
describe LOCAL_DEMONSTRATION_RULE 	This is a simple test rule

このルールは、メールの本文から "test "という文字列を大文字と小文字を区別して検索し、見つかった場合はメールのスコアに0.1を加算します。さて、このルールはルールとしてはとてもシンプルです。 test "だけでなく、"testing "や "attest "にもマッチします。 describe文には、詳細レポートが使用される場合、詳細レポートに表示されるテキストが含まれます（これはSpamassassinバージョン2.5x以降の本文のデフォルト設定です）。

正規表現では、単語の区切り（英数字やアンダースコアでないもの）がマッチするために存在しなければならない場所を示すために \b を使用することができます。

上のルールは、"testing "や "attest "にはマッチしないようにすることができます：

body LOCAL_DEMONSTRATION_RULE	/\btest\b/

このルールは、次のように末尾にiをつけることで、大文字と小文字を区別しないようにすることもできる：

body LOCAL_DEMONSTRATION_RULE	/\btest\b/i
score LOCAL_DEMONSTRATION_RULE 0.1

このルールは、大文字と小文字の組み合わせで、「test」というスペルを何らかの形の単語区切りで囲んだものにマッチする。

Header rules

では、ヘッダー・ルールに移りましょう。ヘッダー・ルールは、メッセージのヘッダーにある文字列をチェックします。最も一般的なルールは、Subject、From、Toのいずれかをチェックするものですが、非標準のものも含めて、あらゆるメッセージヘッダをチェックするように書くことができます。 test "ルールを使って、件名をチェックするルールに変更してみましょう。

header LOCAL_DEMONSTRATION_SUBJECT	Subject =~ /\btest\b/i
score LOCAL_DEMONSTRATION_SUBJECT	0.1

これらのルールでは、=~の前の最初の部分はチェックしたいヘッダー名を示し、残りはおなじみの正規表現である。ヘッダー名自体は常に大文字小文字を区別しないので、上記のルールは、"test "を含む subject: 行、または "test "を含む SUBJECT: 行にマッチする。

From:行やその他のヘッダーをチェックしても、ほとんど同じように機能する：

header LOCAL_DEMONSTRATION_FROM	From =~ /test\.com/i
score LOCAL_DEMONSTRATION_FROM	0.1

このルールは、blacklist_fromができないようなことはあまりできないので、かなり馬鹿げています。通常、From行ルールを作成する場合は、より洗練されたルールを使用するために作成します。しかし、今回はその作り方を説明するとともに、いくつかの句読点文字は正規表現構文の一部であり、文字通りに使用する場合はその前に「 \ 」を付ける必要があることを指摘したいと思います。通常perlの正規表現では.はワイルドカードですが、この例では "test.com "を探し、"testzcom "にはマッチしません。

header LOCAL_DEMONSTRATION_ALL	ALL =~ /test\.com/i
score LOCAL_DEMONSTRATION_ALL	0.1

あまり使われないが、この機能はヘッダー名の大文字小文字を区別してチェックするのにも使える(コロンの後の部分だけでなく、行全体を調べる)。ここで'^'文字を使いたい場合は、行末にmを付けなければならない。

header LOCAL_DEMONSTRATION_WEIRD_FROM  ALL =~ /^FrOM\:/m

Notes about rule scores

それでは "score "コマンドの動作について少し触れておきましょう。

スコアが0に設定されたルールは全く評価されません。
scoreステートメントがないルールは、3または4が真でない限り、1.0で評価されます。
ダブルアンダースコアで始まるルールはスコアなしで評価され、サブルールにスコアを持たせたくないメタルールでの使用を意図しています。
T_で始まるルールは「テスト」ルールとして扱われ、0.01（ほぼ0）のスコアで実行されます。これはルールをテストするときに便利で、ルールを維持するつもりがないと思えばスコアラインを作成する必要がなくなる。

このセクションの最後に、スコアの選択について一言残しておこう。まずは0.1のような、メッセージにあまり影響を与えない非常に低いスコアから始めることをお勧めする。ルールをよく観察し、あなたが望むときに発動し、望まないときに発動しないことを確認してください。それから、より効果を上げるためにスコアを上げ始めますが、やり過ぎないようにしてください。1.0を超えるスコアのカスタムルールは、スパム以外のメッセージに当たらないという確信がない限り、あまり使いたくないものです。また、偽陽性の問題を修正するために、非スパムメッセージにのみマッチするようにルールを書き、負のスコアを与えることができることを覚えておいてください。強い負スコアも少し注意深く扱われるべきですが、それほど深刻ではありません。一般的に、偽陽性は貴重なメールが読み飛ばされる可能性があるため問題を引き起こしますが、偽陰性は些細な迷惑なので、陰性スコアにはもう少し自由度を持たせてもよいでしょう。

Advanced Scoring

score コマンドは1つまたは4つのパラメータを持つことができる。パラメータが1つ（ノルム）しかない場合は、そのスコアが常に使用される。例

score LOCAL_DEMONSTRATION_ALL   0.1

4つのパラメータを持つ：

最初のパラメータは、ベイズ分類器とネットワークテストが使用されていないときに適用されます。
2番目のパラメータは、ベイズ分類器は使用されていないが、ネットワークテストは使用されている場合に適用されます。
3番目のパラメータは、ベイズ分類器は使用されているが、ネットワークテストは使用されていない場合に適用されます。
4番目のパラメータは、ベイズ分類器とネットワークテストの両方が使用されている場合に適用されます。

例:

score LOCAL_DEMONSTRATION_ALL   0.1 0.3 0.3. 0.1

参考

https://cwiki.apache.org/confluence/display/SPAMASSASSIN/writingrules