On 01/05/2019 22:04, Viktor Dukhovni wrote:
> On Wed, May 01, 2019 at 09:57:29PM +0200, John Fawcett wrote:
>
>>> 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.
>> 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.
> As mentioned above, it is not just virtual aliases, but the proposed
> compatibility break is likely what most users actually expect, and
> then have to learn the actual non-intuitive behaviour.
Thanks for clarifying. I had missed that.
I can only answer for myself, but still it would be no issue even if the
search order is changed for all these because I tend to use single tables.
I do use multiple tables in local_recipient_maps but for lists it does
not make any difference to the result if the search order is changed.
John
