The seventh part of Exim's runtime configuration, following the rewriting configuration, is concerned with SMTP authentication. This is an extension to the SMTP protocol, described in RFC 2554, which allows a client SMTP host to authenticate itself to a server. By this means a server might, for example, recognize clients that are permitted to use it as a relay. SMTP authentication is not of relevance to the transfer of mail between servers that have no managerial connection with each other.
When Exim is receiving SMTP mail, it is acting as a server; when it is sending out messages over SMTP, it is acting as a client. Configuration options are provided for use in both these circumstances. The RFC allows for a number of different `authentication mechanisms'. These are configured by specifying authenticator drivers for Exim. Like the directors, routers, and transports, which authenticators are included in the binary is controlled by build-time definitions. Two are currently available, included by setting
AUTH_CRAM_MD5=yes AUTH_PLAINTEXT=yes
in `Local/Makefile', respectively. The first of these supports the CRAM-MD5 authentication mechanism (RFC 2195), while the second can be configured to support the PLAIN authentication mechanism (RFC 2595) or the LOGIN mechanism, which is not formally documented, but used by several MUAs.
Almost all the code for handling authentication is omitted from Exim unless at least one AUTH_xxx is defined. This includes the code for implementing configuration options such as `auth_hosts'. Attempts to use such options provoke `unknown option' errors when no authentication code is included in the binary.
The authenticators are configured using the same syntax as other drivers (see chapter "Driver specifications"). If none are required, the entire seventh section of the configuration file may be omitted. If at least one authenticator is included in the binary, the contents of the configuration can be obtained by running one of
exim -bP authenticator_list exim -bP authenticators exim -bP authenticator <authenticator name>
Each authenticator can have both server and client functions. To make it clear which options apply to which, the prefixes `server_' and `client_' are used on option names which are specific to either the server or the client function, respectively. Server and client functions are disabled if none of their options are set. If an authenticator is to be used for both server and client functions, then a single definition, using both sets of options, is required. For example:
cram:
driver = cram_md5
public_name = CRAM-MD5
server_secret = ${if eq{$1}{ph10}{secret1}fail}
client_name = ph10
client_secret = secret2
The `server_' option is used when Exim is acting as a server, and the `client_' options when it is acting as a client.
Descriptions of the individual authenticators are given in subsequent chapters. The remainder of this chapter covers the generic options for the authenticators, followed by general discussion of the way authentication works.
Option: driver
Type: string
Default: unset
This option must always be set. It specifies which of the available authenticators is to be used.
Option: public_name
Type: string
Default: unset
This option specifies the name of the authentication mechanism which the driver implements, and by which it is known to the outside world. These names should contain only upper case letters, digits, underscores, and hyphens (RFC 2222), but Exim in fact matches them caselessly. If `public_name' is not set, it defaults to the driver instance's name.
The public names of authenticators that are configured as servers are advertised by Exim when it receives an EHLO command, in the order in which they are defined. When an AUTH command is received, the list of authenticators is scanned in definition order for one whose public name matches the mechanism given in the AUTH command.
Option: server_set_id
Type: string
Default: unset
When an Exim server successfully authenticates a client, this string is expanded using data from the authentication, and preserved for any incoming messages in the variable `$authenticated_id'. It is also included in the log lines for incoming messages. For example, a user/password authenticator configuration might preserve the user name which was used to authenticate, and refer to it subsequently during delivery of the message.
When a message is received from an authenticated host, the value of `$received_protocol' is set to `asmtp' instead of `esmtp', and `$sender_host_authenticated' contains the name (not the public name) of the authenticator driver which successfully authenticated the client from which the message was received. It is empty if there was no successful authentication.
The SMTP AUTH command is accepted from any connected client host. If, however, the client host matches an item in the `auth_hosts' option, then it is required to authenticate itself before any commands other than HELO, EHLO, HELP, AUTH, NOOP, RSET, or QUIT are accepted.
A client that matches an item in `host_auth_accept_relay' is permitted to relay to any domain, provided that it is authenticated, whether or not it matches `auth_hosts'. In other words, an authenticated client is permitted to relay if it matches either `host_accept_relay' or `host_auth_accept_relay', whereas an unauthenticated client host may relay only if it matches `host_accept_relay'.
Two possible common cases are envisaged:
Many variations are possible. For example, in the second case, some hosts could be required to authenticate by making them match `auth_hosts'.
Exim's `-bh' option can be useful for testing server authentication configurations. The data for the AUTH command has to be sent encoded in base 64. A quick way to produce such data for testing is the following Perl script:
use MIME::Base64;
printf ("%s", encode_base64(eval "\"$ARGV[0]\""));
This interprets its argument as a Perl string, and then encodes it. The interpretation as a Perl string allows binary zeros, which are required for some kinds of authentication, to be included in the data. For example, a command line to run this script on such data might be
encode '\0user\0password'
Note the use of single quotes to prevent the shell interpreting the backslashes.
When a client host has authenticated itself, Exim pays attention to the AUTH parameter on incoming SMTP MAIL commands. Otherwise, it accepts the syntax, but ignores the data. Unless the data is the string `<>', it is set as the authenticated sender of the message. The value is available during delivery in the `$authenticated_sender' variable, and is passed on to other hosts to which Exim authenticates as a client. Do not confuse this value with `$authenticated_id', which is a string obtained from the authentication process, and which is not usually a complete email address.
The `smtp' transport has an option called `authenticate_hosts' if Exim is built with authentication support. When the `smtp' transport connects to a server that announces support for authentication, and also matches an entry in `authenticate_hosts', Exim (as a client) tries to authenticate as follows:
When Exim has authenticated itself to a remote server, it adds the AUTH parameter to the MAIL commands it sends, if it has got an authenticated sender for the message. If a local process calls Exim to send a message, the sender address that is built from the login name and qualify domain is treated as authenticated.
Go to the first, previous, next, last section, table of contents.