ONLamp.com: Cooking with sendmail, Part 2

Published on ONLamp.com (http://www.onlamp.com/)
See this if you're having trouble printing code examples

O'Reilly Book Excerpts: sendmail Cookbook

Cooking with sendmail, Part 2

by Craig Hunt

Recipe 8.4: Configuring sendmail for STARTTLS

Problem

You have been asked to configure sendmail to offer STARTTLS service for transport layer security.

Solution

STARTTLS requires that OpenSSL is properly installed and configured. See Introduction for information on installing OpenSSL. It also requires a copy of sendmail compiled with STARTTLS support, as described in Recipe 1.6 and Recipe 1.7. Additionally, the sendmail host needs a certificate if it will be accepting inbound STARTTLS connections. Use OpenSSL to create the certificate, as described in Recipe 8.2 and Recipe 8.3.

Create a sendmail configuration with defines pointing to the files that contain the host's certificate, the host's private key, the root CA certificate file, and the directory where CA certificates are stored. Here are examples of the defines:

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')

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

Discussion

This recipe provides a full STARTTLS configuration. A system configured with all of these defines can act as a TLS server or client and can perform both encryption and authentication. The six defines point sendmail to the files necessary for this full range of service:

confCACERT_PATH
Sets the value for the CACERTPath option in the sendmail.cf file. The CACERTPath option points to the directory in which certificate authority certificates are stored. It is very common for this directory to be the same one that holds the server and client certificates.
confCACERT
Sets the value for the CACERTFile option, which points to the certificate of the root certificate authority. The value provided to this define is the full pathname of the file that holds the CA certificate.
confSERVER_CERT
Sets the value for the sendmail.cf ServerCertFile option, which holds the full pathname of the file containing the server certificate used for inbound conenctions.
confSERVER_KEY
Sets the value for the ServerKeyFile option. The ServerKeyFile option points to the file that holds the server's private key.
confCLIENT_CERT
Sets the value for the sendmail.cf ClientCertFile option, which holds the full pathname of the file containing the client certificate used for inbound connections.
confCLIENT_KEY
Sets the value for the ClientKeyFile option. The ClientKeyFile option points to the file that holds the client's private key.

If OpenSSL is installed, sendmail is compiled with STARTTLS support, and these defines point to valid certificates, sendmail will advertise STARTTLS in response to the SMTP EHLO command. A simple telnet test shows that STARTTLS is ready for use:

# 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:6l4ZhaGP3Qczqknqm/KdTFGsrBe2SCYC@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-STARTTLS
250-DELIVERBY
250 HELP
QUIT
221 2.0.0 chef.wrotethebook.com closing connection
Connection closed by foreign host.

If your system doesn't advertise STARTTLS in response to the EHLO command, check the logfile to make sure that all file permissions are correct. If they are, try increasing the LogLevel to 14 to log additional STARTTLS debugging information. See Recipe 1.10 for information on setting the LogLevel.

This recipe shows a system configured with both client and server certificates and keys. Many systems are configured as both clients and servers for STARTTLS because mail is often forwarded by one system to another. When the system receives inbound mail, it acts as a STARTTLS server. When it forwards that mail on to another system, it acts as a STARTTLS client. Therefore, the system needs to act as both a STARTTLS server and a STARTTLS client. Normally such a system uses the same certificate and key for both its client and server roles.

A STARTTLS client will attempt to use STARTTLS whenever the server offers it. Running the sendmail command with the -v option shows the STARTTLS client side of this sample configuration. An example of this is seen in the following code:

> EHLO rodent.wrotethebook.com
250-chef.wrotethebook.com Hello rodent.wrotethebook.com [192.168.0.3], 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-STARTTLS
250-DELIVERBY
250 HELP
>-t command used above:>

response, the test shows another
>Return-Path: <craig@rodent.wrotethebook.com>
Received: from rodent.wrotethebook.com (rodent.wrotethebook.com
    [192.168.0.3])
        by chef.wrotethebook.com (8.12.9/8.12.9) with ESMTP id h0UGn9P7001230
        (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK)
        for <craig@chef.wrotethebook.com>; Thu, 30 Jan 2003 11:49:10 -0500
Received: (from root@localhost)
        by rodent.wrotethebook.com (8.12.9/8.12.9) id h0UGvpSD010157;
        Thu, 30 Jan 2003 11:57:51 -0500
Date: Thu, 30 Jan 2003 11:57:51 -0500
Message-Id: <200301301657.h0UGvpSD010157@rodent.wrotethebook.com>
To: craig@chef.wrotethebook.com
From: craig@rodent.wrotethebook.com
Subject: First STARTTLS testEHLO<

The "Received": header generated by
EHLOchef.wrotethebook.com<, which is the STARTTLS
server in this exchange, shows the TLS characteristics of the link
over which the mail was received. The header displays the version of
the TLS protocol that was used for the connection, the type of
encryption used for the connection, the number of bits used for the
encryption, and whether the client's certificate was
verified. Because this information is only placed in the header when
TLS is used for the connection, it tells us that the client is
properly configured to use TLS when communicating with this server.STARTTLS>





rodent>

 command,
and the server's TLS ready response are all used to
create the tunnel. The second <See Also>

EHLORecipe 8.2) and issues an > and Recipe 8.3<
cover how certificates -v
command. In response to that command, the server advertises that
STARTTLS is available. The client then issues a
>and keys are created. Chapter 1

" provides additional information on compiling
sendmail. The sendmail" book covers STARTTLS in
Section 10.10.>


>


 .
250 2.0.0 h0UGn9P7001230 Message accepted for delivery
craig@chef.wrotethebook.com... Sent (h0UGn9P7001230 Message accepted for delivery)
Closing connection to chef.wrotethebook.com.
>



-v> >To: craig@chef.wrotethebook.com
From: craig@rodent.wrotethebook.com
Subject: First STARTTLS test

Ctrl-D
craig@chef.wrotethebook.com... Connecting to chef.wrotethebook.com. via esmtp...
220 chef.wrotethebook.com ESMTP Sendmail 8.12.9/8.12.9; Fri, 22 Aug 2003 12:01:37 -
0400
>

The client (rodent) connects to the server (chef) and issues an EHLO command. In response to that command, the server advertises that STARTTLS is available. The client then issues a STARTTLS command to open the TLS connection. The server responds with the message:

220 2.0.0 Ready to start TLS

Immediately after the response, the test shows another EHLO message. Many system administrators are confused by this. Don't be. The STARTTLS negotiation takes place"outside" of the email exchange. STARTTLS creates the encrypted tunnel through which the mail travels. The first EHLO, the server's STARTTLS advertisement, the client's STARTTLS command, and the server's TLS ready response are all used to create the tunnel. The second EHLO command and all that follows it are part of the standard SMTP protocol exchange, which is sent inside the encrypted tunnel. Note that this SMTP protocol exchange is displayed by the sendmail -v command as clear text. The mail stream is only encrypted on the network. Within the end systems, the mail stream is clear text.

The effect of the STARTTLS protocol can be indirectly observed in the headers of the mail message that passed through the encrypted tunnel. The following headers are from the test message sent by the sendmail -Am -v -t command used above:

Return-Path:<craig@rodent.wrotethebook.com>
Received: from rodent.wrotethebook.com (rodent.wrotethebook.com
    [192.168.0.3])
        by chef.wrotethebook.com (8.12.9/8.12.9) with ESMTP id h0UGn9P7001230
        (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK)
        for <craig@chef.wrotethebook.com>; Thu, 30 Jan 2003 11:49:10 -0500
Received: (from root@localhost)
        by rodent.wrotethebook.com (8.12.9/8.12.9) id h0UGvpSD010157;
        Thu, 30 Jan 2003 11:57:51 -0500
Date: Thu, 30 Jan 2003 11:57:51 -0500
Message-Id: <200301301657.h0UGvpSD010157@rodent.wrotethebook.com>
To: craig@chef.wrotethebook.com
From: craig@rodent.wrotethebook.com
Subject: First STARTTLS test

The Received: header generated by chef.wrotethebook.com, which is the STARTTLS server in this exchange, shows the TLS characteristics of the link over which the mail was received. The header displays the version of the TLS protocol that was used for the connection, the type of encryption used for the connection, the number of bits used for the encryption, and whether the client's certificate was verified. Because this information is only placed in the header when TLS is used for the connection, it tells us that the client is properly configured to use TLS when communicating with this server.

Recipe 10.14: Limiting the SMTP Command Set

Problem

You want to disable certain SMTP commands.

Solution

Add the confPRIVACY_FLAGS define to the sendmail configuration to set PrivacyOptions that disable unwanted, optional SMTP commands. This sample define disables the EXPN, VRFY, VERB, and ETRN commands:

dnl Disable EXPN, VRFY, VERB and ETRN
define(`confPRIVACY_FLAGS', `noexpn,novrfy,noverb,noetrn')

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

Discussion

The confPRIVACY_FLAGS define sets PrivacyOptions flags in the sendmail.cf file. One of the things that these flags can do is disable unwanted, optional SMTP commands. By default, sendmail supports the full array of SMTP commands, as this simple test shows:

# sendmail -bs -Cgeneric-linux.cf
220 chef.wrotethebook.com ESMTP Sendmail 8.12.9/8.12.9; Mon, 10 Mar 2003 14:39:47 -0500
EHLO localhost
250-chef.wrotethebook.com Hello root@localhost, 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
EXPN <admin>
250-2.1.5 <anna@crab.wrotethebook.com>
250-2.1.5 <andy@rodent.wrotethebook.com>
250 2.1.5 <jane@rodent.wrotethebook.com>
VRFY <alana>
250 2.1.5 Alana Henson <alana@chef.wrotethebook.com>
QUIT
221 2.0.0 chef.wrotethebook.com closing connection

In response to the EHLO command, the SMTP server lists the SMTP extensions it supports, including optional commands. Some of these commands, VRFY, EXPN, and VERB, provide information that a security-conscious site might not wish to provide:

The VERB command places the SMTP protocol exchange into verbose mode, which provides debugging help but might also reveal information about your site that you would rather not advertise.
The VRFY command verifies an email address and provides additional information about the user at that address. In the example just shown, the system provides the user's real name and the user's full email address.
The EXPN command expands a mailing list and displays the email address of each member of the list, as the test above shows. Intruders and spammers might collect this information and use it against your system.

After reconfiguring sendmail with the confPRIVACY_FLAGS define shown in Recipe 10.14.2, rerunning the test produces very different results:

# sendmail -bs
220 chef.wrotethebook.com ESMTP Sendmail 8.12.9/8.12.9; Mon, 10 Mar 2003 14:47:35 -0500
EHLO localhost
250-chef.wrotethebook.com Hello root@localhost, pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-AUTH DIGEST-MD5 CRAM-MD5
250-DELIVERBY
250 HELP
EXPN <admin>
502 5.7.0 Sorry, we do not allow this operation
VRFY <alana>
252 2.5.2 Cannot VRFY user; try RCPT to attempt delivery (or try finger)
QUIT
221 2.0.0 chef.wrotethebook.com closing connection

Now the server advertises a smaller set of features, and returns errors when the EXPN and VRFY commands are entered.

In addition to the noexpn, novrfy, and noverb flags, the sample define in Recipe 10.14.2 uses the noetrn flag. In the first test, the system advertised the ETRN command. After this recipe is applied, the server no longer advertises or supports that command. ETRN is used by remote systems to cause the server to run the queue. ETRN is an important command for supporting dial-in clients that need to have the queue run while they are online. Our sample system does not support dial-in SMTP clients, so we have disabled the ETRN command to prevent remote sites from forcing the server to run the queue.

The noexpn, novrfy, and noverb flags could all have been set using the goaway flag. The goaway flag sets several flags at once. In addition to the noexpn, novrfy, and noverb flags, the goaway flag sets:

authwarnings

authwarnings tells sendmail to insert X-Authentication-Warnings: headers into the mail whenever it suspects that the message is not authentic. authwarnings is the default PrivacyOptions flag used when the sendmail.cf file is built by m4. If the system administrator directly edits the sendmail.cf file and inserts a PrivacyOptions statement that has no flags set, public becomes the default. public tells sendmail that it should not do any special security checks or SMTP syntax checks.

nobodyreturn

The nobodyreturn flag tells sendmail not to return the original message body when it bounces a message, even if the return is specifically requested with the RET=FULL DSN extension on the MAIL From: SMTP command. noreceipts is a related flag that is not used by goaway. noreceipts causes sendmail to ignore the NOTIFY=SUCCESS DSN extension of the RCPT To: command and to ignore Return-Receipt-To: headers. When noreceipts is used, sendmail does not advertise or support DSN. For this reason, goaway does not set noreceipts, and it is not recommended that you use it either. nobodyreturn only affects the RET=FULL DSN extension; the other DSN features are still available.

needmailhelo, needvrfyhelo, and needexpnhelo

These three flags cause sendmail to require a valid HELO/EHLO command from the client before accepting certain other commands. needmailhelo, needvrfyhelo, and needexpnhelo are used and discussed in Recipe 10.15.

The goaway flag does not set the noetrn flag used in this recipe, nor does it set the public and noreceipts flags described above. Additionally, it does not set the restrictexpand, restrictmailq, and restrictqrun flags. noetrn and noreceipts are not used because they disable features that are, in certain circumstances, very useful. The goaway flag does not use public because it lessens security. restrictexpand, restrictmailq, and restrictqrun are not used because those flags affect who can use certain options on the sendmail command line; they do not affect the SMTP protocol or security interactions with remote systems that are the target of the goaway flag.[8] goaway is a good choice for enhanced sendmail security. However, this recipe shows that individual flags can also be selected to create a custom security configuration.

Even more custom control is available through creating custom rulesets. The rulesets check_vrfy, check_expn, and check_etrn can be used to define custom controls for the VRFY, EXPN, and ETRN commands, respectively. This recipe disables these commands completely.