Postfixの最近のブログ記事

check_sender_ns_access

| コメント(0) | トラックバック(0)
  1. つぎつぎと新たなドメインを取得してアドレスを変えてくるので、check_sender_access ではらちがあかない。 check_client_accessで制限することに。
  2. class C アドレスブロックまるごとつかってIPアドレスを変えてくるので、IPアドレスひとつひとつ書いていたのではらちがあかない。 アドレスブロックごと制限することに。
  3. つぎつぎと新たな class C アドレスブロックを取得してIPアドレスもドメインも変えてくるので、 アドレスブロックを追加していってもいたちごっこ (続き参照)。
  4. 各メールドメインをホストする name servers はごく限られているので、 この NS を落とす...のは大変なので、check_sender_ns_access を使う。
  5. つぎつぎと新たな DNS を立ててくる...かどうかは今後の見物。

tarpitting (Teergrubing) については、 Postfix ではさほど凝ったことはできない。 まあどうせ「いやがらせ」程度の効果しかないし (dictionary attack はかなり抑止できるが)。

あと、こまかな RFC2821/2822 違反のチェックなど。

わざわざ書くほどのことはない。header_checks を使えばいい。 ここでは pcre_table(5) を使うが、regex_table(5) でも同じ。

サイト内のアドレスを sender に持つアドレスはすべてサイト内からしかこないと仮定できるのなら、外部からきたものはすべて拒否すればいい。そうでない場合 (サイト内のユーザが発信したメッセージが他サイトで転送されてサイト内のユーザに届くのを許す場合など) でも、サービス用のアドレスについてはサイト外からの配信を拒否したい。

なぜなら、これはほとんどすべてが詐称で、サービスの信頼性に影響を与えかねない (みんなサービス用アドレスからのメールを見てくれなくなる --- どうせ見ないかもしれないけど) からだ。

また、システムユーザ (一般利用者ではないユーザ) はサイト外にはメールを発信しないはずなので、バウンスも受け取るはずがない。そこで、システムユーザ宛のバウンスは拒否したい。

実は smtpd_restriction_classes を使ってみたかっただけ。

クライアントの発行するハロー (HELO/EHLO) コマンドを検査することによって、スパム送信を拒否する。これで、だいたい 40-60% は拒否できている。

このアーカイブについて

このページには、過去に書かれたブログ記事のうちPostfixカテゴリに属しているものが含まれています。

前のカテゴリはJLREQです。

次のカテゴリはSqWebMailです。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。