Wietse Venema:
> Viktor Dukhovni:
> > On Fri, Jul 24, 2015 at 01:32:40PM +0200, Dominik Chilla wrote:
> >
> > > I'm trying to use the new inline:{key=value, ...} map in combination with
> > > smtpd_restriction_classes. What I want the map to do is to reject by
> > > default (last key is a kind of wildcard?) if no key=value matched.
> >
> > The "inline" table type has no support for wildcards. It only
> > supports literals.
> >
> > > Is it possible to specify a wildcard-key in an inline map?
> >
> > No.
>
> I'm thinking of adding multi-table lookup (similar to canonical_maps,
> transport_maps, and other _maps features that can search more than
> one table. Then one could say:
>
> check_mumble_access maps:{inline:{key=value, ...}, static:{reject text...}}
>
> Being able to search multiple maps can be useful as a general feature.
TL;DR: I implemented and documented(!) this in the train home. The
code is very similar to that of the pipemap:{} table. Unfortunately,
this implementation is not suitable for Postfix access map queries.
Gory details: Postfix access maps not only look up the full query
string (for example a domain name, an email address, or a network
address) but also substrings of the query string (for example a
parent domain, the localpart of an email address, or a network
prefix that contains the network address). Those substring queries
should be made only with tables such as hash:, ldap: and the like,
but not with cidr:, pcre: or regexp: tables. In order to be useful,
access maps should support combinations of all those table types,
and that is where my initial maps:{...} implementation fails. It
cannot know whether a query is for a full string or for a substring.
This can be fixed in two ways: 1) modify the Postfix low-level
dict(3) API so that a request can specify whether a query is for a
full string or for a substring, or 2) re-implement access map lookups
on top of the higher-level Postfix maps(3) layer where a request
can already specify that a query is for a full string or for a
substring. The first approach involves changes to all low-level
lookup table implementations, and the second approach requires that
access map queries and maybe other Postfix queries be migrated
from the low-level dict(3) API to the higher-level maps(3) API.
Another consequence is syntax. If we don't change the low-level
dict(3) API then we can't use a notation like xxx:{yyy}. Instead,
perhaps we can use something like:
check_mumble_access {inline:{key=value, ...}, static:{reject text...}}
Of course, orthogonality then demands that we allow {table(s)...}
everywhere where Postfix syntax currently allows ONE table, and
that requires migrating other user-visible features from dict(3)
to maps(3). Most user-visible features already work on top of
maps(3), but access(5) was implemented before that API existed.
Wietse
