Chapter 7. Authenticating with AUTH

Introduction

Strong authentication uses cryptographic techniques to verify the identity of the end points in a network exchange. For sendmail, strong authentication ensures that the connecting host and the receiving host are who they claim to be. In this chapter, we look at how AUTH can be used for authentication.

Authentication is not the same as encryption. Encryption can be used to hide the content of a piece of mail or to hide the entire SMTP protocol exchange, including the mail. (One technique for encrypting the SMTP exchange, and the mail it carries, is covered in Chapter 8.) Authentication does not hide the contents of mail; rather, it ensures that the mail comes from the correct source.

Traditional sendmail authentication systems are based on the hostname or IP address. Examples of this can be found in Chapter 3, which uses hostnames and IP addresses to grant relaying privileges. However, the current IP address of a valid client may not be known. A mobile client that obtains its address from a DHCP server may have an address that constantly changes. Mobile clients need an authentication scheme that is not dependent on a changeable IP address. Additionally, hostnames and addresses are easily spoofed and thus do not provide strong authentication. Of course, it is debatable whether a service such as mail relaying really needs strong authentication, but it is clear that mobile clients need authentication that is independent of the IP address. The AUTH protocol provides some strong authentication techniques that do not rely on the IP address or hostname.

The AUTH Protocol

AUTH is an SMTP protocol extension. It is defined in RFC 2554, SMTP Service Extension for Authentication. RFC 2554 outlines the negotiations that are used to select an authentication mechanism. The RFC describes three functions for the AUTH keyword:

  • 250-AUTH is the response of the SMTP EHLO command. The response advertises the supported authentication mechanisms. The configuration that causes sendmail to list AUTH in the EHLO response and to accept incoming AUTH connections is covered in Recipe 7.1. That configuration applies when sendmail runs as an MTA, and it is only applicable when sendmail is run with the -bd command-line option.

  • AUTH is the SMTP command used to request authentication and to select the authentication mechanism for the session. The connecting host must select one of the mechanisms advertised by the receiving host, or the authentication attempt is rejected. sendmail will request AUTH authentication when it is configured as described in Recipe 7.2. A laptop or desktop that sends SMTP mail but does not accept inbound SMTP connections could be configured using only Recipe 7.2. A system that accepts incoming AUTH connections and creates outgoing AUTH connections would combine the configurations from both Recipe 7.1 and Recipe 7.2.

  • AUTH= is a parameter used on the MAIL From: line to identify the authenticated source address. The AUTH= parameter comes from the connecting host as part of the initial envelope sender address. If the receiving host trusts the AUTH= parameter, it propagates it on to the next mail relay. Recipe 7.6 provides additional information about the AUTH= parameter.

The AUTH protocol relies on SASL ( the Simple Authentication and Security Layer (SASL) for the actual authentication. RFC 2222, Simple Authentication and Security Layer (SASL), describes the SASL framework and defines how protocols negotiate an authentication method. RFC 2222 identifies four authentication techniques:

KERBEROS_V4

Authentication is performed by a Kerberos 4 server.

GSSAPI

The GSS-API is used for authentication. This type of authentication can be performed by a Kerberos 5 server.

S/KEY

The one-time password system S/Key is used for authentication.

EXTERNAL

Authentication depends on an external security system, such as Transport Layer Security (TLS).

Subsequently, several more authentication techniques have been added to the SASL framework. Some examples are:

ANONYMOUS

This technique, which is defined in RFC 2245, permits unauthenticated access.

PLAIN

Authentication is based on clear text passwords.

LOGIN

This is an undocumented authentication technique, included for compatibility with outdated SMTP clients, that also uses clear text passwords.

CRAM-MD5

This is a shared secret authentication method that uses Message Digest 5 (MD5) for security. Challenge Response Authentication Mode MD5 (CRAM-MD5) is an older authentication method that has been superceded by DIGEST-MD5.

DIGEST-MD5

This is the preferred MD5 authentication method. Like CRAM-MD5, it is a shared secret authentication method that uses Message Digest 5 (MD5) for security. However, DIGEST-MD5 is more resistant to security attacks, and it supports encryption of the SMTP conversation.

sendmail does not contain implementations of the various authentication techniques. Instead, sendmail uses the techniques that are implemented and configured in SASL. For this to work, Cyrus SASL must be installed and properly configured on the sendmail system.

Cyrus SASL

Cyrus SASL is implemented as a library. The SASL library standardizes the way in which applications interface with the authentication methods. Many Unix systems come with the SASL libraries preinstalled. Our sample Red Hat Linux system is a good example. Red Hat includes SASL as one of the standard RPMs. An rpm command can check whether it is installed, as in this example:

# rpm -qa cyrus-sasl
cyrus-sasl-1.5.24-25

If SASL is not installed on your system, check to see if it was delivered as part of your Unix software. If it was, install the copy of SASL provided by your Unix vendor. If it is not available from your vendor, go to http://asg.web.cmu.edu/cyrus/download/ or ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/ to download the latest version of SASL. Information on SASL is available at http://asg.web.cmu.edu/sasl/.

After Cyrus SASL is installed, the specific authentication techniques must be configured before they can be used. To understand SASL configuration, you must understand SASL terminology. The Cyrus SASL documentation defines four special terms:[1]

userid

The username that determines the permissions granted to the client. The client is given the permissions normally granted to the specified user. userid is also called the authorization id.

authid

The account name used to authenticate the connection. authid is also called the authentication id.

realm

A group of users, systems, and services that share a common authentication environment. All members of a given group use the same realm value. It is common to use a domain name or hostname for the realm value.

mechanism

Identifies the type of authentication used. For example, DIGEST-MD5 is a valid mechanism value.

The userid and authid values cause the most confusion. To understand how SASL uses these two values, think of an /etc/passwd file with one entry for craig and another for kathy. In a normal login, when Kathy logs in to the kathy account, she is granted the permissions given to that account. With SASL, it is possible to set authid to kathy and userid to craig, which means that the kathy account password is required for authentication, but the permissions granted to the user are the permissions granted to the craig account.

Several of the strong authentication techniques available through SASL require the configuration of separate authentication services—KERBEROS_V4 and GSSAPI are good examples. This chapter focuses on the strong authentication techniques that can be implemented on a sendmail system without installing any software other than SASL. Two strong authentication techniques, DIGEST-MD5 and CRAM-MD5, are provided with the Cyrus SASL libraries. Both of these techniques can be easily configured for sendmail authentication.

DIGEST-MD5 and CRAM-MD5 are configured through the /etc/sasldb database. This is done using the saslpasswd commands. Use saslpasswd to enter the SASL authid and realm and the password that the connecting host will use during authentication. Recipe 7.1 provides an example of how this is done.

Because these are shared-secret authentication mechanisms, the connecting host must be configured with values that match those entered in the sasldb file on the receiving host. On sendmail 8.12 systems, these values are defined in an AuthInfo: entry. Normally this entry is placed in the access database, as described in Recipe Recipe 7.2. Optionally, an authinfo file can be used to hold the AUTH credentials, as described in Recipe 7.3.

The SASL Sendmail.conf file

DIGEST-MD5 and CRAM-MD5 are very secure and easily configured, making them excellent choices for sendmail authentication. There are, however, other authentication techniques available through SASL that can be used with sendmail. While DIGEST-MD5 and CRAM-MD5 do not require it, some of the other mechanisms require configuration through the Sendmail.conf SASL application file. Three configuration commands can be used in the Sendmail.conf file. They are:

srvtab

The srvtab command points to the file that contains the Kerberos 4 service key. The argument provided with this command is the full pathname of the service key file.

auto_transition

The auto_transition command causes SASL to automatically create a sasldb entry for every user that authenticates using the PLAIN authentication method.

pwcheck_method

The pwcheck_method command defines the technique that SASL should use to validate the clear text password received during PLAIN method authentication. The possible values for the pwcheck_method are:

passwd

Tells SASL to look up passwords in the /etc/passwd file.

shadow

Tells SASL to look up passwords on the /etc/shadow file. Because of the file permissions associated with the /etc/shadow file, the application must be running as root.

pam

Tells SASL to use Pluggable Authentication Modules (PAM). PAM must, of course, be properly configured to authenticate the password.

sasldb

Tells SASL that the passwords for the PLAIN authentication method are stored in the sasldb file. Normally, sasldb is only used for DIGEST-MD5 and CRAM-MD5 authentication.

kerberos_v4

Tells SASL to authenticate clear text passwords through the Kerberos 4 server. Kerberos 4 must be installed, configured, and running, and the Kerberos 4 server must be configured to accept clear text passwords.

sia

Tells SASL to use Digital’s Security Integration Architecture (SIA) to validate passwords.

pwcheck

Tells SASL to pass the data to an external program for password checking.

A sendmail system that advertised the PLAIN authentication method might have a Sendmail.conf file similar to the one shown below:

# cat /usr/lib/sasl/Sendmail.conf
pwcheck_method:pam

The recipes in this chapter do not require the /usr/lib/sasl/Sendmail.conf file because they each use the DIGEST-MD5 authentication mechanism, which does not require the Sendmail.conf file. DIGEST-MD5 is secure, easy to configure, and available as part of Cyrus SASL. If you must use another SASL authentication mechanism, see the SASL documentation for more information on how they are configured.

Passing Flags to SASL

sendmail can be configured to request optional processing from SASL for the AUTH protocol. The confAUTH_OPTIONS define can set several flags that affect the way that sendmail and SASL interact. These flag are listed in Table 7-1.

Table 7-1. SASL flags

Flag

Purpose

A

Use the AUTH= parameter only when successfully authenticated.

a

Request optional protection against active attacks during the authentication exchange.

c

Require client credentials if the authentication mechanism supports them.

d

Reject authentication techniques that are susceptible to dictionary attacks.

f

Don’t use the same static shared-secret for each session.

p

Reject authentication techniques that are susceptible to simple passive attacks.

y

Don’t allow the ANONYMOUS authentication mechanism.

The A option controls when the AUTH= parameter is added to the envelope sender information on the SMTP Mail From: command line. The A option is used in Recipe 7.6, which demonstrates how the confAUTH_OPTIONS flag define is used.

The a option increases the checks SASL performs to detect active authentication attacks. SASL is used in a variety of situations. In some applications, higher security is worth the cost in increased processing and authentication delays. Normally, that is not the case for email. Mail hosts are authenticating to prevent spammers from relaying through your server. Spammers do not spend the time and money to launch active authentication attacks against servers that use strong authentication. When increased security is needed for an email connection, it is probably better to use transport layer security, as described in Chapter 8.

The c flag tells SASL to require client credentials when an authentication mechanism is used that supports client credentials. (Although it is not used inside of a SASL session, the TLS protocol, described in Chapter 8, is an example of a protocol that optionally permits the use of client credentials.) Don’t confuse client credentials with AUTH credentials. The AUTH credentials discussed in this chapter are the shared-secret and other AUTH values used for authentication. The DIGEST-MD5 and CRAM-MD5 authentication techniques used by sendmail require AUTH credentials without the c option.

The f option tells SASL to use forward security between sessions. This means that the shared-secret used for one session is not used in the next session. Some technique must be used to negotiate a new secret for each session. Of course this requires an authentication mechanism that can handle forward security. The authentication techniques commonly used by sendmail do not implement forward security; therefore, this flag is not normally used in sendmail configuration.

The three remaining options, d, p, and y, all limit the techniques that can be used for authentication. For example, specifying the p option blocks the use of the PLAIN and LOGIN techniques over an unsecured connection.

These flags pass information to SASL, changing the way that SASL serves sendmail. Values passed from SASL are also used inside sendmail.

Authentication Macros and Rulesets

sendmail uses the information provided by authentication. sendmail stores authentication data in several macros. The authentication macros are:

${auth_author}

This macro holds the sendmail authorization id, which is the address assigned to the AUTH= parameter on the MAIL From: line.

${auth_authen}

This macro holds the sendmail authentication id, which is either the userid or the userid and the realm, written as userid @ realm.

${auth_type}

This macro holds the name of the authentication method used to authenticate the client. For example, DIGEST-MD5 would be a possible ${auth_type} value.

${auth_ssf}

This macro holds the number of bits used for optional SASL encryption. If no SASL link encryption is used, this macro is unassigned.

In addition to the authentication macros, the hostname and the IP address of the system at the other end of the mail transport connection are stored in macros, which can be useful information for authentication checks. The following values are stored in the macros:

${server_addr}

The IP address of the remote server, as determined from the TCP connection. This macro is used on the client.

${server_name}

The hostname of the remote server, as determined from a hostname lookup of the ${server_addr} value. This macro is used on the client.

${client_addr}

The IP address of the client, as determined from the TCP connection. This macro is used on the server.

${client_name}

The hostname of the client, as determined from a hostname lookup of the ${client_addr} value. This macro is used on the server.

sendmail also provides ruleset hooks that simplify the process of adding authentication checks. The primary hooks used with AUTH are:

Local_check_mail

This ruleset adds checks to the check_mail ruleset, which is used to process the envelope sender address from the MAIL From: line. The check_mail ruleset is not specific to AUTH, but the overlap between the ${auth_author} value and the envelope sender address means that Local_check_mail is occasionally used for custom AUTH processing.

Local_check_rcpt

This ruleset adds checks to the check_rcpt ruleset, which processes the envelope recipient address from the RCPT To: line. The check_rcpt ruleset is not specific to AUTH, but because it is used to authorize delivery to a recipient, Local_check_rcpt is occasionally used to modify it for AUTH processing.

Local_trust_auth

This ruleset adds checks to the trust_auth ruleset, which is used by the server to determine whether the AUTH= parameter on the MAIL From: line should be trusted. The trust_auth ruleset is specific to the AUTH protocol because the AUTH= parameter is only used when AUTH is running on the client. Use Local_trust_auth to customize the processing of the AUTH= parameter.

Local_Relay_Auth

This ruleset is called by the Rcpt_ok ruleset. By default, sendmail grants relaying privileges to an authenticated client only if the client authenticated is using a mechanism listed in the $={TrustAuthMech} class. Use Local_Relay_Auth to modify the process of granting relaying privileges to authenticated clients.

7.1. Offering AUTH Authentication

Problem

In order to require strong authentication before granting special privileges, such as relaying, you have been asked to configure sendmail to offer AUTH authentication.

Solution

AUTH requires the SASL library. Configure the SASL authentication technique that you wish to use. See this chapter’s Introduction for information about the SASL library and where it can be obtained.

Use -d0.1 to check the sendmail compiler options. If the “Compiled with:” list displays SASL, restart sendmail to reload the freshly configured SASL libraries and you’re ready to run. If SASL is not included in the “Compiled with:” list, recompile sendmail as shown in Recipe 1.5.

Discussion

There is no need to add m4 macros to the sendmail configuration to advertise basic AUTH mechanisms. Only a properly installed and configured SASL library and a copy of sendmail that has been compiled with SASL support are needed.

The SASL configuration is driven by which SASL authentication techniques are installed on your system and by which of those techniques are selected for use. Our sample Red Hat system was delivered with SASL preinstalled. Figure 7-1 shows the System Environment/Libraries window from an RPM management tool.

Observing the installed SASL libraries in Red Hat Linux
Figure 7-1. Observing the installed SASL libraries in Red Hat Linux

The figure shows the three SASL library modules that came with this Linux system. cyrus-sasl-1.5.24-25 is the basic SASL library. cyrus-sasl-plain-1.5.24-25 is the SASL plug-in that provides the PLAIN and LOGIN authentication techniques. cyrus-sasl-md5-1.5.24-25 is the plug-in that provides the CRAM-MD5 and DIGEST-MD5 SASL authentication techniques. Of these, only CRAM-MD5 and DIGEST-MD5 offer any real security.

The sendmail server will not advertise the DIGEST-MD5 and CRAM-MD5 techniques unless the file /etc/sasldb exists. sasldb stores the names and passwords used for MD5 authentication. The file is built by saslpasswd the first time it is used to create an SASL password. To authenticate a client with the sasldb, add the client’s name and password to the database. Assume we want to authenticate crab using MD5 and that we assign crab the password: It'sasecret!. The following command would accomplish this and make both CRAM-MD5 and DIGEST-MD5 available for sendmail authentication:

# saslpasswd -c -u wrotethebook.com crab
Password: It'sasecret!
Again (for verification): It'sasecret!

The -u argument defines the SASL realm. When creating an SASL account for AUTH authentication, always explicitly define the realm with the -u argument. The realm used on both endpoints must agree in order for authentication to succeed. Take control of this important information by explicitly defining the realm that both the server and the client should use. In the example, the realm is wrotethebook.com, which is the same as the local domain name. The string used to name the realm is arbitrary. It can be any value you choose. While the realm does not have to be a domain name, it usually is for the sake of simplicity.

The -c argument tells saslpasswd to create a new account. The account name, crab in the example, is placed at the end of the command line. saslpasswd then prompts for a password for the crab account. This password is the shared-secret key used for DIGEST-MD5 or CRAM-MD5 authentication.

After configuring SASL, the receiving host responds to the SMTP EHLO command by listing the available AUTH authentication techniques. A telnet test shows this:

# telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 chef.wrotethebook.com ESMTP Sendmail 8.12.9/8.12.9; Fri, 22 Aug 2003 12:01:37 -
0400
ehlo localhost
250-chef.wrotethebook.com Hello IDENT:jlXFenYjCfmga11KxmpDxZFsKgljZB2/@localhost 
[127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5
250-DELIVERBY
250 HELP
QUIT
221 2.0.0 chef.wrotethebook.com closing connection
Connection closed by foreign host.

The receiving host responds to the EHLO command with a list of the extended services that it supports. The 250-AUTH response shows that the host supports the AUTH protocol, and the response lists the specific authentication techniques that it supports. In the example, the server advertises DIGEST-MD5 and CRAM-MD5, meaning that SASL has been configured for CRAM-MD5 and DIGEST-MD5, and sendmail has been directed to advertise these authentication methods. Recipe 7.4 describes how to control which AUTH techniques are advertised by sendmail.

In the example above, the receiving system responds with 250-AUTH. If you have just configured the receiving system, and it doesn’t issue the 250-AUTH response, there are several things you can do to try to discover the problem. First, check the log to see if any security problems are logged. sendmail may have been unable to open a required file.

If basic logging doesn’t show the problem, increase the LogLevel to 13 and rerun the test shown above. (Recipe 1.10 provides an example of setting the sendmail LogLevel.) Examine the log again.

sendmail only advertises AUTH if some of the authentication mechanisms that it is configured to accept are available from SASL and properly configured. grep the log for the string mech=. The available mech= log entry lists the mechanisms that sendmail believes are offered by SASL. The allowed mech= entry lists the mechanisms that sendmail believes it is allowed to offer. sendmail only issues the 250-AUTH response if these lists share some common items. If the available mech= list identifies some mechanism, you can change the list of mechanisms that sendmail will accept using the confAUTH_MECHANISMS define described in Recipe Recipe 7.6.

If the available mech= list is empty, and the log contains either an error message from SASL that contains the string listmech=0 or the sendmail error message “AUTH warning: no mechanisms,” SASL is not properly installed and configured. SASL must be installed with authentication mechanisms, as noted earlier in the discussion of Figure 7-1. Make sure you download and properly install all of the required libraries.

If SASL is not complaining but sendmail is, perhaps sendmail is looking in the wrong place for SASL libraries. The path to SASL libraries can be set using the environment variable SASL_PATH by adding lines such as the following to the sendmail configuration:

LOCAL_CONFIG
ESASL_PATH=/usr/lib/sasl

Of course, this path is only an example. You would use the path value appropriate to your system.

Installing SASL, configuring the sasldb, and compiling sendmail with SASL support configures sendmail to accept only inbound AUTH connections. If the system must also send out mail using AUTH authentication, the configuration in Recipe 7.2 should be added to this recipe to create a complete configuration.

See Also

Recipe 7.4 and Recipe 7.5 provide related AUTH configuration examples. The sendmail book covers AUTH configuration in Section 10.9. See the sysadmin.html file in the SASL documentation directory for additional information about SASL configuration.

7.2. Authenticating with AUTH

Problem

You have been asked to configure sendmail to use AUTH authentication when sending mail.

Solution

Make sure that the SASL libraries are installed and that sendmail is compiled with SASL support. See Recipe 1.5 and this chapter’s Introduction if your system lacks either of these necessary components.

Add the host’s authentication credentials to the access database using an AuthInfo: tag. Use the u: parameter to define the SASL authorization ID, the I: parameter to define the SASL authentication ID, the P: parameter to define the shared secret, the R: parameter to define the SASL realm, and the M: parameter to request an AUTH mechanism. Because the AuthInfo: entry contains a password written in clear text, it is important to make sure that the access database is only readable by root.

Create a sendmail configuration containing the access_db feature. Here is the required FEATURE macro:

dnl Use the access database for AUTH credentials
FEATURE(`access_db')

Following the instructions in Recipe 1.8, rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail, and restart sendmail.

Discussion

To successfully authenticate, a host must be able to provide the receiving system with valid security credentials. These credentials are stored on the connecting host in the access database using the AuthInfo: tag. Here is an example of adding an AuthInfo: entry to the access database:

# cd /etc/mail
# cat >> access
               AuthInfo:chef.wrotethebook.com "U:crab" "I:crab" "P:It'sasecret!" "R:wrotethebook
.com" "M:DIGEST-MD5"
Ctrl-D
# makemap hash access < access
# chmod 600 access access.db

The components of this access database entry are, as follows:

AuthInfo:

This is the access database tag. It identifies this entry as containing information used for authentication with the AUTH protocol.

chef.wrotethebook.com

The name of the remote system that will accept these credentials immediately follows the tag. The security credentials in this example are used by the local host to authenticate itself when it connects to chef.wrotethebook.com. The remote system can also be identified by IP address, although the hostname is more commonly used. If this field is empty (i.e., if no host is defined), the credentials are used for authentication when connecting to any system that advertises AUTH for which there is no specific AuthInfo: entry.

U:crab

The U: parameter defines the SASL authorization id, which is also called the user id. The authorization id is used to grant privileges on the remote system. If no value is provided for U:, sendmail uses the value assigned to I: as the default value for U:. See Introduction for more information about the SASL userid, which is also called the authorization id.

I:crab

The I: parameter defines the authentication id. This is the account name used during the authentication process. The authentication id is the name that is associated with the password in the sasldb file on the receiving system. If no value is provided for I:, sendmail uses the value assigned to U: as the default value for I:. Because U: and I: reference each other for default values, at least one of these values must be included in the AuthInfo: entry. See Introduction for more information about the SASL authid.

P:It'sasecret!

The P: parameter defines the password. In the example, the password is It'sasecret!. The password assigned to the P: parameter must match the password assigned to the authentication id in the sasldb file on the receiving host. This value is the shared-secret used for authentication.

R:wrotethebook.com

The R: parameter identifies the SASL realm. This value must match the SASL realm assigned to the authentication id in the sasldb file on the receiving host. Recipe Recipe 7.1 shows how the SASL realm is assigned to the authentication id on the receiving host using the -u argument of the saslpasswd command. If no value is provided for the R: parameter, sendmail uses the value returned by $j as the SASL realm. ($j contains the fully qualified domain name of the local host.)

M:DIGEST-MD5

The M: parameter identifies the authentication technique that will be used. If no value is provided for M:, the AUTH protocol selects the “best” authentication technique that is available on both systems.

The authentication values defined by the AuthInfo: entry on the sending system must agree with those defined on the receiving system by saslpasswd. If any one of the values does not agree, authentication fails with the following error message:

500 5.7.0 authentication failed

Send mail to the remote host to test the AUTH credentials. Call sendmail with the -v option in order to watch the protocol interactions. Here is a sample test:

$ sendmail -Am -v -t
               To: [email protected]
               From: [email protected]
               Subject: Test

               Please ignore.
Ctrl-D
[email protected]... Connecting to chef.wrotethebook.com. via esmtp...
220 chef.wrotethebook.com ESMTP Sendmail 8.12.9/8.12.9; Tue, 7 Jan 2003 13:25:58 -
0500
>>> EHLO crab.wrotethebook.com
250-chef.wrotethebook.com Hello IDENT:iE/rw7zeTz25z3Y8g3qLEbb5uGQ8RtyH@crab [192.168.
0.15], pleased to meet you
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-SIZE
250-DSN
250-AUTH DIGEST-MD5 CRAM-MD5
250 HELP
>>> AUTH DIGEST-MD5 =
334 bm9uY2U9ImFZcjB6VERCSWNBYUpFTVhNWGg2THQ5VllPW1kNS1zZXNz
>>> dXNlcm5hbWU9ImNyYWlnIixyZWFsbT0id3JvdGV0aGVib29ryZmU3OTI3NzEzYTg5MGJjZQ==
334 cnNwYXV0aD0zYzMyMTc5YzhiMTQwYzQzNWJiNTgwOTZmOGZjYTQ4Mg==
>>>
235 2.0.0 OK Authenticated
>>> MAIL From:<[email protected]> SIZE=97 [email protected]
250 2.1.0 <[email protected]>... Sender ok
>>> RCPT To:<[email protected]>
250 2.1.5 <[email protected]>... Recipient ok
>>> DATA
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 h07IPxt01997 Message accepted for delivery
[email protected]... Sent (h07IPxt01997 Message accepted for delivery)
Closing connection to chef.wrotethebook.com.
>>> QUIT
221 2.0.0 chef.wrotethebook.com closing connection

In addition to the -v option, this test invokes sendmail with -t and -Am. -t tells sendmail to obtain the recipient address from any To:, CC:, and Bcc: lines in the message. (In the example, we specified the recipient with a To: line in the message.) The first five lines after the sendmail command is our test message, which is terminated by a Ctrl-D end-of-file mark. The -Am option tells sendmail to run as an MTA, using the sendmail.cf configuration. If this option is not specified, sendmail runs as a message submission program (MSP), uses the submit.cf configuration, and displays the interaction between the user’s sendmail command and the local system. Because we want to watch the MTA interaction between our system and a remote system, we need to use the -Am option.[2]

Every line after the Ctrl-D is output from sendmail. Output lines that start with >>> are SMTP commands coming from the sending system. Lines that start with a numeric response code come from the receiving system.

The local system sends an EHLO command. In response, the remote system displays the list of extended commands that it supports. One of these tells the local host that the remote system supports AUTH and that it offers two authentication techniques, DIGEST-MD5 and CRAM-MD5. The local host sends an AUTH command requesting the DIGEST-MD5 technique to authenticate the connection. The endpoints exchange MD5 challenges and responses, and the remote system displays the message:

235 2.0.0 OK Authenticated

After that message, the mail delivery proceeds normally. The only effect that the recipient might notice is the addition of the word “authenticated” to the mail’s Received: header, as shown below:

Received: from crab.wrotethebook.com
    (IDENT:iE/rw7zeTz25z3Y8g3qLEbb5uGQ8RtyH@crab [192.168.0.15])
        (authenticated)
        by chef.wrotethebook.com (8.12.9/8.12.9) with ESMTP id
    h07IPxt01997
        for <[email protected]>; Tue, 7 Jan 2003 13:25:59 -0500

The tests show that the AuthInfo: entry in the access database works and provides sendmail with the correct information to authenticate the local host to the remote host. However, versions of sendmail prior to sendmail 8.12 cannot store authentication information in the access database. On these older systems, AUTH security credentials are stored in a separate file. The file must be identified in the sendmail m4 configuration using the confDEF_AUTH_INFO define. For example, the following line added to the sendmail configuration tells sendmail that the SASL credentials are stored in a file named /etc/mail/default_auth_info:

define(`confDEF_AUTH_INFO', `/etc/mail/default_auth_info')

The confDEF_AUTH_INFO define is deprecated and should not be used with sendmail 8.12 or later versions of sendmail. In fact, it is ignored when added to a sendmail 8.12 configuration that also includes either the access_db feature or the authinfo feature.[3] Versions of sendmail before 8.12, however, do use the confDEF_AUTH_INFO file and do not support the AuthInfo: tag for the access database. If you have an older version of sendmail, upgrade to the latest version as described in Chapter 1. You should only use the deprecated file if you have an old version of sendmail that you cannot upgrade. A sample /etc/mail/default_auth_info file created for the confDEF_AUTH_INFO define shown above might contain:

crab
crab
It'sasecret!
wrotethebook.com
DIGEST-MD5

The first line defines the authorization identity, which is equivalent to the U: value in the access database. The second line defines the authentication identity, which is equivalent to the I: value. The third line contains the password, which is the P: value in the access database. The fourth line defines the SASL realm, which is the access database R: value. The fifth line specifies the authentication mechanism that should be used, which is equivalent to the M: value in the access database. (This fifth line is only useful with sendmail versions starting with 8.12; prior versions of sendmail will ignore it.) The file pointed to by confDEF_AUTH_INFO contains only one set of credentials that are used for authentication with all remote systems—the access database permits you to define different credentials for each remote host. The access database is superior and should be used if at all possible.

This recipe configures AUTH for outbound connections. Recipe 7.1 configures inbound connections. Use saslpasswd as described in Recipe 7.1 to configure the passwords for systems that connect to your sendmail system. Use Authinfo: entries in the access database to configure the password your system uses when it connects to an external host. Combine these two recipes when your host both accepts inbound AUTH connections and makes outbound AUTH connections.

See Also

Recipe 7.3 provides an alternative way to configure AUTH credentials. Evaluate Recipe 7.3 before implementing this recipe. Recipe 1.5 covers compiling sendmail with SASL support. The access database is used and discussed in Chapter 3 and Chapter 6. The sendmail book covers the AuthInfo: tag in Section 10.9.3.2 and the confDEF_AUTH_INFO define in Section 24.9.27.

7.3. Storing AUTH Credentials in the authinfo File

Problem

Security requirements make it necessary for you to store AUTH authentication credentials in a file separate from the access database.

Solution

Create the /etc/mail/authinfo file. Store the client’s authentication credentials in that file using the same AuthInfo: tag used in the access database. Make sure that the authinfo text file and database are not readable by anyone except root.

Add the authinfo feature to the sendmail configuration. Here are the lines that should be added to the sendmail configuration:

dnl Use the authinfo database for AUTH credentials
FEATURE(`authinfo')

Following the guidance of Recipe 1.8, rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail, and restart sendmail.

Discussion

An alternative to defining the AUTH credentials in the access database is to define the credentials in a separate file named /etc/mail/authinfo. The primary reason for doing this is file security. AUTH passwords are stored in the access database and in the authinfo file as clear text. Because the access database holds a wide variety of information, there is a remote possibility that you might grant multiple users read access to that file. If, for some reason, you do grant users other than root read access to the access database, move the AuthInfo: entries from the access database to the authinfo file, and add the authinfo feature to the sendmail configuration. The authinfo feature simply tells sendmail to lookup authentication credentials in the authinfo database instead of in the access database. Here is an example of creating an authinfo file:

# cd /etc/mail
# cat > authinfo
               AuthInfo:chef.wrotethebook.com "U:crab" "I:crab" "P:It'sasecret!" "R:wrotethebook.
com" "M:DIGEST-MD5"
               Ctrl-D
# makemap hash authinfo < authinfo
# chmod 600 authinfo authinfo.db

Entries in the authinfo database are the standard AuthInfo: entries used in the access database. The entries have the same format and contain the same information. The Discussion section of Recipe 7.2 provides details of the AuthInfo: entry format.

Using this recipe’s configuration, run the sendmail -Am -v -t test shown in the Discussion of Recipe 7.2. Again the message:

235 2.0.0 OK Authenticated

is displayed, indicating that sendmail successfully authenticated the local host to the remote system without using the access database. You can prove the access database was not used with a simple sendmail -bt test:

# sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> /map access AuthInfo:rodent.wrotethebook.com
Map named "access" not found
> /map authinfo AuthInfo:rodent.wrotethebook.com
map_lookup: authinfo (AuthInfo:chef.wrotethebook.com) returns "U:crab" "I:crab" "P:
It'sasecret!" "R:wrotethebook.com" "M:DIGEST-MD5" (0)
> /quit

This test shows that the access database does not exist, yet the system was successfully authenticated. Clearly this is because the AuthInfo: entries are stored in the authinfo database. Of course, this is just an example. On a real system, you will have both the access database and the authinfo database. The only reasons to use the authinfo database are to separate the authentication data from the other data already stored in the access database and to secure that data so that the clear text passwords it contains cannot be easily read. In the example above, we were only able to read the authinfo database because we ran the sendmail -bt command as root.

This recipe assumes that the system has the necessary SASL support. If your system does not, see Introduction for information on obtaining the SASL libraries, and see Recipe 1.5 for information on recompiling sendmail with SASL support before attempting to implement this recipe.

See Also

Recipe 7.2 provides an alternative way to configure AUTH credentials, which should be evaluated before implementing this recipe. Recipe 7.2 also provides information about the format and content of AuthInfo: entries. Recipe 1.5 covers compiling sendmail with SASL support, and Chapter 1 provides general information about compiling sendmail. The sendmail book covers the AuthInfo: tag in Section 10.9.3.2 and the authinfo feature in Section 10.9.3.

7.4. Limiting Advertised Authentication Mechanisms

Problem

Several different SASL authentication techniques are configured for various uses. You wish to control which authentication techniques are advertised for SMTP AUTH authentication.

Solution

Add the confAUTH_MECHANISMS define to the sendmail configuration. Use the define to list only those authentication techniques that you wish to advertise. Here is a sample confAUTH_MECHANISMS define that might be added to the sendmail configuration:

dnl Define the acceptable AUTH mechanisms
define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5')

Build the new sendmail configuration file, copy it to /etc/mail/sendmail.cf, and restart sendmail, as described in Recipe 1.8.

Discussion

The confAUTH_MECHANISMS define sets the values assigned to the sendmail.cf AuthMechanisms option. sendmail advertises any SASL authentication technique listed in the AuthMechanisms option that is configured and running on the local host. The AuthMechanisms comment in a basic sendmail.cf file shows the default list of authentication techniques used by sendmail:

$ grep AuthMechanisms generic-linux.cf
#O AuthMechanisms=EXTERNAL GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5

By default, sendmail will advertise:

  • EXTERNAL, if an external security mechanism, such as TLS, is configured and running.

  • GSSAPI, if the local host is operational as a Kerberos 5 client.

  • KERBEROS_V4, if the local host is operational as a Kerberos 4 client.

  • DIGEST-MD5, if the sasldb database is configured.

  • CRAM-MD5, if the sasldb database is configured.

The receiving host advertises the available authentication techniques, but the connecting host selects the technique that will be used. Therein lies the problem. It is possible for the connecting host to select a technique that you really don’t want to use for SMTP authentication, unless you explicitly specify the advertised techniques using the confAUTH_MECHANISMS define. For example:

# telnet rodent smtp
Trying 192.168.0.3...
Connected to rodent.
Escape character is '^]'.
220 rodent.wrotethebook.com ESMTP Sendmail 8.12.9/8.12.9; Fri, 22 Aug 2003 12:01:37 -
0400
ehlo chef
250-rodent.wrotethebook.com Hello IDENT:/tNy4XlJuCgfwrxksOjP9e2Hm3dZuOiC@chef [192.
168.0.8], pleased to meet you
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-SIZE
250-DSN
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5
250 HELP
quit
221 2.0.0 rodent.wrotethebook.com closing connection
Connection closed by foreign host.

This telnet test shows that rodent.wrotethebook.com advertises Kerberos 5 as a technique that can be used for SMTP authentication. If the connecting system is a Kerberos 5 client, it may choose this technique to authenticate itself, which is all well and good if the administrator of rodent really wants to use Kerberos 5 for SMTP authentication. If not, the confAUTH_MECHANISMS define shown in the Solution section can be used to limit the list of advertised authentication techniques. After installing that confAUTH_MECHANISMS define on rodent, it displays the following line in its EHLO response:

250-AUTH DIGEST-MD5 CRAM-MD5

The confAUTH_MECHANISMS define can also be used to increase the list of advertised authentication techniques. For example, the default SASL configuration on a Red Hat Linux system includes PLAIN and LOGIN as well as DIGEST-MD5 and CRAM-MD5. If the administrator of a Red Hat system placed the following confAUTH_MECHANISMS define in the sendmail configuration:

define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5 PLAIN LOGIN')

the server would display the following advertisement in its EHLO response:

250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN

In most cases, this is not a good thing to do. PLAIN and LOGIN are not secure authentication techniques, and they should not be used with sendmail over an unsecured link. PLAIN sends clear text passwords over the network—where they are vulnerable to snooping. LOGIN implements nonstandard, undocumented, and unsupported authentication techniques used by older, broken SMTP clients, and it also sends clear text passwords. These techniques should only be used if the link itself is encrypted to prevent password snooping.

See Also

Recipe 7.1 and Recipe 7.5 provide related AUTH configuration examples. The sendmail book covers AUTH configuration in Section 10.9 and the confAUTH_MECHANISMS define in 24.9.5.

7.5. Using AUTH to Permit Relaying

Problem

You have been asked to configure a mail relay host that cannot rely on IP addresses or hostnames to grant relaying privileges.

Solution

Compile sendmail with AUTH support as described in Recipe 1.5. Install and configure SASL as described in the chapter Introduction and in Recipe 7.1.

Add the TRUST_AUTH_MECH macro to the sendmail configuration to list the authentication mechanisms trusted to authorize relaying. Here is a sample TRUST_AUTH_MECH macro that could be added to the sendmail configuration:

dnl List mechanisms trusted to authorize relaying
TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5')

Build the new sendmail configuration file, copy it to /etc/mail/sendmail.cf, and restart sendmail with the new configuration. See the example in Recipe 1.8.

Discussion

AUTH authentication sets a variety of macros that can be examined by sendmail and used inside sendmail.cf rulesets. (Several of these macros are discussed in Introduction.) However, AUTH authentication does not grant special privileges. An authenticated host that is not granted relaying privileges by traditional means will have its mail rejected by sendmail if it attempts to relay mail. The following excerpt from an SMTP exchange shows this:

235 2.0.0 OK Authenticated
>>> MAIL From:<[email protected]> SIZE=96 [email protected]
250 2.1.0 <[email protected]>... Sender ok
>>> RCPT To:<[email protected]>
550 5.7.1 <[email protected]>... Relaying denied

The 235 response shows that the connecting host has been successfully authenticated. The 550 response shows that, regardless of authentication, the host is not granted relaying privileges.

Use the TRUST_AUTH_MECH macro to permit relaying by AUTH authenticated clients. The TRUST_AUTH_MECH macro adds the $={TrustAuthMech} class to the sendmail.cf file and defines the values for that class. The TRUST_AUTH_MECH example shown in the Solution section adds the following line to the sendmail.cf file:

C{TrustAuthMech}DIGEST-MD5 CRAM-MD5

The $={TrustAuthMech} class is used in the Rcpt_ok ruleset to authorize relaying. This test is added to the standard group of relaying tests. A host that is granted relaying privileges based on its IP address or hostname is allowed to relay even if it is not authenticated by AUTH. A host that would normally be denied relaying, however, is allowed to relay if it is authenticated by AUTH using one of the techniques listed in the $={TrustAuthMech} class.

The “Relaying denied” error shown at the start of this discussion occurred when chef attempted to relay mail addressed to crab through rodent. rodent is not configured to allow any relaying from external clients. After the TRUST_AUTH_MECH macro was added to the configuration on rodent, mail sent from chef to crab through rodent produced a different result, as the test below shows:

# sendmail -Cauth.cf -v -t
               To: [email protected]
               From: [email protected]
               Subject: Relay test with auth

               Please ignore.
Crtl-D
[email protected]... Connecting to rodent.wrotethebook.com. via relay...
220 rodent.wrotethebook.com ESMTP Sendmail 8.12.9/8.12.9; Wed, 8 Jan 2003 19:14:35 -
0500
>>> EHLO chef.wrotethebook.com
250-rodent.wrotethebook.com Hello IDENT:ntwzejGL8kWjSvERN8B101kmvotCXzx9@chef [192.
168.0.8], pleased to meet you
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-SIZE
250-DSN
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5
250 HELP
>>> AUTH DIGEST-MD5 =
334 bm9uY2U9ImdScXZhVjVxYkpVdjJvU3FGWnR2UXJtR2hFhtPW1kNS1zZXNz
>>> dXNlcm5hbWU9ImNoZWYiLHJlYWxtPSJ3cm90ZXRoZWJvb2YWMwZDIxM2QyYmE2MTVmZjY5
334 cnNwYXV0aD0zNzg3ZGI3N2E0M2YyYzhhMDdkZGRiYjg5N2NjNDkxOQ==
>>>
235 2.0.0 OK Authenticated
>>> MAIL From:<[email protected]> SIZE=96 [email protected]
250 2.1.0 <[email protected]>... Sender ok
>>> RCPT To:<[email protected]>
250 2.1.5 <[email protected]>... Recipient ok
>>> DATA
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 h090EZh01410 Message accepted for delivery
[email protected]... Sent (h090EZh01410 Message accepted for delivery)
Closing connection to rodent.wrotethebook.com.
>>> QUIT
221 2.0.0 rodent.wrotethebook.com closing connection

For this test, a special AUTH configuration was created on chef that defined rodent as the SMART_HOST relay. Without this special configuration, chef would just deliver the mail directly to crab—we want to test relaying through rodent.

In this case, chef is authenticated using the DIGEST-MD5 technique. This technique is listed in the $={TrustedAuthMech} class on rodent. Therefore, rodent accepts mail from chef for relaying.

See Also

Recipe 7.1 and Recipe 7.4 provide additional AUTH configuration examples. How relaying is controlled through the traditional means of IP address and hostname is covered in Chapter 3, and the SMART_HOST define is discussed in Recipe Recipe 3.2. The sendmail book covers AUTH configuration in Section 10.9 and the TRUST_AUTH_MECH macro in Section 10.9.3.

7.6. Controlling the AUTH= Parameter

Problem

Because some broken SMTP implementations see the AUTH= parameter as a syntax error, you have decided to configure sendmail to add the AUTH= parameter to the MAIL From: line only when authentication succeeds.

Solution

If these steps have not yet been done, compile sendmail with AUTH support as described in Recipe 1.5, and install and configure SASL as described in the chapter Introduction and in Recipe 7.1.

Next, create the AUTH credentials for outbound connections, using either the techniques described in Recipe 7.2 or Recipe 7.3.

Add a confAUTH_OPTIONS define with the A flag set to the sendmail configuration. The required define is:

dnl Send AUTH= only when authenticated
define(`confAUTH_OPTIONS', `A')

Rebuild and install the new sendmail.cf file, and restart sendmail, as shown in Recipe 1.8.

Discussion

Use the A option of the confAUTH_OPTIONS define to prevent sendmail from adding the AUTH= parameter to the envelope sender address when the local host has not been authenticated. sendmail does not send an AUTH= parameter to a remote system if that system does not advertise AUTH. But, by default, a sendmail system that is configured to support AUTH adds the AUTH= parameter to every mail message sent to a system that advertises AUTH, even if authentication fails, as this excerpt from an actual SMTP exchange shows:

500 5.7.0 authentication failed
>>> MAIL From:<[email protected]> SIZE=111 [email protected]
250 2.1.0 <[email protected]>... Sender ok

In fact, sendmail adds the AUTH= parameter to the MAIL From: line even if authentication is not attempted. If the remote host advertises AUTH, a sendmail host configured for AUTH always sends the AUTH= parameter. In the following test, rodent offers AUTH mechanisms not configured on chef. Therefore, chef does not attempt to authenticate, but because it is configured for other AUTH mechanisms, chef sends the AUTH= parameter:

# sendmail -Am -v -t
               To: [email protected]
               From: [email protected]
               Subject: Test yet again

               Ctrl-D
[email protected]... Connecting to rodent.wrotethebook.com. via esmtp...
220 rodent.wrotethebook.com ESMTP Sendmail 8.12.9/8.12.9; Fri, 10 Jan 2003 13:52:32 -
0500
>>> EHLO chef.wrotethebook.com
250-rodent.wrotethebook.com Hello IDENT:UZFl3RUw1vRsWKcZqcKAEudx69KnFn37@chef [192.
168.0.8], pleased to meet you
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-SIZE
250-DSN
250-AUTH DIGEST-MD5 CRAM-MD5
250 HELP
>>> MAIL From:<[email protected]> SIZE=92 [email protected]
250 2.1.0 <[email protected]>... Sender ok
>>> RCPT To:<[email protected]>
250 2.1.5 <[email protected]>... Recipient ok
>>> DATA
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 h0AIqW501445 Message accepted for delivery
[email protected]... Sent (h0AIqW501445 Message accepted for delivery)
Closing connection to rodent.wrotethebook.com.
>>> QUIT
221 2.0.0 rodent.wrotethebook.com closing connection

Setting the A option with the confAUTH_OPTIONS define changes this behavior: sendmail does not add the AUTH= parameter unless authentication succeeds. This excerpt shows that AUTH= is not added when authentication fails:

500 5.7.0 authentication failed
>>> MAIL From:<[email protected]> SIZE=111
250 2.1.0 <[email protected]>... Sender ok

However, if authentication succeeds, the AUTH= parameter is still added to the MAIL From: line, as this excerpt shows:

235 2.0.0 OK Authenticated
>>> MAIL From:<[email protected]> SIZE=111 [email protected]
250 2.1.0 <[email protected]>... Sender ok

The AUTH= parameter is propagated on to the next mail relay if the receiving host trusts the AUTH= parameter that it received from the connecting host. sendmail only trusts that parameter if the connecting host was authenticated. The trust_auth ruleset is passed the AUTH= parameter and determines whether this value should be trusted. You can modify the way that the server handles the AUTH= parameter by writing your own Local_trust_auth ruleset.

See Also

Recipe 7.2 and Recipe 7.3 provide additional information on configuring AUTH. The sendmail book covers the AUTH= parameter in Section 21.9.6 and the confAUTH_OPTIONS define in Section 24.9.6.

7.7. Avoiding Double Encryption

Problem

You have a system that is configured for both external encryption and SASL security. On those occasions when strong external encryption is in use, you want to avoid using AUTH encryption.

Solution

Create a sendmail configuration that sets the maximum amount of encryption with the confAUTH_MAX_BITS define. Set the maximum number of encryption bits to a value less than the number of bits used by the external encryption; for example, setting this define to 128 turns off AUTH encryption when the transport layer is already encrypted with TLS. The following lines added to the sendmail configuration turns off AUTH encryption when other encryption is used:

dnl Disable double encryption
define(`confAUTH_MAX_BITS', `128')

Build and install sendmail.cf, and then restart sendmail, as shown in Recipe 1.8.

Discussion

This recipe assumes that AUTH is configured as described in Recipes Recipe 7.1 and Recipe 7.2 and that STARTTLS is configured as described in Chapter 8.

The confAUTH_MAX_BITS define creates the AuthMaxBits option in the sendmail.cf file and assigns a value to that option. For example:

O AuthMaxBits=128

This option tells sendmail that SASL encryption added to any existing encryption should not exceed 128-bits of encryption. Since any existing external encryption will provide at least 128-bits of encryption, this option turns off SASL encryption when the link is already encrypted.

Chapter 8 describes how TLS is used to encrypt the mail transport. When the link is encrypted by an external mechanism, such as TLS, there is no need to add a second layer of encryption with SASL. It is also possible to specify EXTERNAL on the list of advertised authentication techniques using the confAUTH_MECHANISMS define. Doing this avoids adding a second layer of unneeded authentication to a link that has been authenticated by an external protocol, such as TLS.

See Also

Recipe 7.4 covers the confAUTH_MECHANISMS define. The sendmail book covers confAUTH_MAX_BITS in Section 24.9.4.

7.8. Requiring Authentication

Problem

You have an internal mail system that is not advertised to the outside world and never provides service to the outside world. You have been asked to configure that system to always require strong authentication from connecting hosts.

Solution

Create a basic AUTH configuration as described in Recipe 7.1 and Recipe 7.2.

Add to the sendmail configuration a DAEMON_OPTIONS macro that specifies the M=a modifier to require AUTH authentication. Adding the following lines requires AUTH for any connection on the SMTP port:

dnl Require AUTH for all incoming SMTP connections
DAEMON_OPTIONS(`Name=MTA, M=a')

Build the sendmail.cf file, copy it to /etc/mail/sendmail.cf, and restart sendmail. Use Recipe 1.8 as a guide.

Discussion

Use the DAEMON_OPTIONS macro on systems running sendmail 8.12. Prior to sendmail 8.12, daemon port options were set using the confDAEMON_OPTIONS define. confDAEMON_OPTIONS is no longer valid. Attempting to use it with a current release of sendmail produces the following build error:

WARNING: confDAEMON_OPTIONS is no longer valid.
        Use DAEMON_OPTIONS(  ); see cf/README.

If you have an older version of sendmail that uses the confDAEMON_OPTIONS define, we recommend upgrading to a newer version of sendmail. The DAEMON_OPTIONS macro provides more configuration features.

The DAEMON_OPTIONS macro adds values to a sendmail.cf DaemonPortOptions statement or inserts a new DaemonPortOptions statement into the sendmail.cf file. A basic sendmail.cf configuration includes two DaemonPortOptions statements—one for the message submission agent (MSA) and one for the mail transfer agent (MTA). A grep of the generic-linux.cf file shows this:

# grep DaemonPortOptions generic-linux.cf
O DaemonPortOptions=Name=MTA
O DaemonPortOptions=Port=587, Name=MSA, M=E

The DAEMON_OPTIONS macro in the Solution section adds a modifier to the message transfer agent DaemonPortOptions statement, creating the following sendmail.cf command:

O DaemonPortOptions=Name=MTA, M=a

The fact that the MTA is being modified is made clear by the Name=MTA parameter. However, even if that parameter was not specified, the MTA would have been modified because the Port value defaults to smtp, which is the port used by the MTA. To add the a modifier to the MSA configuration, the default MSA configuration needs to be removed with the no_default_msa feature, and the DAEMON_OPTIONS macro needs to explicitly refer to the MSA. For example:

FEATURE(`no_default_msa')
DAEMON_OPTIONS(`Port=587, Name=MSA, M=Ea')

The key = value pairs of the DaemonPortOptions statement select optional characteristics for the sendmail daemon’s ports. key can be any of the following:

Name

An arbitrary, internal name used to identify the daemon. Two values are pre-defined: MSA for the message submission agent and MTA for the message transmission agent.

Port

The port number or the name of a well-known port defined in the /etc/services file. This defaults to smtp, which is the name for port 25 used by the MTA. The standard port used for an MSA is 587.

Addr

The IP address of the network interface on which the daemon should listen for email connections. This defaults to INADDR_ANY, which matches every network interface installed on the system, meaning that email is accepted on every network interface. If an interface is identified with the Addr key, mail is only accepted on that interface, which can have unintended consequences. For example, adding Addr=192.168.0.3 to the MTA DaemonPortOptions on the host 192.168.0.3 would mean that mail from the local host to itself would be rejected because the localhost interface is 127.0.0.1—not 192.168.0.3.

Family

The address family, which is either inet or inet6. It defaults to inet.

Listen

The maximum number of pending connections allowed in the listen queue. The default is operating system dependent, but, on our sample Linux system, it defaults to 10.

SndBufSize

The size of the TCP send buffer in bytes.

RcvBufSize

The size of the TCP receive buffer in bytes.

M

The modifier, which is a flag that selects optional behavior for the interface or port. The modifier flags are:

a

Causes sendmail to require authentication for every inbound connection.

b

Tells sendmail to bind to the interface through which the incoming mail was received when sending outgoing mail.

c

Enables hostname canonification.

f

Requires fully qualified hostnames on email addresses.

u

Permits unqualified sender addresses, meaning that the hostname part of the sender address is not required.

A

Disables AUTH authentication for this port.

C

Disables hostname canonification.

E

Disables the SMTP ETRN command.

O

Marks the socket as optional. Normally, sendmail listens on a new socket for every DaemonPortOptions statement defined in the sendmail.cf file. When O is specified, the socket is ignored if it fails to open correctly.

S

Do not allow STARTTLS on this interface. Chapter 8 covers STARTTLS.

By default, a system configured as described in Recipe 7.1 offers authentication, but it does not require it. A simple telnet test of a system running the basic AUTH configuration from Recipe 7.1 shows this:

# telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 chef.wrotethebook.com ESMTP Sendmail 8.12.9/8.12.9; Fri, 22 Aug 2003 12:01:37 -
0400
ehlo localhost
250-chef.wrotethebook.com Hello IDENT:QQqOd8VZzdwOiABzBr3HvETLtxcEaPg1@localhost 
[127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5
250-DELIVERBY
250 HELP
MAIL From:<[email protected]>
250 2.1.0 <[email protected]>... Sender ok
RCPT TO:<[email protected]>
250 2.1.5 <[email protected]>... Recipient ok
QUIT
221 2.0.0 chef.wrotethebook.com closing connection
Connection closed by foreign host.

The default configuration advertises the AUTH protocol, but it allows the mail connect to continue even though the connecting host does not authenticate itself. This is not just the default, it is also a requirement of the AUTH standard. If a mail system is advertised to the outside world, it cannot require authentication. Specifically, mail exchangers are forbidden to require authentication. The reason is simple. MX records advertise the mail exchanger as available for mail delivery. It cannot then refuse the mail for which it advertises.

Only mail hosts that are not advertised to the outside world are permitted to require authentication. An example of such a system might be a corporate mail relay located behind a firewall. This recipe could be used on such a system.

Rerunning the telnet test, after the DaemonPortOptions modifier is installed, shows the following result:

# telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 chef.wrotethebook.com ESMTP Sendmail 8.12.9/8.12.9; Fri, 22 Aug 2003 12:01:37 -
0400
ehlo localhost
250-chef.wrotethebook.com Hello IDENT:DXXGyJYPz7FDqe1dqRJVCgvxLAaoFgWP@localhost 
[127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5
250-DELIVERBY
250 HELP
MAIL From:<[email protected]>
530 5.7.0 Authentication required
QUIT
221 2.0.0 chef.wrotethebook.com closing connection
Connection closed by foreign host.

In this case, when the connecting host attempts to start a mail dialogue without authentication, an “Authentication required” error is issued.

The limitation of the DAEMON_OPTIONS macro is that it applies to all inbound connections. If more flexibility is required by your configuration, see Recipe 7.9.

See Also

Recipe 7.1 and Recipe 7.2 cover basic AUTH configuration. The sendmail book covers the DAEMON_OPTIONS macro in Section 24.9.24. See TCP/IP Network Administration, Third Edition, by Craig Hunt (O’Reilly), for information on well-known ports and the /etc/services file.

7.9. Selectively Requiring Authentication

Problem

You have a mail host that cannot be configured to require strong authentication from every connecting host, yet you have been asked to configure that system to always require strong authentication from certain connecting hosts.

Solution

Make sure that the basic AUTH configuration requirements described in Recipe 7.1 are met.

Create Srv_Features: access database entries for all hosts that are required to authenticate using AUTH. The key field of each entry begins with the tag Srv_Features:, which is followed by the domain name, hostname, or IP address that identifies the system that is required to authenticate itself. The return value of each entry is the letter l.

Add the access_db feature to the sendmail configuration. Here is the required FEATURE macro:

dnl Enable the access database
FEATURE(`access_db')

Following the instructions in Recipe 1.8, rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail, and restart sendmail.

Discussion

Srv_Features: access database entries allow you to control the extended features offered to the connecting host based on the domain name or IP address of the connecting host. The syntax of the Srv_Features: entry is:

Srv_Features:name     
               flags

Srv_Features: is the required tag. name is the name of the connecting host, which can be defined by a full or partial domain name or a full or partial IP address. A full domain name or IP address matches a single host. A partial domain name matches all hosts in that domain, and a partial IP address matches all hosts on the specified network. When the name field is blank, the entry applies to all inbound mail connections that do not have a more specific Srv_Features: match. The precedence of matches is from the longest (the most specific) to the shortest (the least specific).

The flags field is a list of one or more single-letter flags that indicate whether an extended service should be enabled or disabled for the specified connecting host. When the flags field contains more than one flag, the individual flags are separated by whitespace. A lowercase letter in the flags field enables an SMTP extension, and an uppercase letter disables the extension. All of the flags, except t, come in upper/lower case pairings. Table 7-2 lists the letters that enable and disable SMTP extensions.

Table 7-2. Srv_Features: flags

Yes

No

Description

a

A

Advertise AUTH.

b

B

Advertise the VERB command.

d

D

Advertise the DSN extension.

e

E

Advertise the ETRN command.

l

L

Require AUTH authentication from the connecting host.

p

P

Advertise PIPELINING.

s

S

Advertise STARTTLS.

t

Defer the connection with a temporary error.

v

V

Request a client certificate from the connecting host.

x

X

Advertise the EXPN command.

The a/A flag and the l/L flag are the flags that relate directly to the AUTH protocol extension. In particular, this recipe uses the l flag to selectively require authentication. For example, assume that you want to require AUTH authentication from any host connecting from the dialin.wrotethebook.com domain. You could do that by adding the following entry to the access database:

Srv_Features:dialin.wrotethebook.com      l

Now, a connection attempt from any host in the dialin.wrotethebook.com domain is refused if the host does not authenticate. All other hosts, however, are still allowed to connect without authenticating because there are no other Srv_Features: entries in the access database that relate to AUTH authentication. AUTH is still advertised to all hosts, and any host that chooses to is allowed to authenticate because that is the default sendmail behavior. In the absence of an applicable Srv_Features: entry, the default sendmail behavior applies. This is exactly what we want for this recipe, but it can be more clearly documented in the access database by using two entries instead of the one shown above:

Srv_Features:dialin.wrotethebook.com      l
Srv_Features:                             L

In this case, authentication is still required from the hosts in the dialin.wrotethebook.com domain. But this time, we explicitly show that we do not require authentication from anyone else by using a Srv_Features: entry with a blank name field and an L flag.

This configuration could be taken a step further. Using the A flag in the second Srv_Features: entry would prevent sendmail from advertising AUTH to any hosts except those in the dialin.wrotethebook.com domain. Here is that variation:

Srv_Features:dialin.wrotethebook.com      l
Srv_Features:                             L A

In this case, hosts outside of the dialin.wrotethebook.com domain are not required to authenticate and are not even given a chance to do so.

See Also

Recipe 7.1 describes the basic configuration that needs to be done before this recipe is implemented. The sendmail book covers the Srv_Features: entry in Section 19.9.4.


[1] In addition to these four special items, SASL uses a password when one is required by the authentication technique.

[2] Older versions of sendmail do not use submit.cf configuration and do not have, or need, the -Am commandline option.

[3] It is possible to force sendmail 8.12 to use the file pointed to by confDEF_AUTH_INFO by editing the sendmail.cf file and deleting the authinfo ruleset. But this is not recommended.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.149.26.246