5. Authentication service or what is Cyrus-SASL?

Cyrus-SASL is a software that provides different methods and mechanisms of authentication. This software is often used in conjunction with Cyrus IMAP Server and is provided as standalone software. SASLs concept, the Simple Authentication and Security Layer, is written down in RFC 2222.


This HOWTO will focus on the Cyrus-SASL version only.

5.1. Methods to provide the authentication service

Cyrus-SASL may use various methods to connect to a source that holds user and password data. By nature Cyrus-SASL is capable to connect to PAM and sasldb. However there are situations where this approach runs short:

5.1.1. Permissions

To authenticate via PAM from passwd/shadow requires root privileges. Any daemon (here: Postfix) that uses SASL which is not run as root, will therefore not be permitted to query passwd/shadow. Some systems solve this by adding the SASL-user to a special group that is permitted to read from passwd/shadow.

Is that good? Well consider running Postfix chrooted and having to copy your passwd/shadow files to the jail. Huh? Yes, you'd have to do that and that would make the idea running a chrooted Postfix to keep malicious users from your valuable password useless. You'd be at the start again... read on as there is a solution to this!

5.1.2. User:pass sources

There are situations where you don't want to use PAM or sasldb, because you want to have all the mail users separated from machines users or have them on a different machine or you run a central AUTH service for single sign on and so on...

For both scenarios you may configure SASL to use a daemon that will run as root and can connect to various backends e.g. a LDAP or SQL database.


Cyrus-SASL daemons don't support LDAP and e.g. MySQL™ from source. However there are patches available on the net that will give you those functionalities. You will have to patch Cyrus-SASL, recompile and install it, before these functionalities will be available to SASL.

You may use different methods to provide authentication service with Cyrus-SASL.

5.1.3. Daemons

Cyrus-SASL comes with two daemons that may run on your mail server: pwcheck and saslauthd. Basically they are pretty much the same. The newer daemon saslauthd (since Cyrus-SASL 1.5.27) is said to be based on the code of the former pwcheck. Anyway saslauthd goes beyond the functionality of pwcheck and pwcheck will be dropped in the future. So we will have a look at the newer daemon in this HOWTO.


LDAP and SQL authentication

If you want to authenticate your mail users against an LDAP or SQL server you might want to go for the pwcheck daemon. There might be more patches available for this at the moment.

5.1.4. Which method can you use in Postfix?

You can use all of them, but note: If you use PAM, saslauthd or pwcheck you only have the mechanisms PLAIN and LOGIN at your command.

5.2. Mechanisms for Authentication

Cyrus-SASL offers various mechanisms to clients that seek authentication.


Authentication data is transmitted plaintext. Anyone can authenticate to the system.


This mechanism is of no use in our context as it would result in making our SMTP server an open relay!

5.2.2. PLAIN

If you use PLAIN data is transmitted plaintext. The mechanism is simple and it works well, but imposes a security risk if used without encrypted communication layer!

Used without encryption anyone can read the authentication data as it is transmitted plaintext. Anyone running a sniffer (e.g. snort, tcpdump) could read the secrets.

The solution is to use the TLS-Patch (Transport Layer Security, formerly: SSL) as provided by Lutz Jänicke to Postfix.


We believe TLS is mandatory when one uses mechanism PLAIN and will also provide information on how to install and configure TLS-Support in this HOWTO.

5.2.3. LOGIN

Authentication data is transmitted plaintext. LOGIN imposes the same security risk as described in PLAIN. The same solution applies if you want to get rid of the problem.

The LOGIN mechanism exists parallel with PLAIN, simply because there are Mail clients (e.g. Outlook Express, Outlook) that do not implement the RFC-standard when seeking authentication. Cyrus-SASL supports LOGIN, but there is no support to users by the makers of Cyrus-SASL.

5.2.4. DIGEST-MD5

RFC 2831

You can use this mechanism without TLS.

5.2.5. CRAM-MD5

It is conjectured that use of the CRAM authentication mechanism provides origin identification and replay protection for a session. Accordingly, a server that implements both a cleartext password command and this authentication type should not allow both methods of access for a given user.” (from: RFC 2195, 4 Security Considerations).

You can use this mechanism without TLS.

5.2.6. GSSAPI (MIT Kerberos 5 or Heimdal Kerberos 5)

You can use this mechanism without TLS.

5.2.7. KERBEROS_V4

You can use this mechanism without TLS.

5.3. Concerns on Cyrus-SASL's SASL implementation

The SASL concept as described in the RFC is a good idea. Yet at the moment Cyrus-SASL lacks sufficient documentation and does not provide meaningful error messages.

Therefore it becomes a black-box to those who lack programming skills and simply would take look at the code to understand what's going on or wrong. Environments with high-security standards consider these issues as disqualifying criteria for use of software.

As for the documentation this HOWTO aims to provide you with the knowledge needed to install, configure and run Cyrus-SASL in combination with Postfix.


The Cryptix SASL Library is the second SASL library known at the moment. It runs with JAVA, but isn't supported by Postfix.

While writing this HOWTO cabalSASL has become the next competitor to Cyrus-SASL. Read more at the official cabalSASL website.