上記の広告は１ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

メールリレーサーバとメールスプールサーバの二段構成でメールサーバを構成している場合で、スプールサーバの存在しないアカウント宛にメールが送られた場合、たいていの場合リレーサーバより「User Unknown」でバウンスメールを返します。
しかし、スパムメールは大半が送信者アドレスが偽装されてるので、「存在しないメールアドレス」だった場合、相手先メールサーバと接続できずバウンスメールを配送できないためキューに溜まり溢れるという事象が発生します。
また、特定の偽装アドレス宛にエラーメールを大量に送信しているとスパム送信者とみなされRBL等に登録される恐れもあります。
このようなSMTPの仕様を逆手に取った攻撃をBackscatter攻撃といい、相当うっとうしい攻撃です。

そこで今回はスプールサーバでできるBackscatter対策として、存在しないアカウント宛にきたメールも受信してゴミアカウントへ配送する方法を紹介します。

●スプールサーバがsendmailの場合
sendmail.mcに下記の設定を追加し、sendmail.cfを作成します。

define(`LUSER_RELAY',`local:ゴミアカウント名')dnl


sendmail.cfに直接設定する場合は下記を追加します。

# place to which unknown users should be forwarded
Kuser user -m -a<>
DLlocal:ゴミアカウント名


●スプールサーバがpostfixの場合
main.cfに書きの設定を追加します。

local_recipient_maps =
luser_relay=ゴミアカウント名

あとは、ゴミアカウントのメールボックスを定期的にメンテナンスすれば良いかと思います。

最近、アドレスが詐称されたスパムメールがいっぱい飛んできて、受信者がいないスパムメールのバウンスがdeferredキューに溜まりまくっている。。
deferredキューに溜まりまくっているバウンスメールの配送できない原因についてのログを以下にメモっておきます。

●Connection timed out
3ウェイハンドシェイクの際、SYNを送信したがSYN/ACKが返ってこなかったのでタイムアウトした。（相手ホストが存在しない可能性がある）

●Connection refused
3ウェイハンドシェイクの際、SYNを送信したがRSTが返ってきた。（相手ホストは存在するがSMTPサービスが動いていない可能性がある）

●Name service error for name
DNS問い合わせを行ったが、送信先メールサーバが存在しなかった。

●server dropped connection
接続は確立したけど、相手ホストに接続を切られた。

●server refused mail service
接続は確立したけど、SMTPステータス4xx又は5xxが返ってきた。

●read timeout
SMTPでのタイムアウト

●said: 451 VS14-RT5 Mailbox bounce arrival rate exceeds system limit
相手先メールボックスが容量制限に達しているため受信を拒否された。

●no route to host
ルーティング障害

メールスプール用サーバでユーザを削除する際、メールボックスを削除するのをついつい忘れてしまうことってないですか？
今回は、過去に削除し忘れたメールボックスをリスト表示するスクリプトを作成したので紹介します。

[使い方]
１．「nouser_check.sh」内の以下の部分を編集し、メールボックスが格納されているディレクトリを指定します。

SPOOLDIR="/var/mail"

２．以下のようにスクリプトを実行します。
　# nouser_check.sh [出力ファイル名]



３．出力ファイルに、以下のような所有者が存在しないメールボックス一覧が作成されます。

所有者 サイズ(byte) メールボックス名
3255 0 user1
3259 0 user2
3333 311247 user3




[スクリプト]

nouser_check.sh

#!/bin/sh
#
# 使い方：
# nouser_check.sh [出力ファイル名]
#

# メールボックスの場所指定
SPOOLDIR="/var/mail"

echo "所有者 サイズ(byte) メールボックス名" > $1
ls -l $SPOOLDIR | awk '{print $3,$5,$NF}' | grep "^[0-9]" > unuserlist.tmp
cat unuserlist.tmp | awk '{print $NF}' > unusername.tmp

cat /etc/passwd | awk -F: '{print $1}' > passwd.tmp

for i in `cat unusername.tmp`
do
flag=""
for h in `cat passwd.tmp`
do
if [ $i = $h ];
then
flag=ok
break
else
flag=ng
fi
done

if [ $flag = "ng" ];
then
grep "$i$" unuserlist.tmp >> $1

fi
done

rm unuserlist.tmp
rm passwd.tmp
rm unusername.tmp

「Postfixのどのキューにどれだけメールが溜まってるか」を調べるための簡単なスクリプトを作成したので以下に記載します。
正常動作チェック用スクリプトの一つに加えてみてはいかがでしょうか？

queue_count.sh

#!/bin/sh

QUEUE_PATH="/var/spool/postfix"
echo "### Postfix MailQueue File Count(PATH:$QUEUE_PATH) ###"
for i in `ls $QUEUE_PATH`
do
echo -n $i :
ls -l $QUEUE_PATH/$i/* | grep "^-" | wc -l
done 2> /dev/null

上記を作成し、実行すると以下のように「キュー名」とキュー内の「ファイル数」が出力されます。
### Postfix MailQueue File Count(PATH:/var/spool/postfix) ###
active :0
bounce :0
corrupt :0
defer :0
deferred :0
flush :0
hold :0
incoming :0
maildrop :0
pid :11
private :0
public :0
saved :0
trace :0

Squidのアップデート作業ではまってしまった。。
OSは、Solaris2.6です。

アップデート完了後にsquidを起動し、ps -ef | grep squid で確認したら、最初は正常に起動するが、しばらく経つと勝手に落ちてるって具合で正常に動作しません。

cache.logを見てみると、squid起動直後に

FATAL: Received Segment Violation...dying

と出力されていたので調べてみると、squidのコンパイル時に使用するgccのバージョン2.95.1から2.95.4にはコンパイラーの最適化の部分にバグがあるそうで、そのバグがsquidに影響し、最初のアクセスを受けた際に上記ログをはいて落ちるとのことです。。

　# gcc -v　


で、gccのバージョンを調べてみると、「2.95.2」でビンゴでした。
このバグを避けるには最適化しないでコンパイルしたら良いそうで、configureを実行する前に以下を実行すれば正常に動作するようになりました。

　# CFLAGS='-g -Wall'