Navigation
Configuring Saslauthd for use with Postfix (Debian Etch)
Using Saslauthd and Postfix with Debian Etch
- Introduction
- Downloading and Installing
- Saslauthd configuration
- IMAP Server Configuration
- Postfix Configuration
- Debugging
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 of a tweak than usual, especially if you wish to run it with Postfix chroot.
This How-to will show how to run Saslauthd without the Postfix chroot. The process of getting it back to work within the chroot will be documented in an upcoming Howto. I will show how to use the rimap authentication protocol, but any other mechanism can be used with a quick look at the man page.
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. I will also document setting up the Dovecot mail server as soon as I have a bit of time! 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 IMAP 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!
It is recommended that you store user passwords on your authentication database in the clear. Though this could be a problem if the SQL server is untrusted, it means that clients can use CRAM-MD5 to authenticate with the SMTP server, and with the use of TLS in the process, there is no greater benefit to using plain passwords as opposed to encrypted ones!
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. Look here (http://policyd.org/features.html) for an overview of services provided by postfix-policyd.
2. 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.
All appropriate packages will be downloaded and installed to you Debian system. For other distributions, please refer to https://sourceforge.net/project/showfiles.php?group_id=133598&package_id=146713.
3. 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.
3.1 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:
File: /etc/default/saslauthd
START=yes MECHANISMS= "rimap"It is also required 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"
3.2 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.
3.3 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 adviseable 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 3.2 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.
4. 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.
5. 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.
5.1 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.
File: /etc/postfix/master.cf
So, in this example, instead of:
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 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.
5.2 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.
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.
5.3 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 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 [true] 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 client_restrictions and sender_restrictions, leaving all rules until rcpt to: in the SMTP process.
File: /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.
File: /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.
Revised January 2008 © Ronald MacDonald.