Using Saslauthd and Postfix with Debian Etch
Ronald MacDonald <firstname.lastname@example.org> Wed Jan 16 19:32:50 GMT 2008
- January 2008 - Main article
- March 2009 - Revised debugging
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, show how to run Saslauthd without the Postfix chroot. I will demonstrate how you might use the rimap authentication protocol, but any other mechanism can be used with a quick look at the
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
This How-to assumes all the current sources as of January 2008. Therefore the configuration files may differ somewhat to the version you may have downloaded earlier, or under Woody/Sarge.
apt-get install saslauthd
All appropriate packages will be downloaded and installed to your Debian system.
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.
Saslauthd uses a plethora of options for configuration. Amongst the most useful are
Firstly, enable the saslauthd daemon and select the rimap mechanism for use: In
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.
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
email@example.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
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.
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.
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
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.
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
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
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. Patience is a virtue!
Following these rules will remove the
sender_restrictions, leaving all rules until
rcpt to in the SMTP process (in
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
mynetworks = 127.0.0.0/8
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
# ========================================================================== # 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
main.cf as follows:
/etc/postfix/main.cf: debug_peer_list = 127.0.0.1