Converting Sendmail to Postfix, Part Two: Configuring Postfix
- Basic Postfix Configuration
- Supporting Virtual Domains
- Supporting External or Mobile Users
- Summary
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:
Smart relay—A mail server responsible for sending and/or delivering email for an entire network of hosts. A smart relay may define alternative transports or routes for email within the organization. The additional email routing rules might override email delivery directions otherwise defined by DNS mail exchanger (MX) records, for example.
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:
# ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (50) # ========================================================================== smtp inet n - - - - smtpd pickup fifo n n - 60 1 pickup cleanup unix - - - - 0 cleanup qmgr fifo n - - 300 1 qmgr rewrite unix - - - - - trivial-rewrite bounce unix - - - - 0 bounce defer unix - - - - 0 bounce flush unix - - - 1000? 0 flush smtp unix - - - - - smtp showq unix n - - - - showq error unix - - - - - error local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp
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.
/etc/postfix/main.cf: mydestination = $myhostname, localhost.$mydomain, $mydomain mydomain = domain.com myhostname = mail.$mydomain myorigin = $mydomain
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:
/etc/postfix/master.cf: #smtp inet n - - - - smtpd #local unix - n n - - local
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:
/etc/postfix/main.cf:
myorigin = domain.com
mydestination = domain.com
mynetworks = 192.0.1.0/24 172.16.2.0/24
transport_maps = hash:/etc/postfix/transport
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
local_transport = error:local mail delivery is disabled on this machine
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.
/etc/postfix/main.cf:
relay_domains = $mydestination
backedupdomain.com
smtpd_recipient_restrictions =
permit_mynetworks
check_relay_domains