Go to the first, previous, next, last section, table of contents.


43. Virtual domains

There are a number of ways in which virtual domains can be handled in Exim. As this seems to be quite a common requirement, some ways of doing this are described here. These are not the only possibilities.

43.1 All mail to a given host

Simply sending all mail for a domain to a given host isn't really a virtual domain; it is just a routing operation that can be handled by a domainlist router.

To send all mail for a domain to a particular local part at a given host, define the domain as local, then process it with a smartuser director that sets the new delivery address and passes the message to an smtp transport which specifies the host. Alternatively, use a forwardfile director pointing to a fixed file name; the file can contain any number of addresses to which each message is forwarded.

43.2 Virtual domains not preserving envelopes

A virtual domain that does not preserve the envelope information when delivering can be handled by an alias file defined for a local domain. If you are handling a large number of local domains, you can define them as a file lookup. For example:

local_domains = your.normal.domain:\
                dbm;/customer/domains

Where /customer/domains is a DBM file built from a source file that contains just a list of domains:

# list of virtual domains for customers
customer1.domain
customer2.domain

This can be turned into a DBM file by exim_dbmbuild.

You can then set up a director (see below) to handle the customer domains, arranging a separate alias file for each domain. A single director can handle all of them if the names follow a fixed pattern. Permissions can be arranged so that appropriate people can edit the alias files. The domains option ensures that this director is used only for the customer domains. The DBM file lookup is cached, so it isn't too inefficient to do this. The no_more setting ensures that if the lookup fails, Exim gives up on the address without trying any subsequent directors.

virtual:
  driver = aliasfile
  domains = dbm;/customer/domains
  no_more
  file = /etc/mail/$domain
  search_type = lsearch

A successful aliasing operation results in a new envelope recipient address, which is then directed or routed from scratch.

43.3 Virtual domains preserving envelopes

If you want to arrange for mail for known local parts at certain domains to be sent to specific hosts without changing the envelope recipients of messages, then the following is one way of doing it.

Set up the domains as local, and create an aliasfile director for them, as above, but in addition, specify a transport for the director:

virtual:
  driver = aliasfile
  domains = dbm;/customer/domains
  transport = virtual_smtp
  no_more
  file = /etc/mail/$domain
  search_type = lsearch

Each domain has its own alias file, but the provision of a transport means that this is used purely as a check list of local parts. The data portion of each alias is not used.

The transport has to look up the appropriate host to which the message must be sent:

virtual_smtp:
  driver = smtp
  hosts = ${lookup{$domain}dbm{/virtual/routes}{$value}fail}

The file /virtual/routes contains lines of the form

customer1.domain:  cust1.host
customer2.domain:  cust2.host

and the messages get delivered with RCPT (the envelope) containing the original destination address (for example, postmaster@customer1.domain). In fact, you could use the same file for /virtual/routes and /customer/domains, since the lookup on the latter doesn't make any use of the data -- it's just checking that the file contains the key.


Go to the first, previous, next, last section, table of contents.