Noah Meyerhans wrote:
> Hi all. I've got a legacy domain that I'd like to turn into a virtual
> host. This is straightforward, and I've got a bunch of these. This one
> is somewhat different, though, because there are a whole mess of other
> domains that, using MX records, are basically synonymous with this one
> domain. I'd like to avoid any sort of static configuration for these
> various other domains, since they'll all "legacy" and should gradually
> go away. I'd also prefer to abstract the specific domain names out of
> the exim config, so I can do this for additional domains in the future
> if needed.
Probably helpful then to also utilize a lookup in the 'MAIN' section where you
define the hostlist as to which domains are treated as 'local'
ISTR examples have been posted here using flatfiles, SQL, and other things in
between.
>
> In other words, we've got foo.example.com, which I'd like to turn into
> the virtual host. But then we've also got bar.example.com that lists
> foo.example.com as it's primary MX.
>
> So I've created these routes:
>
> legacy_mx:
> driver = manualroute
> domains = @mx_primary : !+local_domains
> self = pass
> route_data = ${lookup dnsdb{mxh=$domain}}
>
> legacy_redirect:
> driver = redirect
> domains = @mx_primary : !+local_domains
> condition = def:self_hostname
> data = ${lookup {$local_part}dbm{/etc/exim/$self_hostname.db}}
> allow_fail
> allow_defer
>
'Sems sane' dnsdb expert will be along shortly.
But I'm not sure you will actually need all of it *IF* the 'sunset' domains you
are 'gathering up' will remain served on this box.
Having them listed as local_domains (so they do not head off-box) may be the
larger part of what you need.
Throw a shoe at me if I've missed the point and they *are* off-box..
> The idea is that I'll create an A record in DNS for
> foo-legacy-mx.example.com that points to this host. The various MX
> entries for the domains will be updated to list this host, rather than
> the original target (call it foo.example.com). Then
> /etc/exim/foo-legacy-mx.example.com.db will be a dbm database of the
> aliases for this virtual host configuration. Exim will know to check
> that file because the legacy-mx route will set $self_hostname when it
> passes control to the legacy-mx-redirect route.
>
> This seems to work in simple cases when testing, but I'd like to see
> what others think. Is this a reasonable approach? Is there a better
> way?
>
> Thanks,
> noah
>
>
I can't say 'better' - as SQL is no lightweight, and a lightweight is all you
really need.
But what we use for essentially the same purpose in SQL should be much the same
if drawing data from a dbm.
=====
# ROUTE_6A LOCAL:
#
db_user:
driver = accept
transport = db_delivery
condition = ${lookup pgsql{SELECT pg_mailroot FROM mailprof \
WHERE pg_local_part='${quote_pgsql:$local_part}' AND \
pg_domain='${quote_pgsql:$domain}'}}
cannot_route_message = Not known to us.
NB: Target User AND domain have to be in the DB before traffic will be accepted.
============
# TRANSPORT_4 LOCAL DB: db_delivery.
#
db_delivery:
driver = appendfile
user = <redacted>
group = <redacted>
delivery_date_add = true
envelope_to_add = true
return_path_add = true
maildir_format = true
mode = <redacted>
directory = /${lookup pgsql{SELECT ... <redacted>
create_directory = true
directory_mode = <redacted>
NB: target mailstore does NOT have to exist before first message arrives.
Note also, that as all but the very root of the mailstore is DB resident, it is
dead-easy to migrate users mailstores intact to new domains (Dovecot being
driven off the same DB here).
=====
I list these primarily to demonstrate that a stock 'accept' and a stock
'appendfile' get the job done w/o need of manualroute or redirect, for *our*
needs. YMMV, of course..
IF the legacy domains are to be OFF box, OTOH - or at least for a while ...
What we have used is a simple router for each domain that sets up address_data
and helo_data.
Whichever one has triggered then calls the *same* transport, which changes
colour & flavour based on the address-data and helo_data onpassed to it.
HTH,
Bill
