Configuring Postfix for SASL

Before you get started, decide on the authentication mechanisms you plan to support and the authentication framework you want SASL to use with Postfix.

12.3.1 Specifying a Framework

The SASL library uses a separate configuration file for each application it works with. Postfix uses a file named smtpd.conf for SASL purposes. This file is usually located at /usr/local/lib/sasl2/smtpd.conf. At a minimum, smtpd.conf contains a line indicating the framework to use. We are going to look at specifying either Unix passwords or separate SASL passwords for Postfix authentication. See the Cyrus documentation to see other options you might include in smtpd.conf.

12.3.1.1 Unix passwords

Often, it's most convenient for SASL to use the existing system database to authenticate users. Historically, this meant using the /etc/passwd file. Today, it's more likely that you use /etc/shadow, PAM, or some related authentication database. Since these passwords are not available to unprivileged processes, and Postfix purposely runs with limited privileges, it cannot normally authenticate users.

The Cyrus libraries deal with the problem by providing a special authentication server called saslauthd. It handles requests on behalf of Postfix. The saslauthd daemon requires superuser privileges; however, since it runs as a process distinct from Postfix and does not have to communicate outside of your network, the security impact is minimized. If you are going to use Unix passwords with SASL, you must run the saslauthd daemon that ships with the Cyrus distribution. Note that using Unix passwords with saslauthd limits you to plaintext passwords because the daemon needs the actual passwords to verify them. See Chapter 13 for using encryption between Postfix and email clients.

To specify that you want Postfix to use the saslauthd daemon for authentication, create the smtpd.conf with a line like the following:

pwcheck_method: saslauthd

saslauthd comes with the Cyrus SASL distribution and should be installed in a convenient location. The daemon must be running in the background for Postfix to use it to authenticate clients. When you start saslauthd, you tell it what type of password system you are using with the -a option. The most common options are pam, shadow, or getpwent (for the conventional /etc/passwd). For example, to start the daemon on a system that uses PAM for authentication, type the command:

# saslauthd -a pam

Consult the Cyrus documentation for other options when using saslauthd. Also, you probably want this daemon to start automatically at system initialization so that it is always available for your Postfix server. You can add saslauthd to your system's startup processes in the same way you add other daemons such as Postfix.

12.3.1.2 SASL passwords

If you don't want your mail server to use existing system accounts, you can create a separate database of users and passwords that is independent of the system password mechanism. You can create accounts for email users who have mail access only and will not be able to log into the host itself. Include the following line in your smtpd.conf file:

pwcheck_method: auxprop

The term auxprop comes from the Cyrus notion of auxiliary property plug-ins. Plug-ins allow you to insert external programs for authentication. The Cyrus SASL distribution ships with sasldb as the default auxiliary property plug-in and that should be all you need to work with Postfix. The keyword auxprop simply says to use an external SASL password file.

You do not have to run the saslauthd daemon when using SASL passwords, but you must create the external password file containing credentials for all of your email accounts. By default, the SASL username/password file is kept at /etc/sasldb2. The Postfix SMTP server needs at least read access to the file, and if you use the auto_transition feature of Cyrus SASL (see the Cyrus documentation), Postfix will also require write access to the file. If you don't need the auto_transition feature, it's best not to give Postfix write access to the password file.

If you have other processes that also need access to the file (such as a POP/IMAP server), you may have to adjust the ownership and permissions so all the processes that need it can access it. For example, you might want to create an sasl group on your system. Make sure that the postfix user and other accounts that need access to the file are all in that group. If any of the other processes need to update the file, then read-only is too restrictive and you'll have to provide write access for the processes that need it. To set the permissions to 440, so that it is read-only and not generally readable by users on the system, type the following commands:

# chown postfix:sasl /etc/sasldb2 # chmod 440 /etc/sasldb2

To create accounts for your SMTP server, use the saslpasswd2 command included with the Cyrus SASL distribution. It stores accounts in /etc/sasldb2. You must specify both a username and an SASL domain. For Postfix the domain should be the value specified in the myhostname parameter. If you use the command postconf -h myhostname to determine your hostname, you can be sure you have the correct one. The following command creates an account for the user kdent:

# saslpasswd2 -c -u `postconf -h myhostname` kdent Password: Again (for verification):

Enter the password twice, as prompted. The -c option tells saslpasswd2 to create the user account, and -u is used to specify the domain for this account, which you take directly from the Postfix configuration.

12.3.2 Configuring Postfix

All of the relevant Postfix parameters for SASL password authentication start with smtpd_sasl* for the SMTP server or smtp_sasl* for the SMTP client. For server configuration you need at a minimum the smtpd_sasl_auth_enable parameter and the permit_sasl_authenticated restriction, which must be assigned to one of the smtpd restriction parameters. See Chapter 11 for more information on UBE restrictions.

12.3.2.1 Enabling SASL

In order to turn on authentication in the Postfix SMTP server, add the enable parameter to your main.cf file:

smtpd_sasl_auth_enable = yes

In addition, some older email clients[2] don't follow the SMTP authentication protocol correctly. The specification calls for the server to list its supported mechanisms after the keyword AUTH followed by a space. These clients expect to receive AUTH followed by an equals sign. Postfix allows you to accommodate them by setting the following parameter:

[2] Reportedly, Microsoft Outlook and Outlook Express before Version 5, but you may have to experiment to determine if your clients are culprits.

broken_sasl_auth_clients = yes

By setting this parameter, you tell Postfix to advertise its SMTP authentication support in the nonstandard way as well as the standard way. This option is perfectly safe to use since it doesn't interfere with other mail clients, and the nonstandard ones will now work as well.

12.3.2.2 Preventing sender spoofing

To make sure that clients use correct sender addresses when relaying, Postfix allows you to map sender addresses to SASL logins. For example, if you have an address kdent@example.com that should be used only by the SASL user kdent, you can create a file requiring the correct user for that address:

kdent@example.com kdent

The file is a normal Postfix lookup table and allows regular expressions as well as local parts and domains (see Chapter 4 for information on Postfix lookup tables). Use the parameter smtpd_sender_login_maps in main.cf to indicate the table you create:

smtpd_sender_login_maps = hash:/etc/postfix/sasl_senders

You can list as many addresses as you need in the table. To reject messages from users attempting to use incorrect sender addresses or users who are not authenticated at all who attempt to use a specified address, include the restriction reject_sender_login_mismatch with your restriction parameters (see Chapter 11 for information on UBE restrictions).

12.3.2.3 Permitting authenticated users

If you are already using the smtpd_recipient_restrictions parameter as part of your UBE blocking, you have to tell Postfix to allow authenticated users to relay by adding permit_sasl_authenticated to the list of restrictions. If you were previously using the default and didn't need a smtpd_recipient_restrictions parameter, just add the following line:

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

If you are already using the smtpd_recipient_restrictions parameter, just add permit_sasl_authenticated to the list of restrictions. Be sure to include some kind of rejection restriction in your list (see Chapter 11).

12.3.2.4 Specifying mechanisms

The smtpd_sasl_security_options parameter lets you control which password mechanisms are listed when clients connect to your SMTP server. The complete list of available mechanisms depends on your system and the mechanisms that were available when your SASL libraries were built. If you don't specify any options, the default is to accept all available mechanisms including plaintext passwords, but not anonymous logins. If you are using the saslauthd daemon, you must accept plaintext passwords, so the default configuration probably makes the most sense. If you specify any of the options, you override the default, so make sure that you include noanonymous among your options. If you set this parameter, you can specify any combination of the following values. For example:

smtpd_sasl_security_options = noanonymous, noplaintext

Common mechanisms include:

noplaintext

If your security policy does not permit passwords to be sent as plaintext, specify noplaintext. This causes SASL to use one of the challenge/response techniques that authenticate without transmitting actual passwords.

noactive

In active attacks, attackers manage to insert themselves between the client and server. Some types of active attacks are commonly referred to as man-in-the-middle attacks. Attackers may be able to read or alter data as it is transmitted or pretend to be the client or server. Specify noactive to limit supported password mechanisms to those that are not known to be vulnerable to active attacks.

nodictionary

In dictionary attacks, attackers run through a preassembled database of possible passwords trying each one in turn to see if it allows access. Databases are typically made up of lists of cities, teams, proper names, and all dictionary words plus obvious variations on the words. Specify nodictionary to limit supported password mechanisms to those that are not known to be vulnerable to dictionary attacks.

noanonymous

Anonymous logins have no useful purpose for SMTP servers. By default Postfix does not allow anonymous logins. If you specify any other options, be sure to also specify noanonymous since you will be overriding the default.

mutual_auth

You can require mechanisms that provide mutual authentication where both the client and server provide credentials proving their identities. Specify mutual_auth to limit advertised mechanisms to those that provide for mutual authentication.

12.3.3 Configuration Summary

Following are step-by-step instructions summarizing the configuration described in this chapter. This is a broad overview of what's required to set up your Postfix system with SASL:

1. Determine the authentication mechanisms and framework you plan to support.
2. Install the SASL libraries and recompile Postfix with SASL support. Or obtain a Postfix distribution with SASL, including support for the authentication mechanisms and SASL options you need.
3. Reinstall Postfix.
4. Create the file /usr/local/lib/sasl2/smtpd.conf. Enter either saslauthd or auxprop for pwcheck_method.
5. If you are using Unix passwords for authentication, start the saslauthd daemon, specifying the type of authentication in use on your system. Otherwise, use the saslpasswd2 command to create email accounts on your system.
6. Edit main.cf to turn on authentication. This requires that you enable SASL and that you specify that authenticated clients should be allowed to relay mail. A basic setup requires at least the following parameters:

   smtpd_sasl_auth_enable = yes smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

7. Reload Postfix so that it recognizes the changes in its main.cf configuration file:

   # postfix reload