Mixing of address classes per domain

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Mixing of address classes per domain

Andreas Thienemann
Hi,

I have inherited an older postfix and sendmail system with a cyrus imapd.
My plan now is to migrate that to a postfix 3.x MTA with a dovecot imap
backend.
Pretty standard so far.

When trying to migrate the existing mail routing logic I did come accross
certain rules which are working correctly on the old system but where I am
having problems fitting them into the current address classes logic.

Local addresses are handled currently through a mailbox_transport =
lmtp:private/dovecot-lmtp entry. This is working fine for addresses
directed at hosts listed at mydestination.

I do have a handfull of users received mail via UUCP which I am handling
as members relay domain class. These I have configured with a
relay_domains lookup table containing full hostnames such as
"foo.example.com OK" and a transport_maps entry of "foo.example.com
uucp:foo". This too is working well.
I also have a few FQDNs where the nexthop is a smtp server, where the
setup is handled via relay_domains and transport_maps as well.

Where I am a bit unsure is how I want to handle the virtual addresses.
I do have a bunch of domains for which I want postfix to handle mail and
deliver mainly to local users via lmtp to dovecot.

My initial plan was to use the virtual_alias_domains and
virtual_alias_maps entries to ensure correct delivery for these addresses.
My routing rules here are as follows:
[hidden email] -> foo
@bar.example.com -> bar
@foobar.example.com -> [hidden email]

99% of these target addresses/values are local accounts with no either no
domain or example.com which is part of the mydestinations entry.
For these, traffic is correctly delivered.

My problem is, I do have a handful of domains where routing is very mixed.
I might have a catchall account @baz.example.com -> baz but I have _also_
a need to route the more specific [hidden email] -> uucp:bar.

As far as I understand, the virtual_alias_maps will only do rewriting to
local or remote addresses but disregard transport entries.

I would really prefer _not_ to create any workarounds where I redirect
[hidden email] to [hidden email] which then is added to
relay_domains and gets a transport entry. The existing setup seemed to be
able to cope directly with the redirect to uucp rather than needing any
workarounds.

Does anyone have a hint how to get this working correctly? Adding the
domain to both virtual_domains and relay_domains seems to work but as far
as I understand previous discussions here on the list this is a rather bad
idea.

Cheers,
  Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Mixing of address classes per domain

Viktor Dukhovni

> On Sep 18, 2017, at 11:35 AM, Andreas Thienemann <[hidden email]> 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.

It is virtual_alias_domains that preempts transport selection for
addresses that are NOT rewritten to some real domain.  Thus you
can have:

        mydestination = local.example.com, ...
        relay_domains = real.example.com, ...
        virtual_alias_domains = valias.example.com, ...
        virtual_mailbox_domains = vmbox.example.com, ...

and the only constraints are:

* Each domain belongs to exactly one address class.
* ONLY domains that contain no real recipients to be
  handed off to some transport for delivery may be
  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 [hidden email]
        [hidden email] [hidden email]

and then in transport_maps:

        [hidden email] uucp

or, conversely

        real.example.com uucp

If the majority of users that stay in @real.example.comm use that
transport.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Mixing of address classes per domain

Andreas Thienemann
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 [hidden email]
> [hidden email] [hidden email]

What does the mapping of the mailbox to itself do? I had not seen that
before in the docs.


> and then in transport_maps:
>
> [hidden email] 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 [hidden email]
mapping back to itself. Is that entry needed in such a form?

cheers,
  Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Mixing of address classes per domain

Viktor Dukhovni

> On Sep 18, 2017, at 12:59 PM, Andreas Thienemann <[hidden email]> wrote:
>
>> * 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?

Virtual alias rewriting applies to *all* recipients, regardless of address
class.

>> 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 [hidden email]
>> [hidden email] [hidden email]
>
> What does the mapping of the mailbox to itself do? I had not seen
> that before in the docs.

It avoids hitting the catch-all for that address.  More specific
lookup keys preƫmpt less-specific lookup keys, but keep in mind
that rewriting is recursive and stops only when:

   * A lookup key maps to itself, OR
   * A lookup key is not found, Or
   * The recursion limit is reached

Otherwise, the RHS of a lookup becomes the LHS of the next lookup
up to the recursion limit.

>> and then in transport_maps:
>>
>> [hidden email] 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 [hidden email]
> mapping back to itself. Is that entry needed in such a form?

Transport selection happens downstream of virtual alias rewriting.
If the address rewrites to something else, transport lookup is
based on the final output of virtual alias rewriting.

--
        Viktor.