On Thu, Nov 29, 2012 at 05:31:29PM +0200, Geoff Shang wrote:
> Right now, the company itself is using a particular domain for its
> Email, lets call it example.com. But, in a classic case of not
> thinking far enough ahead, it's been decided that the example.com
> domain will now be used for our Email service for customers, and
> that corporate mail will be moved to a new domain, lets call it
> example2.com.
In my experience, public facing email domains for organizations
with complex email requirements are almost almost best implemented
as virtual alias domains. This adds a layer of indirection between
the outside view of an email domain (everyone is just u...@example.com)
and the inside view (rewrite to u...@users-mailbox-domain.example.net).
With this there is no crisis as managent changes requirements,
acquires a new division, ... Just add more rewrites and a transport
entry if necessary if any of the underlying mailbox domains need
non-trivial routing.
default_database_type = cdb
indexed = ${default_database_type}:${config_directory}/
relay_domains =
virtual_alias_domains = example.com
# Feel free to use LDAP, ...
virtual_alias_maps = ${indexed}virtual
# Stick to indexed files, and keep it simple:
transport_maps = ${indexed}transport
You don't list the users twice and set relay_domains empty.
virtual:
u...@example.com u...@imap.example.com
custo...@example.com custo...@custimap.example.com
transport:
# Add [] if destination is by design an A not an MX RRset.
imap.example.com relay:imap.example.com
custimap.example.com relay:custimap.example.com
The "relay" transport is chosen so it does not compete for process slots
with outbound mail and is often tuned with more appropriate timeouts, ...
for internal delivery.
--
Viktor.
