sendmail 8.12

Last Update 2004-08-11

Introduction

sendmail 8.12 aims at higher performance and better security.

sendmail 8.12.11 is available (2004-01-18).

sendmail 8.12.10 is available (2003-09-17). Unfortunately we were forced to release this version early without having a chance to coordinate with vendors that distribute sendmail.

Notice To achieve better security than the default installation you should consider enabling the RunAsUser option as explained in the operations guide. Even though this option restricts some functionality and requires (for conventional (V7) mailboxes) a set-user-ID root local delivery agent (e.g., procmail or mail.local), it greatly enhances the overall security of the mail system because sendmail will not run as root in all cases where it deals with external input.

Notice Only sendmail 8.12.7 and newer work with Berkeley DB 4.1.25 (you can't use earlier versions of either).

Problems and Patches

Note: the patches below are not needed for sendmail 8.12.10 or newer!

libmilter

New Features

sendmail 8.12 has several new features which are listed in the RELEASE_NOTES. In the following some of them are explained.

Most important of all: sendmail is not set-user-ID root anymore. See sendmail/SECURITY for details.

To deal with broken MTAs it is possible to turn off STARTTLS (and other features) on a per host basis using the tagged entries in the access map. For the server, you can use:

Srv_Features:some.domain flags

where flags can be a (comma or space separated) list of the following characters:
A Do not offer AUTH
P Do not offer PIPELINING
S Do not offer STARTTLS
V Do not request a client certificate in STARTTLS
Generally upper case characters turn off a feature while lower case characters turn it on.

STARTTLS related

sendmail 8.12 allows more control over the use of STARTTLS. In addition to the features of 8.11, a new tag TLS_Rcpt has been introduced that controls STARTTLS on a per-recipient basis instead of per-host. Furthermore, there can be a list of extensions. Such a list starts with + and the items are separated by ++. Allowed extensions are:
CN:name name must match ${cn_subject}
CN ${server_name} must match ${cn_subject}
CS:name name must match ${cert_subject}
CI:name name must match ${cert_issuer}
Example: e-mail send to secure.example.com should only use an encrypted connection. e-mail received from hosts within the laptop.example.com domain should only be accepted if they have been authenticated. The host which receives e-mail for darth@endmail.org must present a cert that uses the CN smtp.endmail.org.
TLS_Srv:secure.example.com ENCR:112
TLS_Clt:laptop.example.com PERM+VERIFY:112
TLS_Rcpt:darth@endmail.org ENCR:112+CN:smtp.endmail.org

The STARTTLS related part of the Received: header has been changed:

(version=${tls_version} cipher=${cipher} bit=${cipher_bits}  verify=${verify})

AUTH related

If sendmail acts as client, it needs some information how to authenticate against another MTA. This information can be provided by the ruleset authinfo. The authinfo ruleset looks up {server_name} using the tag AuthInfo: in the access map. If no entry is found, {server_addr} is looked up in the same way and finally just the tag AuthInfo: to provide default values.

The RHS for an Auth: entry in the access map should consists of a list of tokens, each of which has the form: "TDstring" (including the quotes). T is a tag which describes the item, D is a delimiter, either ':' for simple text or '=' for a base64 encoded string. Valid values for the tag are:
U user (authorization) id
I authentication id
P password
R realm
M list of mechanisms delimited by spaces

Example entries are:

AuthInfo:other.dom "U:user" "I:user" "P:secret" "R:other.dom" "M:DIGEST-MD5"
AuthInfo:more.dom "U:user" "P=c2VjcmV0"

User or authentication id must exist as well as the password. All other entries have default values. If one of user or authentication id is missing, the existing value is used for the missing item. Realm defaults to $j and the list of mechanisms to those specified by AuthMechanisms.

Since this map contains sensitive information, either the access map must be unreadable by everyone but root (or the trusted user) or FEATURE(`authinfo') must be used which provides a separate map. Notice: It is not checked whether the map is actually group/world-unreadable, this is left to the user.

Notice: the default configuration file causes the option DefaultAuthInfo to fail since the ruleset authinfo is in the .cf file. If you really want to use DefaultAuthInfo (it is deprecated) then you have to remove the ruleset.

Misc

A first version of a TUNING guide is available. Please send feedback to me.


[(links)] [Hints] [Avoiding UBE] [cf/README] [New]
Copyright © Claus Aßmann Please send comments to: <ca at sendmail.org>
Disclaimer: the information provided may be inaccurate or outdated or incomplete. Please contact me if you find an error.