Your Linux Data Center Experts

Postfix has some really nice features. As many of you know, we've been quite heavily a qmail shop for a very long time. Part of that is because back when I first started looking for an alternative to Sendmail (but much more secure), Postfix didn't exist. A lot has changed in the last decade…

Well, relatively a lot. Actually, qmail hasn't changed very much in that time. The latest stable release of qmail is 1.03, dated mid 1998. before then, the qmail base code was getting regular attention. Not to say that qmail has no activity around it, there's a huge community around it providing patches to qmail.

However, meeting the modern demands requires applying (and usually resolving conflicts between) many of these patches. Our current qmail packages include 24 patches to the stock qmail. Sure, our qmailinstall product (no longer available) automates getting a rather complete mail system set easily, but the contortions involved in all this does show.

More recently, there have been two “community” releases of “netqmail”, which add the bare minimum of patches required for operating a mail system, including several which are very much bug-fixes (and IMHO should have been included in qmail long ago). If you want to run TLS, SMTP relay authentication, SPF and modern conveniences, qmail starts requiring work.

I'm not here to bury qmail, I believe it's a fantastically engineered piece of software. In fact, I would recommend that anyone learning Unix or programming examine it. It's well thought out and very much follows the Unix ideals of many small programs cooperating.

More recently, we've been using Postfix, largely just to gain experience with it. There are a lot of advantages to Postfix, one of the largest is that it's got very active development and many features. TLS and SASL SMTP authentication support are included, to name just a few examples.

Sure, Postfix has it's warts… My biggest complaint is how external checking of the SMTP body is done. Postfix includes a fantastic mechanism for using external plug-ins to do all sorts of wonderful tests at the various stages of the SMTP conversation. However, the latest stage you can get access to is immediately after the client sends the “DATA” command. This means the simple mechanism cannot be used to do SMTP-level rejection of spam, because you do not have the message body.

The way Postfix wants this to be handled is that Postfix can pass the incoming message through an external SMTP server which can view, modify, or reject messages. In this way Postfix can reject an incoming message in the SMTP phase if, for example, it contains a virus. However, SMTP servers are notoriously difficult to build correctly.

It would be extremely nice to be able to wedge another check into the process after the data-phase “.”, to allow the message body to influence the conversation. Of course, there are some difficulties with SMTP that make it difficult to filter messages at this phase. One of them is that you must make per-recipient decisions before you see the message content. Without re-designing SMTP, it's not possible to do an SMTP reject for one recipient while accepting the message for delivery to another copied recipient. Say, for example one user wants to reject spam and another wants to quarantine it.

The reason rejecting as many messages in SMTP phase is important, is that bouncing the message after the fact is extremely problematic. In these days of spammers and viruses forging the sending address of messages, it's not uncommon to get 100 forged sender addresses for every legitimate one. If you reject messages during the SMTP phase, you aren't directly producing shrapnel for others to deal with. If you accept the message and then later bounce it, you are just hurting the people who's addresses have been forged.

So, rejecting messages during the SMTP phase is important, and very easy to write plug-ins for Postfix. It's much more difficult with qmail. qmail's architecture allows you to build a replacement SMTP daemon, but you must fully implement SMTP to do this. This is exactly what the qpsmtpd project has done, with very good results. It's a replacement SMTP daemon written in Perl which allows plug-ins to be developed to do things like greylisting or SPF checking. However, it doesn't implement TLS and unlike the stock qmail SMTP daemon there aren't even patches to implement this functionality yet.

Unfortunately, there are still some places where Postfix is definitely immature. For example, the excellent vpopmail software, which allows for the configuration of virtual users in virtual domains, without requiring system accounts for every user, doesn't work under Postfix cleanly. The recommendation for installing it under Postfix is to also install qmail and have Postfix hand the messages off to qmail – hardly ideal. Allowing vpopmail to be directly called by postfix is going to be problematic, because vpopmail and it's related tools rely fairly heavily on qmail to do deliveries and handle forward aliases.

While Postfix includes functionality for handling virtual mailboxes in virtual domains, I haven't really seen a solution like vpopmail for producing similar results. That's one of the things which I think is holding back Postfix from wider acceptance.

We're lucky because we don't use anything as modern as POP/IMAP in virtual domains. ;-) Our mail system is a fantastic combination of UUCP running over a VPN to each of our individual machines. Before you say “Ewww”, I'd like to point out that it just works brilliantly, with strong end-to-end security and absolutely 0 problems roaming to the coffee shop or the like. It just works, whether we're connected to the Internet or out of range.

comments powered by Disqus

Join our other satisfied clients. Contact us today.