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 $* < @ $+ > $* $: < @ $(domaintable $) > 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. |