Kurt's Closet: Postfix - the Sendmail replacement

September 15, 1999 – Most, if not all the readers of this column run a mail server, and more then likely it is running Sendmail. In all fairness Sendmail is a damn good MTA (Mail Transfer Agent), Eric Allman originally wrote it with one main goal in mind: the mail must get through. Unfortunately, when Sendmail was originally written security wasn't a major concern on the Internet and it shows. Sendmail runs almost exclusively as the root user on most systems, meaning any flaws are potentially very serious. In addition to this Sendmail isn't very good at handling high loads. New mailers, such as Postfix, Zmailer, and Qmail are several times faster then Sendmail on the same hardware. Until recently most of the alternative mailers to Sendmail were not drop-in replacements, to replace Sendmail was a painful task, and the new software typically behaved differently then Sendmail. Postfix was designed from the start to address all these problems.

Security

Postfix does not run exclusively as root, instead a master program (called "master") runs as root and spawns off processes to handle incoming, outgoing and local mail delivery as needed. Using a series of modular components, each task is handled by a separate program (which makes auditing it easier), for example outgoing email is dumped into the queue directory by your software, where "pickup" gets it and hands it to "cleanup", which hands it to "trivial-rewrite" which handles the headers, and finally is given to "smtp" if bound for a foreign system. Postfix is also much easier to setup for a chroot'ed environment than Sendmail is, simply make a few edits to the master.cf file (typically in /etc/postfix) and Postfix will run chroot'ed in its defined queue directory (usually /var/spool/postfix). It is also possible to set process limits for individual portions of postfix, again in the master.cf file. You can also easily set which user the Postfix programs run as, typically it defaults to "postfix" (a user similar in concept to the "nobody" user for apache), which has access to certain queue directories. Another major benefit of Postfix is the clarity of the configuration files, if you haven't yet looked at the guts of a sendmail.cf file I would recommend that you don't (O'Reilly has an 800 page book on Sendmail).

The master.cf file:

# ==========================================================================
# service type	private	unpriv	chroot	wakeup	maxproc	command + args
# (yes) (yes) (yes) (never) (50)
# ==========================================================================
smtp	inet	n	-	n	-	-	smtpd
pickup	fifo	n	n	n	60	1	pickup
cleanup	unix	-	-	n	-	0	cleanup
qmgr	fifo	n	-	n	300	1	qmgr
rewrite	unix	-	-	n	-	-	trivial-rewrite
bounce	unix	-	-	n	-	0	bounce
defer	unix	-	-	n	-	0	bounce
smtp	unix	-	-	n	-	-	smtp
showq	unix	n	-	n	-	-	showq
error	unix	-	-	n	-	-	error
local	unix	-	n	n	-	-	local
cyrus	unix	-	n	n	-	-	pipe
	flag=R user=cyrus argv=/usr/cyrus/bin/deliver -e -q -m ${extension} ${user}
uucp	unix	-	n	n	-	-	pipe
	flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail	unix	-	n	n	-	-	pipe
	flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)

Replacing Sendmail

As stated before, replacing Sendmail with another MTA used to be a very painful task, many mailers approached the "problems" in Sendmail by doing things quite differently and require a pretty extensive overhaul of the mail system, and a very different set of configuration files. With Postfix you can use most of your existing configuration files (such as access, aliases, virtusertable, etc.) simply by defining them appropriately in the main.cf file. In addition to this Postfix behaves like Sendmail, you can invoke it using "sendmail", get a listing of the mailq with "mailq", feed it pretty much the same options and so forth. I find a typical Postfix conversion takes around 10 minutes for most sites (assuming you use an RPM and don't have to compile it), and have yet to encounter any major disasters (although I have found several small to medium sized glitches). 

New problems

Of course replacing one software package with another will solve certain problems, and create new ones, to which Postfix is no exception. Partly due to it's design as a secure MTA you may experience some minor problems with Postfix. The best example is email to root, Postfix, by default, does not like to deliver email with elevated privileges (necessary to send email to root typically). You will need to define an alias for root in the aliases file, such as: "root: someuser". This also leads to problems with several mailing list packages, especially SmartList, which by default does all sorts of funky things that Postfix will not stand for. In any case I would advise switching to Majordomo, it is easier to configure and maintain via email for owners of mailing lists.

Scalability

A major issue with Sendmail is scalability, and performance in general. Small things such as restarting Sendmail on a daily basis so that you can update config files automatically (for example email redirection for virtual hosting) is problematic. Sendmail spawns off processes to receive and send email which sometimes linger until delivery is accomplished before Sendmail exits, meaning your script may not restart Sendmail properly. With postfix you simply issue the command "postfix reload" and postfix reloads it configuration files. This raises another issue, sites are starting to handle email for 10's of thousands of users on a single server, and using flat text files for configuration details such as mapping outgoing user email addresses (to make bob appear as from sales@example.org for example). This file could become several hundred thousand lines long in the future and slow the system down. Postfix can however be integrated with a database backend (currently MySQL is supported) to host it's configuration files, which not only scales better but allows you to do things such as dynamically blocking email to and from certain sites, and allow users to administrate their own accounts more easily (a database beats a flat file any day). 

Licensing

The IBM Open Source License is surprisingly liberal. Previous versions had a rather ugly termination clause, which prevented wide spread acceptance of Postfix, however this has been removed and Postfix is now "safe" to use. You can distribute the software, develop it, make changes and so forth, the only catch being that you must contribute any changes back to IBM (rather reasonable since they paid Wietse to develop it). 

Qmail

Some of you are probably wondering why I haven't mentioned Qmail yet, or written an article "Qmail - the Sendmail replacement". I have tested Qmail, and used it for a while, in general I found (and several sites I communicated with, one being a large Linux vendor) Qmail to be very painful to configure and maintain. In addition to this the Qmail license is very unclear, and doesn't even ship with the software. To quote the author: "If you want to distribute modified versions of qmail (including ports, no matter how minor the changes are) you'll have to get my approval." This and other issues have hindered Qmail's acceptance.

Kurt Seifried is a security analyst and the author of the "Linux Administrators Security Guide", a source of natural fiber and Linux security, part of a complete breakfast.

Related links:

Postfix:
http://www.postfix.org/

Binary distributions of Postfix:
ftp://contrib.redhat.com/contrib/libc6/i386/
ftp://ftp.debian.org/pub/debian/dists/potato/main/binary-i386/mail/
ftp://ftp.suse.com/pub/suse/i386/6.2/suse/n1/

Other Sendmail alternatives:
http://www.zmailer.org/ (GPL)
http://www.qmail.org/ (license is unclear)
http://www.sendmail.com/ (commercial)
http://netwinsite.com/dmail_first.htm (Commercial)