Hi Viktor,
On Mon, 18 Sep 2017, Viktor Dukhovni wrote:
As far as I understand, the virtual_alias_maps will only do rewriting
to local or remote addresses but disregard transport entries.
No, this is not the case. All that happens with virtual_alias_maps
is recursive rewriting of all input recipient addresses to some final
address.
Ah okay. Then I misunderstood the documentation there. Thanks for
clarifying this.
[...]
and the only constraints are:
* Each domain belongs to exactly one address class.
That was clear already from the existing documentation.
* ONLY domains that contain no real recipients to be
handed off to some transport for delivery may be
listed in virtual_alias_domains.
So just to confirm: virtual_alias_maps is also consulted for a match for
addresses _not_ listed in virtual_alias_domains?
Therefore you can have in virtual_alias_maps:
# The dreaded catchall applies to all mailboxes that
# are not explicitly mapped to themselves or out of the
# domain
@real.example.com catc...@local.example.com
j...@real.example.com j...@real.example.com
What does the mapping of the mailbox to itself do? I had not seen that
before in the docs.
and then in transport_maps:
j...@real.example.com uucp
or, conversely
real.example.com uucp
If the majority of users that stay in @real.example.comm use that
transport.
During my testing the transport_maps entry seemed to not have been
consulted, but then again I also did not have the j...@real.example.com
mapping back to itself. Is that entry needed in such a form?
cheers,
Andreas
