Specifying mechanisms

The smtpd_sasl_security_options parameter lets you control which password mechanisms are listed when clients connect to your SMTP server. The complete list of available mechanisms depends on your system and the mechanisms that were available when your SASL libraries were built. If you don’t specify any options, the default is to accept all available mechanisms including plaintext passwords, but not anonymous logins. If you are using the saslauthd daemon, you must accept plain-text passwords, so the default configuration probably makes the most sense. If you specify any of the options, you override the default, so make sure that you include noanonymous among your options. If you set this parameter, you can specify any combination of the following values. For example:

smtpd_sasl_security_options = noanonymous, noplaintext

Common mechanisms include:

noplaintext

If your security policy does not permit passwords to be sent as plaintext, specify noplaintext. This causes SASL to use one of the challenge/response techniques that authenticate without transmitting actual passwords.

noactive

In active attacks, attackers manage to insert themselves between the client and server. Some types of active attacks are commonly referred to as man-in-the-middle attacks. Attackers may be able to read or alter data as it is transmitted or pretend to be the client or server. Specify noactive to limit supported password mechanisms to those that are not known to be vulnerable to active attacks.

nodictionary

In dictionary attacks, attackers run through a preassembled database of possible passwords trying each one in turn to see if it allows access. Databases are typically made up of lists of cities, teams, proper names, and all dictionary words plus obvious variations on the words. Specify nodictionary to limit supported password mechanisms to those that are not known to be vulnerable to dictionary attacks.

noanonymous

Anonymous logins have no useful purpose for SMTP servers. By default Postfix does not allow anonymous logins. If you specify any other options, be sure to also specify noanonymous since you will be overriding the default.

mutual_auth

You can require mechanisms that provide mutual authentication where both the client and server provide credentials proving their identities. Specify mutual_auth to limit advertised mechanisms to those that provide for mutual authentication.