Recipe 8.10 Requiring TLS for a Recipient

Problem

You have been asked to ensure that encryption and authentication are used for mail addressed to specific recipients.

Solution

Install OpenSSL and recompile sendmail with STARTTLS support as described in the Introduction and in Recipe 1.6 and Recipe 1.7.

Use TLS_Rcpt : access database entries to define those recipients that require TLS security and to specify the level of security required. The key field of each entry contains the tag TLS_Rcpt : and the full or partial address of the recipient. The return value defines the level of security required, and it can be either the keyword ENCR :, followed by the number of bits of encryption required, or the keyword VERIFY , optionally followed by a number of bits of encryption.

Add the access_db feature and the STARTTLS defines to the sendmail configuration. Here are sample lines that could be added to the configuration:

 dnl Point to the CA certificate directory define(`confCACERT_PATH', `/etc/mail/certs') dnl Point to the root CA's certificate define(`confCACERT', `/etc/mail/certs/cacert.pem') dnl Point to the certificate used for inbound connections define(`confSERVER_CERT', `/etc/mail/certs/cert.pem') dnl Point to the private key used for inbound connections define(`confSERVER_KEY', `/etc/mail/certs/key.pem') dnl Point to the certificate used for outbound connections define(`confCLIENT_CERT', `/etc/mail/certs/cert.pem') dnl Point to the private key used for outbound connections define(`confCLIENT_KEY', `/etc/mail/certs/key.pem') dnl Enable the access database FEATURE(`access_db') 

Rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail , and restart sendmail. See Recipe Recipe 1.8 for an example.

Discussion

The TLS_Clt : and TLS_Srv : access database entries used in Recipe 8.7, Recipe 8.8, and Recipe 8.9 enforce minimum TLS security requirements based on the name or address of the remote host. sendmail checks for ${client_name} and ${client_addr} in TLS_CLT : entries for inbound connections, and for ${server_name} and ${server_addr} in TLS_Srv : entries for outbound connections. These entries ensure that connections between the specified remote hosts and local host are secured, but these entries do not guarantee that mail addressed to a specific user will be secure. There is no guarantee because mail can reach recipients over multiple paths ”some of which may be secured and others may not. Look at some sample MX records:

 wrotethebook.com.     IN MX     10  chef.wrotethebook.com. wrotethebook.com.     IN MX     20  rodent.wrotethebook.com. wrotethebook.com.     IN MX     30  mail.example.com. 

Given these three MX records, mail bound for [e-mail] could go over a connection to chef , rodent , or mail.example.com . Assume that chef and rodent have STARTTLS support but that mail.example.com does not. Mail sent from our system to [e-mail] would be encrypted if the delivery connection was made to chef or rodent , but the mail would be sent as clear text if the connection was made to mail.example.com . We don't run mail.example.com , so we can't change the way it is configured ”what we can do is ensure that mail sent to [e-mail] only goes via an adequately encrypted connection. The following TLS_Rcpt : entry ensures that mail is only sent to [e-mail] if the remote host has presented a verified certificate and the link is using 168-bit encryption:

 TLS_Rcpt:[e-mail]     VERIFY:168 

The basic format of the TLS_Rcpt : entry is:

 TLS_Rcpt:   recipient     requirements   +   suffix   ++   suffix   

The string TLS_Rcpt : is the required tag for this database record. recipient is the full or partial email address of the recipient. The recipient address can be:

• A full address in the format user @ host.domain . This format matches a specific user on a specific host. TLS_Rcpt: craig @crab.wrotethebook.com is an example.

• A hostname in the format host.domain ; e.g., TLS_Rcpt:crab.wrotethebook.com . Any user on the specified host is matched.

• A domain name to match every user on every host in the specified domain. For example, TLS_Rcpt:wrotethebook.com would match every recipient in the wrotethebook.com domain.

• A username written in the form user @ ; e.g., TLS_Rcpt:craig@ . This format matches any recipient with the specified username on any host in any domain.

• A blank field, which matches every possible recipient address. This format is used to define a default security requirement for all outbound mail.

The requirements field defines the minimum security requirements that must be met before mail is sent to the recipient. The keyword ENCR or VERIFY can be used in the requirements field to require a level of encryption or a verified certificate. For example ENCR:168 requires a minimum of 168-bit encryption, although it does not require a verified certificate from the remote server. The VERIFY keyword does require a verified certificate and optionally can be combined with a numeric value to also require a level of encryption. For example, VERIFY:168 requires a verified certificate from the remote server and 168-bit encryption on the link. Recipe 8.7, Recipe 8.8, and Recipe 8.9 provide examples of the ENCR and VERIFY keywords. The sample TLS_Rcpt : entry just shown uses VERIFY:168 to require authentication and encryption.

The impact of the sample entry is seen when mail addressed to [e-mail] is routed to the backup MX server mail.example.com :

 #  sendmail -Am -v -t   To: [e-mail]   From: [e-mail]   Subject: Test TLS_Rcpt  :  Ctrl-D  [e-mail]... Connecting to mail.example.com. via esmtp... 220 mail.example.com ESMTP Sendmail 8.12.9/8.12.9; Wed, 5 Feb 2003 15:33:02 -0500 >>> EHLO wrotethebook.net 250-mail.example.com Hello IDENT:24znrK/hAUFBK67n3St2d8DU/5bqb70s@chef [192.168.10. 8], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 250-DELIVERBY 250 HELP >>> MAIL From:<[e-mail]> SIZE=92 AUTH=[e-mail] 250 2.1.0 <[e-mail]>... Sender ok [e-mail]... Deferred >>> RSET 250 2.0.0 Reset state Closing connection to mail.example.com. >>> QUIT 221 2.0.0 mail.example.com closing connection 

The backup MX server mail.example.com does not offer the STARTTLS service in its response to the EHLO command. Therefore, the client does not issue a STARTTLS command. Instead, the client issues the MAIL From : command. The client then checks for a TLS_Rcpt : entry in the access database, finds it, and terminates the session with the message:

 [e-mail] ... Deferred 

This message indicates that the mail has been queued and will be sent again during the next queue run, which means that sendmail is treating this delivery problem as a temporary error. By default, most TLS connection problems are treated as temporary failures. You can change by using the TLS_PERM_ERR define in the master configuration file, or you can override the default for a specific TLS_Rcpt : entry by adding PERM+ to the entry. For example, the following entry would make the failure shown above a permanent failure:

 TLS_Rcpt:[e-mail]     PERM+VERIFY:168 

However, it is not a good idea to make this a permanent failure. Failures caused by TLS_Rcpt : entries should be temporary failures. The failure happened because the connection went to a backup MX server that doesn't support STARTTLS. When the mail is resent during the queue run, it will probably go to the primary MX server, which does have STARTTLS, and therefore, the mail will be successfully delivered. Making the failure permanent undermines the error recovery potential inherent in the sendmail queue process. It is more likely that you would use TEMP+ to make the failure temporary if, for some reason, the default for TLS failures had been set to permanent using the TLS_PERM_ERR define. Recipe 8.7, Recipe 8.8, and Recipe 8.9 cover TLS_PERM_ERR , PERM+ , and TEMP+ .

The other access database entries covered in this chapter also use the ENCR :, VERIFY :, PERM+ , and TEMP+ keywords. However, the TLS_Rcpt : record has more options than these other access entries. The requirements field of the TLS_Rcpt : entry can be followed by one or more optional values. These options are called suffixes because they are added to the TLS_Rcpt : record after the ENCR or VERIFY keyword. The first suffix is added after a single plus sign ( + ), and subsequent suffixes are added with two plus signs ( ++ ). The possible suffixes are:

CN : name

The CN option checks the common name (CN) of the subject from the certificate presented by the server. sendmail holds the CN of the subject in the macro ${cn_subject} . If name is provided, the value of name must match the value stored in the ${cn_subject} macro. If name is left blank, the value returned by ${cn_subject} must match the value returned by ${server_name} . The macro ${server_name} holds the hostname of the remote host to which the client is currently connected, as determined by a reverse domain lookup of the IP address used by TCP for the current connection.

CS : name

The CS option compares name against the value returned by ${cert_subject} . The macro ${cert_subject} holds the distinguished name from the Subject field of the certificate presented by the remote server. The DN and name must match.

CI : name

The CI option compares name against the value returned by ${cert_issuer} . The macro ${cert_issuer} holds the distinguished name from the Issuer field of the certificate presented by the remote server. The value in ${cert_issuer} and the value in the name field must match.

Here is a sample TLS_Rcpt : entry with multiple suffixes: ^[4]

^[4] This is one long line with no line breaks.

 TLS_Rcpt:[e-mail] VERIFY:168+CN++CI:/C=US/ST=Maryland/L=Gaithersburg/ O=WroteTheBook/CN=chef.wrotethebook.com/ 

This TLS_Rcpt : entry requires 168-bit encryption and a verified certificate from the remote host. The common name of the subject of the certificate must be the hostname of the server at the other end of the current connection, and the certificate must be signed by the private CA created on chef.wrotethebook.com in Recipe 8.1.

The various options available for the TLS_Rcpt : entry make it possible to handle most potential situations. Yet, it is also possible to create a custom ruleset to do your own TLS_Rcpt : processing using the Local_tls_rcpt ruleset hook.

See Also

Recipe 8.7, Recipe 8.8, and Recipe 8.9 show examples of related access database entries, and Recipe 8.5 and Recipe 8.6 describe other ways the access database is used with STARTTLS. The sendmail book covers ${cn_subject} in Section 21.9.24, ${server_name} in 21.9.84, ${cert_subject} in 21.9.15, ${cert_issuer} in 21.9.13, and TLS_Rcpt : in 10.10.8.2.