Alain Spineux пишет:
Hi
I've some question bout the smtp_*_restrictions
Have you read http://www.postfix.org/SMTPD_ACCESS_README.html ?
When smtpd_delay_reject=yes (the default) :
- May I expect the policies will be called in the expected order :
first the one from smtpd_client_restrictions (in the order they are
defined of course),
then the ones from smtpd_sender_restrictions and finally the ones from
smtpd_recipient_restrictions
Each restriction evaluated in response to certain event: client - on
connection, helo - after recieving HELO header, sender - after recieving
MAIL FROM etc. So, they called in that order, and then there are
smtpd_data_restrictions, smtpd_end_of_data_restrictions.
Restrictions differ only in the time of evaluation and in the effect of
a REJECT or DEFER result. Also, a reject message is different ("sender
address rejected", "recipient address rejected", etc.).
smtpd_delay_reject=yes only delays the moment when actual reject is
passed to smtp client, it doesn't affect order of evaluation or anything
else. It says "answer with reject only after recieving RCPT TO, even if
it is HELO that was rejected". And it rejects with HELO reject message
in this case, but after RCPT TO.
- It looks like even if a policy appear in the 3 restrictions, it is
tested only once !
Right ?
Each restriction is designed so that it always evaluates to same result
- why should we evaluate more than once? check_helo_access always checks
same helo string against same checking rules, it is right way to reuse
check results.
- If smtpd_delay_reject=yes then I could merge all the policy in the
smtpd_recipient_restrictions
and cleanup duplicate policy ! Right ?
You can, but you can easily go wrong. Documentation says: "By now the
reader may wonder why we need smtpd client, helo or sender restrictions,
when their evaluation is postponed until the RCPT TO or ETRN command.
Some people recommend placing ALL the access restrictions in the
smtpd_recipient_restrictions
<http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions>
list. Unfortunately, this can result in too permissive access."
It is simply easier to put, say, checking for sasl login and sender
address matching into sender restrictions. This way we get
self-descriptive configuration file and useful error message, because we
actually reject sender address in this case.
