|< Day Day Up >|
Fine-tuning a Postfix Configuration
All the Postfix configuration we'll look at is done in the /etc/postfix/main.cf, and options within main.cf consist of lines in the form
where <setting> is one of the Postfix directives, and <value> is a simple setting (such as a hostname, timeout value, and so on), a path to a hash file, such as hash:/etc/aliases, or, in the case of Mac OS X, a NetInfo path, such as netinfo:/aliases. In some cases, lists of values can be used, separated by commas.
A hash file is a binary lookup table that holds key and value pairs. There are two specific types of hash files you'll be interested in with Postfix: map files and alias files, generated with the postmap or postalias command, respectively.
Alias files contain <key> and <value> fields, separated by a colon (:) and whitespace, such as this example /etc/postfix/aliases file:
postmaster: root operator: jray admin: jray
All other hash files simply contain <key> and <value> fields separated by whitespace. The postalias command works exclusively on alias files, whereas postmap is used to generate all other hash files.
To use the Postfix utilities to generate hash files from the corresponding text file, type either postmap <text file> or postalias <alias text file>. Within a few seconds, a binary hash will be created in the same location as the original file, with the extension .db.
Defining Local Domain Names
If your mail server has several different domain names that are capable of receiving mail, you must explicitly list them using the mydestination Postfix directive; otherwise, mail to any name other than your server's primary domain name will be rejected.
Add a line to the main.cf file with all the names for which your mail server should accept email. For example, I want to be able to accept email for poisontooth.com, mail.poisontooth.com, and mail.shadesofinsanity.com. Each of these hostnames' DNS entries points directly to the server. By default, the names $myhostname and localhost.$mydomain are used so when adding new names, be sure to add the defaults back in as well.
To make sure that Postfix accepts email for all the names, my mydestination directive would look like this:
mydestination = $myhostname, localhost.$mydomain, poisontooth.com, mail.poisontooth.com, mail.shadesofinsanity.com
Creating Account Aliases
Aliases provide simple mailing list functionality, enable users to receive email under multiple names, and forward messages to another email account. Aliases are added to the file /etc/postfix/aliases. The aliases file contains lines with the username that will receive email, followed by a colon, and then the email address (local or remote) that should get the message:
<email username>: <recipient email address>
webmaster: jray jraywork: email@example.com root: jray, hlaufman
After editing, the aliases hash file must be rebuilt by running newaliases at the command line or postalias /etc/postfix/aliases. If the database is not rebuilt, Postfix will not notice the changes you've made.
In this simple aliases file, email addressed to Webmaster would be sent to the local user jray, whereas email addressed to jraywork would be forwarded to the account firstname.lastname@example.org. Finally, any messages sent to root would be automatically sent to both jray and hlaufman two local-user accounts.
To simplify and modularize aliases that direct email to multiple users, you can include files that list several email addresses. Consider a line such as
When this entry is added in the aliases file, it includes the list of email addresses in the file /etc/postfix/job.list. This is a convenient way to create a mailing list with little work.
Mac OS X's Postfix implementation offers an alternative way to add mail aliases: via the NetInfo database system. This results in a setup that isn't directly transferable to other Unix systems, but allows you to use the NetInfo Manager and nicl command-line utility to quickly add aliases.
To add aliases directly to the /aliases directory within the NetInfo database, you must first create a NetInfo directory with the name of the alias and then add a member's key with the appropriate alias information. Think of this as splitting the lines in the alias file on the first colon (:) character. The information to the left of the : is the NetInfo alias name, and the information to the right is the member name. For example, consider this line as it appears in /etc/mail/aliases:
This information could be added directly to NetInfo using
brezup:jray jray $ sudo nicl / -create /aliases/jraywork brezup:jray jray $ sudo nicl / -append /aliases/jraywork members email@example.com
The NetInfo GUI tools can be used to perform this action as well. Chapter 20, "Configuring Advanced System Features via NetInfo," discussed the use of the NetInfo Manager utility.
Within the .forward file, add a single line containing the email address to which email should be forwarded.
When you changed the myhostname and mydomain directives to enable Postfix, you edited two out of hundreds of configuration options available for use in the /etc/postfix/main.cf file. Table 26.1 contains a number of settings that you might find useful.
If you plan to operate a successful and secure mail server, you should learn how to control external access to Postfix. The smtpd <object>_restrictions directives provide a wide range of restrictions. These directives control access to the server and can be applied against client addresses, HELO/EHLO headers, and MAIL FROM/RCPT TO addresses.
Four different types of restrictions are considered here: client (smtpd_client_restrictions), helo (smtpd_helo_restrictions), sender (smtpd_sender_restrictions), and recipient (smtpd_recipient_restrictions). In addition to a standard access hash table (see /etc/postfix/access as an example), the restrictions also share some common additional restriction options, so rather than list them separately, Table 26.2 combines them.
Let's take a look at a few examples of restrictions that can be made in your main.cf file.
By default, Postfix only serves as a relay (only transmits messages) for your local subnet. This means that you can start the server without worrying about whether it will be used to send spam. As the administrator, you will, however, need to make choices on what relaying capabilities the server should have.
In a situation in which you need to relay for multiple domains or subnets, use the relay_domains directive to list the subnets that are allowed to transmit mail through your server. For example, assume that I want people in the subnet 192.168.10.0/24 along with those in the domain mysaferelayusers.com to be able to send messages via my Postfix installation. To enable this, I could add
relay_domains = 192.168.10.0/24, mysaferelayusers.com
to the main.cf file. If you want to break this out into a separate file, you can do so using a hash table or a simple text file with one network/domain listed per line:
relay_domains = $config_directory/my-safe-relay-domains
The file /etc/postfix/my-safe-relay-domains would be filled with any networks, clients, or domain names that should be allowed to use the server for relaying.
Applying Access Controls
Access controls determine who can connect to your Postfix SMTP server. Using the restriction directives, you can limit access based on the client address connection, HELO headers, and so on.
For example, assume that you have three possibilities for clients:
goodclient.mydomain.com gooddomain.com badbadbad.com
The first (goodclient.mydomain.com) is an individual host that should always be allowed; the second is a domain (gooddomain.com) that, likewise, should always be considered a valid client. The last domain (badbadbad.com) should be explicitly denied. Because these connections should be allowed or denied based on the client IP or hostname, the directive to use is smtpd_client_restrictions.
To add these controls to your server, create a new access map file, such as /etc/postfix/clientaccess, and then add these lines:
goodclient.mydomain.com OK gooddomain.com OK .gooddomain.com OK .badbadbad.com REJECT Client not allowed badbadbad.com REJECT Client not allowed
The lines of the file are made up of a pattern (in this case, domain or client names) and an action. Domain names that begin with a period (.) match any subdomain within that domain. For restrictions that match against MAIL FROM addresses (such as smtpd_sender_restrictions), you can also provide full or partial email addresses to match and allow or reject individual senders.
In this example, two actions are used: REJECT [rejection message] and OK. As their names imply, the first rejects connections from the client and provides an optional error message, whereas the second allows the connection to be made. Documentation for other actions can be found in the file /etc/postfix/access.
After you've created the appropriate /etc/postfix/clientaccess file, compile it using postmap /etc/postfix/clientaccess. Finally, add the configuration line to main.cf that will impose the restriction:
smtpd_client_restrictions = hash:/etc/postfix/clientaccess
If you also want to block clients without a proper hostname, you could add the directive reject_unknown_client to the list of restrictions (refer to Table 26.2). The line for main.cf would become
smtpd_client_restrictions = hash:/etc/postfix/clientaccess, reject_unknown_client
Using Real-time Blacklisting
One of the first protection features to enable on any spam-sensitive Internet-connected Postfix server should be real-time blacklisting (RBL). RBL services maintain a list of known open relay mail servers and spammers. If you enable RBL service on the mail server, it automatically checks each incoming message to determine whether it is from a known open relay or spammer. If it is, the message is returned as undeliverable.
To test for blacklisted addresses, a standard DNS lookup is performed on a specially constructed version of a hostname. For example, if you want to check the IP address 22.214.171.124 to see whether it is blacklisted, you would look up the special address 126.96.36.199.spam.dnsrbl.net. As you can probably tell, this is nothing but the IP address reversed with .spam.dnsrbl.net added to the end. If a lookup on the address fails, the address is not blacklisted:
brezup:jray jray $ host 188.8.131.52.spam.dnsrbl.net Host 184.108.40.206.spam.dnsrbl.net not found: 3(NXDOMAIN)
To see an example of a successful (or blacklisted) lookup, use the IP address 127.0.0.2 or 220.127.116.11.spam.dnsrbl.net. This address, reserved for testing, should return a valid DNS lookup:
brezup:jray jray $ host 18.104.22.168.spam.dnsrbl.net 22.214.171.124.spam.dnsrbl.net is an alias for test.dnsrbl.net.spam.spam.dnsrbl.net. test.dnsrbl.net.spam.spam.dnsrbl.net has address 127.0.0.4
Searching for RBL or RBL DNS is the easiest way to find the latest and greatest blacklisting servers that are currently active. Here are a few to try:
To enable RBL screening for client connections, simply use the reject_rbl_client <RBL name> restriction from Table 26.2. For example, to add an RBL filter using spam.dnsrbl.net to the client restrictions in the previous section, just change the line to the following:
smtpd_client_restrictions = hash:/etc/postfix/clientaccess, reject_unknown_client, reject_rbl_client spam.dnsrbl.net
For more information about Postfix and its operation and configuration, look into these resources:
|< Day Day Up >|