SMTP AUTH in sendmail 8.10/8.11

Last Update 2000-09-24

[Terminology] [Installation] [Configuration] [Operation] [Misc]

Introduction

sendmail 8.10/8.11 support SMTP AUTH as defined in RFC 2554 which is based on SASL. This document describes the necessary steps for installation and operation of this feature with sendmail 8.10 and later versions.

(2000-03-23) If you use sendmail 8.10.0 as client for SMTP AUTH, please read the security warning.

Terminology

SASL defines two terms which are important in this context: authorization identifier and authentication identifer.

authorization identifier (userid): The userid is the identifier an application uses to check whether operations are allowed (authorized).
authentication identifer (authid): The authentication identifier is the identifier that is being used to authenticate the client. That is, the authentication credentials of the client contain the authentication identifier. This can be used for a proxy server to act as (proxy for) another user.

Installation

Cyrus SASL

Get, compile, and install cyrus-sasl (current (2000-07-21) version: 1.5.24). Read the docs which come with it (as well as README and INSTALL).

Make sure the libraries are installed in a location which sendmail uses on your system by default. The libraries must be "safe", i.e., they should be owned by root and only writable by that user. As usual, the whole path must be safe too.

Next, create a configuration file called Sendmail.conf if needed/wanted.

Create a sasldb password file using saslpasswd if you use any mechanism (CRAM-MD5, DIGEST-MD5, PLAIN if pwcheck_method: sasldb is used in the .conf file) that requires it. BTW: sendmail requires sasldb to be owned by root or the trusted user and not be readable by anyone else since the file contains sensitive data (shared secrets). If there is a conflict with other applications that need to read it too, you can try a trick.

Compile sendmail

Compile sendmail with the correct options, i.e., add

APPENDDEF(`confENVDEF', `-DSASL')
APPENDDEF(`conf_sendmail_LIBS', `-lsasl')

to your site.config.m4 (or OS specific) file in devtools/Site. You maybe need to set:
APPENDDEF(`confLIBDIRS', `-L/PATH/TO/SASL/lib')
APPENDDEF(`confINCDIRS', `-I/PATH/TO/SASL/include')
(obviously you have to replace /PATH/TO/SASL/ with the path on your system) if you haven't installed sasl in a location where the Build tool looks for include and library files. However, this may cause problems during runtime, since the sasl library is dynamically loaded, and most OS don't load libraries from "unknown" locations, esp. since sendmail is usually setuid root (and hence LD_LIBRARY_PATH is ignored to avoid security problems).

If you have a SASL library version before 1.5.10, then you should upgrade. Otherwise you have to set the value for SASL to the version number of the SASL library you use, using a simple conversion: a.b.c -> c + b*100 + a*10000, e.g. 1.5.5 -> 10505.
APPENDDEF(`confENVDEF', `-DSASL=10505')

Initial test

Run

sendmail -d0.1 -bv root | grep SASL

and make sure SASL appears in the output. Otherwise go back to compiling sendmail and make sure your site.config.m4 is really used.

Start the sendmail daemon, connect to it and see whether it comes up with

250-AUTH

in the EHLO response:

% telnet localhost 25
Trying 127.0.0.1...
Connected to localhost
Escape character is '^]'.
220 local.sendmail.ORG ESMTP Sendmail 8.10.0/8.10.0; Thu, 9 Sep 1999 10:48:44 -0700 (PDT)
ehlo localhost
250-local.sendmail.ORG Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-DSN
250-AUTH DIGEST-MD5 CRAM-MD5
250 HELP
quit

If it doesn't, check your logfile whether any security problems are listed (unsafe files). If this doesn't reveal any problems, increase the LogLevel to 13 and try again.

Examples of problems in the logfile:

SASL error: listmech=0, num=0
This means the SASL library didn't find any mechanisms. Check your SASL library configuration and installation. Are any libraries installed in /usr/lib/sasl (or wherever you told SASL to be installed)?
Try the examples programs and the saslpasswd utility.
Do the libraries in lib/sasl have the extension .so (HP-UX: .sl) or are there at least links for those files?
```
-rw-r--r--    51240 Mar 11 20:28 libdigestmd5.a
-rwxr-xr-x      894 Mar 11 20:28 libdigestmd5.la*
lrwxr-xr-x       17 Mar 11 20:28 libdigestmd5.so@ -> libdigestmd5.so.0
-rwxr-xr-x    56056 Mar 11 20:28 libdigestmd5.so.0*
```
If not, you may run a script to create the links.
You can also set the environment variable SASL_PATH, see the Cyrus SASL docs. In sendmail, you can use
```
LOCAL_CONFIG
ESASL_PATH=/PATH/TO/lib/sasl
```

Some tips if authentication still fails:

If you have installed a library or another SASL related file and sendmail doesn't seem to use it, do the following: make the file group writable and start
```
sendmail -O LogLevel=14 -bs
EHLO localhost
QUIT
```
and then check the logfile: it must have an error now for that file. If it doesn't, then your configuration is wrong (check your parameters for configure (SASL) and all the paths).
If you want to use DIGEST-MD5 or CRAM-MD5 and it doesn't work despite the previous check, make sure that sasldb actually contains passwords for those mechanism. This can be done by running looking at its content (using strings or od -c) and checking that the names of whose mechanisms appear in the file.
If the authentication still doesn't succeed, check the dialogue and use a base64 decoder (like ed64.c) to get a clear text representation of it. It may give you some hints what's going wrong.

Configuration

There are some options for the .cf (.mc) file which you may want to change from their default values:

AuthMechanisms (confAUTH_MECHANISMS)

defines a list of mechanisms which are offered at most for authentication. This list is intersected with the list of available (i.e., installed) mechanisms, and the result of the intersection is listed in the AUTH keyword value for the EHLO response.
default: GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5

C{TrustAuthMech} (TRUST_AUTH_MECH())

defines a list of mechanisms which are used to allow relaying.

DefaultAuthInfo (confDEF_AUTH_INFO)

specifies a file in which the authorization identity, the authentication identity, the secret, and the realm to be used for authentication are stored. This file must be in a safe directory and unreadable by everyone except root (or TrustedUser). It is used when sendmail acts as a client to authenticate itself to a server. Example:

admin
admin
MySecretPassword
example.domain

Note: all data is case sensitive (usually).
recommended filename: /etc/mail/default-auth-info

Security Warning: sendmail 8.10.0 uses this data when sending e-mail and tries to authenticate against every server that offers SMTP AUTH. This may reveal the secret if the other side offers a plaintext authentication mechanism. Make sure the secret is not a real password used for an account somewhere. sendmail 8.10.1 minimizes this problem.

DaemonPortOptions (DAEMON_OPTIONS())

has now suboptions (called modifiers), one of which is `a'. This tells the daemon to require authentication for all connections to it.

Example for a .mc file (listing only the part relevant for SMTP AUTH):

TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5')dnl
define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5')dnl
define(`confDEF_AUTH_INFO', `/etc/mail/auth/auth-info')dnl
FEATURE(`no_default_msa')dnl turn off default entry for MSA
DAEMON_OPTIONS(`Port=587, Name=MSA, M=Ea')dnl

Operation

SMTP AUTH allows relaying for senders who have successfully authenticated themselves. Per default, relaying is allowed for any user who authenticated via a trusted mechanism, i.e., one that is defined via
TRUST_AUTH_MECH(`list of mechanisms')
This is useful for roaming users and can replace POP-before-SMTP hacks if the MUA supports SMTP AUTH.

The ruleset trust_auth is used to decide whether the client's authentication identifier (authid) is trusted to act as (proxy for) the requested authorization identity (userid). The provided rules allow authid to act for userid if both are identical and they disallow it if the authentication failed. The ruleset Local_trust_auth can be used to provide further tests. As usual, it can either return the error mailer ($# error) to disallow proxying or $# OK to allow proxying.

New macros for SMTP AUTH are {auth_authen}, {auth_author}, and {auth_type}, which hold the client's authentication credentials (authid), the authorization identity (userid) (i.e., the AUTH= parameter of the MAIL command, if supplied), and the mechanism used for authentication.

Misc

MUA?

Now that sendmail provides SMTP AUTHentication, you probably want a MUA that uses it. However, currently there are only a few clients (e.g., MUA) which support SASL. Many MUAs on Unix call sendmail directly, so for roaming users it is sufficient if their sendmail can authenticate itself against the mailserver.

Plain text authentication

Please don't use PLAIN or LOGIN as authentication mechanisms, unless a strong encryption layer, e.g., via STARTTLS or an external SSL tunnel, is active. Quoting RFC 2595

6. PLAIN SASL mechanism

   Clear-text passwords are simple, interoperate with almost all
   existing operating system authentication databases, and are useful
   for a smooth transition to a more secure password-based
   authentication mechanism.  The drawback is that they are unacceptable
   for use over an unencrypted network connection.

If you use it anyway, and you use Netscape as MUA, then in some cases you may want to turn it off; add

user_pref("mail.auth_login", false);

to Netscape's preferences file.

Security Layer

SASL means Simple Authentication and Security Layer. sendmail 8.11 supports the security layer, while sendmail 8.10 only uses the authentication part.

Warning: If you have a Cyrus SASL version older than 1.5.15, make sure you compile the plugins without any encryption, e.g., DIGEST-MD5 without DES etc. sendmail 8.10 does not support encryption within SASL. If the SASL plugins negotiate a security layer, sendmail 8.10 won't be able to talk to the other side if that switches to the encrypted channel. This is a problem with Cyrus SASL which doesn't obey the maximum security settings of sendmail. You may want to apply a patch to plugins/digestmd5.c (1.5.13).

Credits

The implementation of SMTP AUTH in sendmail 8.10 is based on a patch written by Tim Martin of CMU. He and Larry Greenfield also provided valuable feedback during further development and integrated our patches or implemented features we requested.

[(links)] [Hints] [Avoiding UBE] [cf/README] [New]

Disclaimer: the information provided may be inaccurate or outdated or incomplete. Please contact me if you find an error.