Postfix SASL Howto

WARNING WARNING WARNING

People who go to the trouble of installing Postfix may have
the expectation that Postfix is more secure than some other mailers.
The Cyrus SASL library is a lot of code. With SASL authentication
enabled in the Postfix SMTP client and SMTP server, Postfix becomes
as secure as other mail systems that use the Cyrus SASL library.

Postfix does not record the client's SASL authentication
information in message headers, and does not pass it on via SMTP
commands when forwarding mail, because it is no-one else's business
to know the client username and authentication method. People who
need to know can find the information in the local Postfix maillog
file. Some day, Postfix message headers will be configurable and
then one can record the SASL username without having to edit C
code.

When sending mail, Postfix can look up the server hostname or
destination domain (the address right-hand part) in a table, and if a
username/password is found, it will use that username and password
to authenticate to the server.

Postfix+SASL 1.5.5 was seen working on RedHat 6.1 (pwcheck_method
set to shadow or sasldb), Solaris 2.7 (pwcheck_method set to shadow
or sasldb), and FreeBSD 3.4 (pwcheck_method set to sasldb). On
RedHat 6.1, SASL 1.5.5 insisted on write access to /etc/sasldb.
Note that this seems to be related to the auto_transition switch
in SASL. Note also that the Cyrus SASL documentation says that it
is pointless to enable that if you use "sasldb" for "pwcheck_method".
Later versions of the SASL 1.5.x series should also work.

Postfix+SASL 2.1.1 appears to work on Mandrake Linux 8.1
(pwcheck_method set to saslauthd or auxprop). Note that the
'auxprop' pwcheck_method replaces the 'sasldb' method from SASL
1.5.x. Postfix may need write access to /etc/sasldb2 if you use
the auto_transition feature, or if you use an authentication
mechanism such as OTP (one-time passwords) that needs to update
secrets in the database.

Postfix appears to work with cyrus-sasl-1.5.5 or cyrus-sasl-2.1.1,
which are available from:

ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/.

IMPORTANT: if you install the Cyrus SASL libraries as per the
default, you will have to symlink /usr/lib/sasl -> /usr/local/lib/sasl
for version 1.5.5 or /usr/lib/sasl2 -> /usr/local/lib/sasl2 for
version 2.1.1.

In /usr/local/lib/sasl/smtpd.conf (SASL version 1.5.5) or
/usr/local/lib/sasl2/smtpd.conf (SASL version 2.1.1) you need to
specify how the server should validate client passwords.

In order to authenticate against the UNIX password database, try:

(SASL version 1.5.5)

/usr/local/lib/sasl/smtpd.conf:
pwcheck_method: pwcheck

(SASL version 2.1.1)

/usr/local/lib/sasl2/smtpd.conf:
pwcheck_method: pwcheck

The name of the file in /usr/local/lib/sasl (SASL version 1.5.5)
or /usr/local/lib/sasl2 (SASL version 2.1.1) used by the SASL
library for configuration can be set with:

/etc/postfix/main.cf:
smtpd_sasl_application_name = smtpd

The pwcheck daemon is contained in the cyrus-sasl source tarball.

IMPORTANT: postfix processes need to have group read+execute
permission for the /var/pwcheck directory, otherwise authentication
attempts will fail.

Alternately, in SASL 1.5.26 and later (including 2.1.1), try:

(SASL version 1.5.26)

/usr/local/lib/sasl/smtpd.conf:
pwcheck_method: saslauthd

(SASL version 2.1.1)

/usr/local/lib/sasl2/smtpd.conf:
pwcheck_method: saslauthd

The saslauthd daemon is also contained in the cyrus-sasl source
tarball. It is more flexible than the pwcheck daemon, in that it
can authenticate against PAM and various other sources. To use PAM,
start saslauthd with "-a pam".

In order to authenticate against SASL's own password database:

(SASL version 1.5.5)

/usr/local/lib/sasl/smtpd.conf:
pwcheck_method: sasldb

(SASL version 2.1.1)

/usr/local/lib/sasl2/smtpd.conf:
pwcheck_method: auxprop

This will use the SASL password file (default: /etc/sasldb in
version 1.5.5, or /etc/sasldb2 in version 2.1.1), which is maintained
with the saslpasswd or saslpasswd2 command (part of the Cyrus SASL
software). On some poorly-supported systems the saslpasswd command needs
to be run multiple times before it stops complaining. The Postfix SMTP
server needs read access to the sasldb file - you may have to play games
with group access permissions. With the OTP authentication mechanism,
the SMTP server also needs write access to /etc/sasldb2 or /etc/sasldb
(or the back end SQL database, if used).

IMPORTANT: all users must be able to authenticate using ALL
authentication mechanisms advertised by Postfix, otherwise the
negotiation might end up with an unsupported mechanism, and
authentication would fail. For example if you configure SASL to
use saslauthd for authentication against PAM (pluggable
authentication modules), only the PLAIN and LOGIN mechanisms are
supported and stand a chance to succeed, yet the SASL library would also
advertise other mechanisms, such as DIGEST-MD5. This happens because
those mechanisms are made available by other plugins, and the SASL
library have no way to know that your only valid authentication source
is PAM. Thus you might need to limit the list of mechanisms advertised
by Postfix. This is only possible with SASL version 2.1.1 or later:

/usr/local/lib/sasl2/smtpd.conf:
mech_list: plain login

For the same reasons you might want to limit the list of plugins
used for authentication. With SASL version 1.5.5 your only choice is to
delete the corresponding libraries from /usr/local/lib/sasl. With SASL
version 2.1.1:

IMPORTANT: To get sasldb running, make sure that you set the SASL
domain (realm) to a fully qualified domain name.

EXAMPLE:

(SASL version 1.5.5)

% saslpasswd -c -u `postconf -h myhostname` exampleuser

(SASL version 2.1.1)

% saslpasswd2 -c -u `postconf -h myhostname` exampleuser

You can find out SASL's idea about the realms of the users
in sasldb with sasldblistusers (SASL version 1.5.5) or
sasldblistusers2 (SASL version 2.1.1).

On the Postfix side, you can have only one realm per smtpd
instance, and only the users belonging to that realm would be able to
authenticate. The Postfix variable smtpd_sasl_local_domain controls the
realm used by smtpd:

/etc/postfix/main.cf:
smtpd_sasl_local_domain = $myhostname

To run software chrooted with SASL support is an interesting
exercise. It probably is not worth the trouble.

Older Microsoft SMTP client software implements a non-standard
version of the AUTH protocol syntax, and expects that the SMTP
server replies to EHLO with "250 AUTH=stuff" instead of "250 AUTH
stuff". To accommodate such clients in addition to conformant
clients, set "broken_sasl_auth_clients = yes" in the main.cf file.

In the Cyrus SASL sources you'll find a subdirectory named
"sample". Run make there, "su" to the user postfix (or
whatever your mail_owner directive is set to):

% su postfix

then run the resulting sample server and client in separate
terminals. Strace / ktrace / truss the server to see what makes
it unhappy, and fix the problem. Repeat the previous step until
you can successfully authenticate with the sample client. Only
then get back to Postfix.

Turn on client-side SASL authentication, and specify a table with
per-host or per-destination username and password information.
Postfix first looks up the server hostname; if no entry is found,
then Postfix looks up the destination domain name (usually, the
right-hand part of an email address).

Note: some SMTP servers support PLAIN or LOGIN authentication only.
By default, the Postfix SMTP client does not use authentication
methods that send plaintext passwords, and defers delivery with
the following error message: "Authentication failed: cannot SASL
authenticate to server". To enable plaintext authentication specify,
for example:

/etc/postfix/main.cf:
smtp_sasl_security_options =

The SASL client password file is opened before the SMTP server
enters the optional chroot jail, so you can keep the file in
/etc/postfix.

The Postfix SMTP client is backwards compatible with SMTP
servers that use the non-standard "AUTH=method..." syntax in response
to the EHLO command; there is no Postfix client configuration needed
to work around it.