先週は、Postfixがスパムを減らすために何ができるかについて学びました。さまざまな*_restrictions
構成パラメータcontrol whenを正しく理解していれば、チェックが行われ、次にpermit_mynetworks
やcheck_client_access
controlなどの制限のリストwhatがチェックされます。あれは正しいですか?
私が正しく理解している場合、チェックは次の順序で実行されます。
あれは正しいですか?そして、私が正しく理解していれば、smtpd_delay_reject
はチェックの順序には影響せず、whenにのみ影響します。拒否はsentです。正しい?
smtpd_relay_restrictions
構成パラメータがPlesk 11サーバで設定されていないようです。私のPostfixバージョンは2.8.4です。
また、いくつかのチェックが異なる構成パラメーターで複数回リストされていることにも気付きました。それらは複数回リストされる必要がありますか?
これが私の現在の設定です:
smtpd_sender_restrictions =
check_sender_access hash:/var/spool/postfix/plesk/blacklists
permit_sasl_authenticated
check_client_access pcre:/var/spool/postfix/plesk/non_auth.re
smtpd_client_restrictions =
permit_mynetworks
smtpd_recipient_restrictions =
permit_mynetworks
check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
permit_sasl_authenticated
reject_unauth_destination
私が正しく理解していれば、それはこれと同じです:
smtpd_sender_restrictions =
smtpd_client_restrictions =
smtpd_recipient_restrictions =
permit_mynetworks
check_sender_access hash:/var/spool/postfix/plesk/blacklists
permit_sasl_authenticated
check_client_access pcre:/var/spool/postfix/plesk/non_auth.re
permit_mynetworks
check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
permit_sasl_authenticated
reject_unauth_destination
ブラックリストファイルが空です。 no_authファイルにはこれがあります:
/^/ PREPEND X-No-Auth: unauthenticated sender
そしてno_relayファイルにはこれがあります:
/^/ PREPEND X-No-Relay: not in my network
私が正しく理解している場合、最後の2つは、まだ許可されていないすべての電子メールにヘッダーを追加します。
繰り返しチェック
複数回リストされている場合、Postfixは再度チェックを実行しますか?または、Postfixはそのチェックがすでに行われたことを知っていますか?チェックが複数回実行される場合、それは無駄のようです。それらが複数回実行されない場合、no_auh/no_relayヘッダーは実際にはすべての場合に適切に追加されますか?
smtpd_relay_restrictionsがありません
Postfix SMTPリレーおよびアクセス制御 からの抜粋
注:2.10より前のバージョンのPostfixにはsmtpd_relay_restrictionsがありませんでした。彼らは、smtpd_recipient_restrictionsの下で、メールリレーポリシーとスパムブロッキングポリシーを組み合わせました。これにより、予期しない結果が生じる可能性があります。たとえば、許容的なスパムブロッキングポリシーにより、予期せずに許容的なメールリレーポリシーが発生する可能性があります。
別の抜粋:
一部の人々は、smtpd_recipient_restrictionsリストにすべてのアクセス制限を配置することを推奨しています。残念ながら、これによりアクセスが許容されすぎる可能性があります。
そのため、smtpd_recipient_restrictions
の下にすべての制限をリストしたくないのですが、複数の制限と同じチェックを異なる制限の下に置くと混乱を招きます。 smtpd_recipient_restrictions
とsmtpd_relay_restrictions
だけを使用して、クライアント、helo、送信者を無視しても安全ですか?
ブラックリスト
そのブラックリストはリストのかなり早い段階にありませんか?送信者が私のネットワークの一部であり、認証できる場合、送信者のメールに基づいて本当にブロックする必要がありますか?現在、テーブルは空ですが、どのPleskコンポーネントがそのテーブルにメールアドレスを追加するかはわかりません。また、postmaster @およびabuse @アドレスへの100%の配信を必要とするRFCに反します。
/etc/postfix/main.cf内
#smtpd_client_restrictions =
#smtpd_helo_restrictions =
#smtpd_sender_restrictions =
smtpd_relay_restrictions =
permit_mynetworks
check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
permit_sasl_authenticated
check_client_access pcre:/var/spool/postfix/plesk/non_auth.re
reject_unauth_destination
smtpd_recipient_restrictions =
check_recipient_access pcre:/etc/postfix/custom/recipient_checks.pcre
check_client_access cidr:/etc/postfix/custom/sinokorea.cidr
check_sender_access hash:/var/spool/postfix/plesk/blacklists
/etc/postfix/custom/recipient_checks.pcre内
# Always accept mail to postmaster@ and abuse@
/^postmaster@/ OK
/^abuse@/ OK
# Reject all mail sent to mailapp.ourdomain.com
# except for certain specific recipients
# and bounce messages which may use VERP
if /@mailapp\.ourdomain\.com$/
!/^(?:validuser|anothervalid|bounces(?:\+.+)?)@/ REJECT
endif
正規表現で@
がエスケープされている例を見つけました。特別なキャラクターじゃないですか?
私の提案した構成は私が望んでいることを達成しますか?
(自分自身および他のPleskユーザがこれを読んでいることに注意してください-一部のPleskアクションがこのファイルを上書きしているように見えるため、main.cfファイルへの変更を定期的に復元するには、cronジョブが必要になる場合があります。)
OK、これは長い質問です。上記の質問の一部に答えてみます。そして、それらに基づいて要約を描くこともできます。
免責事項:私はpleskを使用していませんが、postfixを使用しています。この質問の年齢は1年以上だったので、多分pleskはpostfixの設定を更新しました。しかし、私はこの質問は後置制限を設計して実装する人にとって役立つと思います
smtpd_sender_restrictions =
check_sender_access hash:/var/spool/postfix/plesk/blacklists
permit_sasl_authenticated
check_client_access pcre:/var/spool/postfix/plesk/non_auth.re
smtpd_client_restrictions =
permit_mynetworks
smtpd_recipient_restrictions =
permit_mynetworks
check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
permit_sasl_authenticated
reject_unauth_destination
そして
smtpd_sender_restrictions =
smtpd_client_restrictions =
smtpd_recipient_restrictions =
permit_mynetworks
check_sender_access hash:/var/spool/postfix/plesk/blacklists
permit_sasl_authenticated
check_client_access pcre:/var/spool/postfix/plesk/non_auth.re
permit_mynetworks
check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
permit_sasl_authenticated
reject_unauth_destination
Mynetworksからのメールの場合、/var/spool/postfix/plesk/no_relay.re
および/var/spool/postfix/plesk/no_relay.re
によるチェックは行われません。つまり、メールは受け入れられ、変更されません。後置アクション(REJECT、ACCEPT)に関しては、違いはありませんが、多分これらの2つのヘッダーはimportantです。
ええ、2つのチェックを繰り返すと無駄に見えるかもしれません。ただし、この繰り返しのチェックは別の場所/制限に配置されます。そして、すべてのチェックで、Postfixが電子メールをどのように処理したかに関するロジックまたはアルゴリズムがいくつかあります。チェックが check_policy_service やDNSBLなどの重いチェックである場合は、繰り返しチェックされる可能性があります。 permit_mynetwork のような軽量チェックの場合は、無視してかまいません。
まあ、2つのsmtpd_recipient_restrictionsとsmtpd_relay_restrictionsがあれば、いくつかの高度な制限には十分です。しかし、それはpostfix> = 2.10のためのものです。 postfix <2.10のユーザーの場合、複数のディレクティブにチェックを配置して、postfixが になりすぎないようにすることができます。
はい、現在のpostfixの制限を単純化するための良い仕事です。しかし、postfixはpleskの一部であることに注意してください。 pleskのエンジニアは、モジュール性や単純なメンテナンスなどの理由でこれらの制限を調整する場合があります。
概要:
あなたが何をするにせよ、外に出ないでください:
smtpd_client_restrictions = reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net
これらは私一人で大多数を捕らえてきました。