17.1 Tools for Multiple Computers and Qmail

Here's a quick rundown of the tools in our multisystem toolbox.

17.1.1 Multiple Copies of Qmail

Normally, all of qmail is installed in /var/qmail. That directory is specified at build time in conf-qmail. If you change the contents of conf-qmail to, say, /var/qmail2 and rebuild and install qmail, you'll create a complete second copy of qmail along with its queue directories. You can send mail into it using /var/qmail2/bin/qmail-queue or any of the programs that call it, such as /var/qmail2/bin/forward, or by using tcpserver to run a SMTP service with /var/qmail2/bin/qmail-smtpd. Outbound mail works normally, although you can control it using the standard mechanisms such as concurrencyremote and smtproutes.

Remember that qmail's queue cannot be on a shared or remote disk; a single local copy of qmail-send has to manage each queue.

To pass mail for particular domains from one copy of qmail to the other, you can use either SMTP or virtualdomains. To use SMTP, set up a SMTP daemon for the second copy of qmail on localhost (127.0.0.1), but listening on port 26 or any other unused port. Then in the control/smtproutes/ in the first copy, route the mail for each domain to that SMTP daemon:

bad.example.com:localhost:26

To route using virtual domains, add virtualdomain entries to assign all the domains to a pseudo-user called qmail2:

example.com:qmail2 myvirt.com:qmail2

Then in ~alias/.qmail-other-default, forward the mail to the other copy of qmail:

| /var/qmail2/bin/forward "$DEFAULT@HOST"

The qmail2 version of forward will use the qmail2 version of qmail-queue to queue the mail in the second copy of qmail. If you've applied the QMAILQUEUE patch, you can set QMAILQUEUE to /var/qmail2/bin/qmail-queue in any command that queues mail to force the mail into the second copy of qmail.

17.1.2 mini-qmail

mini-qmail is a stripped-down qmail package. It uses QMQP, a faster and simpler scheme than SMTP, to send all mail to another host running regular qmail. Because mini-qmail makes neither local nor remote mail deliveries, and has no mail queue (all mail is sent to the QMQP server immediately), it's useful on client hosts in a mail cluster. The details of setting up mini-qmail are discussed later in this chapter.

17.1.3 Shared Mail Folders

Maildir format mailboxes can safely be shared read/write using NFS. Each message is written as a separate file, so the hosts creating the files use their hostnames as part of the files they create to avoid name collisions, and NFS does a reasonably good job of making file rename operations atomic; delivery to and retrieval from remote Maildirs works well. This means that one host can deliver the mail into a mailbox and another can pick it up, such as when one is the SMTP server and the other is the POP server. Or several hosts can use a shared Maildir as a gateway to a single host or service.

Sharing mboxes is much less reliable, because it depends on the NFS lock daemon to keep multiple writers in sync. People who share mboxes via NFS usually regret having done so.

17.1.4 Multi-Host POP Toasters

If you use vpopmail, described in Chapter 13, it's straightforward to expand to multiple mail servers for both incoming and outgoing mail. The mail system uses three conceptual parts: the SMTP server(s), the POP server(s), and the mail store. In the simplest case, all three parts reside on a single computer, but it's equally workable to put them on separate computers. The mail store resides on one or more computers running NFS servers, and the SMTP and POP servers mount the NFS partition. The SMTP servers receive the mail and deliver it to the mail store, and the POP servers retrieve user mail from the mailstore. Because Maildirs don't require file locking to work correctly, NFS with all its faults is quite adequate for a reliable system. If there's a single POP server, the CDB user database can reside on the POP server (where it can be updated as needed) with the SMTP servers having read-only access. Or better, build vpopmail using MySQL to keep the user database. All of the hosts can access a single MySQL database to track users, mail quotas, and POP-before-SMTP data. If that becomes a bottleneck, MySQL has built-in database mirroring so that there can be a local copy of MySQL on each server that needs it, mirroring the master database, with all updates fed back to the master. This is a very flexible design that should scale to a huge number of mailboxes and servers.

Another alternative for a multi-host system is qmail-ldap. Either it can use NFS for deliveries from multiple SMTP servers to user mailboxes, or the servers can be configured as a cluster in which each user entry in the LDAP database assigns the user's mailbox to a single server. The SMTP servers use QMQP to pass mail that arrives on the wrong server to the right one. Normally, users' MUAs are configured to log into their home server to pick up mail, but if a user logs into the wrong server for POP or IMAP, the session is transparently forwarded to the right one. It's all pretty slick.