5.1 Running Sendmail and Qmail in Parallel

Users tend to be upset when they can't access their email, so it's rarely possible to shut down the old mail system, spend a day getting the new system installed and tested, then turn the mail back on. Fortunately, you don't have to. It's easy to run sendmail and qmail in parallel on the same machine, delivering mail into the same mailboxes, until you're satisfied qmail is working properly, and then shut sendmail down.

Any MTA receives mail through two routes: local and remote. On Unix systems, local mail is injected via the sendmail program, and remote mail is injected via SMTP. When you're running qmail and sendmail in parallel, as long as /usr/lib/sendmail is a link to sendmail, local mail will go to sendmail, and as long as sendmail is listening on port 25, remote mail will also go to sendmail. While you're testing, put qmail's version of sendmail somewhere else, say /var/qmail/bin/sendmail, and run qmail's SMTP daemon on port 26.

Once you're happy with your qmail installation, move the original /usr/lib/sendmail to /usr/lib/sendmail.old (and similarly for any other links to it such as /usr/sbin/sendmail) and link the qmail version in its place. That will start routing local mail to qmail.

For remote mail, kill the sendmail daemon, and restart the qmail SMTP daemon running on port 25. That will start routing remote mail to qmail. Because sendmail probably still has some mail to flush out, restart the sendmail daemon but without the -bd flag that makes it listen on port 25. A typical command would be sendmail -q30m to keep retrying failed deliveries every 30 minutes. After a few days, or when the sendmail queue is empty, you can shut sendmail down for good.

5.1.1 Sendmail Switching Systems

Some versions of BSD and Linux have their own schemes to handle multiple mail systems with different versions of sendmail by providing a layer of indirection between the sendmail program that other applications call and the actual program provided by the mail package. These schemes don't do anything that the direct approach can't also do, but they document the setup better and are more likely to survive system upgrades, so you should use them when you can.

NetBSD and FreeBSD use a program called mailwrapper, which is installed where sendmail would usually go. It consults a file called /etc/mail/mailer.conf, which has the names of the actual programs to run when sendmail is called under any of its many aliases. (See Example 5-1.)

Example 5-1. Typical mailer.conf

sendmail        /var/qmail/bin/sendmail send-mail       /var/qmail/bin/sendmail newaliases      /var/qmail/bin/newaliases

Debian and Red Hat Linux have an "alternatives" scheme that uses symlinks. In a typical alternatives setup, /usr/sbin/sendmail is a symlink to /etc/alternatives/mta, which is in turn a symlink to the real sendmail program. You can just symlink /etc/alternatives/mta to /var/qmail/bin/sendmail or use the alternatives (Red Hat) or update-alternatives (Debian) command to make the links.