SASL authentication and Postfix

Next options require attention:

smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = no
smtpd_sasl_exceptions_networks =
smtpd_sasl_local_domain =
smtpd_sasl_path = 
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous, noplaintext
smtpd_sasl_type = cyrus

    smtpd_sasl_type = dovecot | cyrus
    smtpd_sasl_path = private/auth

This example uses a pathname relative to the Postfix queue directory, so that
it will work whether or not the Postfix SMTP server runs chrooted.Regardless of the
SASL implementation type, enabling SMTP authentication in the Postfix SMTP server
always requires setting the smtpd_sasl_auth_enable option:

    smtpd_sasl_auth_enable = yes

However not all clients recognize the AUTH capability as defined by the SASL
authentication RFC. Some historical implementations expect the server to send an
“=” as separator between the AUTH verb and the list of mechanisms that follows it.
The broken_sasl_auth_clients configuration option lets Postfix repeat the AUTH
statement in a form that these broken clients understand:

    broken_sasl_auth_clients = yes

The Postfix SMTP server supports policies that limit the SASL mechanisms that it makes available to clients, based on the properties of those mechanisms. The next two sections give examples of how these policies are used.

Property Description
noanonymous Don’t use mechanisms that permit
anonymous authentication.
noplaintext Don’t use mechanisms that transmit
unencrypted username and password information.
nodictionary Don’t use mechanisms that are
vulnerable to dictionary attacks.
mutual_auth Use only mechanisms that authenticate
both the client and the server to each other.

The default policy is to allow any mechanism in the Postfix SMTP server except for
those based on anonymous authentication:

    # Specify a list of properties separated by comma or whitespace
    smtpd_sasl_security_options = noanonymous

Always set at least the noanonymous option. Otherwise, the Postfix SMTP server
can give strangers the same authorization as a properly-authenticated client.
A separate parameter controls Postfix SASL mechanism policy during a TLS-encrypted SMTP
session. The default is to copy the settings from the unencrypted session:

    smtpd_sasl_tls_security_options = $smtpd_sasl_security_options

#A more sophisticated policy allows plaintext mechanisms, but only over 
#a TLS-encrypted connection: 

    smtpd_sasl_security_options = noanonymous, noplaintext
    smtpd_sasl_tls_security_options = noanonymous

#To offer SASL authentication only after a TLS-encrypted session
#has been established specify this 

    smtpd_tls_auth_only = yes

After the client has authenticated with SASL, the Postfix SMTP server decides
what the remote SMTP client will be authorized for.
Examples of possible SMTP clients authorizations are:

– Send a message to a remote recipient.
– Use a specific envelope sender in the MAIL FROM command.

These permissions are not enabled by default !!!!!!!!!!!!!

The permit_sasl_authenticated restriction allows SASL-authenticated SMTP
clients to send mail to remote destinations. Add it to the list of
smtpd_recipient_restrictions as follows:

    smtpd_recipient_restrictions =

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

    # Postfix 2.3 and later
    smtpd_sasl_path = smtpd
    # Postfix < 2.3
    smtpd_sasl_application_name = smtpd

The location where Cyrus SASL searches for the named file depends on the Cyrus SASL version
and the OS/distribution used. 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/. Some
Postfix distributions are modified and look for the Cyrus SASL configuration file in
/etc/postfix/sasl/, /var/lib/sasl2/ etc.Cyrus SASL searches /usr/lib/sasl2/ first. If
it finds the specified configuration file there, it will not examine other locations.

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.

authentication backend password verification service / plugin
/etc/shadow saslauthd
PAM saslauthd
IMAP server saslauthd
sasldb sasldb
MySQL, PostgreSQL, SQLite sql
LDAP ldapdb

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. 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:

    pwcheck_method: saslauthd
    mech_list: PLAIN LOGIN

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. Plaintext mechanisms (PLAIN, LOGIN) send credentials unencrypted.
This information should be protected by an additional security layer such as a TLS-encrypted
SMTP session. 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. 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.

Cyrus SASL Plugins - auxiliary property plugins

Cyrus SASL uses a plugin infrastructure (called auxprop) to expand libsasl's capabilities. Currently Cyrus SASL sources provide three authentication plugins.

Plugin Description
sasldb Accounts
are stored stored in a Cyrus SASL Berkeley DB database
sql Accounts are
stored in a SQL database
ldapdb Accounts
are stored stored in an LDAP database

These three plugins support shared-secret mechanisms i.e. CRAM-MD5, DIGEST-MD5 and NTLM. These mechanisms send credentials encrypted but their verification process requires the password to be available in plaintext. Consequently passwords cannot (!) be stored in encrypted form.

The sasldb plugin

The sasldb 'auxprop' plugin authenticates SASL clients against credentials that are stored in a Berkeley DB database. The database schema is specific to Cyrus SASL. The database is usually located at /etc/sasldb2 (/etc/postfix).

The sasldb2 file contains passwords in plaintext, and should have read+write access only to user postfix or a
group that postfix is member of. The saslpasswd2 command-line utility creates and maintains the database:

$saslpasswd2 -c -u username
Again (for verification):

Users must specify as login name, not username. You can run the following command to reuse the Postfix mydomain parameter value as the login domain:

$ saslpasswd2 -c -u `postconf -h mydomain` username
Again (for verification):

The sasldblistusers2 command lists all existing users in the sasldb database:

$ sasldblistusers2 password1 password2

Configure libsasl to use sasldb with the following instructions:

    pwcheck_method: auxprop
    auxprop_plugin: sasldb
    mech_list: CRAM-MD5 DIGEST-MD5 NTLM

In the above example adjust mech_list to the mechanisms that are applicable for your environment.

Scroll to top