Discussion:
beefing up Postfix macro processing
(too old to reply)
Wietse Venema
2014-09-12 21:21:59 UTC
Permalink
I've been looking into an old wish to make Postfix headers and (some
of the) Postfix logging configurable. But before that could happen,
the $name expansion logic needed to be extended because it is a bit
under-powered.

This week I added support for if-then-else logic in conditional
$name expansion and support for conditional expansions based
on the (in)equality of text strings. For example:

${name?{text1}:{text2}}
${{text1} == ${text2} ? {text3} : {text4}}

Where text1..text4 are subject to $name expansion. For the curious:
``${{text1} == ${text2}}'' evaluates to empty or "true". I did not
want to change how the existing "?" and ":" operators work.

All this works recursively, so that in a future release we will be
able to do something like this:

/etc/postfix/main.cf:
received_header = Received:${client_name?
{ from ${helo_name?{$helo_name}:{$client_name}}
($client_name [$client_address])\n }
${tls_protocol? {
...more hairy stuff...
}
by $myhostname ($mail_name) ...

(\n will have to be replaced with newline; whitespace outside {text}
is ignored; the main.cf read function replaces newline-whitespace
with a single space; and $myhostname will have to be expanded
recursively while $client_name will have to be expanded only once).

However, before Postfix headers and logging can be made configurable,
there needs to be a consistent set of attribute names for logging,
for main.cf configuration, and for the policy delegation protocol.
We don't want to have multiple names for the same thing, nor do we
want that the name means different things in different contexts.

This means tweaking some policy delegation protocol attribute names
to make them more specific, and finalizing the attribute names in
Viktor's TLS audit logging, which is currently available as part
of a non-prod release.

Wietse
Wietse Venema
2014-09-12 22:24:26 UTC
Permalink
Typo corrected below: I should have ``{text1} == {text2}'' instead
of ``{text1} == ${text2}''.

Wietse

I've been looking into an old wish to make Postfix headers and (some
of the) Postfix logging configurable. But before that could happen,
the $name expansion logic needed to be extended because it is a bit
under-powered.

This week I added support for if-then-else logic in conditional
$name expansion and support for conditional expansions based
on the (in)equality of text strings. For example:

${name?{text1}:{text2}}
${{text1} == {text2} ? {text3} : {text4}}

Where text1..text4 are subject to $name expansion. For the curious:
``${{text1} == {text2}}'' evaluates to empty or "true". I did not
want to change how the existing "?" and ":" operators work.

All this works recursively, so that in a future release we will be
able to do something like this:

/etc/postfix/main.cf:
received_header = Received:${client_name?
{ from ${helo_name?{$helo_name}:{$client_name}}
($client_name [$client_address])\n }
${tls_protocol? {
...more hairy stuff...
}
by $myhostname ($mail_name) ...

(\n will have to be replaced with newline; whitespace outside {text}
is ignored; the main.cf read function replaces newline-whitespace
with a single space; and $myhostname will have to be expanded
recursively while $client_name will have to be expanded only once).

However, before Postfix headers and logging can be made configurable,
there needs to be a consistent set of attribute names for logging,
for main.cf configuration, and for the policy delegation protocol.
We don't want to have multiple names for the same thing, nor do we
want that the name means different things in different contexts.

This means tweaking some policy delegation protocol attribute names
to make them more specific, and finalizing the attribute names in
Viktor's TLS audit logging, which is currently available as part
of a non-prod release.

Wietse

Loading...