« 2006年04月 | メイン | 2006年06月 »

2006年05月04日

spamassassinをインストール

最近はスパムの数も1日1000通を越えるようになり、メールチェックが
滞ると大変なことになる。
それに加えて、最近メールサーバに手を入れているついでということもあり
spamassassinを導入してみた。

結論から言うと、頼りの検索情報が交錯していて予想以上に手間取った。
perl、qmailの入れなおしや、qmail-scanner等を入れなければならずに
多々はまった(笑)

ブログで書くようなボリュームでは無いので、近いうちにサイトへまとめて記載する予定。

1点だけはまっている方へヒントとなれば...
perl5.8+はデフォルトではsuidperlがインストールされない設定になっているらしい。
# which suidperl
で確認をしてみよう。
portsでインストールする場合には
# cd /usr/ports/lang/perl5.8
# make -DENABLE_SUIDPERL install clean
# rehash; use.perl port
# chmod 4711 /usr/local/bin/suidperl
とする必要がある。

投稿者 sio : 19:25

2006年05月01日

vpopmailについて諸々

POP before SMTPを利用するためにvpopmailを入れなおしたのだが
何点かはまった。

まず、tcp.smtp.cdbがpop接続があっても更新されない。
これはコンフィグする際に
--enable-tcpserver-file=/home/vpopmail/etc/tcp.smtp
オプションをつけてやることで解決した。
このオプションをつけないと、勝手に/usr/local/vpopmail/etc
内に作成してしまい、以降の更新もうまくいかなかった。
手間取った原因として、open-smtpファイルはpop接続があるごとに
同一IPアドレスからであっても更新されるのだが
tcp.smtp.cdbは同一IPアドレスの場合には更新されないために
ファイル更新時刻が異なっても正常な場合があるのだ。

つぎに、quotaのテストをしていてvdeldomainを使用せずに
ディレクトリを削除してしまった場合に
vadddomainもvdeldomainもできなくなってしまった。
その場合はmkdirでドメイン名のディレクトリを作成してから
vdeldomainとすることでデータベースからも削除された。

これは未解決だが、vpopmail-5.4.15はコンフィグエラーが出たため
他のバージョンを使うことにした。

FreeBSDでの例だが、以下の通りで正常に動作した。
----------------------------------------------------------------
# pw groupadd vchkpw -g 89
# pw useradd vpopmail -u 89 -g vchkpw -d /home/vpopmail -s /bin/bash
# ps aux | grep qmail
# kill (rootで立ち上がっているqmailのpid)

# mkdir /home/vpopmail

# tar zxvf vpopmail-5.*.*.tar.gz
# cd vpopmail-5.*.*
# ./configure \
# --enable-roaming-users=y \
# --enable-relay-clear-minutes=15 \
# --enable-domainquotas=y \
# --enable-defaultquota=104857600 \
# --enable-tcpserver-file=/home/vpopmail/etc/tcp.smtp

# make
# make install-strip
----------------------------------------------------------------
crontabに
*/15 * * * * root /home/vpopmail/bin/clearopensmtp 2>&1 > /dev/null

よく --enable-relay-clear-minutes を指定しておきながら
40 * * * * root /home/vpopmail/bin/clearopensmtp 2>&1 > /dev/null
というドキュメントのコピーそのままを掲載しているサイトを見かけるが
これは間違い。
POP before SMTPのデフォルトでは180分間となっているのでその場合には
1時間に1回で良いのだが、通常3時間も開放することは無い。

私の設定した15分の場合でも15分丁度とはならずに、POP認証後16〜29分間有効になる。
(検証済み)

例として、
--enable-relay-clear-minutes=10
40 * * * * root /home/vpopmail/bin/clearopensmtp 2>&1 > /dev/null
の場合。

毎時00/10/20/30/40/50分にclearopensmtpが動作。
open-smtpファイル内で10分を経過しているものを削除してtcp.smtp.cdbも書き換え。
要は削除されるのはこの瞬間だけなのである。

一方許可されるのはPOP認証された時点。

仮に、
--enable-relay-clear-minutes=10
*/10 * * * * root /home/vpopmail/bin/clearopensmtp 2>&1 > /dev/null
とした場合でも
毎時01/11/21/31/41/51分にPOP認証されたIPアドレスは次回のcronでは削除されずに
次回cronが動作するまでの19分間、認証されていることになる。

通常はこれで問題ないと思うが、どうしてもピッタリが良い場合には毎分cronを
動作させるしか無いだろう。（それでも最大59秒間の誤差は出るが...）

投稿者 sio : 17:41

踏み台のバックドア？

今まではプロバイダのSMTPサーバを利用するようにしていたが
ユーザに対してちょっとかっこ悪いのでSMTPサーバの設定をしてみた。
POP before SMTPを使い設定も完了し、
abuse.netでのテストも全てパスしたので運用開始！

しばらく監視していたところqmail-remoteが
見知らぬfromで見知らぬ相手へ送信している...(￣▽￣;
qmailをkillしても止まらないプロセスがある。
qmHandleを使って、とりあえずキューを全て削除(qmHandle -D)したのだが
/var/qmail/bin/qmail-qstat してみると1件残ってる。
qmail-qreadだと表示されない。
このまま再度qmailを動かしてみたところ、徐々にキューが増殖していく。
設定テスト中の数時間の間にバックドアでも仕込まれたのだろうか。
仕方ないので手動でキューディレクトリを探し回ったところ
/var/qmail/queue/mess/0/
ここに怪しげなものを1件発見したので削除。
以降不穏な動きはなくなった。

投稿者 sio : 17:22