The Book of Postfix 103
| The Book of Postfix | |
| author | Ralf Hildebrandt + Patrick Koetter |
| pages | 464 |
| publisher | No Starch Press |
| rating | 9 |
| reviewer | Danny Yee |
| ISBN | 1593270011 |
| summary | understanding and implementing Postfix mail systems |
When The Book of Postfix arrived, I jumped straight to the chapter "Understanding SMTP Authentication", since that was something I wanted to get working. This explains the problem -- how to allow travelling users with unknown IP addresses to send mail through a mail server without opening it up to spammers -- and clearly lays out the options: SMTP-after-POP or -IMAP, SMTP authentication, certificate-based relaying using TLS, or some kind of VPN. "If you want something simple, independent, and secure, SMTP AUTH is probably for you."
The remainder of the chapter explains how to set up a backend for SMTP authentication -- a choice between saslauthd and other options -- and the following chapter then explains how to configure Postfix to use it. This approach is typical of The Book of Postfix, which tackles many topics with paired chapters, the first covering background, theory and any ancillary systems and the second covering the actual Postifx configuration. It also emphasises progressive implementation accompanied by testing, which is most reassuring when modifying production servers.
Other chapters in Part III, "Advanced Configurations", cover running Postfix chrooted, using TLS (two chapters), mail gateways and multiple domains. There's also a chapter that works through building a complete mail system for an organisation. Part IV covers tuning and the appendices cover installing Postfix (for Debian or Redhat Linux, or from source) and troubleshooting.
Moving backwards, the hundred and twenty pages in part II cover content controls. Some basic postmaster background is followed by pairs of chapters on each of message transfer restrictions, built-in content filters, and external content filters. I've been working through these, improving my anti-spam controls, and they're proving really helpful; my next step will be implementing amavisd-new.
Part I explains how to set up a host to run Postfix, with ancillary services such as DNS, NTP and syslog, then how to set up a simple single domain configuration, either on a permanently connected machine or on a dialup machine. It then gives a brief description of Postfix's basic anatomy. Part I is concise -- just fifty pages -- but it offers everything most people will need for a basic setup.
There's no cruft in The Book of Postfix: it's a fairly chunky book, but none of it is padding. Excerpts from configuration files include just the right amount of context and the diagrams (and a very few screenshots) are integrated with the text and tightly focused. Given the scope, it's probably overkill for basic Postfix users, though the first fifty pages would make an excellent "getting started" guide for them.
There are some omissions. There's no general explanation of how the master.cf file works, for example, or of rewriting -- neither "masquerading" nor "canonical" appear in the index or glossary. The "Anatomy of Postfix" chapter could definitely have been more comprehensive.
How does The Book of Postfix compare with the O'Reilly book Postfix: the Definitive Guide ? The Book of Postfix is nearly twice the length and provides much more detailed step-by-step explanations and more on ancillary systems -- it explains how to set up backends for SMTP authentication, for example, rather than just telling you that you need one.
I highly recommend The Book of Postfix to anyone using Postfix and wanting to do more than the basics with it.
Danny Yee has written over 800 other book reviews. You can purchase The Book of Postfix from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Dumb Question... (Score:5, Interesting)
Re:Dumb Question... (Score:4, Interesting)
Mailservers are complex that is why. Just take a look at Exim to see what happens when a mailserver gets a bit too complex. In Exim you have this whole transport pipeline that the message must pass through before it gets delivered. Along the way you can change headers, filter for spam, virus check and about a million other things including sender id.
Thankfully (at least in debian) it comes with a script that will do quite a few basic configurations after asking a few questions. Your e-mail needs may not be as complex as others, but when a site needs a an e-mail server to handle 10,000+ e-mails an hour, streamlining and tweaking the process allows things to be much smoother. I admit I am not anywhere near an expert when it comes to SMTP servers, but I can see the value in wanting to make things run smooth and streamlining the process is a part of that.
Personally, I've found that postfix is pretty easy to set up and maintain compared to other daemons out there. As far as I am concerned, anything has to be better than configuring Sendmail, though I guess it has become a lot more secure over the years.
I'm sure others will have a lot more to say on this subject.
Re:Dumb Question... (Score:3, Interesting)
Pages and pages of stuff that you already have to understand to understand. I agree, mail servers are needlessly complex. All I want to do is receive mail and send it to 3 users on my machine, and have them be able to send mail via TB to the server without it become a spam relay. Why is this so damn hard.
Maybe it isn't but they people that document mail servers don't have a clue.
Why is it so damn hard to have the mail server require a user and password to send mail though it. I don't want to set up a hole SSL TSL BFD system with certificates and crap.
Why is the that the same program that receives mail from the outside world is the one that accepts connections from clients. This is silly and contributes to the spam problem. Much like POP3 or IMAP is a separate program, so should the one that accepts mail from a client like TB or Outlook. Then we wouldn't have this will spam problem.
Mail servers are still stuck in the mainframe days. Time for someone to rethink this mess.