A mailertable is a database that maps host.domain names to special delivery agent and new domain name pairs. Essentially, it provides a database hook into the parse rule set 0. Because mailertable follows handling of the local host, none of the hosts in the $=w ($=w) will be looked up with this feature.

New domain names that result from a mailertable lookup are used for routing but are not reflected in the headers of messages.

To illustrate, one mapping in a source text file could look like this:

compuserv.com    smtp:compuserve.com

The key portion (on the left) must be either a fully qualified host and domain name, such as lady.bcx.com, or a partial domain specification with a leading dot, such as .bcx.com. On the right the delivery agent name must be separated from the new domain name by a colon. The source text file is converted into a database with the makemap(1) program (Section 5.5). Beginning with V8.8 sendmail, the host part of the return value can also specify a user:

downhost.com     smtp:postmaster @mailhub.our.domain
                           
                      V8.8 and above

The host.domain is looked up in the mailertable database, and if that host.domain is found, a delivery agent, colon, and domain pair are returned. If the delivery agent (in mailertable) is error, the #error delivery agent is called. This allows error messages to be put into the database, as, for example:

badhost    error:nohost mail to badhost is prohibited   V8.9 and earlier
badhost    error:5.7.0:550 mail to badhost is prohibited    V8.10 and above

The first token following the error: is passed in the $@ part of the #error delivery agent. Note that, prior to V8.10, you had to use words or <sysexits.h > codes here, not DSN values (such as 5.7.0) because the latter were wrongly broken up into five tokens. Beginning with V8.10, you can also use DSN values here, and they will be handled properly. See error for a full description of the #error delivery agent and for tables of useful words and codes for the $@ part.

If the host is found and it is not an error delivery agent, that delivery agent is selected. Otherwise, the unresolved host.domain is passed to other rule sets for further mailertable lookups. Those other rule sets recursively strip the leftmost part of the host.domain away and look up the result in the mailertable. This continues until either a match is found or only a dot is left. Then that dot is looked up to give you a hook for failed lookups:

.     smtp:smarthost

As a special case, the delivery agent named local causes slightly different behavior in that it allows the name of the target user to be listed without a host part:

virtual.domain    local:bob

Here, any mail that is received for the virtual.domain is delivered to the user bob on the local machine. If the user part is missing:

virtual.domain    local:

the mail is delivered to the user part of the original address. This latter approach can be beneficial when you have a huge number of hosts listed in $=w. Consider moving those hosts to the mailertable database, and placing local: on the righthand side of each entry:^[7]

^[7] Note that moving the host from $=w into the mailertable database can adversely affect masquerading and relay control.

The form for the mailertable feature is:

FEATURE(`mailertable')

This causes the following database declaration in the configuration file:

Kmailertable hash /etc/mail/mailertable

Here the hash is derived from the setting of the DATABASE_MAP_TYPE mc configuration macro (Section 23.5.1), and the /etc/mail is derived from the setting of the MAIL_SETTINGS_DIR mc macro (Section 2.6.5.1). If you wish to change the defaults without having to change these two mc configuration macros, you can simply define that new default by adding a second argument to the feature declaration:

FEATURE(`mailertable',`dbm -o /etc/mail/mailertable')

Here, the database type was changed to dbm, and a -o database switch was added to make the presence of the database optional.

You can also 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):

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

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

The mailertable feature was inspired by the IDA version of sendmail.

In Section 19.5 we deal with the flow of rules through the parse rule set 0. For now, merely note that this mailertable feature fits into the flow of rules through the parse rule set 0 like this: