The courtship period for qmail will be a bit longer and more challenging than with other software you may be used to. Expect your first installation to be a bit of a slog. For one thing, there's all that qmail arcana: /var/qmail, control files, Maildirs, dot-qmail, user alias, Tonya Harding...

But whatever time you spend in the getting to know phase of your relationship with qmail, it will be well repaid in the long-term trouble-free relationship that follows.

qmail does have a few technical prerequisites. These need to be satisfied before you can proceed with installation:

• daemontools
• ucspi-tcp
• a djbdns resolver (recommended)
• a /var/qmail directory that meets certain requirements
• a set of special user accounts

The first two items in this list, daemontools and ucspi-tcp, are required for the usual daemontools run scripts and access control necessary to run qmail reliably and securely.

The use of a djbdns resolver is assumed as a standard of the djb way, either on the qmail server itself, or referenced by the qmail server's /etc/resolv.conf file. (If using another DNS resolver, you may need to patch qmail.)

This brings us to the requirements for /var/qmail.

The standard installation directory for qmail is /var/qmail. Bernstein explains why in this FAQ. Sure, you could try to fight it, but here's a suggestion: don't. You will only confuse your colleagues and perplex your successors. /var/qmail is long established qmail tradition.

What's more important than the pathname /var/qmail, however, are the filesystem characteristics for the following:

• synchronous updates (for the directory tree /var/qmail/queue)
• permit setuid (for the binary /var/qmail/bin/qmail-queue)

The first point means that qmail expects calls to link(2) will immediately update filesystem metadata on disk. Some filesystems buffer or journalize this activity. These filesystems are not considered safe for qmail, though, because unexpected power loss could cause loss of data.

The second point means that the binary that writes to /var/qmail/queue must be permitted to setuid(2) to user qmailq. Some filesystems may be mounted with the option nosuid that inhibits the effect of the setuid bit for security reasons. OpenBSD is an example of a platform that mounts the /var partition with the nosuid option by default. But this option will prevent qmail-queue from being able to write to /var/qmail/queue.

What to do:

1. No matter what platform you are using --and especially if you are building up an email server from scratch-- consider at least putting /var/qmail in its own separate partition. That way you can tune the characteristics of that filesystem independently from your other partitions. High performance servers will even put /var/qmail/queue on its own partition. Note that segregating the qmail hierarchy on its own partition also makes it easier/safer to upgrade the host OS from time to time.

2. For BSD systems (FFS):

   • Don't use soft updates on the partition with /var/qmail/queue
   • Don't use the nosuid option on the partition with /var/qmail/bin/qmail-queue

3. For Linux systems, choose one of the following solutions:

   • Bruce Guenter's syncdir fix (any filesystem)
   • Frank Denis' qmail-link-sync.patch (any filesystem)
   • mount the /var/qmail partition (or, even more specifically, a /var/qmail/queue partition) with the option sync (ext2fs)
   • use chattr -R +S /var/qmail/queue (ext2fs)

   The first two solutions are applied during the qmail build, and are generally preferred to the other solutions. If using reiserfs, see also Frank Denis' Qmail and ReiserFS HOWTO.

4. If using a separate partition for /var/qmail/queue, Bernstein notes that the noatime option is safe to use for any filesystem that supports it.

Once you have a filesystem suitable for /var/qmail, go ahead and make the directory:

# mkdir /var/qmail

Now its time to set up a few special system accounts for qmail.

For security reasons, qmail partitions its activities so that each process runs under different, non-root user accounts. A qmail installation requires the following two system groups in /etc/group:

Then, the following user accounts in /etc/passwd:

None of these user accounts should be provided with an effective password or login shell. Generally this means an asterisk * in the password field, and something like /sbin/nologin or /bin/true or /nonexistent in the login shell field.

Good old vipw(8) works just as well as anything to add these users to /etc/passwd directly, especially since you don't want/need anything installed from /etc/skel.

Otherwise, use whatever tools are provided by your host platform for this purpose (such as useradd(8) in Linux/OpenBSD, and pw(8) on FreeBSD.)

The file named INSTALL.ids in the qmail distribution also describes the specific procedures to follow for several platforms. Note that the section marked Linux will also work for OpenBSD.