Wietse Venema:
> Viktor Dukhovni:
> > > Sorry, it must be the same interface as access tables. Special
> > > cases are taboo.
> >
> > I'm not fond of lossful mangling of the input, especially if policy
> > services are liable to get it wrong. Perhaps this idea needs to
> > wait until the Postfix dictionary layer understands multiple results,
> > returning a list rather than a concatenation. At that point,
> > suitable variants of pcre/regexp or directives at the top of the
> > file can turn on list splitting of the RHS prior to sub-pattern
> > replacement.
>
> Postfix has a simple string interface for its key-value store. I
> have an aversion against changing that into some binary protocol
> with sub-record structure. Similar to my aversion against systemd
> logging, among other things.
JSON can be represented as printable ASCII, and circumvent some of
my aversion against binary protocols. But wait, there is more.
Fundamentally, there is a high cost when switching from the current
"no encoding" table lookup interfaces to "some encoding": all Postfix
tables would have to switch from the current unencoded interface
to some encoded interface, based on JSON or something else.
This is not a matter of adding a special-case entry at the top
of some regexp or pcre file. Multikey/multivalue representation
pervades all map interfaces. Exceptions are not allowed.
This is what a single-key, multi-value, JSON-based system aliases
database would look like:
current:
root: foo, bar
becomes:
"root" ["foo","bar"]
To implement two-key lookup with Berkeley DB, we'd specify something
like ["xxx","yyy"] as the real Berkeley DB database lookup key,
where "xxx" is the first key and "yyy" the second one. In other
words, it is faked with concatenation.
The same encoding would be used internally in the Postfix SMTPD
policy protocol queries and responses: the query as a list of (key,
value) pairs, and the result as a list of values. Every policy
server would have to switch to the new encoding.
Now, suppose we have a single-key, multi-value access map entry
in some PCRE table:
/^(.+@example\.com)$/ ["warn redirecting $1", "redirect f...@example.net"]
(Presumably, two-key matching would require two PCRE patterns.)
Here, the PCRE map would replace quotes and backslashes in the
expansion of $number with JSON escape sequences, so that the expanded
text cannot change the syntactical structure of the result.
Wietse
