Chapter 5: Virtualization

Chapter 5 covers virtualization, which is, generally, a way for one concrete (physical or publicly addressible) service or server to successfully provide services under numerous identities (such as when multiple domain names are served by, or resolve to, a single server).

The three basic virtualization techniques used with qmail — the control/virtualdomains file, user-definable address extensions, and multiple qmail instances — are introduced and expanded upon.

Expanding upon control/virtualdomains, the reader is introduced to two popular solutions for handling virtual domains with qmail, vpopmail and VMailMgr, which are helpfully contrasted. Details of how qmail handles delivery of an email to a vpopmail-managed domain are provided, along with how those details differ under VMailMgr.

The author then touches on how qmail's support for virtual domains typically form just "part of a larger system of storing and retrieving email", which can also include virtual web-domain and/or database systems.

The coverage of multiple qmail installations is valuable for situations requiring distinct qmail queues (e.g. one per virtual domain), distinct public MXes (for SMTP servers), differing requirements, expectations, or policies regarding spam and viruses, and so on. The coverage extends to ways to hide (or try to hide) the use of multiple qmail queues on a single system from its users, but honestly grapples with the fact that such a "veil" is always likely to be imperfect.

In the table on Page 72, at the end of "Basic Virtual Domains", I believe the HOST3 and HOST4 environment variables should have been designated as being left undefined in both "Content" columns.

In item 8 of the numbered list on Page 77, under "Popular Solutions: vpopmail and VMailMgr", I found myself confused by this sample entry:

+example.com-example.com:XXX:YYY:/var/lib/vpopmail/domains/example.com:-::

Specifically, a colon (:) seems to be missing between the "+example.com-" and "example.com:XXX:YYY:".

Under "How to Set Up Multiple Qmail Installations" on Page 80, in the first paragraph, it might be helpful to indicate why the contents of conf-qmail (in the qmail source-code directory) are compiled directly into the binaries. In particular, the reader should be aware that the annoyance of having to maintain a distinct set of qmail binaries for each qmail queue (assuming qmail's code itself isn't modified) is likely an intentional choice made by the author of qmail in order to raise the bar for anyone trying to exploit qmail, especially the qmail-queue component (which runs as user root, regardless of who invokes it), by requiring them to deal with the fact that the (absolute) pathname of the (one) queue is likely to have been placed in a non-modifiable portion of memory for the running process.

Nits: Under "Consequences for Other Services", on Page 79, the last sentence in the last paragraph in the section wants a comma after "same set of user data" and before "is one of the attractions".

Under "How to Set Up Multiple Qmail Installations" on Page 80, third paragraph (after the sample commands), move the comma after "should be started" to after the subsequent parenthetical comment ("(if the new queue will be used)").

Two paragraphs later, it might be worth mentioning that multiple qmail-smtpd instances can also run together by listening on different ports, not just IP addresses, although that doesn't (normally) address the distinct-MX issue.

In the first sentence of the final paragraph in that section, at the top of Page 82, beginning "To what address the second qmail-send instance should listen", that should refer to qmail-smtpd, not qmail-send.

More Reviews

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