Chapter 3: Getting Email Out of the Queue

Chapter 3 complements Chapter 2's superb job by describing how email departs the qmail queue — usually via delivery to a local user or alias (under the control of .qmail files, providing for a fair amount of flexibility) or to a remote server (via SMTP or, potentially, QMTP or some other protocol). Undeliverable mail results in creation of a bounce message, and messages ultimately depart the queue when the qmail-clean program is called upon, by qmail-send, to delete them.

Here, the qmail-lspawn and qmail-local components, employed by qmail-send to deliver mail locally (that is, as directed by .qmail files locally available to the server), are introduced, along with the corresponding components employed to deliver mail to remote servers, qmail-rspawn and qmail-remote (which handles delivery via the SMTP protocol).

Describing user-controlled mail delivery, the author touches on popular (if not well-advised) examples such as use of the vacation program, then delves into the details of the local delivery process, its environment-variable settings, and various tools (whether qmail-specific, provided by a typical Unix system, or available for download), which can be combined to filter, forward, store, and/or bounce mail.

Here, I would have appreciated seeing a "poor man's SpamAssassin" sample shell script and how it might be used to direct likely spam into a special Maildir.

This chapter also introduces qmail's definition of a "user", including aliases and qmail-defined (or mapped) users, as well as users who control virtual domains and those that control extensions to email addresses they control. (For example, user "foo" at "example.com" typically controls, via a .qmail file, not only how email deliveries to "foo@example.com" are handled, but how deliveries to extension addresses, such as "foo-something@example.com", are handled. This simple mechanism makes qmail very useful as a component in a wide variety of situations, such as running mailing lists.)

I found the writeup on the users/assign file especially helpful and succinct.

Remote delivery (typically to an SMTP server) is then covered, summarizing how qmail-remote checks for DNS MX and A records (CNAME lookups are covered later, in Chapter 8 under "DNS") unless a "static route", designated via a matching entry in the control/smtproutes file, is to be used to locate the SMTP server (IP address and port) for a recipient's domain.

Under "qmail-send and the Qmail Queue" on Page 40, at the bottom, after "creates a bounce message to be sent to the original message's sender", I expected it to continue with ", and removes the original message via qmail-clean" or similar.

Under "Forwards" on Page 42, I found the phrase "is confusing", used to characterized an email address that should be prefixed with an ampersand (&) on a .qmail, a bit misleading — who or what might be confused? I recommend always prefixing a forwarding address with the leading ampersand, but I believe the main concern is to make sure an email address, to which mail is to be forwarded, does not itself begin with an ampersand (&), hash mark (#), forward slash (/), period (.), or vertical bar (|), in order to not confuse qmail-local, or any other programs that parse .qmail files, into thinking the email address is something other than a forwarding address.

Under "Maildirs and mboxes" on Page 42, I found the two conflicting uses of the sample names "mailbox" and, later, "Mail", one (each) as an mbox and the other as a Maildir, apparently within a single sample .qmail file, misleading, because .qmail files should never be written that way. Perhaps the samples should have been formatted to clarify that the specifications were not both contained in single .qmail files?

Under "Extensions", on Page 49, after the second (9-item) numbered list of files for which qmail looks, the paragraph beginning "The first of these files that exists" should, I believe, include the caveat "and is non-empty".

Under "Static Routes", on Page 52, in the last paragraph, a parenthetical comment specifies smtproutes matching is based on "(the first one found)", rather than "The longest match in the file will be used", as stated earlier in the section, in the second paragraph from the top of that same page. qmail's man pages don't resolve the conflict, but I believe the longest match found, not the first, is used.

Nits: Top of Page 42, remove comma in "a Return-Path header, indicating the original envelope sender." Or, insert corresponding commas around the elaboration of the Delivered-To header.

More Reviews

Copyright (C) 2007 James Craig Burley, Software Craftsperson
Last modified on 2007-07-09.