Context Navigation

日本語ルールについて

快適な SpamAssassin 生活を送るためには、ルールも重要です。せっかく日本語化パッチをインストールしたので日本語ルールも記述したいところです。また、日本語化パッチ固有の問題もありますので、その辺を交えながら解説したいと思います。
日本語の情報源リソースとして日本SpamAssassinユーザ会の滝澤さんが書かれた解説も参考にしてください。日本語パッチを当てたので、ルールを UTF-8 で記述します。UTF-8で編集可能なフリーなエディタとしては、サクラエディタなどがあります。UTF-8 ですが、BOM 無を選択してください。
日本SpamAssassinユーザ会では、協力者が不足しております。どのような形（翻訳・日本語ルールの整備・ホームページのメンテナンス・日本語パッチ改良＆テスト・サポート＆広告）でも協力していただけると嬉しいです。と、ここでさりげなく宣伝…。

日本語ルール 3.1.x 系統の話

現行ルールは処理の関係上、メールヘッダのパートを内部的にJISコードで処理しているため、@ 等のコードが漢字の"斉"等に含まれるといった弊害もあります（将来的にはUTF-8で内部処理されるようになると思われます）。日本語化パッチの独特の記法で、これらの問題に対処すべき場所ではSpamAssassin既存の記法に加えて :raw という書き方をしなければなりません

具体的には、日本SpamAssassinユーザ会で配布されているルールにおいて

header TW_MULTI_FROM From =~ /\@.*\s+.*\@/ 
describe TW_MULTI_FROM Fromに複数のアドレスがある 
score TW_MULTI_FROM 4.3

ではなく、

header TW_MULTI_FROM From:raw =~ /\@.*\s+.*\@/ 
describe TW_MULTI_FROM Fromに複数のアドレスがある 
score TW_MULTI_FROM 4.3

とします。

ルールには、件名を判定する部分 Subject = ... というものもありますが、これもJISコード問題を考慮するならば同様に Subject:raw とします。

日本語ルール 3.2.x 系統の話

本家に normalize_charset のパッチが取り入れられたので、3.1.x 系統とは状況が変わっています。 normalize_charsetオプションを有効にすると、文字列がUTF-8の文字列になるため、3.1.x で頻出していた ISO-2022-JPのバイト文字列が不用意に標準のルールにマッチする問題が無くなりました。:raw という記法は無くなりました。再定義すべきルールを列挙します。

# Fromヘッダで日本語を使う人が当たり前にいるので必須
score FROM_EXCESS_BASE64 0
# 生JISヘッダを許容するのであれば以下を追加
score SUBJ_ILLEGAL_CHARS 0
# 今後、UTF-8の日本語メールが増えてくることを考慮する場合には以下を追加
score MIME_BASE64_TEXT 1.0
# 署名の整形のためにスペースを多用しているとTVD_SPACE_RATIOにマッチ
# するので、下記ルールを追加
score TVD_SPACE_RATIO 0

と解説しましたが、こちらからぶっこ抜いて下さい。SubVersionでは http://www.hunes.co.jp/oki/repository/xmspamc/trunk/rule-jp/ を指定して下さい。

差障りのない範囲でルールのメンテをしています。が、ルール適応時には、

$ spamassassin --lint

で、チェックしてください。2008/3/12 現在の状況では、ヘタレな日本語スパムは、ほぼ完全に取り除けています。

sa-learn

ベイジアンのデータベースに対して、spamメールとhamメール（スパムでないメール）の学習を行わせるためのツールです。使い方を説明する前に SpamAssassin?でのベイジアンに関する動作をいくつか列挙します。

BAYES_99(スパムワード確率により99%スパムである)といるルールが有効に働くためには、ham, spam 双方の学習が一定以上(200件)必要
新たな学習により古い学習は捨てられるといったサイクルが存在する

spam メールの学習は放っておいても進みますが ham メールの学習はなかなか進みません。よって、新規にインストールした直後では ham メールを200通用意して学習させる必要があります。お勧めしていないですが、AWL(auto-whitelist)を有効にするというのも手です（これにより自動的にスコアが上下する）。メールを1通づつ学習させるのは骨が折れるので、mbox 形式に出力して学習させましょう。メーラがOutlookExpress の環境では、mbox 形式にするのも大変です。そこでTietewさんのアーカイブ置き場から OE2 をダウンロードして利用するとOutlookExpressから mbox 形式のデータが取り出せます。

ham メールの学習

$ sa-learn --ham --mbox my_ham_mails_mbox

spam メールの学習

$ sa-learn --spam --mbox my_spam_mails_mbox

sa-update

何やら素敵な甘～～い響きがありますね:-)。そうです。その名のとおり、ルールの更新を行ってくれるツールです。一応、初期設定を行う事にしましょう。

$ cd 
$ echo updates.spamassassin.org > channels 
$ sa-update --channelfile channels 

$ echo 26C900A46DD40CD5AD24F6D7DEE01987265FA05B > gpgkeys
$ echo 5244EC45 >> gpgkeys
$ sa-update --gpgkeyfile gpgkeys

これで、定期的に（1週間に1回といったペースで）sa-updateを実行し、

$ sa-update

うまくいかない場合は、

$ cd
$ sa-update --channelfile channels --gpgkeyfile gpgkeys

としてみてください。 SpamDaemon?サービスを再起動させれば

こちらは、コマンド・プロンプト

C:\> net stop "XMail Server"
C:\> net stop SpamDaemon
C:\> net start SpamDaemon
C:\> net start "XMail Server"

バッチシです。

やはり環境によっては、gpg の場所を探してくれません cygwin では gpg でええんです。sa-update を修正してください

$ chmod 666 /bin/sa-update

 # bug 4958: for *NIX it's "gpg", in Windows it's "gpg.exe"
  $GPGPath = '/bin/gpg';
  #$GPGPath = 'gpg' . $Config{_exe};
  dbg("gpg: Searching for '$GPGPath'");

  #if ($GPGPath = Mail::SpamAssassin::Util::find_executable_in_env_path($GPGPath)) {
  #  dbg("gpg: found $GPGPath");

    # bug 5030: if GPGPath has a space, put it in quotes
  #  if ($GPGPath =~ / /) {
  #    $GPGPath =~ s/"/\\"/g;
  ##   $GPGPath = qq/"$GPGPath"/;
  #    dbg("gpg: path changed to $GPGPath");
  #  }
  #}
  #else {
  #  die "error: gpg required but not found!\n";
  #}

$ chmod 755 /bin/sa-update

それでもうまくいかない場合があるかもしれません。やけっぱちで

$ sa-update --channelfile /home/Administrator/channels --nogpg --update-dir /var/lib/spamassassin/rules --debug

とやって、/var/lib/spamassassin/rules を確認してください。nogpg は、署名を確認しないのでリスキーです。

`AutoWhiteList`

SpamAssassinの運用を続けていくと、スコアがとてつもなく大きくなったりしますが、その原因は、このルールです。

このルールは、少々変です。仕掛けは、送信者のメールアドレスをみて、スパムと判定されれば、その送信者に対してスコアを上げるように調整し、非スパムと判定されれば、逆にスコアを下げる（マイナス方向へ）という働きをします。ここから本題に入りますが、そもそも送信者なんて信頼できるの？って部分が重要になってきます。このルールの様子を見てきましたが、概ねは合意できますが、このルールをターゲットに送信されているスパムが存在するのか、何割かは見当違いもはなはだしいスコアを叩きだす事があります。

これって、やっぱ変じゃないの？と思ってたら、同様に考えている方はあちこちにいるようで、このルールは無効にしたほうが幸せになれると思います。結局、このルールは、定期的にメンテナンスが必要です。というよりも、AutoWhiteListをメンテナンスするぐらいならホワイトリスト・ブラックリストをメンテナンスした方が、いくらかマシってもんでしょ。正直、このルールには悩まされっぱなしです。

http://mm.apache.jp/pipermail/spamassassin-jp/2006-May/000231.html ここでは、RFC違反なメールアドレスに対して誤認識をするというお話が載っています。これを解決したとしても、送信者の正誤判定なんて不可能ではなんて思います。

http://wiki.apache.org/spamassassin/AwlWrongWay ここでは、スコアを平均する過程の説明があります。しかし、ミス判定された場合には修正が必要であり、そういうメールアドレスは、ちゃんとホワイトリスト・ブラックリストにしなさいと書いてあります。

このルールを無効にするためには、user_prefs ファイルに

use_auto_whitelist 0

の１行を書き加えます。user_prefs （拡張子は無し）は、.spamassassin フォルダ下に作成してください。試してないけど、my_rule.cf って、拡張子(cf)なファイルを /etc/mail/spamassassin に作成して、そこに書いてもOKなんでしょうか…。

Download in other formats:

Plain Text