hacks/mail/迷惑メール対策

2007年12月17日

このエントリーをはてなブックマークに追加

検証サーバの限界…そして次の一手

メインで使用している「お爺ちゃんサーバ」。
その「お爺ちゃんサーバ」のリソースの大半をspamdが使っている。
自分が使用可能な検証サーバが複数あるので、試しにspamdを外部サーバへ切替えてみた。

spamc(procmail)の設定

procmailのレシピ例

:0fw
| /usr/bin/spamc -u spamd -d spamd.example.com
spamdに-dオプションを指定すると、サーバを指定可能。

spamdの設定

設定の詳細は割愛。分かる人にはわかる設定。
自分はdaemontoolsが好きなのでsuperviseとenvdirでプロセスを管理している。
envdirを使うと、共通項目とサーバ固有の設定を分離出来る点がとても良い。

# cat /service/spamd-shared-ro/run
#!/bin/sh
#
# for spamd-ro (read-only)
#

exec 2>&1
sleep 3

PATH=/sbin:/bin:/usr/sbin:/usr/bin

exec envdir ./env sh -c '
  exec /usr/sbin/spamd \
  --siteconfigpath=${SITECONFIGPATH:-/etc/spamassassin/spamd-ro} \
  --helper-home-dir=${HELPERHOMEDIR:-/var/lib/spamd/ro} \
  --username=${USERNAME:-spamd} \
  --groupname=${GROUPNAME:-spamd} \
  --max-children=${MAXCHILDREN:-2} \
  --debug=${DEBUGAREAS} \
  --syslog=${SYSLOG} \
  --allowed-ips=${ALLOWEDIPS:-127.0.0.1} \
  --listen-ip=${LISTENIP:-127.0.0.1}
'
allowd-ipsには接続を許可する元IPアドレスを指定する。
これにより、論理的でも物理的でもいいけど、spamcとspamdを別サーバで動かせる。

効果

[変更前] 作業をしていてストレスを感じる事がたたあった。
 ↓
[変更後] ストレスを感じなくなった。

共用spamd構想

そこそこのスペックのspamdサーバと、
数台のspamcサーバで検証するのはどうなんだろうか。

社内向けに『spamdだけサービス提供』と言うのも面白い…かな。



編集
@hansode at 11:55|PermalinkComments(0)TrackBack(0)

2007年12月04日

このエントリーをはてなブックマークに追加

■一次フィルタとしてSpamAssassin

 検証環境での誤判定率: 5%弱

誤判定の99%は「false negative」
受信箱へ入って来るメールにspamが混入する割合が少なくなり、
大分快適なメール生活なのだが、検証環境はおじいちゃんサーバだ。

おじいちゃんサーバでSpamAssassinを動かすのは厳しい。
とにかく、この事実は分かった。



■二次フィルタとしてSpamAssassin

別環境で検証している。
そこでは、「二次フィルタとしてSpamAssassin」。

一次フィルタでspamを95%程度撃退。
残りの5%に大してSpamAssassinによる判定。

その結果は…
 誤判定率: 10%

一次フィルタと比べると、誤判定率は高い。
だがしかし、内容が違う。「hamの割合」が高い。
それを考慮すると、10%と言う数値は低いはずだ。



■SpamAssassinの使い所

二次フィルタとして使い始めてからは考え方が変わった。

 「SpamAssassinは二次以降のフィルタとして使うのが良いのでは」と言う仮説。

最近、この仮説は確信になりつつある。
裏付ける材料が揃ってない。材料が揃い次第書く予定。



編集
@hansode at 22:10|PermalinkComments(0)TrackBack(0)

2007年11月08日

このエントリーをはてなブックマークに追加

■本題の前に

▼環境
・Debian GNU/Linux
・spamd(SpamAssassin)をdaemontoolsで管理している。
・設定変更のたびに 「svc -t /service/spamd-ro」をしていた


■「/etc/init.d/spamassassin reload」があるよな

中身を見てみよう

  reload|force-reload)
        echo -n "Reloading $DESC: "
        start-stop-daemon --stop --pidfile $PIDFILE --signal HUP --name $PNAME
        echo "$NAME."
        ;;

なるほど。
HUPシグナルを送っているのか。


■daemontoolsでHUPシグナルを送る

「svc -h」が答え。
# svc -h /service/spamd-ro
これでOK
無駄にTERMを送ってしまっていた。
次回からはTERMではなくHUPだ。


■変更
・[2007/11/08 12:00] タイトルのタイポ修正…ボケボケ



編集
@hansode at 10:30|PermalinkComments(0)TrackBack(0)

2007年11月07日

このエントリーをはてなブックマークに追加

■おじいちゃんサーバの血圧が高い

とにかく血圧が高い。そんな状況が続いている。
判定を見ている限り、ベイズDBによる判定があまり意味をなしていない気がした。
そこで試しに設定変更

use_bayes 0

こうしてみた。
するとどうだろう…

おじいちゃんサーバの血圧が正常値に戻った。


■診断結果
・ルールさえしっかり決めておけばベイズDBはあまり要らない
・欲張ってルールを書き過ぎると血圧上昇
・ベイズDBを使わない事により、オーバーヘッドは減り、サーバのリソース確保へ繋がる

おじいちゃんは、まだまだ現役です。



編集
@hansode at 13:15|PermalinkComments(2)TrackBack(0)

2007年09月10日

このエントリーをはてなブックマークに追加

安定している。

そろそろf-nを減らすための何かを考えなければならない段階か。
まずはf-nの傾向を調査かな。


■統計情報
日付総数hamspamf-pf-n誤判定
2007-08-3110267462801242%
2007-09-015222882340254%
2007-09-024161932230215%
2007-09-039016642371192%
2007-09-0410067412650403%
2007-09-059947812130424%
2007-09-067705632070334%
2007-09-078936752180384%
2007-09-084692342350194%
2007-09-095032772260367%


■作業履歴
・whitelist_from追加


■課題
・f-n数を減少
・f-nの傾向調査



編集
@hansode at 11:10|PermalinkComments(0)TrackBack(0)

2007年08月31日

このエントリーをはてなブックマークに追加

凄く安定しているので作業自体があまりない。

■日々の作業
・false positiveからメールアドレス取得し、ドメイン名登録
・メールドメイン名をwhitelist_fromへ登録
・true positiveとなったメールからもドメイン名取得

この程度の作業で済んでいる。

$ egrep ^whitelist_from 20_whitelist_common.cf  | wc -l
55

大分whitelistが増えて来た。
これにより、徐々に判定率が良くなって行く。




■統計: 1週間分
日付総数hamspamf-pf-n誤判定
2007-08-24866636230432 4%
2007-08-25485229256221 4%
2007-08-26460253207046 10%
2007-08-27945760185643 5%
2007-08-28885680205345 5%
2007-08-29832603229340 5%
2007-08-30963736227140 4%

もっとf-n数を減らしたい。



編集
@hansode at 19:15|PermalinkComments(0)TrackBack(0)

2007年08月27日

このエントリーをはてなブックマークに追加

今朝のメールチェックでinboxにspamが多い事に気づく。
原因調査と対応の記録。


■原因調査

▼SpamAssassinの動作確認
SpamAssassinのログを調査してみたらrecoveryのメッセージ。
$ tai64nlocal< /service/spamd-ro/log/main/$(tai64nlocal).s | lv
2007-08-27 04:40:28.563005500 [8096] warn: prefork: select returned -1! recovering: Bad file descriptor
2007-08-27 04:40:29.791522500 [8096] warn: prefork: select returned -1! recovering: Bad file descriptor
2007-08-27 04:40:30.793415500 [8096] warn: prefork: select returned -1! recovering: Bad file descriptor
2007-08-27 04:40:31.795259500 [8096] warn: prefork: select returned -1! recovering: Bad file descriptor
2007-08-27 04:40:32.797110500 [8096] warn: prefork: select returned -1! recovering: Bad file descriptor


1. spamdが反応しない
 ↓
2. spam判定をスルーしてしまう
 ↓
3. inboxへメールが入り込む

こう言う経緯。


▼『spamdは起動している?』
$ sudo svstat /service/spamd-ro
/service/spamd-ro: up (pid $(pid)) $(time) seconds


起動している


▼対応優先順位付け
・じっくり原因調査
・一刻も早く復旧

業務に影響が出るので、1秒でも早い復旧を選択。
『spamdを再起動してみて、もしも駄目だったら次を考えよう。』
そう思い、再起動。

$ sudo svc -t /service/spamd-ro
$ sudo svstat /service/spamd-ro


無事、起動して来た。
その後の動作に問題ない。



■メール再判定

inboxに紛れ込んでしまっている。spamが邪魔。
どうにかしたい。さてどうする?


▼対応手順
1. inboxに入っているファイルリスト取得
2. spamcコマンドに-cオプションを付けて実行
3. spam判定された場合、sandboxへ移動

spamcに-cオプションを追加する事で、
終了ステータスコードを利用出来る。


▼spamc -cの終了ステータスコード
$? = 0: ham
$? !=0: spam



▼実行例
$ cd $(HOME)/Mail/inbox
$ mkdir sandbox
$ for i in *; do spamc -c $i || mv $i ./sandbox/; done



▼何故直接spamフォルダへ移動せず、sandboxへ移動するのか
それは、spamフォルダに同ファイル名が存在するケースを避ける為。
一度sandboxへ移動し、sandboxに入ったメールを改めてspamへ移動。
これでファイルが上書きされる事も無く、順番通りにメールが並ぶ。



■独り言
何事も経験


編集
@hansode at 11:20|PermalinkComments(0)TrackBack(0)

2007年08月20日

このエントリーをはてなブックマークに追加

変化したメール生活の話。

自分は一度全てのメールをinboxに取り込み、
inboxから各フォルダへ振り分けている。



▼日々の生活
1. inbox(ham判定メールの振り分け先)のメールを読む
2. inboxに紛れ込んだfalse negativeの振り分け
3. spamフォルダのメール確認
4. 必要に応じてspamフォルダからfales positiveのフォルダへ振り分け
5. false positiveを注意深く観察し、必要に応じてwhitelistを更新





ある程度、判定制度が安定して来ると作業は少なくなる。
現在一番工数が多いのは、inboxのメール読み。



 Q. 以前と同じ?



▼以前と違う事
・inboxフォルダのメール確認時間減少
・inboxフォルダに入っているfalse negativeのメール数減少
・spamフォルダに入っているfalse positiveのメール数減少






▼全体的に業務効率UP

 inboxフォルダのspam汚染度減少によるメール読み作業のストレス軽減


これが一番大きい。
日々快適なメール生活は成長している。



編集
@hansode at 13:05|PermalinkComments(0)TrackBack(0)

2007年08月19日

このエントリーをはてなブックマークに追加

時々メールマガジンがfalse positiveとなるのでwhitelist_fromに登録している。

今日は2件のfalse positive。
2件ともMessage-Idが大きくspamらしさのスコアを獲得してしまっている。


▼From: info at nicovideo.jp
Message-Id無し
invalidではなく、blank。これはひどい。


▼From: FC2 Information <fc2 at fc2.cc>
Message-Id: 20070818.114720
日付とrandomな数値の組合せ。



ニュースレター、メールマガジンのMessage-Idは大半が変。
こうした方が良いですよ と突っ込みを入れるとキリが無い。
送信者側・管理者側にマナーを良くしてもらいたい。

SpamAssassinでspamメール対策 (7/n) : spam判定され憎くする為の努力を勉強してもらいたい。



編集
@hansode at 16:55|PermalinkComments(0)TrackBack(0)

2007年08月18日

このエントリーをはてなブックマークに追加

You need to upgrade your Flash Player
amChartsを使ってグラフ化

spamが気い木になっていたけど、グラフ化してみると違う事に気付く。
見える化してみると面白い。



編集
@hansode at 15:15|PermalinkComments(0)TrackBack(0)