Postfix SASL authentication

The basic SMTP protocol does not have the ability to verify user identity. Although the sender address on the envelope already implies the sender's identity, because the envelope address is too easy to fake, it cannot be used as identity creden. To determine whether the client has the right to use the relay service, the server must confirm whether the client (sender) is the person claimed by the other party. Before sending a mail address as an ID card, SMTP must require other supplementary mechanisms to verify the identity of the client.
From the Postfix perspective, it must assume two roles: as an SMTP server, it must be able to verify the user's personal identity (so that they can send emails using the SMTP server ); when it is an SMTP client, it needs to be able to provide its own identity card to other MTA checks (to deliver the mail to the final destination through the remote MTA ). Therefore, we will also explain how to set the Postfix so that it can pass the authentication of another MTA.
Most email systems only allow clients on the internal network to use the forwarding service. In other words, the IP address becomes the identification credential of the client. However, not all valid users have fixed IP addresses. For example, if a colleague traveling far away with a laptop may use a temporary IP address near an ISP or hotel, or if they are working at home, they are located outside the office, however, you need to send messages through the office email system. SASL provides reliable authentication regardless of whether you can know your IP address in advance.
RFC 2554 "SMTP service extension for authentication" defines how to add the authentication function to the basic SMTP protocol, which enables SMTP to use the SASL protocol to verify the client identity. We will demonstrate how to use the Cyrus SASL function library developed by Carnegie Mellon University to expand Postfix so that it has SASL verification capabilities.
Because Cyrus SASL exists in the form of a "function library", to enable your Postfix to support SASL, you must link the Cyrus SASL function library when compiling the Postfix. In addition, remote users must also set their Mua so that they can send the correct identification information when forwarding emails through your email system.

Introduction to SASL

Many Client/Server protocols have no verification capability. SASL is a common method used to enhance or add such protocols. When SASL is set, you have to decide two things. One is the verification mechanism used to exchange "identity information" (or "ID card book; the first is to determine the verification architecture of the identity information storage method. The SASL verification mechanism regulates the response process between the client and the server and the encoding method of the transmitted content. the SASL verification architecture determines how the server itself stores the Client ID card and how to verify the password provided by the client. If the client successfully passes the authentication, the server can determine the user's identity and determine the user's permissions. For Postfix, the so-called "permission" refers to the access permission of the forwarding service. You can also decide whether to use a specific sender address when the verified user forwards the email.

Select an appropriate verification mechanism
Cyrus SASL supports multiple verification mechanisms. As to which authentication mechanism is used, both the client and the server must reach a consensus in advance. The following are some common mechanisms;
Plain
Plain is the simplest mechanism, but it is also the most dangerous mechanism, because the ID card book (login name and password) uses base64 string format through the network, there is no encryption protection measures. Therefore, when using the plain mechanism, you may want to combine TLS.
Login
Login is not officially supported by login, but some old Mua versions use this mechanism, so Cyrus SASL allows you to choose whether it supports the login mechanism. If your users are still using this type of old MUa, you must specify the login support when compiling the SASL function library. The certificate exchange process for login is similar to plain.
OTP
OTP is a verification mechanism that uses a single password. This mechanism does not provide any encryption protection, because it is not necessary-each password can only be used once, and a new password should be used each time it comes online. Smto client must be able to generate OTP certificates.
Digest-md5
When this mechanism is used, the client and server share the same recessive password, and the password is not transmitted over the network. The verification process starts when the server first raises a challenge (question). The client uses this challenge and the implicit password to calculate a response (response ). Different challenge cannot calculate the same response. Any Party with a secret password can use the same challenge to calculate the same response. Therefore, as long as the server compares the response returned by the client with the self-calculated response, it can know whether the client has the correct password. Because the real password does not pass through the network, it is not afraid of network monitoring.
Kerberos
Kerberos is a network-type authentication protocol. Unless your network has used Kerberos, you should not be able to use the Kerberos mechanism. If your network has set up a Kerberos authentication center, SASL can perfectly integrate SMTP verification into the existing system.
Anonymous
The anonymous mechanism has no significance for SMTP, because the purpose of SMTP verification is to restrict the objects used by the forwarding service, rather than to form open relay. SASL provides this mechanism mainly to support other protocols.
When the client is linked to an email server that supports SASL, the server lists the available mechanisms with priority for the client to choose from. If the client also supports the multi-clock mechanism, when the first mechanism verification fails, the client may continue to try the second mechanism until it passes the verification or all the mechanisms fail. If the two parties cannot coordinate a common mechanism at the beginning, the verification process will fail.
Once both parties reach a consensus on the mechanism used, the verification process starts. The actual interaction process depends on the mechanism, but usually contains one or more response processes. The verification protocol itself also specifies the encoding format of the response content.

Select an appropriate verification architecture

The SASL verification architecture can use the existing UNIX system password or the dedicated SMTP User Password File. You can also use intermediate control authentication frameworks such as Kerberos on your network.
Which Authentication Architecture is most suitable for you depends on where your server is located and how certificate information is obtained. For example, if the certificate data of all users of SMTP and POP/IMAP is stored in the system password file and verified by PAM, SASL should obtain the certificate data through Pam. On the other hand, if all SMTP users only have virtual accounts, you may need to store certificate data in a dedicated database and set SASL and POP/IMAP server to obtain certificate data from the database.

Postfix and SASL

Before using SASL, you should decide which mechanism and architecture to use, because your decision will affect the compilation, installation, and setting process. First, you must install the SASL function library on your system, or determine the installation directory and version of the SASL function library. Next, use the SASL installation information you collected to set the compilation options of the Postfix, and then re-compile the Postfix to enable SASL verification. Some system platforms may have installed SASL libraries in advance and even provide Postfix packages that support SASL. However, most pre-compiled Postfix packages do not support SASL. Therefore, if you use a ready-made Postfix package, you 'd better first read the relevant documentation, or follow the test methods described in the "test verification configuration" section in this chapter to confirm that your Postfix does support SASL. In addition, make sure that your SASL function library supports every authentication mechanism that the client may use. For example, if another user uses the old version of Outlook Express, your SASL function library must support the login verification mechanism.
The development progress of the Cyrus SASL function library is divided into two lines: SASL and saslv2. SASL has been gradually replaced by saslv2. In the future, Postfix may only support saslv2, so this chapter only discusses saslv2. In addition, both versions of the Postfix and SASL function libraries must be correct before they can be combined.
Postfix supports saslv2 function libraries from 1.17-20020331 lab versions. In earlier versions, only saslv1 is supported. Theoretically, the latest Postfix and the latest Cyrus saslv2 can be smoothly combined.

SASL configuration of Postfix

Assume that you have installed the SASL function library and the Postfix supports SASL, And you are determined which authentication mechanism and architecture to use. Now, let's gradually set the Postfix so that it can use SASL to verify the user's identity.

Set verification architecture
For each application system that uses the Cyrus SASL function library, Cyrus SASL provides an independent configuration file. The SASL configuration file that affects Postfix is smtpd. conf. This file is usually located in/usr/local/lib/sasl2/smtpd. conf. Basically, smtpd. conf should at least specify the verification architecture to be used. We plan to discuss two most common architectures: Unix system passwords and independent SASL dedicated passwords.

UNIX System Password
Generally, it is most convenient for SASL to directly use the existing system password to verify user identity. The traditional system password file should be/etc/passwd, but modern systems with high security can use/etc/shadow, Pam or such certificate databases. Because this type of password file can only be accessed by privileged processes, and Postfix is deliberately designed to avoid privileged identities, the Postfix cannot directly access the system password file.
The Cyrus function library provides a special verification server program called saslauthd, which can replace Postfix to obtain password data. Saslauthd eaemon itself requires a privileged identity. However, because it is a process independent of the Postfix and usually does not need to communicate with the outside world, the security hazard has been minimized. If you want SASL to use a UNIX password, you must start the saslauthd daemon that is included in the Cyrus SASL package. Note that saslauthd is used to access the UNIX system password, indicating that you can only use the plaintext password, because asalauthd requires the actual password for verification.
To let SASL know that Postfix will access the Certificate database through saslauthd daemon, you must add the following content to the smtpd. conf configuration file:
Pwcheck_method: saslauthd
Saslauthd included in the Cyrus SASL package should be installed in a directory listed in the $ PATH environment variable. You must start saslauthd daemon in the background before using the Postfix to verify the client. When you start saslauthd, you must use the-A option to specify the type of the password system. The most common types include Pam, shadow, and getpwent. For example, on a system using Pam, you should use the following command to start saslauthd daemon:
Saslauthd-a Pam

SASL private password
If you do not want to use the system password to verify the SMTP client, you deliberately create an independent account database that has no system password. It may be a good idea to use the SASL password when your Postfix system is purely used to provide the mail service, not to receive external emails, or to log on to the server system itself. Add the following content to your smtpd. conf configuration file:
Pwcheck_method: auxprop
In terms of Cyrus, auxprop indicates auxiliary property plug-ins (exclusive plug-in module for accessibility), which is used for verification by external programs. The default auxiliary plug-in module is sasldb (which is also one of the programs included in the Cyrus SASL Package). It should be able to meet all the Postfix requirements. The keyword auxprop only requires an external SASL password file.
Saslauthd daemon is not required for SASL passwords, but you must store all SMTP client accounts and passwords in a dedicated external password file. The default password file used by SASL is/etc/sasldb2. The Postfix SMTP server must have at least the permission to read this file. If you use the auto_transition function of Cyrus SASL, Postfix requires the permission to write this file. If you do not use the auto_transition function, it is best not to open the write permission to postfix.
If other processes also need to be able to access the SASL password file (for example, POP/IMAP Server), you must adjust the file's ownership and access permissions so that relevant processes can access it. For example, you can create a SASL group and make sure that the Postfix and other accounts that need to access the file belong to this group. If any process needs to update the file, the read-only mode may be too strict, and you must provide the write permission to the necessary process. The following command sets the access mode of/etc/sasldb2 to 440, so that all members of the SASL group can read the file, and other processes do not have access to the file:
Chown Postfix: SASL/etc/sasldb2
Chmod 440/etc/sasldb2
The saslpasswd2 tool provided by the Cyrus SASL package can be used to generate and maintain the/etc/sasldb2 password file. For each account, you must provide three types of information: Logon Name, SASL domain name, and password. For Postfix, the domain name must match the value of the myhostname parameter. Therefore, the safest way to set the domain name is to use postconf-H myhostname to determine the domain name, as shown below:
Saslpasswd2-c-u 'postconf-H myhostname' kdent
-The C option requires saslpasswd2 to create an account. The "-U" option specifies the domain to which the account belongs. The value is taken directly from the Postfix configuration file.

Set Postfix
All Postfix parameters related to SASL password verification are prefixed with smtpd_sasl * (about SMTP server parameters) or smtp_sasl * (about SMTP client parameters. For server configuration, you must at least set the smtpd_sasl_auth_enable parameter, and list the permit_sasl_authenticated restriction conditions in a certain smtpd _ * _ restriction Filtering Rule.

Enable SASL Verification
The smtpd_sasl_auth_enable parameter determines whether the Postfix SMTP server supports SASL Verification:
Smtpd_sasl_auth_enable = Yes
Some old Mua do not fully comply with the SMTP authentication protocol. According to the standards in the Specification, after the SMTP client sends the EHLO command, the SMT server should list its authentication mechanism support list, and this list appears after the keyword auth and a space.
However, some Mua expect to receive the auth and an equal sign;
Postfix allows you to accept such non-compliant behaviors:
Broken_sasl_auth_clients = Yes
After this parameter is set, Postfix lists the SMTP authentication mechanisms supported by this parameter in both standard and non-standard formats.
Because both formats are in the SMTP server response, standard Mua is not affected, and non-standard Mua can be verified using smtp sasl.

Avoid sender impersonation
How do I determine the real sender address used by the client when the client sends a message through Postfix? For example, how can someone who passes SMTP authentication as a but uses B as the issuer's address avoid this impersonation? Postfix allows you to set the correspondence between the sender address and SASL logon identity. For example, assume that a person's email address is a kdent@example.com and his SASL login identity is kdent. If you want a kdent to send an email only in the name of this address, instead of using another mailing address, you should define the following mappings in a query table:
Kdent@example.com kdent
This is a common Postfix query table. You can list the correspondence between each address and each SASL user one by one, or use a regular expression to represent the personal name or domain name of the email address. After creating a query table, point the smtpd_sender_login_maps parameter of Main. cf to this table:
Smtpd_sender_login_maps = hash:/etc/postfxi/sasl_senders
The next step is to include the reject_sender_login_mismatch restriction in a combination of smtpd _ * _ Restrictions filtering rules, so that if kdent passes SASL verification, but he tries to send an email in the name of the mary@example.com, then the Postfix will reject sending messages to him.

Approve authorized users
If your UBE filter rule contains smtpd_recipient_restrictions, you must enable the Postfix to allow authenticated users to use the forwarding service, that is, to place permit_sasl_authenticated in a proper place in the constraints.

Set Verification Mechanism
When the client comes online to the SMTP server, which password verification mechanisms can be used is determined by the smtpd_sasl_security_options parameter. The complete mechanism options depend on which mechanisms are available on your system and what mechanisms are supported by the SASL function library. If no option is specified, all available mechanisms including plaintext passwords are accepted by default, except Anonymous logon. If saslauthd daemon is used, the plaintext password must be accepted. Therefore, the default value is reasonable. If you specify any options, the default value is invalid. Therefore, your options must contain noanonymous. For example:
Smtpd_asal_security_options = noanonymous, noplaintext
The following are general mechanism options:
Noplaintext
This option is excluded from plaintext password verification. This enables the SASL option challenge/response technology to be used. If your security policy does not allow passwords to flow through the network in plain text, specify the noplaintext option, but it also means you cannot use saslauthd.
Noactive
This option will exclude the password mechanism that may be subject to "Active attacks. In "Active attacks", attackers try to embed them between the client and server. Therefore, some types of Active attacks are also called "Man-in-the-middle attacks". Attackers can read or change the data so that the client or server mistakenly thinks that the data is actually sent by the other party.
Nodictionary
This option will exclude the password mechanism that may suffer dictionary attacks. In the dictionary attack, attackers use the pre-compiled Password Database to test the password one by one. This happens to be able to break into your system. This type of password data library is usually composed of cities, teams, pets, common names, dictionary words, and a variety of obvious vocabulary changes. It is called "dictionary attack".
Noanonymous
Exclude Anonymous logon. The main purpose of SMTP authentication is to confirm the identity of the user, so "Anonymous login" is meaningless to the SMTP server. By default, Postfix prohibits anonymous logon. If you specify other options, you must specify noanonymous.
Mutual auth
Mutual authentication mechanism is required-both the client and server must provide evidence to prove their identity.

Set steps for aggregation
The steps involved in adding the SASL function to the Postfix system are complex. To sum up the previous knowledge in this chapter, the following are the configuration steps:
1. Determine the verification mechanism and architecture you intend to support.
2. Install the SASL function library and re-compile the Postfix to include SASL. You can also obtain the Postfix package containing SASL and related SASL verification mechanisms.
3. reinstall Postfix
4. Create/usr/local/lib/sasl2/smtpd. in the conf configuration file, set the pwcheck_method parameter to saslauthd (if SASL saslauthd and the system password are used) or auxprop (if SASL's exclusive password file is used ).
5. If you select a UNIX system password as the verification architecture, start saslauthd daemon and specify the verification method used by your system. Otherwise, use the saslpasswd2 command to create an SMTP client account and password on your system.
6. Edit main. Cf, start the SASL verification function, and specify the verification method. The basic setting requires at least two parameters:
Smtpd_sasl_auth_enable = Yes
Smtpd_recipient_restrictions = permit_mynetworks,
Permit_sasl_authicated, reject_unauth destination
7. Reload the Postfix so that the changes made in the main. cf configuration file take effect:
Postfix reload

Test SASL configuration Verification

After the installation is completed, how can we determine that there are no errors in all the steps to prove that the Postfix has indeed been verified according to our requirements? When a user travels outside China, it is definitely not a good solution to see if they will call back and complain. The best way is to directly observe the interaction of the SMTP server, experience the verification process, and immediately check the clues left by the log file.
To connect to the SMTP server, the easiest way is to use the Telnet tool program and then talk to the server process SMTP. The most easily tested plain mechanism. If you disable this mechanism, we recommend that you enable it for the time being and disable it after testing.
Let's first understand the details of the plain mechanism and then start the experiment. The plain mechanism requires that you provide an identity string after the AUTH command, which is encoded as a base64 format. The order of the data that constitutes this string is "Login identity", followed by a null character, followed by "password owner identity", followed by a null character, the last is the "password" itself. Generally, the "Login identity" is the same as the "password owner identity. For example, assume that the user's kdnet password is Rumpelstiltskin, And the login identity is the same as the password owner identity, then, his id string is "kdent/okdent/orumpelistiltskin" (pre-encoding format ).
The trouble lies in how to encode the identifier string into base64 format and does not contain the CR character at the end of the string. If your system has mmcncode and printf commands, this step should not be difficult. The printf command can display strings in the specified format, but does not automatically add a line break character at the end of the string like Echo. The mmencode command can encode the input string into various mime formats, and the default format is exactly the base64 we need.
Therefore, we can use the following command to generate an identifier string in base64 format:
Printf 'kdent/0 kdent/0rumpelstiltskin' | mmencode
Some System Platform printf may not be able to correctly process the null character (/0) in the middle of the string. If you want to know whether printf on your system has this problem, you only need to check whether the base64 encoding result is shorter than the original string. If you have problems with printf, use echo-N instead of printf.

SMTP client Verification

In the first half of this chapter, we will focus on how Postfix plays the role of the SMTP verification server-to verify the remote Mua or MTA identity, so as to determine whether the other party has the right to use the forwarding service. Now, we need to change the angle to discuss how Postfix plays the client role -- propose your own identity creden。 to obtain the permission to use the remote MTA to forward the service location.
First, you must provide a password file to the Postfix, which contains certificate data that can be obtained through a remote server. Each record of the password file contains a domain name representing the remote server and a group of accounts and passwords that can be verified by the server. The format is as follows:
Destination Username: Password
When the Postfix sends an email, it first checks the domain part of the recipient address, if it cannot find a fully consistent destination in the password file, and then looks for the host name to be online. This check process allows the Postfix to easily connect multiple MX hosts that share databases of the same account. The parameter used to determine the location of the password file is smtp_sasl_password_maps.
It is determined that the client line is the smtp_sasl_security_options parameter. The setting method is the same as that of the smtpd_sasl_security_options parameter on the server side. If you do not specify any options, the default behavior is to allow all mechanisms that can be found on the system, except Anonymous logon.

Setting Process for SMTP client Verification

Let's take an example to demonstrate how to set a postfix so that it can present its identity creden。 when forwarding emails through the remote system. In this example, assume that we have a group of accounts that can use all server hosts of the ora.com domain and a group of accounts that can use the mail.postfix.org host.
1. Create the/etc/Postfix/sasl_passwd password file and enter our account and password, for example:
Ora.com kdent: Rumpelstiltskin
Mail.postfix.org KYLE: Quixote
2. Use postmap to generate database files:
Postmap/etc/Postfix/sasl_passwd
3. Edit the main. cf configuration file and start the client verification function. Note that the parameter to be set this time is smtp_sasl_auth_enable, instead of smtpd_sasl_auth_enable (the latter is used to start server verification ). In the smtp_sasl_password_maps parameter, specify the location of the password file:
Smtp_asal_auth_enable = Yes
Smtp_sasl_password_maps = hash:/etc/Postfix/sasl_passwd
4. Reload the Postfix to make the changes take effect:
Postfix reload
Now, whenever the Postfix SMTP client tries to forward mail via any domain or host listed in/etc/Postfix/sasl_passwd, it provides the corresponding verification book. For example, if your Postfix SMTP client is online to the mail.ora.com server, it will use the kden and Rumpelstiltskin accounts and passwords.