Using Saslauthd and Postfix with Debian Etch

2008-01-16 (Last Modified: 2009-03-01)

Introduction

Saslauthd is inherently difficult to use with the Debian distribution of Postfix, since Postfix is by default run chrooted. Using Saslauthd with Postfix requires a bit more tweaking than usual, especially if you wish to run it with Postfix chrooted.

This configuration outline, however, shows how to run Saslauthd without the Postfix chroot. I will demonstrate how you might use the rimap protocol, but any other mechanism can be used with a quick look at the man pages.

This Howto assumes you already have Postfix up and running, as well as an IMAP server, such as Dovecot, which can easily be manipulated to provide Saslauthd the information it needs. As a point of reference, I use Postfix virtual with MySQL, as well as the policy service postfix-policyd and Maia - an AMaViS MySQL based front end. For mail delivery, I use maildrop for the purposes of using per-user mail filters, specifically for shunting spam to a separate folder.

This How-to guides the user to authenticate valid users against the IMAP server, making credential management much easier, as disabling a user login will also disable the user from sending any mail - providing you’ve set up the Postfix rules correctly!

Saslauthd can also be used to help the running of postfix-policyd. Postfix-policyd is a daemon which runs as a Postfix policy server, allowing you to throttle the number of messages each user sends and receives on your system. Refer to http://policyd.org/features.html for an overview of services provided by postfix-policyd.

Downloading and Installing

apt-get install saslauthd

All appropriate packages will be downloaded and installed to your Debian system.

Saslauthd Configuration

Since Postfix should run using a non-critical user, Saslauthd stands between the Postfix user and root so as to allow Postfix to look up user authentication databases. Therefore, the following configurations are most likely not exactly what you require.

Mechanism Options

Saslauthd uses a plethora of options for configuration. Amongst the most useful are PAM, LDAP, and IMAP.

Firstly, enable the saslauthd daemon and select the rimap mechanism for use: In /etc/default/saslauthd:

START=yes
MECHANISMS="rimap"

It is also necessary to specify the hostname/address of the IMAP server, even if it is running on localhost. Adding the following line to /etc/default/saslauthd will pass the correct options to Saslauthd.

MECH_OPTIONS="127.0.0.1"

Realms

Make sure you identify the appropriate realms saslauthd will pass to the IMAP server for authentication. Using the -r switch on the saslauthd OPTIONS will pass the username user@domain.com to the IMAP server, instead of just the username. The domain will otherwise be dropped. This is necessary for most virtual systems, offering more than one domain on the same box.

Debug and Root

The root of saslauthd is specified in the Debian distribution, in /etc/default/saslauthd , to be under the postfix spool. Therefore, since Postfix is going to be un-chrooted, it would be advisable to uncomment the -m option and its path to the Postfix chroot.

Additionally, in the example below, the -r switch is being used to pass the entire email address as the username for the IMAP server lookup. Please refer to #Realms.

OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"
OPTIONS="-c -rVd"

Leave the saslauthd server stopped until everything else has been configured. If you wish to run it at this stage. Running the command saslauthd will display the debug output in the terminal. Executing saslauthd in this manner uses the configuration /etc/default/saslauthd.

IMAP server configuration

This stage is hardly ever necessary, since most IMAP servers are already in use and presumably already looking up the user authentication databases.

The IMAP server is being used to check that the user has access to the system. Presumably if a user is allowed to collect emails from a system, they are also allowed to send emails back out.

NOTE that this becomes problematic if you use aliases as well as mailboxes on your virtual domains – virtual aliases will not have a corresponding username/password in the user tables unless specified otherwise.

Postfix Configuration

This configuration of Postfix will do the following:

Un-chroot Postfix, at least temporarily.
Specify to Postfix what authentication to use in SMTP sessions
Add restrictions to SMTP senders to allow sending mail from remote systems, but only with authentication.

Un-chrooting Postfix

The Postfix services in the Debian distribution are almost all chrooted by default, so the first thing to do is to un-chroot the whole lot. This is easily done, by consulting the column Chroot? [y/n] and altering the services to suit.

Getting the system to work without chroot and then gradually setting everything chrooted saves more time if you’re not sure, or haven’t done this before. In file /etc/postfix/master.cf, where we have the following:

smtp      inet  n       -       -       -       -       smtpd 
pickup    fifo  n       -       -       60      1       pickup
cleanup   unix  n       -       -       -       0       cleanup
qmgr      fifo  n       -       -       300     1       qmgr
rewrite   unix  -       -       -       -       -       trivial-rewrite
bounce    unix  -       -       -       -       0       bounce
defer     unix  -       -       -       -       0       bounce
trace     unix  -       -       -       -       0       bounce

We actually want:

smtp      inet  n       -       n       -       -       smtpd 
pickup    fifo  n       -       n       60      1       pickup 
cleanup   unix  n       -       n       -       0       cleanup
qmgr      fifo  n       -       n       300     1       qmgr
rewrite   unix  -       -       n       -       -       trivial-rewrite
bounce    unix  -       -       n       -       0       bounce
defer     unix  -       -       n       -       0       bounce
trace     unix  -       -       n       -       0       bounce

A postfix reload after saving this file will un-chroot the system. Leave this until later though, or mail may stop getting to/from the server.

Specifying the Authentication for Postfix

Simply stating what authentication to use in the /etc/default/saslauthd file will not affect how Postfix tries to authenticate SMTP clients. Therefore, create a file /etc/postfix/sasl/smtpd.conf.

If you’re using the IMAP server to do your lookups (using rimap), the setup of your smtpd.conf is much simpler.

pwcheck_method: saslauthd
mech_list: plain login cram-md5 digest-md5

However, if you wish to use mysql, it’s a bit more complicated. Firstly, you must specify the type of authentication, which is actually a plugin via auxprop. Then you set up the MySQL options and the query to select the password from the database. Postfix will handle the password and compare it against the client input.

pwcheck_method: saslauthd auxprop
auxprop_plugin: mysql
mech_list: plain login cram-md5 digest-md5
sql_engine: mysql
sql_hostnames: [your_hostname]
sql_user: [username]  
sql_passwd: [password]
sql_database: [user_database]
sql_select: SELECT [password_column] FROM [authentication_table] WHERE [username_column] = '%u@%r'

If you’re lucky, and my guesswork (above) is correct, then that should be that.

Adding restrictions to Postfix

A word about smtpd_restrictions

Under Postfix, restrictions are applied at three stages. The first is at ehlo, the second at the mail from and the third and rcpt to. If you are not familiar with this terminology, it may be useful to have a look at the [telnet mail url] page. In essence, you can reply the smtpd restrictions at the appropriate stage, but it’s recommended that you apply all the restrictions outlined in this guide at the smtpd_recipient_restrictions stage. This way, the rules are kept a bit simpler and easier to read.

The rules are, by default, ‘permit’. This way, the rules act to weed out the unauthorised requests, leaving the correctly-addressed mail for further processing. Note that saslauthd will not work properly to authorise the client unless it is at the top of the rules, as in the example below.

If you have already specified many rules, try commenting them all out at least until the saslauthd part is working properly. Then you can start putting the rules back in one by one, to check each one is in the correct location.

Following these rules will remove the client_restrictions and sender_restrictions, leaving all rules until rcpt to in the SMTP process (in /etc/postfix/main.cf):

smtpd_client_restrictions =
smtpd_sender_restrictions =
smtpd_recipient_restrictions =
        permit_sasl_authenticated,
        reject_unauth_destination,
        permit_mynetworks,
        reject_invalid_hostname,
        reject_unknown_sender_domain

Note that the rule permit_mynetworks means that clients recognised as ‘local’ are not required to authenticate via SASL. Therefore an authentication failiure will not affect the delivery of mail in this case. To counteract this, it’s a good idea to specify only 127.0.0.1 (localhost) as mynetworks, as below (in /etc/postfix/main.cf):

mynetworks = 127.0.0.0/8

Debugging

There’s no better guide to debugging Postfix than written by the man himself: http://www.postfix.org/DEBUG_README.html.

A quick note, however, for reference: if you wish to debug a daemon in Postfix, append -v to the end of the line, in master.cf, to make it more verbose.

For instance, to debug smtp, one would have the line as follows in master.cf:

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       n       -       -       smtpd -v

To debug verbosely the communication Postfix has with one host, you can specify the debug_peer_list in main.cf as follows:

/etc/postfix/main.cf:
    debug_peer_list = 127.0.0.1