Naar inhoud springen

Postfix: SASL installatie

Uit VanderSchaft
Versie door Dschaft (overleg | bijdragen) op 20 mrt 2026 om 14:41
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)

Configuring Cyrus SASL

The Cyrus SASL framework supports a wide variety of applications (POP, IMAP, SMTP, etc.). Different applications may require different configurations. As a consequence each application may have its own configuration file.

The first step configuring Cyrus SASL is to determine name and location of a configuration file that describes how the Postfix SMTP server will use the SASL framework. Cyrus SASL configuration file name

The name of the configuration file (default: smtpd.conf) is configurable. It is a concatenation from a value that the Postfix SMTP server sends to the Cyrus SASL library, and the suffix .conf, added by Cyrus SASL.

The value sent by Postfix is the name of the server component that will use Cyrus SASL. It defaults to smtpd and is configured with one of the following variables:

   /etc/postfix/main.cf:
       # Postfix 2.3 and later
       smtpd_sasl_path = smtpd
       # Postfix < 2.3
       smtpd_sasl_application_name = smtpd

Cyrus SASL configuration file location

The location where Cyrus SASL searches for the named file depends on the Cyrus SASL version and the OS/distribution used.

You can read more about the following topics:

         Cyrus SASL version 2.x searches for the configuration file in /usr/lib/sasl2/.
         Cyrus SASL version 2.1.22 and newer additionally search in /etc/sasl2/.
         With Postfix 2.5 and later you can explicitly configure the search path via the cyrus_sasl_config_path configuration parameter. 
         Specify zero or more colon-separated directories. If set empty (the default value) the search path is the one compiled into the Cyrus SASL library.

Some Postfix distributions employ a non-empty default value for cyrus_sasl_config_path to look for the Cyrus SASL configuration file in /etc/postfix/sasl/, /var/lib/sasl2/ etc. See the output of postconf cyrus_sasl_config_path and/or the distribution-specific documentation to determine the expected location.

Some Debian-based Postfix distributions ignore the "cyrus_sasl_config_path" parameter setting, and force Postfix to open the file /etc/postfix/sasl/smtpd.conf.

Note

Cyrus SASL searches /usr/lib/sasl2/ first. If it finds the specified configuration file there, it will not examine other locations.

Postfix to Cyrus SASL communication

As the Postfix SMTP server is linked with the Cyrus SASL library libsasl, communication between Postfix and Cyrus SASL takes place by calling functions in the SASL library. The SASL library may use an external password verification service, or an internal plugin to connect to authentication backends and verify the SMTP client's authentication data against the system password file or other databases. The following table shows typical combinations discussed in this document:

authentication backend password verification service / plugin

/etc/shadow saslauthd PAM saslauthd IMAP server saslauthd sasldb sasldb MySQL, PostgreSQL, SQLite sql LDAP ldapdb

Note

Read the Cyrus SASL documentation for other backends it can use.

saslauthd - Cyrus SASL password verification service Communication between the Postfix SMTP server (read: Cyrus SASL's libsasl) and the saslauthd server takes place over a UNIX-domain socket. saslauthd usually establishes the UNIX domain socket in /var/run/saslauthd/ and waits for authentication requests. The Postfix SMTP server must have read+execute permission to this directory or authentication attempts will fail.

Important

Some distributions require the user postfix to be member of a special group e.g. sasl, otherwise it will not be able to access the saslauthd socket directory.

The following example configures the Cyrus SASL library to contact saslauthd as its password verification service:

/etc/sasl2/smtpd.conf:
   pwcheck_method: saslauthd
   mech_list: PLAIN LOGIN

Important

Do not specify any other mechanisms in mech_list than PLAIN or LOGIN when using saslauthd! It can only handle these two mechanisms, and authentication will fail if clients are allowed to choose other mechanisms.

Important

Plaintext mechanisms (PLAIN, LOGIN) send credentials unencrypted. This information should be protected by an additional security layer such as a TLS-encrypted SMTP session (see: TLS_README).

Additionally the saslauthd server itself must be configured. It must be told which authentication backend to turn to for password verification. The backend is selected with a saslauthd command-line option and will be shown in the following examples.

Note

Some distributions use a configuration file to provide saslauthd command line options to set e.g. the authentication backend. Typical locations are /etc/sysconfig/saslauthd or /etc/default/saslauthd.