UNIX System Administration Handbook - Evi Nemeth [348]
Table 19.13 Basic configuration options
a. More specifically, the maximum number of child processes that can run at once. When the limit is reached, sendmail refuses connections. This option can prevent (or create) denial of service (DOS) attacks.
Use the HOST_STATUS_DIRECTORY option when a busy host has to handle lots of failed mail deliveries. This option directs sendmail to keep a file for each host to which delivery has failed in the status directory and causes sendmail to use that status information to prioritize the hosts when the queue is run again. This status information effectively implements negative caching and allows information to be shared across queue runs. It’s a big performance win on busy servers. Here is an example that uses the directory /etc/mail/.hoststat (create the directory first):
define('confHOST_STATUS_DIRECTORY', '.hoststat')
The FALLBACK_MX option is also a performance win. It forwards all undeliverable mail to a local server that can handle the bogons, freeing the regular mail server to deliver the mail with good addresses. This feature is very useful for a site with large mailing lists that invariably contain addresses that are temporarily or permanently undeliverable. For example,
define('confFALLBACK_MX', 'mailbackup.xor.com')
would forward all messages that fail on their first delivery attempt to the central server mailbackup.xor.com for further processing.
Some daemon options that affect performance are invoked with a slightly different syntax. For example, to make sendmail act as both an MSA (mail submission agent) and an MTA (mail transport agent), use
DAEMON_OPTIONS('Port=25,Name=MTA')
DAEMON_OPTIONS('Port=587,Name=MSA,M=E')
This is the default configuration starting with version 8.10.
19.9 CONFIGURATION FILE EXAMPLES
We haven’t really finished with all the configuration options (a spam section and a security section are coming up), but it’s time to look at some example configuration files. This order may be a bit like putting the cart before the horse, but it seems to work the best of the arrangements that we’ve tried. The essential configuration feature that we have not yet covered is the access database, which is used primarily to filter and control spam. It’s covered starting on page 599.
In documenting the config files in use at various sites, we invariably run into some cruft left over from bygone days that is either wrong or not needed. We have cleaned up these inconsistencies, spelling errors, etc., before using the config files as examples, so they are not shown here exactly as they appeared on the original servers. Nevertheless, they reflect real-world configurations.
A computer science student’s home machine
Our first example is a student, Rob Braun, who has a Linux box (gw.synack.net) at home and does virtual hosting for a few friends’ domains: xinetd.org, teich.net, and cubecast.com.
He also hosts his own domain, synack.net. Rob maps all incoming mail to the correct person with LDAP. He uses the virtusertable to handle the virtual hosting mappings, and the genericstable to handle outgoing mail. Of the many table types that affect outgoing mail, genericstable is the only one that can rewrite the username as well as the destination host.
Rob’s genericstable file (which he actually calls outmap) contains:
bbraun rob@synack.net
stabilej jon@synack.net
teich oren@teich.net
Rob uses the DNS Realtime Blackhole List (dnsbl) for spam control. He also uses masquerading features to stamp any outgoing mail that is not already rewritten by the genericstable as coming from user@synack.net instead of user@gw.synack.net. Here is the complete gw.mc file:
divert(0)
VERSIONID('@(#)synack.net.mc 8.7 (Berkeley)5/19/1998')
OSTYPE(linux)
DOMAIN(generic)
FEATURE(dnsbl)
FEATURE(virtusertable, '/etc/mail/inmap')
FEATURE(genericstable, '/etc/mail/outmap')
GENERICS_DOMAIN_FILE('/etc/mail/local-host-names')
MASQUERADE_AS(synack.net)
FEATURE('masquerade_envelope')
FEATURE('ldap_routing')