Some sites need to use multiple domain names when transitioning from an old domain to a new one. The domaintable feature enables such transitions to operate smoothly by rewriting the old domain to the new. To begin, create a file of the form:

old.domain    new.domain

In it the left side of each line has one of possibly many fully qualified hostnames, and the right side has the new name. The makemap(1) program (Section 5.5) is then used to convert that file into a database.

The domaintable feature causes a rule such as this to be included in your configuration file:

R $* < @ $+ > $*                 $: $1 < @ $(domaintable $2 $) > $3

Here, each host part of an address in the canonify rule set 3 is looked up in the domaintable map. If it is found, the new name from that map replaces it.

The domaintable feature enables this lookup by including a K configuration command:

Kdomaintable hash /etc/mail/domaintable

The form of the domaintable feature is:

FEATURE(`domaintable')

The domaintable feature is one of those that can take an argument to specify a different form of, or different name for, the database:

FEATURE(`domaintable',`dbm /etc/mail/db/domaintable')

The extra argument causes the aforementioned K command to be replaced with the following one:

Kdomaintable dbm /etc/mail/db/domaintable

You can provide an extra argument that is a literal LDAP:

FEATURE(`domaintable', `LDAP')

The default in this instance becomes the following (we have wrapped the lines to fit the page):

Kdomaintable ldap -1 -v sendmailMTAMapValue -k (&(objectClass=sendmailMTAMapObject)
(|(sendmailMTACluster=${sendmailMTACluster})(sendmailMTAHost=$j))
(sendmailMTAMapName=domain)(sendmailMTAKey=%0))

See ldap (was ldapx) for a description of the ldap database type and its -1, -v, and -k switches.

Although this feature might appear suitable for a service provider that wishes to accept mail for client domains, it really is not. Such a service provider should use the virtusertable feature (FEATURE(virtusertable)) instead.