hacks/mail/迷惑メール対策
2007年12月17日
検証サーバの限界…そして次の一手
メインで使用している「お爺ちゃんサーバ」。その「お爺ちゃんサーバ」のリソースの大半をspamdが使っている。
自分が使用可能な検証サーバが複数あるので、試しにspamdを外部サーバへ切替えてみた。
spamc(procmail)の設定
procmailのレシピ例:0fw | /usr/bin/spamc -u spamd -d spamd.example.comspamdに-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だけサービス提供』と言うのも面白い…かな。
2007年12月04日
■一次フィルタとしてSpamAssassin
検証環境での誤判定率: 5%弱
誤判定の99%は「false negative」
受信箱へ入って来るメールにspamが混入する割合が少なくなり、
大分快適なメール生活なのだが、検証環境はおじいちゃんサーバだ。
おじいちゃんサーバでSpamAssassinを動かすのは厳しい。
とにかく、この事実は分かった。
■二次フィルタとしてSpamAssassin
別環境で検証している。
そこでは、「二次フィルタとしてSpamAssassin」。
一次フィルタでspamを95%程度撃退。
残りの5%に大してSpamAssassinによる判定。
その結果は…
誤判定率: 10%
一次フィルタと比べると、誤判定率は高い。
だがしかし、内容が違う。「hamの割合」が高い。
それを考慮すると、10%と言う数値は低いはずだ。
■SpamAssassinの使い所
二次フィルタとして使い始めてからは考え方が変わった。
「SpamAssassinは二次以降のフィルタとして使うのが良いのでは」と言う仮説。
最近、この仮説は確信になりつつある。
裏付ける材料が揃ってない。材料が揃い次第書く予定。
検証環境での誤判定率: 5%弱
誤判定の99%は「false negative」
受信箱へ入って来るメールにspamが混入する割合が少なくなり、
大分快適なメール生活なのだが、検証環境はおじいちゃんサーバだ。
おじいちゃんサーバでSpamAssassinを動かすのは厳しい。
とにかく、この事実は分かった。
■二次フィルタとしてSpamAssassin
別環境で検証している。
そこでは、「二次フィルタとしてSpamAssassin」。
一次フィルタでspamを95%程度撃退。
残りの5%に大してSpamAssassinによる判定。
その結果は…
誤判定率: 10%
一次フィルタと比べると、誤判定率は高い。
だがしかし、内容が違う。「hamの割合」が高い。
それを考慮すると、10%と言う数値は低いはずだ。
■SpamAssassinの使い所
二次フィルタとして使い始めてからは考え方が変わった。
「SpamAssassinは二次以降のフィルタとして使うのが良いのでは」と言う仮説。
最近、この仮説は確信になりつつある。
裏付ける材料が揃ってない。材料が揃い次第書く予定。
2007年11月08日
■本題の前に
▼環境
・Debian GNU/Linux
・spamd(SpamAssassin)をdaemontoolsで管理している。
・設定変更のたびに 「svc -t /service/spamd-ro」をしていた
■「/etc/init.d/spamassassin reload」があるよな
中身を見てみよう
なるほど。
HUPシグナルを送っているのか。
■daemontoolsでHUPシグナルを送る
「svc -h」が答え。
無駄にTERMを送ってしまっていた。
次回からはTERMではなくHUPだ。
■変更
・[2007/11/08 12:00] タイトルのタイポ修正…ボケボケ
▼環境
・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] タイトルのタイポ修正…ボケボケ
2007年11月07日
2007年09月10日
安定している。
そろそろf-nを減らすための何かを考えなければならない段階か。
まずはf-nの傾向を調査かな。
■統計情報
■作業履歴
・whitelist_from追加
■課題
・f-n数を減少
・f-nの傾向調査
そろそろf-nを減らすための何かを考えなければならない段階か。
まずはf-nの傾向を調査かな。
■統計情報
| 日付 | 総数 | ham | spam | f-p | f-n | 誤判定 |
|---|---|---|---|---|---|---|
| 2007-08-31 | 1026 | 746 | 280 | 1 | 24 | 2% |
| 2007-09-01 | 522 | 288 | 234 | 0 | 25 | 4% |
| 2007-09-02 | 416 | 193 | 223 | 0 | 21 | 5% |
| 2007-09-03 | 901 | 664 | 237 | 1 | 19 | 2% |
| 2007-09-04 | 1006 | 741 | 265 | 0 | 40 | 3% |
| 2007-09-05 | 994 | 781 | 213 | 0 | 42 | 4% |
| 2007-09-06 | 770 | 563 | 207 | 0 | 33 | 4% |
| 2007-09-07 | 893 | 675 | 218 | 0 | 38 | 4% |
| 2007-09-08 | 469 | 234 | 235 | 0 | 19 | 4% |
| 2007-09-09 | 503 | 277 | 226 | 0 | 36 | 7% |
■作業履歴
・whitelist_from追加
■課題
・f-n数を減少
・f-nの傾向調査
2007年08月31日
凄く安定しているので作業自体があまりない。
■日々の作業
・false positiveからメールアドレス取得し、ドメイン名登録
・メールドメイン名をwhitelist_fromへ登録
・true positiveとなったメールからもドメイン名取得
この程度の作業で済んでいる。
大分whitelistが増えて来た。
これにより、徐々に判定率が良くなって行く。


■統計: 1週間分
もっとf-n数を減らしたい。
■日々の作業
・false positiveからメールアドレス取得し、ドメイン名登録
・メールドメイン名をwhitelist_fromへ登録
・true positiveとなったメールからもドメイン名取得
この程度の作業で済んでいる。
$ egrep ^whitelist_from 20_whitelist_common.cf | wc -l
55
55
大分whitelistが増えて来た。
これにより、徐々に判定率が良くなって行く。

■統計: 1週間分
| 日付 | 総数 | ham | spam | f-p | f-n | 誤判定 |
|---|---|---|---|---|---|---|
| 2007-08-24 | 866 | 636 | 230 | 4 | 32 | 4% |
| 2007-08-25 | 485 | 229 | 256 | 2 | 21 | 4% |
| 2007-08-26 | 460 | 253 | 207 | 0 | 46 | 10% |
| 2007-08-27 | 945 | 760 | 185 | 6 | 43 | 5% |
| 2007-08-28 | 885 | 680 | 205 | 3 | 45 | 5% |
| 2007-08-29 | 832 | 603 | 229 | 3 | 40 | 5% |
| 2007-08-30 | 963 | 736 | 227 | 1 | 40 | 4% |
もっとf-n数を減らしたい。
2007年08月27日
今朝のメールチェックでinboxにspamが多い事に気づく。
原因調査と対応の記録。
■原因調査
▼SpamAssassinの動作確認
SpamAssassinのログを調査してみたらrecoveryのメッセージ。
1. spamdが反応しない
↓
2. spam判定をスルーしてしまう
↓
3. inboxへメールが入り込む
こう言う経緯。
▼『spamdは起動している?』
起動している
▼対応優先順位付け
・じっくり原因調査
・一刻も早く復旧
業務に影響が出るので、1秒でも早い復旧を選択。
『spamdを再起動してみて、もしも駄目だったら次を考えよう。』
そう思い、再起動。
無事、起動して来た。
その後の動作に問題ない。
■メール再判定
inboxに紛れ込んでしまっている。spamが邪魔。
どうにかしたい。さてどうする?
▼対応手順
1. inboxに入っているファイルリスト取得
2. spamcコマンドに-cオプションを付けて実行
3. spam判定された場合、sandboxへ移動
spamcに-cオプションを追加する事で、
終了ステータスコードを利用出来る。
▼spamc -cの終了ステータスコード
▼実行例
▼何故直接spamフォルダへ移動せず、sandboxへ移動するのか
それは、spamフォルダに同ファイル名が存在するケースを避ける為。
一度sandboxへ移動し、sandboxに入ったメールを改めて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
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
/service/spamd-ro: up (pid $(pid)) $(time) seconds
起動している
▼対応優先順位付け
・じっくり原因調査
・一刻も早く復旧
業務に影響が出るので、1秒でも早い復旧を選択。
『spamdを再起動してみて、もしも駄目だったら次を考えよう。』
そう思い、再起動。
$ sudo svc -t /service/spamd-ro
$ sudo svstat /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
$? !=0: spam
▼実行例
$ cd $(HOME)/Mail/inbox
$ mkdir sandbox
$ for i in *; do spamc -c $i || mv $i ./sandbox/; done
$ mkdir sandbox
$ for i in *; do spamc -c $i || mv $i ./sandbox/; done
▼何故直接spamフォルダへ移動せず、sandboxへ移動するのか
それは、spamフォルダに同ファイル名が存在するケースを避ける為。
一度sandboxへ移動し、sandboxに入ったメールを改めてspamへ移動。
これでファイルが上書きされる事も無く、順番通りにメールが並ぶ。
■独り言
何事も経験
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汚染度減少によるメール読み作業のストレス軽減
これが一番大きい。
日々快適なメール生活は成長している。
自分は一度全てのメールを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汚染度減少によるメール読み作業のストレス軽減
これが一番大きい。
日々快適なメール生活は成長している。
2007年08月19日
時々メールマガジンがfalse positiveとなるのでwhitelist_fromに登録している。
今日は2件のfalse positive。
2件ともMessage-Idが大きくspamらしさのスコアを獲得してしまっている。
▼From: info at nicovideo.jp
invalidではなく、blank。これはひどい。
▼From: FC2 Information <fc2 at fc2.cc>
日付とrandomな数値の組合せ。
ニュースレター、メールマガジンのMessage-Idは大半が変。
こうした方が良いですよ と突っ込みを入れるとキリが無い。
送信者側・管理者側にマナーを良くしてもらいたい。
SpamAssassinでspamメール対策 (7/n) : spam判定され憎くする為の努力を勉強してもらいたい。
今日は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判定され憎くする為の努力を勉強してもらいたい。
2007年08月18日
You need to upgrade your Flash Player
amChartsを使ってグラフ化spamが気い木になっていたけど、グラフ化してみると違う事に気付く。
見える化してみると面白い。