Table of Contents for

Postfix: The Definitive Guide

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.

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 kdent@mail.example.com. However, frequently users want their mail to be sent from the domain name without any extra host information (kdent@example.com instead of kdent@mail.example.com). If that is the case, set myorigin to $mydomain:

myorigin = $mydomain

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.

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.

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.

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.

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.