On 3/27/2013 10:07 PM, Matthew Hall wrote: > One other question here. So, if I have a host which matches > permit_sasl_authenticated, but also matches one of the rejections > present in check_reverse_client_hostname_access, but > permit_sasl_authenticated comes first in recipient_restrictions, then > it's still going to work right, because the first rule in the chain > wins, correct? Just want to be sure I parsed the documentation > correctly.
Yes, first match wins. http://www.postfix.org/documentation.html - for the purpose of this discussion, we'll treat "OK" and "permit" as interchangeable. - the smtpd_*_restrictions are executed in the order: smtpd_client_restrictions smtpd_helo_restrictions smtpd_sender_restrictions smtpd_recipient_restrictions smtpd_relay_restrictions (if your postfix supports this) smtpd_data_restrictions smtpd_end_of_data_restrictions You might notice this is the same order as an SMTP transaction. Details here: http://www.postfix.org/OVERVIEW.html - within each smtpd_*_restrictions section, restrictions are executed in exactly the order you specify. - first match wins - any REJECT/DEFER action takes effect immediately; all subsequent smtpd_*_restrictions are skipped. - each smtpd_*_restrictions section must resolve to "permit" (or empty) to accept mail. A "permit" in one smtpd_*_restrictions section is not inherited by the next section. - special case -- access(5) documents several "OTHER ACTIONS" other than OK/REJECT. These actions stop processing of that single access table and skip to the next rule within the same smtpd_*_restrictions section. DEFER_IF_PERMIT and DEFER_IF_REJECT are also treated this way; they don't take effect until a REJECT or (final) PERMIT decision is made. http://www.postfix.org/access.5.html -- Noel Jones
