Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: mouss (mlist.onlyfree.fr)
Date: Tue Apr 24 2007 - 09:14:34 CDT
Mark Watts wrote:
> 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
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_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).