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.
We discussed the purpose and importance of the
myhostname parameter earlier in this chapter. If
myhostname is not specified, Postfix uses
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
mydomain to your system's domain. If
mydomain is explicitly set, Postfix
the domain name specified and the local hostname reported by
gethostname to create the fully
If you set
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
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
myhostname parameters, Postfix reports the
problem in your log file. See Section 4.4.1 later in this
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
From: address of
email@example.com. However, frequently
users want their mail to be sent from the domain name without any
extra host information (firstname.lastname@example.org
instead of email@example.com). If that is
the case, set
myorigin = $mydomain
parameter lists all the domains your Postfix system should accept
mail for and deliver to local users. By default Postfix accepts mail
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.
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 .
By default Postfix is not an open relay. The
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
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"
Alternatively, you can explicitly indicate the hosts that
should be allowed to relay mail by setting
mynetworks. If you set
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.