On 25/12/22 02:48, Jaroslaw Rafa wrote:
The various smtpd_*_restrictions lists are applied at various stages of the SMTP transaction. smtpd_client_restrictions are applied right at the beginning of the connection, smtpd_helo_restrictions are applied after HELO/EHLO, and so on.
This is not entirely true, and not true by default, see the smtpd_delay_reject setting in postconf(5).
But in each connection phase Postfix "knows" all the parameters from previous phases too,
Also by default (if smtpd_delay_reject is not set to "no") then the reverse is true as well (e.g. you can use recipient restrictions in smtpd_client_restrictions). Again see postconf(5) for details.
and you can use all the restriction clauses referring to them. So in fact you can ove all restrictions to smtpd_recipient_restrictions and set all previous restrictions to empty.
This is true regardless.
It's just a matter of convenience in which phase you specify particular restrictions.
I will often times put most of my restrictions in smtpd_recipient_restrictions and leave the others blank. There are some exceptions to this (e.g. data restrictions) and you should understand how smtpd_recipient_restrictions and smtpd_relay_restrictions work specifically before just blindly doing this.
One thing to keep in mind here, though, is when you put restrictions in separate restriction sets, any REJECT result in any restriction class will result in the message being rejected. But when you order your restrictions under one class such as smtpd_recipient_restrictions, then if you have a result of PERMIT followed later by a restriction that would have resulted in REJECT the rejection will never get processed and so the message will be permitted. In some cases you can use this to your advantage, but often times people get bitten by this, so if you don't really understand how restriction ordering works and what causes a message to pass or reject based on the restriction lists then it may be best to just leave them in separate restriction sets.
Peter
