On 3/28/2013 12:12 AM, Noel Jones wrote: > Yes, first match wins.
This needs to be *immediately* followed by what you stated way down below, copied here: > - 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. Otherwise it can cause serious confusion with new/inexperienced users. And this is one of the big reasons I recommend folks put everything under smtpd_recipient_restrictions. I don't have the thread archived (it's been 8 years or so), so I'm guessing here, but IIRC it took at least a half dozen or more emails back-forth before I understood this lack or inheritance. Once I did, and realized how much I'd have to duplicate among the sections, I switched to EURR (everything under recipient restrictions). -- Stan > > 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 >
