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
/etc/postfix/main.cf:
smtpd_sasl_type = dovecot | cyrus
/etc/postfix/main.cf:
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:
/etc/postfix/main.cf:
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:
/etc/postfix/main.cf:
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:
/etc/postfix/main.cf:
# 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:
/etc/postfix/main.cf:
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
#A more sophisticated policy allows plaintext mechanisms, but only over
#a TLS-encrypted connection:
/etc/postfix/main.cf:
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
/etc/postfix/main.cf:
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:
/etc/postfix/main.cf:
smtpd_recipient_restrictions =
...
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
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
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:
/etc/sasl2/smtpd.conf:
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 example.com username Password: Again (for verification):
Users must specify username@example.com 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 Password: Again (for verification):
The sasldblistusers2 command lists all existing users in the sasldb database:
$ sasldblistusers2 username1@example.com: password1 username2@example.com: password2
Configure libsasl to use sasldb with the following instructions:
/etc/sasl2/smtpd.conf:
pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM
or
mech_list: CRAM-MD5 DIGEST-MD5 NTLM
In the above example adjust mech_list to the mechanisms that are applicable for your environment.