Mismatch virtual_alias_maps

[b...@systron.de]

Hello list.

This is not working:

user1@host1 sends mail to userX@host2
Intention: userX@host2 incoming forwarding to user2@host1

host2 virtual_alias_maps:
@host1 user1@host1
@host2 user2@host1

But user1@host1 receive back his eMail with origin userX@host2


This runs after a lot of trials:

host2 virtual_alias_maps:
@host2 user2@host1


postfix Version: 2.7.1-1+squeeze1

The logic of the virtual_alias_maps select with the sender
the entry of the virtual_alias_maps, i assume.

Any comments?

[Jeroen Geilman]

On 05/01/2013 11:17 AM, b...@systron.de wrote:
> Hello list.
>
> This is not working:
>
> user1@host1 sends mail to userX@host2
> Intention: userX@host2 incoming forwarding to user2@host1
>
> host2 virtual_alias_maps:
> @host1 user1@host1
> @host2 user2@host1

Don't blindly use catch-alls; see below for why.

> But user1@host1 receive back his eMail with origin userX@host2

virtual_alias_maps is recursive; lookups are performed until the result
no longer matches a lookup key, or the input is equal to the output.

In your case: RCPT TO userX@host2 is rewritten by virtual_alias_maps to
user2@host1.

The new recipient is again matched and rewritten to user1@host1.

At this point virtual_alias_maps stops expanding, since it will keep
resolving to user1@host1; single-level loop detection is built in.

> This runs after a lot of trials:
>
> host2 virtual_alias_maps:
> @host2 user2@host1

Which begs the question why you have a host2 at all.

> postfix Version: 2.7.1-1+squeeze1
>
> The logic of the virtual_alias_maps select with the sender
> the entry of the virtual_alias_maps, i assume.

No, virtual_alias_maps does not affect nor act upon the SENDER address.

Whatever problem you are trying to solve, it is much better served by
judicious use of transport_maps and/or unfscking your MX setup.

--
J.