Converting Sendmail to Postfix, Part Two: Configuring Postfix

This second article in a two-part series on using the mail server Postfix covers basic configuration and some advanced topics, including virtual domains and supporting external and mobile users.

The first article in this series described the advantages of using Postfix
over the "Internet standard" mail transport agentSendmail. This
article covers some basic configuration scenarios.

Basic Postfix Configuration

Postfix, as installed from source or distribution package, requires little if
any changes to work on a computer that has a direct Internet connection. The
Postfix development team has chosen a good set of defaults for all its
parameters to help you through the process of installing and sending email
securely and responsibly. Out of the proverbial box, it just works.

The fact that Postfix works without having to spend your next four weekends
in your office curled up with a nice 1,200-page installation reference manual
(volume 1 of 3, of course) does not mean that there are no settings to change.
Contrary to that belief, there are more than 200 (217 at the time of this
writing) individual settings that alter the behavior of the stock Postfix
installation. This does not include third-party add-ons or patches.

The more you customize and specialize Postfix to mold to your environment,
the more intimate you need to be with the configuration files. Luckily, they are
heavily commented with examples.

The Postfix Frequently Asked Questions (FAQ) document has many examples,
including mobile users who are intermittently connected to the Internet. This
article is primarily concerned with converting clients over from common Sendmail
configurations.

The default installation of Postfix should work the same as any vendor
preinstalled version of Sendmail would. The other key Sendmail configurations
are as follows:

Null-clientA workstation configured for no local mail services; all
email generated on a null-client is sent to the configured mail relay.

SMTP relayUsually a firewall or DMZ server that passes email
through to an internal smart relay mail server, but rejects unauthorized email
and delivers no mail locally.

Supporting Virtual domainsThe common configuration in which the
mail server receives email for domain1.com and domain2.com, and so
on.

Supporting Remote UsersDynamically configured, remotely connected,
remote branches all offer different problems, and should be addressed in the
most efficient manner.

There are two configuration files, master.cf and main.cf,
which primarily define how Postfix operates. From these two files, nearly all
other (if any) configuration files, maps, and lookup tables are defined.
Let's look at master.cf first.

master.cf

The file master.cf is the Postfix master process configuration file.
It defines what and how local Postfix components are used, essentially defining
the entire Postfix system. master.cf is composed of lines that describe
how the Postfix component program should be run. Each line has eight fields that
define the run-time parameters of that particular Postfix service. The fields,
as with just about every aspect of configuring Postfix, are documented in the
configuration file itself. The contents of a working master.cf are
shown below:

The process configuration file allows you to quickly add, remove, or change
parameters and restraints of individual components of the Postfix system. Simply
by commenting out a line, you can turn off a particular service. Likewise,
either uncommenting a line or adding a new one, you can add a program or service
used by Postfix.

If you developed a replacement component that you want to use in place of the
stock Postfix component, you simply need to edit the command-line and arguments
associated with the Postfix service. After you restart the Postfix service, you
have effectively customized the Postfix system without compromising the rest of
the programs or source.

main.cf

The main.cf file is the Global Postfix configuration file, which
defines operational parameters for Postfix as you want it to run on your mail
server. The format is very simple: Lines beginning with the pound (or hash)
symbol are comments and are ignored, as are blank lines. Parameters are set by
using the following pairs:

parameter = value

Lines that begin with whitespace are considered to be part of the previous
line. This makes adding or removing additional parameter values quite nice
because you can simply add or delete lines without worrying about affecting
other values. The values themselves can reference other parameters by using the
$other_parameter_name style.

The main.cf file is heavily commented, but contains only a small
subset of the available parameters and possible values. Fuller listings and
commented usage of the parameters, their values, and their effects are
documented in the examples directory included in the source tar
archive, and usually in the /usr/share/doc/postfix/examples directory
in most GNU/Linux distributions.

Converting Your Sendmail Smart Relays

Smart relays know how to deliver email, either via DNS MX records, or via
special transport routing maps. Smart relays then receive email from client
machines, and will then route and/or deliver it as appropriate on the
client's behalf. Smart relays may also deliver email locally for domains
that it is responsible for, and make those mail spools available via NFS or
POP/IMAP access.

Postfix has sane defaults for all parameters, so there is very little you
need to configure to enable Postfix to start sending and receiving email for
your organization. The snippet below just shows the settings in the
main.cf that most administrators will set. The master.cf
should not need to be changed at all.

Obviously you need to change the $mydomain parameter to match your
own domain, and the $myhostname parameter to match your mail
server's hostname. With those settings in place, you are well on your way
to replacing Sendmail.

Converting your Sendmail Null-clients

A null-client is a machine that can only send mail. It receives no mail from
the network, and it does not deliver any mail locally. A null-client typically
uses POP/IMAP or NFS for mailbox access. The $myorigin parameter is
what gets appended after the @ (at) symbol in the email address, so it
shows where the email originated from. The default is $myhostname,
however, we are not interested in having email sent to individual workstations.
Appending the domain name removes the unnecessary information.

The important line here is relayhost because it instructs Postfix to
use the DNS MX records to find the email relay for this workstation's
domain.

/etc/postfix/main.cf:
myorigin = $mydomain
relayhost = $mydomain

If your organization has not properly set up DNS, and is not using MX records
to help deliver email internally, you can explicitly set the $relayhost
parameter to a fully qualified hostname.

Because the null-client does not receive email, and because it delivers no
email locally, we can edit the master.cf to simplify things and reduce
resource utilization locally:

Comment out the above lines by placing a pound sign before the service name.

Configuring a Firewall Machine as a Relay Only

Running email on your firewall has the potential for trouble because it is an
additional foothold you're providing to attackers. Smaller organizations
that may not have the resources to set up a separate DMZ-hosted email relay can
configure your firewall machine to act as a relay-only email "proxy"
server. The idea is that for the outside world, the firewall will be your
primary mail server. The firewall server will allow incoming SMTP connections
from the Internet. However, the firewall will not delivery email locally; it
will just spool it, and relay it to an internal email server.

The relaying of email to the internal email server is done through the
transport_maps directive. This directive instructs Postfix to look at
the transport map and do pattern matching based on the destination domain name.
The transport file is quite simple:

/etc/postfix/transport:
domain.com smtp:internal-mail.domain.com

After creating the transport file, issue the following command:

postmap hash:/etc/postfix/transport

The postmap command converts the text file into a keyed database
file. The postmap command generally accepts hash, btree, and dbm as the
database type. To find out what types of database lookup methods are supported
by your Postfix installation, type the following:

postconf -m

Restricting the networks that may relay through the firewall, and what
destinations are accepted or rejected is set through a combination of
mynetworks, mydestination, and
smtp_recipient_restrictions. The key value to add to the
smtp_recipient_restrictions is reject_unauth_destination,
which rejects messages that are not addressed properly to match your
restrictions. A snippet of modified parameters in main.cf looks like
this:

The local_transport parameter enforces the fact that no email is
delivered locally, so email to root@firewall.domain.com will be
rejected with the error that local mail delivery is disabled. To enforce this
policy decision, we will comment out the local delivery agent part of Postfix in
the master.cf file:

/etc/postfix/master.cf:
#local unix - n n - - local

Configuring a Postfix to be a Backup Email Server

A very common configuration for email servers is to be a backup mail
exchanger (MX) for a primary mail server. This provides some reliability in an
inherently unreliable Internet. Backup mail servers will receive email on behalf
of other mail servers (thus, this is a form of relaying), but will not attempt
to deliver the email locally.

Configuring Postfix to do backup MX mail forwarding is quite easy. First,
make sure that your Postfix server is listed as a secondary MX server in DNS for
the domain you are backing up. Then, add the domain you are backing up to the
relay_domains parameter. Also ensure that check_relay_domains
is listed as part of the smtpd_recipient_restrictions parameter.