“Does this mean that a condition in smtpd_helo_restrcitiosn which
triggers a "REJECT" will, upon entering RCPTO TO mode, result in the
rejection with nothing else evaluated?”
Yes but it doesn’t matter in which of the 5 lists it is encountered.
Once REJECT is encountered, all evaluation ends…
“If so, it sill makes sense to put them all in
smtpd_recipient_restrictions”
Not necessarily - it will depend on how one structures their tests.
Keeping them in separate lists affords one the option of PERMIT’ing
several different sets of rules whereas as if all in RECIPIENT, then all
processing stops as soon as the first PERMT, REJECT, or DEFER is
encountered. This is distinctly different PERMIT behavior vs. having
them in separate lists.
- - -
On 10 Mar 2021, at 15:20, JF Mezei wrote:
On 2021-03-10 15:08, Noel Jones wrote:
This is incorrect. With the default smtpd_delay_reject=yes, all
evaluations are performed after the client sends RCPT TO.
Thanks for clarification. Reading the docs of delay_reject brings up
another question:
"Wait until the RCPT TO command before evaluating
$smtpd_client_restrictions, $smtpd_helo_restrictions and
$smtpd_sender_restrictions"
Does this mean that a condition in smtpd_helo_restrcitiosn which
triggers a "REJECT" will, upon entering RCPTO TO mode, result in the
rejection with nothing else evaluated?
(aka: does the documentation have an implicit "in that order" after
the
$smtpd_sender_restrictions" ?
If so, it sill makes sense to put them all in
smtpd_recipient_restrictions as you can be explicitely order the
excecution of tests from any of the phases in the order that suits you
(aka: permit a sender before the test for helo are done).
