From: mouss (mlist.onlyfree.fr)
Date: Tue Apr 24 2007 - 09:14:34 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Mark Watts wrote:
> [snip]
> That explains one or two odd things we were seeing after I made the change.
>
> Theres obviously an order these get processed in - is it documented anywhere?
> (flow-chart would be nice)
>

the main doc is
    http://www.postfix.org/SMTPD_ACCESS_README.html

Things to keep in mind:

- postfix executes restrictions in this order: client, helo, sender,
recipient (let's keep data out of this discussion)

- in each set, checks are exectued sequentially. each check returns one
of the documented actions (permit, reject, ....).

- some actions stop processing of all restrictions (reject is an example).
- some other actions stop processing of the current restriction set, so
postfix moves to the next restriction set (permit is an example).
- other actions are not final (dunno is an example). some of these may
change a "state" of the transaction (FILTER is an example as it sets the
content_filter to be used).

regarding "exploded" vs "compact" versions, consider the following example.

smtpd_client_restrictions = check_foo
smtpd_recipient_restrictions = check_bar

This is the same as

smtpd_client_restrictions =
smtpd_recipient_restrictions = check_foo2, check_bar

where check_foo2 is similar to check_foo, but you need to think of the
"final" actions discussed above. for example, a PERMIT in check_foo must
be replaced by a DUNNO in check_foo2.

if check_foo returns multiple checks (such as "permit_mynetworks,
check_blah_blah, check_blah2...") or if there are multiple checks in
smtpd_client_restrictions, then the conversion is harder than in the
example above (you can't just replace PERMIT with a DUNNO, because you
need to skip all subsequent checks until check_bar).

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]