ざったばらん

リレーサーバーの Back Scatterの対策もしたところ随分とこれは減ったんで。
ついでにメインのサーバーの spamassassinにも barracuda reputationを引かせるようにしておこう。

user_prefsに Brracudaのエントリを追加して spamassassinの再起動で OK

header          RCVD_IN_BRCD_REPT    eval:check_rbl_txt(‘brbl’,’b.barracudacentral.org.’)
describe        RCVD_IN_BRCD_REPT    Received via a relay in b.barracudacentral.org
tflags          RCVD_IN_BRCD_REPT    net
score           RCVD_IN_BRCD_REPT    2.5

識別名(RCVD_IN_BRCD_REPT )は何でもいいけど分かりやすく。
引っかかった時のscoreは 2.5ポイントでしばらく様子を見てみよう。

しばらく SPAMが来るのを待って maillogにRCVD_IN_BRCD_REPT があれば動作している。
待っていると Barracudaに引っかかるのがなかなか来なかったりするwww

幸い引っかかるやつが来たらレポートには

2.5 RCVD_IN_BRCD_REPT      RBL: Received via a relay in b.barracudacentral.org
[Client host blocked using Barracuda Reputation,]
[see <http://www.barracudanetworks.com/reputation/?r=1&ip=83.96.87.209>]

こんな感じで出力されているはず。

最近 backup mx(secondary mx)に対する back scatterが多くなってきたて、このままだと、ip reputationとか rblに登録されちゃったらかなわんので対策。

うちの場合、backup mxは sendmailで運用しているのだが  relay-domainsに受け取る(転送する)ドメインを指定しているわけだが、ユーザーテーブルを持たないので、それこそrelay-domainsに書いているドメインであれば宛先が実在しようとしなかろうと受け取ってしまってリレー先に転送してしまう。
リレー先では当然 511 user unknownを backup mxに返すわけだが、差出人に返すのは backup mxの仕事。
と言うことで、差出人を詐称していれば詐称先に「そんなユーザー居ないよう」って返すんだが、詐称している先だからこれがバウンスしてキューに溜まったり、返送できてしまったら受け取った側はそれこそ迷惑メール！
ま、これが smtpの盲点を突いた back scatterなわけだが….
(さらに…)