Postfix: The Definitive Guide

Important Configuration Considerations

We saw at the beginning of this chapter how Postfix requires only minimal configuration changes to work. Depending on how you plan to use your Postfix system, you may want to consider some of the more common options. This section discusses how your system identifies itself, and then covers the very important topic of relay control.

Configuring Your MTA Identity

There are four parameters dealing with your system’s hostname and domain that you want to consider, no matter how you use Postfix: myhostname, mydomain, myorigin, and mydestination.

myhostname and mydomain

We discussed the purpose and importance of the myhostname parameter earlier in this chapter. If myhostname is not specified, Postfix uses the function gethostname to determine what your system’s hostname is. If your system correctly reports the fully qualified hostname, you can leave myhostname unspecified in the configuration file. Some systems may not be configured correctly or may not report the fully qualified version of the hostname. In these cases, you can set either myhostname to the fully qualified hostname or mydomain to your system’s domain. If mydomain is explicitly set, Postfix automatically sets myhostname to the domain name specified and the local hostname reported by gethostname to create the fully qualified hostname.

If you set myhostname to the system’s fully qualified hostname but omit mydomain, Postfix uses the value of myhostname, minus the first component of the fully qualified hostname, to automatically set mydomain. A value of mail.example.com for myhostname causes mydomain to be example.com unless you explicitly set it to something else. Similarly, a hostname of mail.ny.example.com causes the value to be ny.example.com. If your system does not report its fully qualified name, and you have not set either the mydomain or myhostname parameters, Postfix reports the problem in your log file. See Section 4.4.1 later in this chapter.

myorigin

When your users send or receive mail through the Postfix system with no domain name specified in the envelope or header addresses, the parameter myorigin determines what domain name should be appended. The default is to use the value of myhostname. If Postfix is running on a system whose hostname is mail.example.com, messages from the user kdent have a From: address of [e-mail]. However, frequently users want their mail to be sent from the domain name without any extra host information ([e-mail] instead of [e-mail]). If that is the case, set myorigin to $mydomain:

myorigin = $mydomain

mydestination

The mydestination parameter lists all the domains your Postfix system should accept mail for and deliver to local users. By default Postfix accepts mail destined for $myhostname and localhost.$mydomain. If you want your system to accept mail for your entire domain and not just the single host it is running on, add $mydomain to the list:

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

Now your mail server can act as a gateway receiving all mail for the domain.

Relay Control

In addition to accepting mail and delivering messages to your local users, Postfix also relays messages to other systems. It’s very important to restrict who is allowed to relay messages through your system. Systems on your own network may require the ability to send messages anywhere, but you do not want to provide the rest of the world with the same service. Relay control is an important topic in email administration because of the prevalence of Unsolicited Bulk Email (UBE), or spam. (See Chapter 11for more information on UBE.) A common practice among spammers is to find a well-connected system that allows them to relay their mail. You want to prevent anyone who is not authorized from using your system to relay mail. If you leave yourself configured as an open relay, not only will you be contributing to the spam problem, but your own machine may become unusable as it is abused by spammers. Furthermore, you may find that other systems start refusing mail from you as they discover that your system is the source of spam. They’ll refuse the spam as well as any legitimate messages your own systems send. Mail servers that permit anyone to relay mail are called open relays .

Restricting relay access

By default Postfix is not an open relay. The parameters mynetworks_style and mynetworks determine what other systems can use your mail server to send messages. The default configuration allows relaying only from other machines that are connected to the same IP subnet as your server. You can limit or broaden the range of addresses that should be allowed to relay by setting the parameter mynetworks_style. If you prefer to limit relaying to the local machine only, set mynetworks_style to “host”. You can also set mynetworks_style to “class” to allow relaying by any host within the same class A, B, or C network as your server. For many networks a class setting opens relaying to too many systems. If you aren’t familiar with IP address classes, stick to the default “subnet” or more restrictive “host” settings.

Alternatively, you can explicitly indicate the hosts that should be allowed to relay mail by setting mynetworks. If you set mynetworks, the mynetworks_style parameter is ignored. You can list individual IP addresses or specify subnets using the network/netmask notation—for example, 192.168.100.0/28. This parameter is handy if you need to provide mail relay to hosts outside of your network because you can list specific IP addresses regardless of their relationship to your own subnet. If, for example, you want to provide relaying to remote users, you simply add an IP address to your list. In this case, your remote users need a static IP address, or at least an address assigned from a limited range of addresses. If your remote users do not have static IP addresses, then you have to configure some kind of SMTP authentication.

SMTP authentication

All of the techniques for SMTP authentication introduce their own complexities. You would be wise to consider simpler options before selecting an authentication technique. Is it possible to get static IP addresses for your remote users? Can your remote users avail themselves of another SMTP server? Perhaps your users’ remote access provider offers an SMTP server as well.

Your first inclination may be to use UBE controls to permit mail relaying when a message’s envelope sender address is from the local domain. Don’t do this. Envelope addresses are trivial to fake, and spammers know to use local addresses for this purpose. Configuring your mail server in this way makes you an open relay.

Dynamic IP solutions

Chapter 12 discusses using SASL for SMTP authentication. SASL is a general protocol that defines how a server and client can exchange authentication credentials. It requires that additional libraries be linked to your SMTP server. There are three alternatives to SASL that all work similarly: pop-before-smtp , DRAC (Dynamic Relay Authorization Control), and WHOSON. Each of these methods is designed to work with clients that have dynamically assigned IP addresses. They require that a user first log in to a POP/IMAP server, thereby supplying the client’s currently assigned IP address to your system or network. The client IP address is fed to the SMTP server, which then permits mail relaying by the client system for some configurable time limit. This technique is mostly transparent to end users, but it does require that they first check for new messages (logging into the POP/IMAP server) before trying to send out any messages.

Both pop-before-smtp and DRAC work with Postfix by dynamically updating a Postfix lookup table, adding new addresses as users authenticate, and deleting others when the time period expires. Postfix doesn’t require any special libraries or configuration. You simply configure it to check the lookup table that is updated when users log in via your POP/IMAP server. Your POP/IMAP server, on the other hand, may require changes and recompiling to work. DRAC differs from pop-before-smtp in that it can work over a network, while pop-before-smtp requires that the POP/IMAP server be installed on the same system as the SMTP server.

WHOSON is actually a protocol that provides an interface to both the POP/IMAP and SMTP servers. You have to run a WHOSON server on your network, and you must obtain a patch that adds a new lookup type to Postfix. After building Postfix with the patch, it can communicate with the WHOSON server to determine if a particular client IP address should be allowed to relay mail.

Certificate authentication

Another option to consider is client-side certificate authentication. (See Chapter 13 for a full discussion of Transport Layer Security and certificates.) We normally think of certificates as a means to encrypt communications, but they can also be used as a strong method of authentication. However, they do require management of certificates and support for the TLS protocol.

None of these add-ons is an ideal solution. They require additional code compiled into your existing daemons that may then require special write access to system files. They also require additional work for busy system administrators. If you cannot use any of the nonauthenticating alternatives mentioned earlier, or your business requirements demand that all of your users’ mail pass through your system no matter where they are on the Internet, SASL is probably the solution that offers the most reliable and scalable method to authenticate users.