Phil Pennock wrote:
> On 2009-06-10 at 14:36 -0400, 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.
>>
>> 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}}
>
> So @mx_primary matches where this host is the primary MX; you then
> generate a list of all hosts in any MX record for this domain and route
> it to them, thus you're having the primary MX send mail to the backups
> as well as itself.
>
> So if I set up MX records with you as primary and 10 other hosts, I have
> a 10/11 chance of using you as an open relay; the address will verify
> and depending upon config still be routed off-site, depending upon
> setup. This seems fragile.
>
> Generally, deferring trust of which domains you trust to be "you" to DNS
> is fragile, unless you control which DNS servers you're checking and not
> using normal DNS at all. Ie, still fragile in practice.
>
> Since you're relying upon $self_hostname.db existing for the domain, to
> hold the aliases, why not use the existence of an aliases file to create
> support for a domain?
>
> You could use the require_files pre-condition on a router, for instance.
> So once the aliases file for a domain exists, you accept mail for that
> domain.
>
> -Phil
>
Taking that a step further - maybe ...
Assumption:
1) Mailstore for all domains involved already exists or is easily created as a
skeleton set up by test messages ELSE manually
2) Mailstore is of the format:
/<mailstore_root>/domain.tld/$local_part/<mbox or Maildir structure>
- If the 'target' (virtual) hosts are to 'gradually go away'..
WHILE the target (old) domains and users exist in the mailstore:
dsearch;/<mailstore_root>/ finds the <domain>.<tld> for $domain
dsearch;/<mailstore_root>/domain.tld/ finds the users for $local_part
NB: Exim needs to be built with dsearch. dsearch can be used in BOTH acl's AND
router/transport sets. 'require_files' also a good idea..
AS selected domains 'go away', their mailstore is deleted (unlikely), moved to
archive storage (possible), left in place 'until', ELSE renamed/merged-into
domains intended to survive/replace/consolidate those 'going away' (thereby
preserving the messages of users).
The dsearch(es) automagically keep track of which $domains and users are still
active 'locally'.
mx records (or lack of same) are still relied on for any domains moved off-box
or 'retired' totally.
Better than a DBM?
Pass.
Depends on how many domains, what ELSE needs doing, and what the balance might
be between admin effort and .. whatever.. I'm ass u me 'ing a phased migration
here with active users who are eventually to have new domains.
Not used as described, but used two other ways, and works well:
- automagically add/remove domains and mailing lists w/o altering Exim or alias
files or Ecartis scripts.
- automagically grant a 'pass' on incoming to correspondents our users have sent
to at least once (applying the dsearch to the by-addressee outbound archive
mailstore).
Bill
