[サーバ] postfixはネ申
06/24/2005 19:13 (投稿者：たかの)

男は黙ってpostfix。 とりあえずsmtpd_sender_restrictionsの中身、はっときます。

smtpd_sender_restrictions = permit_mynetworks check_sender_access hash:/etc/postfix/sender_access reject_unknown_sender_domain reject_rbl_client relays.ordb.org reject_rbl_client dialup.blacklist.jippg.org reject_rbl_client mail-abuse.blacklist.jippg.org reject_rbl_client shortbl.blacklist.jippg.org reject_rbl_client dul.dnsbl.sorbs.net reject_rbl_client list.dsbl.org reject_rbl_client multihop.dsbl.org reject_rbl_client cbl.abuseat.org reject_rbl_client blackholes.intersil.net reject_rbl_client blackholes.wirehub.net reject_rbl_client dynablock.wirehub.net reject_rbl_client dnsbl.njabl.org reject_rbl_client assholes.madscience.nl reject_rbl_client black.z721.com reject_rbl_client dialup.z721.com reject_unknown_client reject_unverified_sender reject_unauth_pipelining もともとは、sender_accessファイルにこんなん書いていた。 aol.com reject_unverified_sender hotmail.com reject_unverified_sender bigfoot.com reject_unverified_sender yahoo.co.jp reject_unverified_sender docomo.ne.jp reject_unverified_sender 代わりにmain.cf側のreject_unverified_senderにはwarn_if_rejectをつけてた。 けど、挙動を見ていると、結局受け取ってしまったメールもアドレス不在で返せずにキューにたまるだけなので、思い切って全部外してしまったよ。なのでcheck_sender_accessは、もういらない（はず）なんだけど、挙動を確認する時間が今ちょっとないので、とりあえず残してある。 しかしまぁ、ここまで綺麗に止まるとは思わなかった。早くやっとけばよかった。 届けるアテの無いメールは受け取ってはいけないと、つくづく思ったよ。びっくり。

メールでコメント

• main.cfの設定
  07/03/2005 00:35 (投稿者：たかの)
  

  その後若干変化して、今ではこうなってます。 （Spam関連のところだけ抜粋） ---- bounce_queue_lifetime = 12h address_verify_positive_refresh_time = 30m smtpd_sender_restrictions = permit_mynetworks check_sender_access hash:/etc/postfix/sender_access reject_unknown_sender_domain reject_rbl_client relays.ordb.org reject_rbl_client dialup.blacklist.jippg.org reject_rbl_client mail-abuse.blacklist.jippg.org reject_rbl_client shortbl.blacklist.jippg.org reject_rbl_client dul.dnsbl.sorbs.net reject_rbl_client list.dsbl.org reject_rbl_client multihop.dsbl.org reject_rbl_client cbl.abuseat.org reject_rbl_client blackholes.intersil.net reject_rbl_client blackholes.wirehub.net reject_rbl_client dynablock.wirehub.net reject_rbl_client dnsbl.njabl.org reject_rbl_client assholes.madscience.nl reject_rbl_client black.z721.com reject_rbl_client dialup.z721.com reject_unknown_client reject_unverified_sender reject_unauth_pipelining defer_if_reject reject_rbl_client bl.spamcop.net ---- キューのlifetimeを短めにしているのは、近年のメールの使われ方を考えると、数日間遅延して届けても、ちょっと遅すぎだろうという観点からです。UUCPでバケツリレーやっとる時代とは違いますから…。 また、有効なメールアドレスであるかのチェックを30分しかキャッシュしないのは「ヤフーなんかで新規にフリーアドレスを取ってはSpam大爆発」型への対処です。こういうのは、最初のメールを受けたときには「まだ」アドレスが生きているので通してしまいます。ですが、30分もすればエラーリターンでメールボックスは潰れてしまうので、それ以上はザルのように通すことは無いというわけ。 実感としては、やっぱりreject_unknown_clientとreject_unverified_senderの威力が絶大です。今まで止め切れなかったメールの9割くらいまで、こいつで止まります。 さらにdefer_if_rejectで、管理の危うい（登録が積極的すぎて大手まで蹴ってしまうような）SpamCopのようなRBLも積極的に活用できるので尚よいです。 five-ten-sg.comはBIGLOBEの会員向けDMサーバまで蹴ってましたので、さすがに外しましたが。 check_sender_accessも残しています。 これは今、あまりにもふるまいが下劣な差出人アドレスを個別撃破するのに使ってます。 postfix導入で、もうひとつ嬉しい副産物が。 logwatchでreject状況のサマリが出るようになったのですが、ドメインに辞書を当てるような無茶をするSpam屋は、かなり狭い範囲のIPアドレスブロックから集中して出されています。しかも、蹴られていることを自覚できていないようで、蹴っても蹴っても懲りもせず送り続けてくるようです。 こういうのは、おそらく特定少数の人間の仕業。日本国内であれば、今秋にもバリバリ御縄に捕れる環境になる。 捕まらなければいいやと飲酒運転する奴と一緒で、一度は痛い目を見てもらわないとね。 きっと、一度痛い目を見ないと分からないタイプでしょうから。 しっかり前科もつけていただきましょう。刑事罰ですよ。

  
  
• 現在の成績
  07/07/2005 11:58 (投稿者：たかの)
  

  とりあえず、こんなん出ました。 Messages rejected: Access denied 717 Time(s) Domain not found 4238 Time(s) defer_if_reject requested 361 Time(s) Messages rejected using Anti-Spam site 3955 Time(s) ↓おまけのバカ。いーかげんにしんさい。 Unrecognized warning: dsl-200-67-149-183.prod-empresarial.com.mx[200.67.149.183] sent non-SMTP command: From: "Frank" <electric21cracker@hotmail.com> : 1 Time(s) pl487.nas926.o-tokyo.nttpc.ne.jp[210.165.238.231] sent non-SMTP command: Reply-To: =?ISO-2022-JP?B?GyRCN3pDW0U5Sl4lRyU2JSQlcyU5JT8lOCUqGyhK?=<a1@kentikupers.com> : 1 Time(s) unknown[202.137.160.125] sent non-SMTP command: From: "Carlos" <front24221yoda@hotmail.com> : 1 Time(s)

  
  
• IP DROP
  07/09/2005 15:27 (投稿者：たかの)
  

  さらに続報です。 どうもreject reportを見ていると、特定少数のSpammerばかりが大量の辞書Spamを投げつけてくるらしい。 ログがうるさいのはどうということは無いんだが、これが原因で蹴っちゃいけないメールのREJECTを見落としてしまうのは少々マズい。 というわけで、これらをIPレベルで止めてみた。 iptables-saveの内容はこんな感じ。 ---- # Generated by iptables-save v1.2.5 on Sat Jul 9 15:13:50 2005 *filter :INPUT ACCEPT [8858623:876280292] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [6973162:1877244727] -A INPUT -s 211.240.60.205 -p tcp -m tcp --dport 25 -j DROP -A INPUT -s 58.81.193.230 -p tcp -m tcp --dport 25 -j DROP -A INPUT -s 61.14.173.0/255.255.255.0 -p tcp -m tcp --dport 25 -j DROP -A INPUT -s 218.187.44.0/255.255.255.0 -p tcp -m tcp --dport 25 -j DROP -A INPUT -s 211.112.25.0/255.255.255.0 -p tcp -m tcp --dport 25 -j DROP -A INPUT -s 219.147.189.0/255.255.255.0 -p tcp -m tcp --dport 25 -j DROP -A INPUT -s 61.14.173.0/255.255.255.0 -p tcp -m tcp --dport 25 -j DROP -A INPUT -s 219.102.18.17 -p tcp -m tcp --dport 25 -j DROP -A INPUT -s 210.159.162.0/255.255.255.0 -p tcp -m tcp --dport 25 -j DROP -A INPUT -s 222.171.18.0/255.255.255.0 -p tcp -m tcp --dport 25 -j DROP -A INPUT -s 222.171.27.0/255.255.255.0 -p tcp -m tcp --dport 25 -j DROP -A INPUT -s 210.165.28.34 -p tcp -m tcp --dport 25 -j DROP -A INPUT -s 219.102.20.0/255.255.255.0 -p tcp -m tcp --dport 25 -j DROP -A INPUT -s 219.102.16.232 -p tcp -m tcp --dport 25 -j DROP COMMIT # Completed on Sat Jul 9 15:13:50 2005 ---- これだけで、80％ほどのSpamが完全に止まった。呆れてモノが言えん。ありえねぇよ実際。 アドレスブロックの主な割当先は、nttpc.ne.jp, ocn.ne.jp, yournet.ne.jp(FreeBit系), usen.ad.jpという感じ。 この4社だけでDQNリストの9割以上を占めているといっても過言では無いだろう。 どんなザルな入会審査をしているのか分からないが、プロバイダ責任制限法の趣旨を理解しているとはとても思えないな。 nttpcとyournetは、他社へOEM供給をしている関係上、この傾向が顕著に現れるのだろう。サラ金のブラックリストみたいに、悪質な契約者情報のリストでも共有したらどうかね。