On 28/04/2019 21:49, Wietse Venema wrote:
> ...
>
> Once the above is implemented, the same approach could be used to
> improve other parts of Postfix by making existing hard-coded behavior
> configurable, for example how check_client_access looks up subnet
> and partial address information, or how virtual_alias_maps looks
> up full and partial address forms. The examples below show the
> lookup order that is currently hard-coded.
>
> smtpd_mumble_restrictions =
> ...
> check_client_access {
> maptype:mapname,
> # instead of parent, maybe use dot-parent or no parent
> { search = domain, parent, address, subnet }
> }
> ...
>
> virtual_alias_maps = {
> hash:/etc/postfix/virtual,
> { search = full, full-noext, localpart-if-local, at-domain }
> } {
> other table ...
> }
>
> Ditto for canonical_maps and transport_maps.
>
> This would be a compatibility break, because with the above, all
> virtual_alias_maps searches are done on the first table before
> trying the next table. One could argue that current behavior is
> non-intuitive.
>
> ....
>
> Wietse
Sounds like a good idea which should make the code more robust by
removing hard coded logic in multiple places.
If virtual_alias_maps are the only place where postfix searches for a
pattern across multiple tables before passing on to the next pattern
then it should not be too much of a surprise to bring it in line with
the rest of the lookup logic.
I guess that virtual_alias_maps configurations with multiple tables are
less common than those with a single table. However, if strong reasons
come out against the change, the search order could be configurable
either "horizontally" across multiple tables or "vertically" into single
tables. It would just mean sorting the name_code vector a different way
from the default. Though personally I would vote for the incompatible
change.
John
