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.
There is a small gotcha: the $number expansion in regexp and pcre
table lookup results happens before {} parsing. This would make {}
parsing dependent on the content of $number expansion, i.e. untrusted
data, creating a command injection vulnerability.
To avoid this:
- Either the {} parsing needs to be done before $number expansion.
I'm rejecting this option because it is likely to break the
orthogonality of the Postfix table lookup interface, and that must
be avoided at all cost.
- Or the $number expansion stays where it is now, before {} parsing,
but the caller can specify a filter that censors out {} in $number
expansions, so that the caller's command parser cannot be tricked
into executing the wrong command. This extends the table API with
one function that does nothing except for regexp and pcre tables.
(Of course nothing in Postfix can protect against accidents caused
by text manipulations inside a policy daemon; they would have to
censor themselves, or Postfix would need an option to disable {}
support for policy filter replies).
The second option would be applicable for any feature that uses
table lookups with untrusted data in the lookup key and that does
non-trivial parsing of the lookup result. Examples of such features
are header/body_checks, smtp_header/body_checks, milter_header_checks,
access maps, but not smtpd_command_filter or *_delivery_status_filter.
Wietse
