Basic Postfix Configuration

Like Exim, Postfix was designed to have a main configuration file that can be easily interpreted and edited by humans ”or at least, by humans who know enough about SMTP terminology to understand the names used. Postfix was also designed to be a modular mail server, in which multiple programs work together to accomplish the tasks performed by just one program in sendmail or Exim. The general outlines of Postfix's features are similar to those of sendmail or Exim; like these other SMTP servers, Postfix allows address masquerading, acceptance of mail sent to multiple domains as local, a variety of relay options, and anti-spam features.

Postfix is the default MTA with Linux Mandrake, but it's available as an option in some others, including Debian and SuSE. The Red Hat PowerTools collection includes Postfix, as well. The Mandrake RPM package can be installed in many other RPM-based Linux distributions, although the SysV startup script included in that package may not work. Because Mandrake is the major distribution that uses Postfix by default, this discussion focuses upon Postfix as delivered with Mandrake. Most other Postfix packages are similar in their defaults, though.

Postfix's Configuration Files

The Postfix configuration file you're most likely to modify is main.cf , and it's normally located in /etc/postfix . You specify features such as your local domains and relay configuration options here. Most items in main.cf take the following form:

  option  =  value  

Some of the main.cf options are referred to in later lines as variables . This is done by preceding the original option name with a dollar sign ( $ ) and placing it in the value position. For instance, consider the following pair of lines, which may be separated by many other lines:

 myhostname = franklin.threeroomco.com myorigin = $myhostname 

This combination sets the myhostname variable to the computer's hostname, franklin.threeroomco.com , and then sets myorigin to the same value. Such chains are common in Postfix, so you may find yourself tracing back through variables to determine what a given option is set to be.

The default main.cf file consists mostly of comments, which are lines that begin with pound signs ( # ). These comments do most of the work of documenting the options that they precede, so you can learn a great deal about Postfix configuration by reading its configuration file.

The main.cf file includes references to several other files. As with sendmail , some of these are binary files (with .db filename extensions) that are built from files of the same name, but lacking the .db extensions. The file of this type that you're most likely to want to edit is aliases ( aliases.db in its binary form). This file sets up delivery aliases, much like the sendmail file of the same name. For instance, a line in this file that reads root: amelia causes all mail addressed to root to be delivered to amelia . To convert the text-format aliases file into the binary aliases.db , type postalias aliases from the directory in which aliases resides.

After you modify a text-mode file and create the matching .db file, Postfix will eventually discover the changes. You can speed this process up by typing postfix reload or by restarting Postfix through its SysV startup script.

Postfix Address Masquerading

The myorigin parameter sets the name that Postfix uses to identify itself to remote systems. A default configuration sets this parameter to the value of the $myhostname variable, which in turn defaults to the computer's regular hostname. This default configuration works well for many systems, but you may want to change it if the computer has multiple hostnames or if you want to use the domain name rather than the hostname. To do this, you should set the myorigin parameter to something appropriate, like this:

 myorigin = threeroomco.com 

Alternatively, you can use another variable on the value side of this assignment. One possible value is $mydomain . This variable defaults to $myhostname minus the leftmost component. For instance, if $myhostname is franklin.threeroomco.com , $mydomain defaults to threeroomco.com . You can set any of these by inserting appropriate lines in main.conf . In fact, the default main.conf includes example lines that have been commented out, so you can uncomment these and edit them to suit your needs.

Setting myorigin only performs a very basic form of address configuration. Specifically, this setting only affects initial SMTP handshaking and the default address that's used if a mail program doesn't explicitly set the domain part of a From: address. You might want to perform a somewhat more complete form of address masquerading if your mail server relays mail for other systems on your domain, which might set their own complete addresses in their headers. For instance, suppose a Postfix client wants to relay mail through Postfix, but the client specifies a From: address of [e-mail] . You might want to remove the client portion of that address, yielding [e-mail] . Assuming that the $mydomain variable is set to threeroomco.com , you can accomplish the goal by using the following option:

 masquerade_domains = $mydomain 

This option causes Postfix to strip away the nondomain portion of any hostname within $mydomain when it processes the mail message. The result is that both From: and To: headers for mail from systems within $mydomain will show $mydomain addresses, not individual systems within $mydomain .

You can implement a still more complete form of address masquerading, also known as address rewriting, by pointing Postfix to a rewriting database file with the sender_canonical_maps option, thus:

 sender_canonical_maps = hash:/etc/postfix/sender_canonical 

You can then create a set of mappings in the sender_canonical file. Each line of this file contains an address that might appear in a header followed by the address with which it should be replaced . For instance, the following two lines replace both client.threeroomco.com and localhost with threeroomco.com :

 @client.threeroomco.com @threeroomco.com @localhost @threeroomco.com 

You can use a similar technique if you need to remap usernames. For instance, your e-mail system might be in transition between ones that use different username forms. You can use a canonical map file to convert all references to the obsolete addressing to the new one on a user-by-user basis (one line per user ).

After creating the sender_canonical file, you must convert it to a binary form by typing postmap sender_canonical . You can then type postfix reload or restart Postfix to have it use the new mapping.

As a general rule, you should use the minimum level of address masquerading that you require. Most Postfix installations work fine with nothing more than the default settings, or perhaps an explicit adjustment to $myorigin . The masquerade_domains option is useful on mail relays that may process mail that's already passed through mail servers on Linux or UNIX workstations. Address rewriting is extremely powerful, in part because it rewrites much more of the e-mail's headers than do the other techniques, including even the contents of the Received: headers. This fact makes many administrators reluctant to use this feature, but sometimes it's very useful, particularly if you have programs that insist on using peculiar usernames or hostnames in their From: addresses.

Configuring Postfix to Accept Mail

Like other mail servers, Postfix accepts as local only mail addressed to specific hostnames. Postfix uses the mydestination parameter to decide what hostnames to treat as local. This parameter defaults to $myhostname plus localhost.$mydomain . For instance, if $mydomain is threeroomco.com and $myhostname is franklin.threeroomco.com , Postfix accepts mail addressed to franklin.threeroomco.com or localhost.threeroomco.com .

You can easily adjust the mydestination parameter, and in fact a mail server for a domain should have this parameter adjusted to include at least $myhostname and $mydomain . Adding localhost alone is also often a good idea. You should separate your entries with commas or spaces. In sum, a typical mail server for a single domain might include an entry like the following:

 mydestination = localhost, localhost.$mydomain, $myhostname,                 $mydomain 

NOTE

You do not need to end a mydestination line with a backslash ( \ ) if it continues to the next line, as is the case with many configuration files. Instead, the second and subsequent lines should begin with a space or tab to signal that they're continuations of the first line.

You can have a Postfix server handle multiple domains by specifying them all in a single mydestination parameter. Most of these domains would be listed explicitly, rather than through variables.

Postfix Relay Configuration

Like most mail servers, Postfix supports many relay options, including both using the Postfix computer as a relay and having Postfix deliver its outgoing mail through another computer that functions as a relay. These relay options are configured through the main.cf file.

Configuring Postfix to Relay Mail

By default, Postfix relays mail that meets any of the following criteria:

• The sender is on any of the networks specified by $mynetworks . This variable defaults to the networks associated with all of the computer's network interfaces, including the localhost interface.

• The sender is in a domain specified by $relay_domains . This variable defaults to the value of $mydestination .

• The sender is attempting to relay mail to a computer in one of the $relay_domains domains, or a subdomain thereof.

The defaults mean that Postfix relays for any computer that's on any of Postfix's local network interfaces, or in the same domain as Postfix. This configuration works well for many mail servers that should function as local relays, but you may want to adjust it. To do so, you may need to alter either or both of $mynetworks and $relay_domains . For instance, suppose Postfix is to function as the MTA for a workstation called work.threeroomco.com . Such a system should never relay, so you might want to redefine these variables as follows :

 mynetworks = 127.0.0.0/8 relay_domains = work.threeroomco.com 

This configuration limits relaying to the localhost network and the Postfix mail server itself. On the other hand, you might want to loosen relaying to include additional domains or networks. You might do so with parameters like the following:

 mynetworks = 192.168.99.0/24, 172.24.0.0/16, 127.0.0.0/8 relay_domains = $mydestination, pangaea.edu 

These options cause Postfix to relay messages originating from the 192.168.99.0/24, 172.24.0.0/16, and localhost (127.0.0.0/8) networks, or from the $mydestination or pangaea.edu domains.

Underlying the mynetworks and relay_domains controls, as well as several other delivery and relaying restriction options, is the smtpd_sender_restrictions parameter. This option doesn't appear in the default main.cf file, but you can add it if you need even finer control over relaying. You can read more about it in the Postfix documentation. The permit_mx_backup value to this option is noteworthy as being similar to sendmail's relay_based_on_MX feature.

Configuring Postfix to Send Through a Relay

In a simple case, configuring Postfix to use another system as a relay requires setting just one option in main.cf : relayhost . This option specifies the hostname of a computer that can function as a mail relay for your domain, or the name of the domain if the MX record for that domain points to the appropriate mail relay system. For instance, if the mail relay for your system is franklin.threeroomco.com , you could use the following line in main.cf :

 relayhost = franklin.threeroomco.com 

If your system is in the same domain as the relay system and if the MX record for that domain points to the correct system, you can use $mydomain in place of franklin.threeroomco.com . Using the domain name has the advantage that Postfix will automatically adjust should your domain's mail server change.

Normally, Postfix attempts to use DNS lookups when sending mail. If your local network lacks a DNS server (for instance, if you rely exclusively upon /etc/ hosts entries for local name resolution), you should include one additional line:

 disable_dns_lookups = yes 

This line causes Postfix to not rely upon DNS lookups for name resolution, so it can contact the relay system by means of an /etc/hosts entry or the like.

Postfix Anti-Spam Configuration

Postfix, like sendmail and Exim, provides several anti-spam measures, some of them very sophisticated. You can use a pattern matching system to block spam based on patterns in mail headers or use a blackhole list.

The main Postfix pattern-matching tool is a fairly sophisticated one that examines message headers using a regular expression system. You can specify that a message be rejected based on a match against a regular expression, similar to those used by the egrep tool. This system is frequently used in conjunction with a separate file of regular expressions, although you can specify regular expressions in the main.cf file itself. The more common configuration points Postfix to an external file by using a main.cf entry like the following:

 header_checks = regexp:/etc/postfix/bad_headers 

You would fill the file bad_headers with regular expressions like those shown in Listing 19.2. Postfix attempts to match the message headers sent with the message against these regular expressions, and if it matches and the file specifies that the message should be rejected, the message is bounced. The regular expressions can be either POSIX-style (indicated by a regexp: specification, as shown above), or PCRE-style (indicated by a pcre: specification).

Listing 19.2 Postfix regular expression spam filter file

 #### Spam-sign subject headers /^Subject: ADV:/ REJECT /^Subject: Accept Visa/ REJECT #### From: and Received: headers from spammers /^(FromReceived):.*badspammer\.net/ REJECT /^From: spammer@abigisp\.net/ REJECT 

NOTE

The upcoming section, "The Recipe Conditions," describes regular expressions in more detail. For still more information, consult the egrep man page.

Postfix's header_checks option is extremely powerful, but it can be difficult to configure and maintain. A simpler approach is to use a blackhole list. You can do so by using two main.cf options, as shown here:

 maps_rbl_domains = relays.mail-abuse.org, dialups.mail-abuse.org smtpd_client_restrictions = reject_maps_rbl 

The maps_rbl_domains option allows you to specify server addresses for blackhole lists, as shown in Table 19.1. You can list several domains, separated by commas or spaces. The second line tells Postfix to use those domains as a basis for rejecting mail from the sending host. The smtpd_client_restrictions option can take other values instead of or in addition to reject_maps_rbl . For instance, reject_unknown_client causes Postfix to refuse delivery if the sending system doesn't have a valid reverse DNS lookup. The Postfix documentation goes into more detail about these options.

In addition to explicit spam controls, Postfix sports a number of options that, while not strictly anti-spam measures, may have some beneficial effect on spam delivery. These include the following:

• smtpd_helo_required ” This option defaults to no , but if you set it to yes , Postfix won't process a message unless the sender uses HELO or EHLO . This blocks some poorly written spam software, but it also blocks some misconfigured but otherwise legitimate SMTP servers.

• smtpd_helo_restrictions ” You can further tighten Postfix's handling of HELO or EHLO transactions with this option, which takes several values. For instance, reject_unknown_hostname causes Postfix to terminate the connection if Postfix can't find an A or MX record for the specified calling hostname, and reject_non_fqdn_hostname requires that the sender use a fully-qualified domain name (FQDN) ”one that includes both a hostname and a domain name. There are several other possible values for this option; consult the Postfix documentation for details.

• smtpd_sender_restrictions ” If this option is present, it requires that the From: address meet the specified criteria. For instance, reject_unknown_sender_domain causes a rejection if Postfix can't find the specified From: address's domain, and reject_non_fqdn_sender requires that the sender use an FQDN as part of the address.

These or other Postfix options may be useful in various situations, but the defaults (which don't place too many restrictions) are a good starting point. Implementing too many restrictions too quickly can result in lost mail.

Preventing Postfix from becoming a source of relayed spam, of course, depends on appropriate anti-relay configuration. The default Postfix configuration is slightly more open than that of recent versions of sendmail because Postfix comes configured to relay mail for its local domain and network. You may want to tighten this configuration for Postfix on a workstation, as described earlier.