昨日早朝、サーバの負荷が高まり、メール遅延が発生していました。
ログの見直しと、tcpdumpの表示から、いくつかの設定を見直しました。
一番の問題は、よけいなDNS問い合わせが（特定のアドレスから）極端に多いこと。
多分、乗っ取られているのでしょう。(^^;
という事で、iptablesでそれらのアドレスからのアクセスをDROP。
ついでに、内部で使っているDNSからは問い合わせしないように、
別回線から問い合わせをするようにresolv.confを設定。
さらに、courier-mtaで、user unknownのエラーを送信しないようにしました。
これで、メールアドレスを間違っている場合でもエラーが帰ってこないのですが、
こちらから送ったメールに対して返信すれば問題ないでしょうし、
それぞれ判りやすいメールアドレスを使っていると思うので、大丈夫でしょう。
courierのetcディレクトリに、aliasfilteracctとaliasDirを作成し、
aliasfilteracctにaliasDirのパスを記述。
aliasDirに#の一文字を書いた.courier-defaultを作成。
mail.logを見ると、これだけで良いようです。
aliasfilteracctの設定は、特に再起動も必要なく、書いた直後に反映されます。
そういえば、昔courier-mtaではまった事と言えば、maildroprcの文法。
これ、ちょっと特殊で、「{」と「}」は、独立した１行に書かなければいかないらしい。
つまり、
if( ... ) {
...
} else {
...
}
などが出来なくて、
if( ... )
{
...
}
else
{
...
}
としなけいと、エラーが出ます。
2/16補足
メールで、rootやpostmasterのエイリアスを削除したら、
いくつかの手抜き設定で動かしていたレポートソフトからのメールが来なくなってしまった。
これらの宛先アドレスをrootから実際のアドレスに変更。
予想通り、DNS問い合わせ元が、同じネットワークないの別のアドレスになって
また問い合わせし始めた。
とりあえず、返事をしないのだが、DNSに負担がかかるので、
iptablesで213.171.192.0/19をまとめてDROP。
（しつこいから、実際のネットワークを出してしまいます）
興味ある人は、自分でwhoisでも使うと判るでしょうが、GBのネットワークです。
これ以降、ここのネットワークからは、いっさい繋がりません。(^^;
これで、しばらく平和になるかな。
コメントする