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


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.

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.

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.

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.