Chapter 6. Why Postfix?

The section of this document might also be considered a “sales” section or just plain old advocacy... pick your poison on that one. To put it bluntly Postfix is a very, very good MTA and if you haven't tried it you really ought to. As the author, Wietse Venema puts it, “Postfix is a direct competitor to the qmail by Dan Bernstein. That's competitor, not enemy. I'm sure that friendly competition will help to improve both programs.”

In design Postfix is very, very close to qmail as it uses a modular design rather than a monolithic one (e.g. several smaller programs working together to complete the required tasks as opposed to one huge binary written to do it all). This means that Postfix conserves machine resources by default and in practice is lightning quick. The command line accessible binaries included with ostfix are:

The postfix command controls the operation of the mail system. It is the interface for starting and stopping the mail system, and for some other administrative operations. This command is reserved to the super-user.

The postalias command maintains Postfix alias databases. This is the program behind the newaliases command.

The postcat command displays the contents of Postfix queue files. This is a limited, preliminary utility. This program is likely to be superseded by something more powerful that can also edit Postfix queue files.

The postconf command displays Postfix parameters: actual values, default values, or parameters that have non-default settings. This is a limited, preliminary utility. This program is likely to be superseded by something more powerful that can not only list but also edit the file.

The postdrop command is the mail posting agent that is run by the sendmail command on systems that have no world-writable maildrop queue directory.

The postkick command makes some internal communication channels available for use in, for example, shell scripts.

The postlock command provides Postfix-compatible mailbox locking for use in, for example, shell scripts.

The postlog command provides Postfix-compatible logging for shell scripts.

The postmap command maintains Postfix lookup tables such as canonical, virtual and others. It is a cousin of the UNIX makemap command.

The postsuper command maintains the Postfix queue. It removes old temporary files, and moves queue files into the right directory after a change in the hashing depth of queue directories. This command is run at mail system startup time.

For sendmail compatibility the mailq and newaliases commands, as well as a link to the old sendmail binary location (/usr/sbin/sendmail) have been preserved. They are not the same as they are under sendmail but their functionality remains the same. The link to sendmail makes it really easy to use Postfix with majordomo as well, though there are some things you should change in your majordomo aliases. We'll cover that in the listserv section of this document.

From an anecdotal perspective Postfix stands up very well in head to head comparisons with sendmail. A scientific examination is not within the scope of this document but it might help you to understand how it compares if we relate a short story.

An ISP with approximately 7500 users was making the move from sendmail to Postfix. Their old MTA machine was an under-powered host running IDE disks, 128MB of RAM and a low end Intel Pentium II, single processor. They built a much better machine for their new mail server (SMP PII with a DAC960 RAID controller, a pile of SCSI disks and 384MB of RAM). As the following occurred the new machine already had Postfix installed and they needed to move their old mail spools over from the old machine to the new machine. There are lots of ways to do this but they chose formail (a part of the procmail suite) as the simplest tool to use. They wrote a script (formail -Y -s /path/to/sendmail </path/to/mailspool) which recursed through their old mail spool files in alphabetical order and forwarded all of the mail for each user from the old machine to the new. The transmission medium was LAN based (the Internet was not used). Also the new Postfix machine was already the primary MX for their domain so it was receiving new mail inbound and serving up mail via POP3 as well. The old mail server (which was running sendmail 8.9.1) was no longer receiving mail or serving any POP3 clients at all. Once they started the process they'd only gotten about 10 minutes into operation and the old machine was on its knees and had just about broken down completely under the load. The new machine was happily chugging along with a load of about .5. The processes on the old machine had to be killed as the box was literally in the throes of a very nasty death. Once everything was back under control the chosen methods were reexamined. Now it's easy to say that the old box was just under-powered but the best part of the story is what happened next. Rather than continue the process as it was they elected to remove sendmail and install Postfix on the old machine. Once this was done they re-started the formail script and without a hitch all of the mail was moved over without any additional difficulty (though it did take about 9 hours to complete the process). Now this is definitely an anecdotal testament but it is a very good example of the significant differences between sendmail and Postfix in the “real world”. It's important to note that this does not mean that sendmail is a bad product. It is the standard MTA used by the majority of mail servers on the net but in a head to head comparison it doesn't appear to bear up near as well as Postfix. Try it and judge for yourself.