Electronic Review of Computer Books

[ ERCB Home | New | Feature | Brief | DDJ | Letters | Links ]

[an error occurred while processing this directive]

Vital Statistics

Title Postfix
Author Richard Blum
Publisher SAMS Publishing
http://www.mcp.com/publishers/sams/
Copyright 2001
ISBN 0-672-32114-9
Pages 593
Price $49.99


Easy on the Ego

A complete review of Postfix, by Richard Blum, must also cover Postfix the program. If you have already settled on Postfix and are looking around for more extensive documentation, buy this book. There aren't any others (yet) and it is easier on the ego than embarrassing yourself in public by asking another FAQ on e-mail lists and newsgroups. If you are considering Postfix or another Mail Transport Agent (MTA), the software and its documentation must be considered along with the available books. None of them come with really good documentation. Web sites, e-mail lists, and user groups all help.

Blum also has books on sendmail and qmail MTAs. The standard book on sendmail is sendmail, by Bryan Costales with Eric Allman (sendmail's author) from O'Reilly & Associates (1000 pages, dense, not something to read for fun).

In reading "how to" books, I have developed a system of marking pages with colored Post-It flags -- green for action items; sections describing something I want to try out. Yellow flags mark sections I am not sure are correct that need checking out. Red flags mark typos, mistakes, and other incorrect information. If I am contemplating reviewing the book, blue flags mark potential quotes. Postfix rates 10 green flags (low for a book of this size), one yellow flag, and four red flags. I caught two of the red flags myself, the rest were culled from the e-mail list. All are relatively minor, for example, the relayhost parameter is misspelled as "relay_host" (page 171). And in the index (Table 8.1 on page 174) append_at_myorigin rewrites "user" as "user@$myorigin", not as "user@$mydomain" ($myorigin and $mydomain usually have the same value). It is mistakenly claimed in several places that a virtual username that maps to a bare username is delivered locally when it really is delivered to user@$myorigin. But again, this usually is the same thing.

Chapters 1, 2, 4, and 5 describe e-mail systems in general and the Postfix architecture. I found this to be useful background information. By showing what's going on under the hood, it is much easier to debug any problems. The SMTP, POP, and IMAP protocols are built on top of the telnet protocol. It is often easier to telnet directly into a server instead of coaxing more error or debug messages out of a client program. There are numerous examples of this throughout the book. However, after four or five chapters of this, it began to feel like padding. Each was a complete session from telnet invocation, through QUIT, and getting the shell prompt back. After a certain point, login and logout could have been omitted.

The first half of Chapter 6, "Installing Postfix," feels like fluff. If you have to be told how to download and install an RPM or source tarball, you aren't ready to run your own e-mail system. The second half is where it becomes helpful with instructions on installing Postfix in a chroot environment:

"As an extra security precaution, the Postfix system can run in a restricted area on the mail server. This ensures that even if a mail program is compromised, the attacker will not be able to access files in the mail server system directories. Postfix uses the Unix chroot command to accomplish this.

"The Unix chroot forces a command to treat the specified directory as the file-system root directory. After chroot has been run, the program can no longer access any files or executables above the specified directory. Files outside the specified directory structure can be considered "safe" from the particular chroot'd program. Since the program can't "get out," the specified directory is often referred to as a "chroot'd jail."

"All of the Postfix core programs except local and pipe can run using the chroot environment. By default, the Postfix chroot script (discussed below) sets /var/spool/postfix/ as the root directory for Postfix programs."

The rest of the chapter covers the utility programs. Since many prospective Postfix users are running sendmail, sendmail equivalents are given where they exist. Both Postfix and qmail have a sendmail wrapper for their own equivalents. For example, the Postfix mailq can also be invoked by the sendmail equivalent, "sendmail -bp." There are too many programs that assume sendmail is present to ignore. Neither Postfix or qmail's sendmail wrappers have complete compatibility, so they should not be depended on whenever it isn't necessary.

Chapters 7, 8, and 9 describe the configuration files. These chapters cover the what and how of the major sections, but it is a bit short on the why. Since Postfix can run on 486s, UltraSparcs, and IBM mainframes, it may be difficult to give general advice. As appropriate, some parameters are covered in later chapters. Unfortunately, some are not covered at all or at least are not in the index (for instance, disable_dns_lookups).

A lot of the Postfix docs assume you already know the jargon (for example, you are already administering an e-mail system and are migrating to Postfix). They don't define a virtual domain or a virtual interface anywhere. I didn't get a satisfactory explanation on the e-mail list. Postfix defines both terms and includes them in the index.

"One feature of MTAs is the capability to receive mail destined for other locations. Once the mail is received, it must be stored until the remote location connects to the mail server to retrieve it. This is called a virtual domain."

Virtual interfaces are called "IP aliases" in the Linux world. They are useful for setting up Postfix alongside a running production e-mail server. It can be configured and tested without impacting e-mail delivery. Chapter 10 covers how to migrate from sendmail to Postfix. With some care, both can be installed and be run at the same time on different interfaces. Production e-mail can be switched back and forth as problems with Postfix are found and corrected.

Chapter 10 covers two typical setups: an ISP and an office e-mail system. Dial-up systems are covered as part of the latter. There is one area I have not seen covered anywhere: The very small office or home office (vSOHO) LAN with a private/internal (unregistered) domain name, with or without an internal DNS server. This lack isn't limited to just Postfix or even MTA docs. I encounter this situation both at home and at work, and there isn't much help out there.

After reading Postfix, I had a working Postfix, but it wasn't as clean as I liked and that usually means it's fragile and will break. Postfix is becoming like Perl -- there's more than one way to do it. This also means that by the time I've solved a tough problem, it is usually solved several ways. Then it is just a matter of trimming out the redundancies. There has to be a better way of configuring it or looking at the vSOHO problem. Pieces are out there -- I find a hint that sends me back to the docs and an isolated explanation of features that aren't discussed within any larger context. Nothing pulls it all together for the vSOHO.

Chapter 13 is entitled "Postfix Server Administration," and covers basic logging, problem handling, and spam rejection. The spam controls can also be used to block viruses with known headers, Melissa for instance. It would have been nice if there was more on virus blocking, and the one technique mentioned was indexed. At the time the book was written, there were few antivirus programs for Linux. There are more now, both proprietary and open source.

"Migrating from Sendmail to Postfix" gets a whole chapter. Read it all before starting. On the last page of the chapter is a caution to not uninstall sendmail before completing the migration. Also, reread the sections on IP aliasing and test it before going live. No one has an asbestos suit strong enough to save you from messing up everyone's e-mail. Even Road Runner (a cable modem ISP) here in Central Texas was forced into giving rebates for five days of no e-mail due to a botched server upgrade. (Luckily for me, I had installed Postfix and routed the bulk of my e-mail around them the week before as a technical challenge.)

Chapter 15 is "Using the Maildir Mailbox format." The Maildir format is an alternative to the mbox format used by most older *nix mail systems. Maildir was developed by qmail's author, Dan Bernstein, to get around the reliability and performance problems of file locking on NFS volumes. It also has benefits on local disks. It is just a one line change to the Postfix main.cf configuration file to switch. Some work is needed to create the necessary new directories and files. Most e-mail clients that can handle Maildir can also handle mbox and can even handle a mix of the two. The second half of the chapter covers installing the Courier IMAP package. Courier is a full blown e-mail package, including MTA. The developers also make the IMAP server, the Maildrop Mail Delivery Agent (MDA), and SqWebMail available as separate packages. Courier has extended the Maildir format in ways that break some packages that support the base format, such as the xbuffy e-mail notification applet.

There is a whole chapter on "Mail Delivery Agent Programs." In spite of the plural in the title, it only covers Procmail. How to connect Postfix to an MDA is the same for all of them. Unfortunately, Procmail takes sendmail as its model. It is robust, versatile, has lots of users who are willing to share their knowledge, and its configuration file syntax is cryptic. Check out Maildrop as a more readable alternative (note: Postfix has a queue named maildrop, no relation).

Almost all of my green flags (action items) are in the first half of the book, but this is not to say the second half is without value. Its value to me was in its explaining what not to do. There is a chapter apiece on using Postfix with MySQL and OpenLDAP. The latter is good for storing usernames, passwords, and billing information for an ISP. LDAP is good for the more hierarchical information of an office. Both are overkill in the SOHO environments I work in. Both chapters look adequate to get a prototype up and running. Most production systems will require more work and documentation. In choosing between them, look at what other applications need to access this data.

Majordomo is one of the most popular Mailing List Managers (MLM) and gets a chapter of its own. While it is an interesting read, it isn't something I plan on doing just to raise my geek cred. I didn't see anything that gives Majordomo a particular advantage over any other MLM. The documentation is basic, what comes with the MLM is a better reason to choose Majordomo or some other package.

Chapter 20 is entitled "Using POP3 and IMAP with Postfix." MTAs only get mail as far as the user mailboxes on the local machine. Unless a user has access to the machine (via telnet, rlogin, ssh, NFS, or physical access), they can't read their mail.

"Two protocols that allow remote access of mailboxes are the Post Office Protocol (POP3) and the Interactive Mail Access Protocol (IMAP). POP3 and IMAP allow remote users to view and delete mail messages on the mail server from a remote workstation using an e-mail client. The Unix mail server must run server software that supports either POP3 or IMAP to allow remote users this kind of access to their mailboxes.

"This chapter describes two server software packages that allow a Unix mail server to support the POP3 and IMAP retrieval of e-mail messages. The University of Washington IMAP program supports both POP3 and IMAP. Qualcomm's qpopper program can be used to support POP3 access of normal Postfix sendmail-style mailboxes from remote e-mail clients. But first, a short discussion about MUA protocols is presented."

Even if you choose a different POP3 or IMAP server, the examples of how to access the server with a telnet client are still useful for trouble shooting.

The Web is another common way to access e-mail servers remotely. There is brief mention of several packages and the SqWebMail package is described in more detail. It is part of the Courier MTA package and available separately. It uses the Maildir mailbox format. Combining this with the Courier POP3 and/or IMAP mail servers should allow local access via any e-mail client that supports the Maildir format, remote access via POP3 and IMAP, and Web access. This covers just about everything except security. qpopper supports APOP, a modification of POP3 that sends passwords encrypted instead of as plain-text. SqWebMail can use secure HTTP (HTTPS) to encrypt passwords and content.

The chapter on "Performance Tuning Postfix" covers some helpful tweaks to common configurations. Small systems don't need to bother but large systems are possible (one of the e-list subscribers is scaling up to move a million messages a day). Tuning a large system is a matter of balancing hardware capability and software configuration to prevent logjams.

The last chapter is how to troubleshoot "Common Postfix Problems." It is helpful, but hardly complete. That is what the e-mail list is for.

In summary, I don't regret buying this book but was disappointed that it did not cover more advanced topics. With sophisticated programs like Postfix, I am finding that documentation, e-mail list, and books are not sufficient by themselves, but that all three together work very well.

-- Jeffrey Taylor (jeff.taylor@ieee.org)


Table of Contents

Introduction

Part I Introduction to E-Mail Services and Postfix

Part II Installing and Configuring Postfix

Past III Advanced Postfix Server Topics

Index


Quick Rating

Readability Star Star Star HalfStar
Originality Star Star HalfStar
Accuracy Star Star Star
Consistency Star Star Star
Timeliness Star Star
Editing Star Star Star
Design Star Star Star
Overall Value Star Star Star

Explanation of ERCB rating scale:
No stars = unacceptable
1 Star = marginal
2 Stars = average
3 Stars = above average
4 Stars = exceptional


Copyright © 2001 Electronic Review of Computer Books
Created 9/2/2001 / Last modified 9/2/2001 / webmaster@ercb.com