- On 3/27/2013 10:07 PM, Matthew Hall wrote:
> One other question here. So, if I have a host which matchesYes, first match wins.
> 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
- for the purpose of this discussion, we'll treat "OK" and "permit"
- the smtpd_*_restrictions are executed in the order:
smtpd_relay_restrictions (if your postfix supports this)
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.
-- Noel Jones
- On 2013-03-27 23:11, Matthew Hall wrote:
> I ran into a bit of an issue trying out fqrdns.pcre as recommendedadd permit_sasl_authenticated before fqrdns.pcre testing
> here in this thread. The header in the file recommended adding it
> smtpd_client_restrictions. However if I place it there, I end up
> rejecting mail even from SASL authenticated client devices, if they
> also match a rule in fqrdns.pcre.
senders that put my email into body content will deliver it to my own
trashcan, so if you like to get reply, dont do it