5.3 System Issues

The sendmail.cf configuration file provides a fantastic amount of configurability to sendmail, some of which is quite useful. Most of sendmail's tricks have straightforward equivalents in qmail. It may be useful to print out sendmail.cf so you can check off each configuration option as you deal with it.

5.3.1 Deconstructing sendmail.cf

Much of the configuration information in a typical sendmail.cf needs no qmail equivalent. Since sendmail was written in an era when it wasn't clear what mail system would predominate, it can handle a wide variety of long-dead mail addressing formats, and much of sendmail.cf defines the syntax of email addresses, something that's built into qmail.

Nonetheless, sendmail.cf files usually do have some local customization that you need to translate. Because the configuration language is so arcane, most sites use a set of m4 macros to generate the file. In the following discussion, I mention primarily the m4 macros rather than the generated configuration codes.

5.3.2 Local Deliveries

Sendmail uses several macros starting with LOCAL_MAILER to define the local mail configuration. The qmail equivalent is the default delivery agent set at startup time. The sample boot scripts described in Chapter 4 cover most of the common cases.

If you want to deliver mail into mbox files in /var/spool, use one of the binm boot scripts, whichever one calls the same mailer that sendmail is calling. If any of your users have .forward files, use the +df versions of the boot scripts.

If you want to deliver to mbox files in users' home directories, use the home or home+df boot script. If you want to deliver into Maildirs, start with the home or home+df script, but change ./Mailbox to ./Maildir/. Don't forget the trailing slash, which tells qmail that it's a Maildir. Qmail will not create Maildirs automatically, so you must create them yourself. If your user directories are all under /home, running this script as root does the trick:

cd /home for i in * do    maildirmake $i/Maildir    chown -R $i $i/Maildir done

If the sendmail configuration has FEATURE('local_procmail'), it's using procmail to deliver local mail. See Section 4.6 in Chapter 4 for details on setting up procmail.

5.3.3 Hostnames and Masquerading

Sendmail provides an elaborate masquerading system to rewrite addresses on mail. Historically, people used masquerading so that the syntax of mail addresses within an organization could be different from (generally simpler than) the addresses visible outside. While this made some sense when mail systems had different, incompatible, and mutually hostile addressing syntaxes, it's not a very good idea now that mail systems all use Internet-style addresses. Not surprisingly, qmail provides only minimal help for masquerading.

The one function of masquerading that is still useful is to hide hostnames within a network. If your domain were example.com with hosts named good.example.com and bad.example.com, you would probably like the return address on your mail to be [e-mail] rather than [e-mail] or [e-mail]. Qmail makes this easy.

Several control files in /var/qmail/control set the hostnames to use:

me

The hostname of this host, such as good.example.com.

locals

A list of local domains. Lists the local domain and the machine's hostname, for example:

example.com good.example.com

The domains in the sendmail virtusertable and mailertable files are virtual domains, not local domains, so don't list them here.

envnoathost

If qmail-send encounters an unqualified address without a domain, add this host name. Make this the domain, such as example.com. Such addresses are only likely to occur in incoming SMTP mail.

defaulthost

If qmail-inject encounters an unqualified address without a domain, add this hostname. Make this the domain, such as example.com. This handles addresses coming in via the sendmail compatibility program.

defaultdomain

If qmail-inject encounters an address where the host part does not contain a dot, add this hostname. Make this the domain, such as example.com. This turns addresses like root@bad into [e-mail], so on networks with multiple mail subdomains, local users can abbreviate the addresses.

These aren't all of the control files that affect addressing, but all of the others have reasonable defaults, so there's no need to create them.

Sendmail provides several ways to specify multiple names for the local host. If your sendmail setup has /etc/mail/local-host-names, all the names in that file are names for the local host. Or you may have LOCAL_DOMAIN lines in the configuration file, each specifying another name for the local host. In qmail, all of these turn into lines in the locals file.

5.3.4 Local and Virtual Domains

Sendmail and qmail handle domains somewhat differently. Qmail has a simple division into local, virtual, and remote domains, whereas sendmail has many special cases. Fortunately, most of the special cases translate easily into virtual or remote domains.

Qmail's local domains treat mailbox names as mailboxes on the local computer.

Virtual domains can handle any domains that are neither treated as local mailboxes (local) or sent elsewhere via SMTP (remote). Virtual domains deliver to a set of mailboxes other than the standard set on the computer and route mail via something other than SMTP.

The usual sendmail approach to virtual domains is with a virtusertable file that contains instructions on how to route every address in every virtual domain. The easiest way to translate virtusertables is to use the add-on fastforward program, as described in Chapter 12.

5.3.5 Remote Domains, and Primary and Backup MXes

Qmail's remote domains deliver mail to other hosts via SMTP. Anything that's not local (listed in locals) or virtual (listed in virtualdomains) is remote.

Normally a host receives mail only for domains it handles itself, so the list in rcpthosts is the combination of local and virtual domains. Mail hosts can also be "backup" or "secondary" MXes, receiving mail for domains handled elsewhere, to provide a place to buffer the mail if the primary MX isn't available. To make qmail a backup MX, just add the domains to back up to rcpthosts or morercpthosts. If an incoming message isn't handled locally, qmail will automatically forward it to the primary MX when it can. Sendmail has some backup MX kludges, like the one that automatically provides backup service for any domain that has an MX pointing at the host. For security reasons, qmail doesn't do that; the list of domains has to be explicit. For systems that handle many domains, it's not hard to generate a suitable morercpthosts automatically from whatever database maintains the DNS, and it's more secure than letting any random domain point its MX at you and make you an unwilling relay.

5.3.6 Smarthosts

Many small systems deliver mail using a "smarthost," a larger or better-connected system that handles all outgoing mail, typically a gateway system on the local network or at one's ISP. Qmail has a very simple, if not obvious, way to specify a smarthost. Put the smarthost's name into smtproutes preceded by a colon, e.g.:

:mail.myisp.com

The syntax of each line in smtproutes is the name of the domain to route, colon, the name of the host to route it. A missing domain makes the entry the default to use for all domains that don't have explicit routes.

5.3.7 Uucp and Other Specialized Deliveries

Sendmail can specify that mail to particular domains be routed specially, for example, if the sendmail system is acting as a gateway to dialup uucp hosts. Qmail's virtual domain system is flexible enough that it can easily implement all sorts of gateway and specialized routing. See Chapter 12.

5.3.8 Spam Filtering

Sendmail can configure DNS blacklists and other spam filters in sendmail.cf. Qmail can do all of the same filtering, but it's set up completely differently because qmail's SMTP daemon, where the filtering happens, runs independently of the core mail delivery system. See Chapter 9.