Last updated on September 2^nd 2004

Contents

Introduction
Major Features
Installing Postfix
Configuration
POP-Before-SMTP Authorization
High-End Use Considerations
Content-Filtering in Postfix
Case Study (Small ISP)
Unique and Free Scripts
Monitoring Postfix
Postfix Books
Important Links

Introduction

Have you had enough of sendmail yet? ;)

If you use your system for anything more than the most basic Email needs and especially if you're using Email for your business or as an ISP - you owe it to yourself to check out Postfix as a replacement for the stock Solaris sendmail implementation. In fact, many BSD and Linux distributions already come with Postfix installed instead of sendmail and is gaining ground among those in the know.

Postfix is quantum leaps ahead of sendmail when it comes to configuration, tuning and customization - not to mention fighting spam. Instead of dealing in archane rules which requires its own book to understand, and even then only by long, grey-bearded wizards, Postfix configuration is done using Apache style directives and table lookups. Forget understanding various macros and strange options in the sendmail.cf file and dig on the new style of doing things that is Postfix.

Major Features

There are numerous reasons why you would want to replace sendmail in addition to the above, namely some really great features that modern users of Email expect and things that system administrators really need.

A couple of configuration files with understandable names help spread out the available options and configuration information. What makes Postfix really nice as a replacement for sendmail is the fact that you can seamlessly and transparently replace sendmail using the same files you're already used to, making migration easy. Postfix supports the /var/mail/ filesystem, /etc/aliases, /etc/access, NIS, NetInfo and ~/.forward files. Virtual hosting is incredibly easy to implement and Postfix' handling of table lookups for its information in various formats allows it to scale very well indeed, using things like a SQL database, LDAP, NIS/NetInfo and DB or flat files.

Postfix also strives to be much more secure than sendmail, which is known for having more than its share of exploits and security holes. Using multiple layers of defense to protect the local system against intruders, almost every Postfix daemon can run in a chroot jail with fixed low privileges. There is no direct path from the network to the security sensitive local delivery programs - an intruder has to break through several other programs first. Postfix does not trust the contents of its own queue files, or the contents of its own IPC messages either. Postfix filters sender-provided information before exporting it via environment variables and finally, no Postfix program is set-uid, utilizing its own user and group like Apache does.

Postfix was developed to be fast - much faster, with higher throughput potential than sendmail. A desktop PC running Postfix can receive and deliver a million different messages per day using Web server tricks to reduce process creation and file system overhead, without compromising reliability. A dozen little programs that each perform only one specific task and that are true to the Unix way of doing things make up Postfix, versus the monolithic sendmail daemon. Sites with specific requirements can replace one or more of these programs with custom ones. It is similarly easy to disable functionality as well. Firewalls and client workstations don't need local delivery at all. Another smart design feature is the way Postfix exponentially backs off as the load increases and always remains in control. Mail bombs and heavy loads are handled gracefully and don't bog the server down, bringing it to its knees.

Spam (a.k.a. "Unsolicited Commercial Email" or UCE) is the bane of every user of the Internet and has become a serious issue. The best way to protect yourself, your users and your systems is to stop the means by which these scum perpetuate it. Postfix can restrict what hosts can relay their mail through the system, and supports restrictions on what mail is allowed to come in. Postfix implements the usual suspects: blacklists, RBL lookups, HELO/sender DNS lookups and more. Content filtering for either spam or viruses has also been implemented in Postfix through header and body filtering and also third-party software and supports both regular and Perl regular expression syntax. If you have a wide user base with often changing IP addresses, you could use DRAC and some custom configuration tweaks and allow "POP-before-SMTP" authorization en masse.

What is Postfix not? Sendmail can communicate using SMTP, DECnet, X.400 and UUCP. Postfix is designed to be flexible enough that it can operate in such environments without requiring virtual domain or alias kludges, but the initial release only talks SMTP, and has only limited support for UUCP. Postfix also lacks the complete rule-based functionality of sendmail on such a grand scale for address rewriting (lacking it's own language) but instead offers simple to understand directives and table lookups. Unless you have some extensive backwards-compatibility to worry about or frequently exchange Email with a wide variety of odd or old hardware systems, Postfix should be all you need. Adding support for other lookup mechanisms is relatively easy.

Postfix was written by Wietse Zweitze Venema and formerly known as VMailer. It was released by the end of 1998 as the IBM Secure Mailer and then became known as Postfix.

Installing Postfix

Postfix can be obtained either through binary packages or can be compiled and installed directly from source code. The latter is usually the preferred method so as to be sure you're installing the latest stable version rather than relying on potentially insecure or flawed previous releases since binary packages aren't necessarily known for being very current. Also, since you're compiling the source code from a trusted source, you can be sure you're getting the pure code without the potential for anyone to have done anything dubious with the package.

You can download the source code from your nearest mirror. One thing that I'm very happy to see is the new version numbering scheme implemented. Postfix releases used to consist of the date of release rather than actual version numbers and while concise, were a few too many numbers to read. For example, rather than "postfix-19991231-pl13.tar.gz" you can now anticipate something like "postfix-1.1.3.tar.gz" instead.

Once you have the source code, uncompress, compile and install as you normally would any software package. More details on how to do this specifically, will be added shortly.

Once you've installed and tested Postfix and find that it is of production quality and able to handle your needs, you might want to remove sendmail completely and perhaps most importantly cleanly - from the system. To do so, use the Solaris tool "/usr/sbin/pkgrm" to remove the sendmail package. This ensures that you get all the files, and do so in a clean manner rather than just deleting or overwriting files which makes for a nice, sano install. The two packages that make up sendmail are "sendmail root" and "sendmail usr" and can be found by issuing the command "pkginfo | grep sendmail." Issue the command "/usr/sbin/pkgrm SUNW___" to actually remove each package.

Configuration

Configuration, as already hinted - is much, much easier with Postfix over sendmail. You have one master configuration file, and several other files for various options - most of which being examples that you can modify and include. Actual data such as aliases, virtual domains that you host and access controls are all contained in lookup tables that can either be flat files or database driven. They can be locally hosted, or remote.

While this article aims to be complete, the vast options available to you are beyond its scope and are better left to the documentation available on the Postfix site which will be maintained and kept up-to-date with the current release of Postfix.

A great introduction to basic configuration is one such example.

POP-Before-SMTP Authorization

POP-Before-SMTP Authorization via DRAC can be handled very nicely by following this DRAC HOW-TO written by Ralf Hildebrandt. In order to use it, you'll need to have the Berkeley DB library installed and use an IMAP or POP client that can work with DRAC. A great POP server that works with DRAC and the one that I recommend is Qpopper which is written by the Qualcomm people behind the Eudora Email client, and is quite popular among the ISP crowd for it's feature set. See the DRAC home page for details on how to install and set it up.

The combination of Postfix, Qpopper and DRAC make a great solution for ISP or mobile business user situations where your users/customers can have variable IP addresses yet need to send/relay Email through your server.

High-End Use Considerations

For high-end use of Postfix, certain considerations must be taken. For example - high availability, scalability, robustness, redundancy, storage and bottlenecks must all be considered, depending on your intended use of Postfix in your environment. Let's take a look at each of these fine buzzwords individually, and see what they mean in regards to Postix.

High availability means having your Email server up and running not only as much as possible, but pretty much 365 days a year, 7 days a week, 24 hours a day without fail. Whether this can be accomplished or not - should also entail having backup servers (a.k.a. "backup MX hosts") in case your main server is down to hold the Email until it's back up again. In this case, your set up would be just like with sendmail; having two (or more) servers that are in different locations and on different backbones or networks if at all possible. One should serve as the "backup MX host" via DNS MX records.

Scability and robustness are design considerations that you need to be aware of as you build up your infrastructure. If you build a server for X number of users, what happens if you suddenly needed to support twice as many users? How about triple? How easily could you provide better processing power or more storage without ripping apart what you already have? How about peak loads and spikes - can you easily handle them, should they occur?

Rendundancy is similar in concept to high availability but in this case goes deeper, to the system level. Instead of having a system like a desktop PC with one CPU and one power supply, take a Sun Microsystems E220R rack-mount server. It has two CPUs that can work independantly of each other, even having one fail, the system continues. Same thing with faulty RAM DIMMs as they are quietly shut down and ignored. Dual power supplies also exist in the event of a failure. All are designed to provide redundant subsystems in the event of a failure.

Storage depends on how much Email volume you anticipate having. If you're a small company or department, you can get by with a normal desktop PC hard drive without much worry. If you're a larger company or an ISP however, you had better consider something much beefier. Two popular options here include RAID and NAS ("network attached storage") solutions. Depending on your exact requirements and sheer storage needs that can scale well you might consider using either a SAN or NAS solution, NFS mounting your mailspool files.

Bottlenecks can arise in multiple areas of your configuration, from CPU to RAM to storage or all of them combined. Heavy Email use is very storage I/O intensive as mail moves from queue to queue (various areas of the filesystem) and activity is logged. Considering storage options as above, it would be wise to store your mailspools on RAID or SAN/NAS solutions. In the case of the latter, consider the network traffic you'll be generating and the possible need for a dedicated back-end storage network, possibly Gigabit copper or fiber. CPU and RAM usage is generally very well behaved with Postfix as it was designed to be so. However, keep an eye on these resources using your normal Solaris tools as your server runs during various perdiods of the day to spot potential problem areas before they manifest themselves that could lead to outages in service or lost mail.

No matter what or how you design your infrastructure using the above techniques, you must always test it and make sure it works as planned before it ever goes into production. Folks get real antsy when they lose their Email or when they can't access it! Security and anti-spam measures should also be extensively tested. Think about having a "development box" where you can test things out before pushing to the production, or live server.

Content-Filtering in Postfix

This section was graciously submitted by Andy Harrison!

One of my favorite features of Postfix is its ability to match patterns against the envelope of an incoming message. The message is rejected before the body is even received. Say good-bye to repetitious spam!

There are two methods of pattern matching filters, Perl compatible regular expressions (PCRE) and good old regular expressions. To enable PCRE, first make sure you have the PCRE library installed on your system. You can find the latest version at:

ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/

Then, in your postfix main.cf config file, you'll need a line like:

header_checks = regexp:/path/to/antispam_regexp, \
  pcre:/path/to/antispam_pcre

You can also do body_checks if you enabled it at compile time, but keep in mind, this can add some serious load to a heavily used mail server.

I do my own additions to the antispam_regexp file, but I stumbled upon a nice file of PCRE expressions somewhere on the Net while scouring for anti-spam info. It has some great matches that detect many of the mass-Email software and reject them, as well as some other nice matches that basically notice common mistakes spammers make. I don't like to post this publicly because eventually it will help the spammers discover what mistakes they're making and become better spammers.

The format of the regexp file is pretty basic regexp stuff. The tricky part is that spammers are creative and know that we're filtering against them so they come up with different ways to put the same subject. "University Diploma" has gone through many variations, such as "u n i v e r s i t y, u-n-i-v-e-r-s-i-t-y, etc." So you'll want to use your regexp skills to match them all. I use:

/^subject:.*u.*n.*i.*v.*e.*r.*s.*i.*t.*y/          REJECT

This will flush it all. If someone sent a legit mail to you that contained the word "university" in the subject, they'll simply get a message back stating "content rejected."

If you aren't regexp savvy, the ".*" means, put simply - zero or more characters. So "u.*n" would match a "u" followed by zero or any number of characters, followed by an "n." This will match regardless of spaces, as well. This is important because I try to never put spaces in my filter expressions, remembering that spammers are devious and creative in their unethical endeavors.

Another good syntax to use is the "or" syntax. In my regexp file, I have:

/^Subject:.*debt.*(consolidat|eliminat)/           REJECT

This will match "debt consolidation" as well as "debt elimination" and reject it. Notice I leave everything off after the "t" because the spammers use the words consolidate, consolidation, consolidating, etc. You don't have to worry about capital letters, though, the regexp file is not case sensitive.

You aren't restricted to just subject filtering, either. Call me unworldly, but I don't know anyone from Hong Kong, nor India, yet I regularly would receive spam from there. So, I also have in my regexp file:

/^From:.*\.in$/                                    REJECT
/^From:.*\.hk$/                                    REJECT
/^Received:.*from.*\.in /                          REJECT
/^Received:.*from.*\.hk /                          REJECT

You don't even have to specify subject, from, or received in your expressions, either. I have an entry in my file for:

/40x40x40/                                         REJECT

I've seen the "40x40x40" as a subject, from address, even a hostname, from people trying to warn me about the 40x40x40 plan.

I have saved my best for last though. Probably the single best addition to my regexp filters were these:

/^subject.*     [0-9]{5,}$/                        REJECT
/^subject.*     [a-z]{5,}$/                        REJECT

Ever notice that a great deal of your spam comes through with that little serial number way at the end of the subject line? Well, this matches against it. It's probably responsible for having removed 50% of my spam. This filter alone is worth the effort!

Case Study (Small ISP)

A case study of using Postfix in a small ISP environment... Will be added shortly.

An example infrastructure utilizing Postfix in a small ISP environment, featuring NAS storage on a dedicated gigabit fiber network with fully redundant servers and backbone connections. The infrastructure looks similar to the following diagram:

Unique and Free Scripts

As you use Postfix day-to-day, especially in a high volume environment, you begin writing little scripts to make common tasks easier. Below are several scripts that I've begun to develop during use at a small ISP to do things such as pruning the current queue or performing simple searches for possible spammers in your system log file (/var/log/syslog).

These scripts are not necessarily or likely to be fully developed, as they were a work in progress and more as a proof of concept - but do in fact work. They'll be refined and these copies updated, but for the meantime and in an effort to illustrate some possibilities they are presented here for your free use. As such, they bear no warranties and use them at your own risk...

This script checks for "unknowns" trying to send mail through our server, which so far have all been rejected and usually show a pattern of forged "From:" addresses.

#!/bin/sh

echo "Top twenty unknowns possibly sending spam:"
echo ""
echo " ### IP Address of Origin"
echo "------------------------------"

grep 'RCPT from unknown' /var/log/syslog | awk '{print $12}' | \
  grep -v "RCPT" | sort | uniq -c | sort -rn | head -20

This will generate a "top twenty" listing of "reject" messages in /var/log/syslog. This tells you who the biggest offenders are possibly in tracking down spam, resource abuse (DoS), etc.

#!/bin/sh

grep "reject" /var/log/syslog | awk -F':' '{print $5, $6, $7, $8}' | \
  sort | uniq -c | sort -rn | head -20

This script copies all the important Postfix files in the /etc/postfix directory to the hidden /etc/postfix/.backup directory just to be safe before you make any changes to the existing files. Simple run this script first, then modify your files. Of course, if you have other or different files, then modify the script to suit your needs.

#!/usr/local/bin/bash

# Copies all the important Postfix files in the /etc/postfix directory
# to the hidden /etc/postfix/.backup directory just to be safe before
# you make any changes to the existing files.
#
# This should probably be cron'ed but if you hose something when the
# cron hits, it will wipe out your backup.  D'ohhhh!
#
# Maybe stash it on the NetApp and let SnapRestore deal with it...

echo
echo "Backing up critical Postfix config files to /etc/postfix/.backup..."

cd /etc/postfix
cp aliases access relay_domains otherhosts virtual main.cf /etc/postfix/.backup/
cd -

echo "Done."
echo

This script makes restarting Postfix just as easy as the normal Postfix tools, but includes the commands necessary to ensure that the latest versions of the lookup tables are used as well. This is just an example, and should be modified to suit your environment more closely.

#!/usr/local/bin/bash

# Quick script - much easier to do and ensure a clean, total restart
# of Postfix with all the latest files.

echo "Flushing Postfix queue..."
  /usr/sbin/postfix flush

echo "Generating fresh aliases dbm files..."
  newaliases

echo "Generating fresh access dbm files..."
  /usr/sbin/postmap /etc/postfix/access

echo "Generating fresh virtual dbm files..."
  /usr/sbin/postmap /etc/postfix/virtual

echo "Hard-bouncing Postfx now..."
  /usr/sbin/postfix stop
  /usr/sbin/postfix start

echo "Postfix restarted..."

Monitoring Postfix

So how do you know just what your mail server is doing? Is it performing well? Are the number of messages you process increasing or decreasing and at what rate?

Using the great pflogsumm.pl Perl script written by James S. Seymour you can keep a close watch on just what Postfix is processing day to day. This is a VERY useful tool in helping you analyze your Email server's throughput and usage, as well as for keeping an eye out for spam sending bastards out there so that you can put their IP addresses and domains in your /etc/postfix/access file for blocking, if the built-in rules fail to catch them.

Visit the "PostFix LOG entry SUMMarizer" home page for more info.

A script run through crontab every day at midnight to Email the Postfix statistics for the day to the root user:

#!/bin/sh

/etc/postfix/pflogsumm.pl -d yesterday -smtpd_stats --verbose_msg_detail \
  /var/log/syslog | /usr/bin/mail root@localhost

Postfix Books

There is currently only one book on Postfix, entitled "Postfix" published by Sams and written by Richard Blum.

To see all books currently available covering either sendmail or Postfix, try this link.

Important Links

Overview - A summary of what Postfix is all about
Anatomy - A tour through the Postfix mail system
Configuration - Postfix configuration, basic and advanced
The Postfix FAQ
Postfix release mirrors
Postfix Solaris Package Maker Script
Red Hat Postfix FAQ
Postfix SMTP Authentication HOWTO by Devin L. Ganger
HOWTO by Ralf Hildebrandt
Postfix HOWTO by Matthias Andree
Virtual+MySQL HOWTO by Daniel V. Pedersen
Configuring large-scale UNIX/Linux servers