Sendmail has done it again – proved just how powerful it is, as long as you know what you’re doing.

While investigating the configuration of the ciphers to used by Apache (SSLCipherSuite) and the associated SSLHonorCipherOrder option (to ensure the server’s cipher preference order is used), I realised that although I enable TLS on my Sendmail instances I don’t configure the cipher options. Given I’d spent some time coming up with my preferred cipher order for Apache (unfortunately RC4-SHA is fairly high on the list) I decided I may as well put it in place for other daemons which perform OpenSSL based encryption (Sendmail and IMAP for instance). Given the available Sendmail documentation is light on this subject I had to go digging.

The “standard” encryption related options (enabled with the STARTTLS define at compilation time) for Sendmail are pretty well documented and understood:

There are some other useful options available when the STARTTLS define is combined with the _FFR_TLS_1 define at compile time.


Note: You can determine the compile settings used for your version of Sendmail by running:

sendmail -d0.14 -bt < /dev/null


These four options do not appear to be documented properly anywhere – even the Sendmail source code is pretty light on their configuration syntax and use. The CipherList option is mentioned as an available option on a page titled “Tips and Tricks for Sendmail Hackers“, dated 2006-03-31. There are a few other web pages and blog posts which mention or show one how to use the CipherList option. No mention is made of the remaining three.

These four options are configured in the LOCAL_CONFIG section of your file. The following is an example (which may or may not be suitable for you) of such a section:

O CipherList=HIGH:RC4-SHA:RC4-MD5


The options described:

CipherList : This option configures the available cipher list for encrypted connections. Your cipher list can be tuned by using the openssl ciphers -v command. Stronger ciphers are obviously better. Excluding weak ciphers may mean that very old clients will be unable to connect. Note that with SSLv3 and TLS1.x the client, by default, will select its preferred cipher from the server’s list.

ServerSSLOptions : This option configures the OpenSSL connection flags used for the SSL/TLS connections into Sendmail. By default Sendmail, and most other applications using the OpenSSL library, uses the SSL_OP_ALL composite flag for its connections. This option allows these flags to be altered. The first option to consider using is SSL_OP_CIPHER_SERVER_PREFERENCE. This option causes the server, rather than the client, to choose the cipher based on its preference order. The next option to consider is SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS. This option disables a countermeasure against a SSLv3/TLSv1 protocol vulnerability. This flag disables the countermeasure and is set by default when SSL_OP_ALL is used. Thus, if one wishes to have the vulnerability countermeasure enabled, this flag needs to be disabled. Depending on the clients and servers of your Sendmail instance you may wish to consider the use of SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3 and SSL_OP_NO_TLSv1. Note that the current version of Sendmail does not have support for OpenSSL’s SSL_OP_NO_TLS_v1_1 nor for SSL_OP_NO_TLSv1_2. These two could be quite useful and I have submitted a patch to Sendmail for these to be included. The value of this parameter is used to manipulate the bits passed to OpenSSL. Note that Sendmail starts with a value of SSL_OP_ALL and this option modifies that value – it does not reset it from scratch. You manipulate the value using [+]SSL_OP_XXX to SET the bits and using -SSL_OP_XXX to CLEAR the bits. Thus a value of +SSL_OP_ALL would have no effect (since those bits are already set. A value of -SSL_OP_ALL would result in no bits being set. A useful value might be +SSL_OP_NO_SSLv2 +SSL_OP_CIPHER_SERVER_PREFERENCE.

ClientSSLOptions : This option configures the OpenSSL connection flags used for the SSL/TLS connections initiated by Sendmail. The parameter’s value works the same as for ServerSSLOptions.

DHParameters512 : This option does not appear to actually be used. It is a valid configuration option which will be parsed. However, it appears as if this parameter is not used by the Sendmail source code at all!


As an aside, DHParameters is another odd configuration option. The documentation implies this is a file containing DH paramters. However, the source code in sendmail/tls.c has this to say:

** valid values for dhparam are (only the first char is checked)
** none no parameters: don't use DH
** 512 generate 512 bit parameters (fixed)
** 1024 generate 1024 bit parameters
** /file/name read parameters from /file/name
** default is: 1024 for server, 512 for client (OK? XXX)

So in fact, it is slightly more flexible than the documentation makes out. Note too, that should you wish to use a DH parameter of more than 1024 bits you will need to use an external file.

So with all that said, a useful set of parameters might be:
O CipherList=HIGH:RC4-SHA:RC4-MD5
O ClientSSLOptions=+SSL_OP_NO_SSLv2

So, based on this configuration, we are only using “high” strength ciphers and also two RC4 ciphers. You may want to remove the RC4-MD5 one if you are concerned about MD5’s strength. For maximum compatibility with old clients, you may want to keep it included. We don’t allow SSLv2 and we request that the server (i.e. our Sendmail instance) chooses the mutual cipher.

Hope this helps.

Another useful thing to note, is that when _FFR_TLS_1 is used you can use two certificates and key files for ServerCertFile and ServerKeyFile – with their names separated with simply a , (i.e. a comma and no spaces). This is useful if you have both an RSA and DSA certificate you wish to use. For example, the configured option within would be:

O ServerCertFile=/etc/mail/tls/server-rsa.crt,/etc/mail/tls/server-dsa.crt
O ServerKeyFile=/etc/mail/tls/server-rsa.key,/etc/mail/tls/server-dsa.key

Due to constraints within OpenSSL’s SSL_CTX_use_PrivateKey_file and SSL_CTX_use_certificate_file calls, both certificates should use the same certificate chain. More information can be found on OpenSSL’s website.

8 thoughts on “Configuration of hidden Sendmail SSL/TLS connection options

  1. Hey Mike, related to your nice post:

    “. Note that the current version of Sendmail does not have support for OpenSSL’s SSL_OP_NO_TLS_v1_1 nor for SSL_OP_NO_TLSv1_2. These two could be quite useful and I have submitted a patch to Sendmail for these to be included.”

    Can you share patch with rest of us? 🙂

    • Sure thing. I submitted two patches. The one you are looking for can be found here. The second one which you probably don’t need which I created for completeness is here.


  2. Fabulous post. Incredibly helpful. Thank you!!!

    I find I like this better:

    O CipherList=HIGH:MEDIUM:!aNULL:!eNULL
    O ClientSSLOptions=+SSL_OP_NO_SSLv2

    in combination with OpenSSL 1.0.1e. Google
    selects ECDHE-RSA-RC4-SHA for inbound mail,
    which is vastly superior to RC4-SHA.

    I’m not sure why any EC ciphers are considered
    MEDIUM by the OpenSSL folks, but I’ll take it

  3. This page seems to be the best practice for OpenSSL ciphers:

    Based on that, I’ve added:





Leave a reply

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>