web-dev-qa-db-ja.com

587で送信するためのsmtpd_client_restrictionsの接尾辞permit_sasl_authenticated

まず、私の設定について説明します。 DebianWheezyで接尾辞2.9.6を使用しています。ポート25でAUTHを許可せず、代わりにMUAにポート587で送信サービスを使用するように強制します。 Debianはmaster.cfに次の設定が付属しています（デフォルトでコメントされています）：

submission inet n       -       -       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

Permit_sasl_authenticatedがsmtpd_client_restrictionsにある理由がわかりません。リレーアクセスを許可するには、main.cfで、またはできればmaster.cfの送信サービスの追加のオーバーライドで、smtpd_recipient_restrictions（または接尾辞> = 2.10の場合はsmtpd_relay_restrictions）にも追加する必要があります。

  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

いずれの場合も、認証を2回チェックし、制限リストの評価が遅れると、両方のチェックがRCPTTOステージで実行されます。リレーアクセスがなければ、AUTHクライアントは$ mydestinationに送信できますが、ポート25のMTAはすでにそれを許可しています。遅延評価がなければ、smtpdは、クライアントチェックを実行するときに、AUTHに関する情報すら持っていません。

Smtpd_client_restrictionsでpermit_sasl_authenticatedを使用することに何かメリットはありますか？これのユースケースは何ですか？

postfixsaslrestrictions
1
Rob

通常、main.cfのsmtpd_client_restrictionsは使用されないため、これは単にmain.cfをオーバーライドするクリーンな方法です。これは、デフォルトでsmtpd_client_restrictions = permitに設定されていると言うのと同じです。

質問で言うようにsmtpd_recipient_restrictionsをオーバーライドすることで同じ結果を得ることができます。その場合、smtpd_client_restrictionsステートメントは必要ありません。おそらく、目立たないパフォーマンス上の利点があるかもしれませんが、main.cf関連のsmtpd_recipient_restrictionsに他の制限が存在する場合認証されたクライアントには、それらをmaster.cfにも追加し、将来の編集と同期することを忘れないでください。

また、Debianパッケージャーの観点からは、smtpd_recipient_restrictionsと比較して、main.cfで何かを実行する可能性がはるかに低いため、smtpd_client_restrictionsをオーバーライドする方が安全です。

3
user269723

Postfixは混合制限リストのサポートを開始しました。からの関連行： Postfix Docs

Around the time that smtpd_delay_reject was introduced, Postfix was also changed 
to support mixed restriction lists that combine information about the client, 
helo, sender and recipient or etrn command. 

Mixing is needed for complex whitelisting policies. For example, in order to 
reject local sender addresses in mail from non-local clients, you need to be 
able to mix restrictions on client information with restrictions on sender 
information in the same restriction list. Without this ability, many per-user
access restrictions would be impossible to express.

上記の段落は、混合制限がサポートされ、必要とされる理由を明確に説明しています。

あなたの場合、認証された後、client（IP /ホストの接続）に制限を適用したくありません。 「ユーザーが認証しても、[email protected]にメールを送信できないようにする必要があります」などの要件があるとすると、smtpd_recipient_restrictionsは次のようになります。

#/etc/postfix/main.cf
smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/blocked_rcptto
             permit_sasl_authenticated
#/etc/postfix/blocked_rcptto
[email protected] REJECT No mails can reach this user from us

お役に立てば幸いです。

1
clement

私自身の質問に答えますが、考えられるユースケースの1つは次のとおりです。

後でsmtpd_client_restrictionsをmain.cf（デフォルトでは空）に追加してスパムなどをブロックした場合、master.cfに送信するためのオーバーライドがすでに存在していると、AUTHクライアントはこれらの制限をスキップできます。 smtpd_client_restrictionsをオーバーライドしないと、AUTHクライアントにスパムチェックを実行することで誰かを驚かせる可能性があります。もちろん、それは必ずしも悪いことではないかもしれません。

1
Rob