UNIX System Administration Handbook - Evi Nemeth [344]
To use the genericstable, ensure your domain is in the generics class. To put a domain in the generics class, you can either list it in the GENERICS_DOMAIN macro or put it in the file specified by the GENERICS_DOMAIN_FILE macro.
For example, to use the genericstable with the defaults for the database, add
GENERICS_DOMAIN_FILE('/etc/mail/local-host-names')
FEATURE('genericstable')
to your .mc configuration file. In this example, any host you accept mail for is included. Enabling the genericstable feature slows down sendmail slightly because every sender address must be looked up.
The virtusertable feature
The virtual user table supports domain aliasing for incoming mail. This feature allows multiple virtual domains to be hosted on one machine and is very common at web hosting sites.
The key field of the table contains either an email addresses (user@host.domain) or a domain specification (@domain). The value field is a local email address, an external email address, or a mailer:address specification. If the key is a domain, the value can either pass the user field along as the variable %1 or route the mail to a different user. Additional information is passed along as %2.
Let’s look at some examples (we have added the comments):
info@foo.com foo-info # route to a local user
info@bar.com bar-info # another local user
joe@bar.com error:No such user # to return an error
@baz.org jane@elsewhere.com # all mail to jane
@baz.org %1@elsewhere.com # to the same user
All the host keys on the left side of the data mappings must be in the cw file (or the new VirtHost class); otherwise, sendmail tries to find the host on the Internet and to deliver the mail there. If DNS points sendmail back to this server, you get a “local configuration error” message in bounces. Unfortunately, sendmail cannot tell that the error message for this instance should be “virtusertable key not in cw file.”
Several pieces are actually involved here:
• DNS MX records must exist so that mail is routed to the right host in the first place, then
• cw entries must be present or VIRTUSER_DOMAIN specified (or equivalently, VIRTUSER_DOMAIN_FILE) to allow the local machine to accept the mail, and finally
• the virtual user table must tell sendmail what to do with the mail.
The feature is invoked with:
FEATURE('virtusertable')
The examples starting on page 588 use virtusertable to implement virtual hosting.
The ldap_routing feature
As a final chunk floating in this cesspool of aliasing, rewriting, and falsification, we have LDAP, the Lightweight Directory Access Protocol. LDAP (see page 560 for general information) can be used as a substitute for the virtusertable with respect to routing email and accepting mail for virtual domains. It can also manage aliases, except for mailing lists.
To use LDAP in this way, you must include several statements in your config file, and you must have built sendmail to include LDAP support. In your .mc file you need the lines
FEATURE('ldap_routing')
LDAPROUTE_DOMAIN('my_domain')
define('confLDAP_DEFAULT_SPEC', '-h server -b searchbase')
to tell sendmail that you want to use an LDAP database for routing incoming mail addressed to the specified domain. The LDAP_DEFAULT_SPEC option identifies the LDAP server and database search base name.
In the following example, the search base is o=sendmail.com, c=US. If you run LDAP on a different port (not 389), add -p ldap_port# to the LDAP_DEFAULT_SPEC.
sendmail uses the values of two tags in the LDAP database:
• mailLocalAddress for the addressee on incoming mail
• mailRoutingAddress for the alias to send it to
sendmail also supports the tag mailHost, which if present routes mail to the highest-priority MX record for the specified host with the mailRoutingAddress as recipient.
For example, the