Am 22.10.2014 um 15:49 schrieb Wietse Venema:
The basic idea is to permit more than one action in an access(5) or
header_checks(5) table lookup result or SMTPD policy response:
A few examples to clarify:
/etc/postfix/access:
# The new multi-action form.
1.2.3.4 { prepend header text... } other actions...
/etc/postfix/header_checks:
# "prepend"+"ignore" should be equivalent to "replace".
/foo/ { prepend replacement header text... } ignore
policy service:
# The new multi-action form.
action = { prepend new header text... } other actions...
In all cases the historical one-action form still works as before.
Remember that Postfix access maps and policy service replies may
contain the same things that are used in smtpd_mumble_restrictions?
With the above syntax means we can now also use all the access(5)
map results in smtpd_mumble_restrictions:
/etc/postfix/main.cf:
smtpd_mumble_restrictions = ... { defer text... }
smtpd_mumble_restrictions = ... { defer_if_permit text... } ...
Why not use the form "command { arguments... }"? The reason is that
historically, commands like "defer" and "reject" have no arguments
when used in smtpd_mumble_restrictions. In order to give those
commands arguments we need the form "{ command arguments... }".
This way we avoid breaking the compatibility of core Postfix features
such as defer" and "reject".
For consistency, the same "{ command args.. }" form must then be
used in access(5) or header_checks(5) table lookup results, and
in SMTPD policy responses
sounds interesting
what i would love is more than one lookup key like specify a action for
a pair "sender rcpt action" what would it make really easy do define
whitelists and blacklists in access tables
@postfix.org @rhsoft.net OK
@example.org @rhsoft.net REJECT
a...@example.org li...@rhsoft.net REJECT
that way and combined with a simple database scheme one could build more
or less complex rules and save for many cases a policy daemon
