Table of Contents for

Postfix: The Definitive Guide

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.

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.

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:

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.

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).

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).

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: