<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><style xmlns="" type="text/css"> div.added { background-color: #ffff99; } div.deleted { text-decoration: line-through; background-color: #FF7F7F; } div.changed { background-color: #99ff99; } div.off { } span.added { background-color: #ffff99; } span.deleted { text-decoration: line-through; background-color: #FF7F7F; } span.changed { background-color: #99ff99; } span.off { } pre.literallayout { background-color: #E8E8D0; padding-left: 0.5cm; padding-top: 5px; padding-bottom: 5px; } div[class=changed] pre.literallayout { background-color: #99ff99; padding-left: 0.5cm; padding-top: 5px; padding-bottom: 5px; } div.literallayout { background-color: #E8E8D0; padding-left: 0.5cm; padding-top: 5px; padding-bottom: 5px; } div[class=changed] div.literallayout { background-color: #99ff99; padding-left: 0.5cm; padding-top: 5px; padding-bottom: 5px; } </style><title>33. SMTP authentication</title><meta name="generator" content="DocBook XSL Stylesheets V1.72.0" /><link rel="start" href="index.html" title="Specification of the Exim Mail Transfer Agent" /><link rel="up" href="index.html" title="Specification of the Exim Mail Transfer Agent" /><link rel="prev" href="ch32.html" title="32. Retry configuration" /><link rel="next" href="ch34.html" title="34. The plaintext authenticator" /></head><body><div class="navheader"> <table width="100%" summary="Navigation header"><tr><td width="20%" align="left"><a accesskey="p" href="ch32.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch34.html">Next</a></td></tr></table></div> <div class="chapter" lang="en" xml:lang="en"> <div class="titlepage"> <div> <div> <h2 class="title"><a href="index.html#toc0272" id="CHAPSMTPAUTH">33. SMTP authentication</a></h2></div> </div> </div> <p> <a id="IIDauthconf1" class="indexterm"></a> <a id="IIDauthconf2" class="indexterm"></a> The “<span class="quote">authenticators</span>” section of Exim’s run time configuration is concerned with SMTP authentication. This facility is an extension to the SMTP protocol, described in RFC 2554, which allows a client SMTP host to authenticate itself to a server. This is a common way for a server to 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. </p> <p> <a id="id613058" class="indexterm"></a> Very briefly, the way SMTP authentication works is as follows: </p> <div class="itemizedlist"> <ul type="disc"><li><p> The server advertises a number of authentication <span class="emphasis"><em>mechanisms</em></span> in response to the client’s EHLO command. </p> </li><li><p> The client issues an AUTH command, naming a specific mechanism. The command may, optionally, contain some authentication data. </p> </li><li><p> The server may issue one or more <span class="emphasis"><em>challenges</em></span>, to which the client must send appropriate responses. In simple authentication mechanisms, the challenges are just prompts for user names and passwords. The server does not have to issue any challenges – in some mechanisms the relevant data may all be transmitted with the AUTH command. </p> </li><li><p> The server either accepts or denies authentication. </p> </li><li><p> If authentication succeeds, the client may optionally make use of the AUTH option on the MAIL command to pass an authenticated sender in subsequent mail transactions. Authentication lasts for the remainder of the SMTP connection. </p> </li><li><p> If authentication fails, the client may give up, or it may try a different authentication mechanism, or it may try transferring mail over the unauthenticated connection. </p> </li></ul></div> <p> If you are setting up a client, and want to know which authentication mechanisms the server supports, you can use Telnet to connect to port 25 (the SMTP port) on the server, and issue an EHLO command. The response to this includes the list of supported mechanisms. For example: </p> <div class="literallayout"> <code class="literal">$ </code><span class="bold"><strong><code class="literal">telnet server.example 25</code></strong></span><br /> <code class="literal">Trying 192.168.34.25...</code><br /> <code class="literal">Connected to server.example.</code><br /> <code class="literal">Escape character is '^]'.</code><br /> <code class="literal">220 server.example ESMTP Exim 4.20 ...</code><br /> <span class="bold"><strong><code class="literal">ehlo client.example</code></strong></span><br /> <code class="literal">250-server.example Hello client.example [10.8.4.5]</code><br /> <code class="literal">250-SIZE 52428800</code><br /> <code class="literal">250-PIPELINING</code><br /> <code class="literal">250-AUTH PLAIN</code><br /> <code class="literal">250 HELP</code><br /> </div> <p> The second-last line of this example output shows that the server supports authentication using the PLAIN mechanism. In Exim, the different authentication mechanisms are configured by specifying <span class="emphasis"><em>authenticator</em></span> drivers. Like the routers and transports, which authenticators are included in the binary is controlled by build-time definitions. The following are currently available, included by setting </p> <pre class="literallayout">AUTH_CRAM_MD5=yes AUTH_CYRUS_SASL=yes AUTH_PLAINTEXT=yes AUTH_SPA=yes </pre><p> in <em class="filename">Local/Makefile</em>, respectively. The first of these supports the CRAM-MD5 authentication mechanism (RFC 2195), and the second provides an interface to the Cyrus SASL authentication library. The third 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. The fourth authenticator supports Microsoft’s <span class="emphasis"><em>Secure Password Authentication</em></span> mechanism. </p> <p> The authenticators are configured using the same syntax as other drivers (see section <a href="ch06.html#SECTfordricon" title="6.22 Format of driver configurations">6.22</a>). If no authenticators are required, no authentication section need be present in the configuration file. Each authenticator can in principle have both server and client functions. 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. Authenticator configuration options are provided for use in both these circumstances. </p> <p> To make it clear which options apply to which situation, the prefixes <span><strong class="option">server_</strong></span> and <span><strong class="option">client_</strong></span> are used on option names that 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, a single definition, using both sets of options, is required. For example: </p> <pre class="literallayout">cram: driver = cram_md5 public_name = CRAM-MD5 server_secret = ${if eq{$auth1}{ph10}{secret1}fail} client_name = ph10 client_secret = secret2 </pre><p> The <span><strong class="option">server_</strong></span> option is used when Exim is acting as a server, and the <span><strong class="option">client_</strong></span> options when it is acting as a client. </p> <p> 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 in Exim. </p> <div class="section" lang="en" xml:lang="en"> <div class="titlepage"> <div> <div> <h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0273" id="SECID168">33.1 Generic options for authenticators</a></h3></div> </div> </div> <p> <a id="id613342" class="indexterm"></a> <a id="id613357" class="indexterm"></a> </p> <p> <a id="id613374" class="indexterm"></a> </p> <div class="informaltable"> <table border="1"><colgroup><col align="left" /><col align="center" /><col align="center" /><col align="right" /></colgroup><tbody><tr><td align="left"><span><strong class="option">client_condition</strong></span></td><td align="center">Use: <span class="emphasis"><em>authenticators</em></span></td><td align="center">Type: <span class="emphasis"><em>string</em></span>†<span class="emphasis"><em></em></span></td><td align="right">Default: <span class="emphasis"><em>unset</em></span></td></tr></tbody></table></div> <p> When Exim is authenticating as a client, it skips any authenticator whose <span><strong class="option">client_condition</strong></span> expansion yields “<span class="quote">0</span>”, “<span class="quote">no</span>”, or “<span class="quote">false</span>”. This can be used, for example, to skip plain text authenticators when the connection is not encrypted by a setting such as: </p> <pre class="literallayout">client_condition = ${if !eq{$tls_cipher}{}} </pre><p> (Older documentation incorrectly states that <em class="varname">$tls_cipher</em> contains the cipher used for incoming messages. In fact, during SMTP delivery, it contains the cipher used for the delivery.) </p> <p> <a id="id613498" class="indexterm"></a> </p> <div class="informaltable"> <table border="1"><colgroup><col align="left" /><col align="center" /><col align="center" /><col align="right" /></colgroup><tbody><tr><td align="left"><span><strong class="option">driver</strong></span></td><td align="center">Use: <span class="emphasis"><em>authenticators</em></span></td><td align="center">Type: <span class="emphasis"><em>string</em></span></td><td align="right">Default: <span class="emphasis"><em>unset</em></span></td></tr></tbody></table></div> <p> This option must always be set. It specifies which of the available authenticators is to be used. </p> <p> <a id="id613586" class="indexterm"></a> </p> <div class="informaltable"> <table border="1"><colgroup><col align="left" /><col align="center" /><col align="center" /><col align="right" /></colgroup><tbody><tr><td align="left"><span><strong class="option">public_name</strong></span></td><td align="center">Use: <span class="emphasis"><em>authenticators</em></span></td><td align="center">Type: <span class="emphasis"><em>string</em></span></td><td align="right">Default: <span class="emphasis"><em>unset</em></span></td></tr></tbody></table></div> <p> This option specifies the name of the authentication mechanism that 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 <span><strong class="option">public_name</strong></span> is not set, it defaults to the driver’s instance name. </p> <p> <a id="id613682" class="indexterm"></a> </p> <div class="informaltable"> <table border="1"><colgroup><col align="left" /><col align="center" /><col align="center" /><col align="right" /></colgroup><tbody><tr><td align="left"><span><strong class="option">server_advertise_condition</strong></span></td><td align="center">Use: <span class="emphasis"><em>authenticators</em></span></td><td align="center">Type: <span class="emphasis"><em>string</em></span>†<span class="emphasis"><em></em></span></td><td align="right">Default: <span class="emphasis"><em>unset</em></span></td></tr></tbody></table></div> <p> When a server is about to advertise an authentication mechanism, the condition is expanded. If it yields the empty string, “<span class="quote">0</span>”, “<span class="quote">no</span>”, or “<span class="quote">false</span>”, the mechanism is not advertised. If the expansion fails, the mechanism is not advertised. If the failure was not forced, and was not caused by a lookup defer, the incident is logged. See section <a href="ch33.html#SECTauthexiser" title="33.3 Authentication on an Exim server">33.3</a> below for further discussion. </p> <p> <a id="id613792" class="indexterm"></a> </p> <div class="informaltable"> <table border="1"><colgroup><col align="left" /><col align="center" /><col align="center" /><col align="right" /></colgroup><tbody><tr><td align="left"><span><strong class="option">server_condition</strong></span></td><td align="center">Use: <span class="emphasis"><em>authenticators</em></span></td><td align="center">Type: <span class="emphasis"><em>string</em></span>†<span class="emphasis"><em></em></span></td><td align="right">Default: <span class="emphasis"><em>unset</em></span></td></tr></tbody></table></div> <p> This option must be set for a <span><strong class="option">plaintext</strong></span> server authenticator, where it is used directly to control authentication. See section <a href="ch34.html#SECTplainserver" title="34.2 Using plaintext in a server">34.2</a> for details. </p> <p> For the other authenticators, <span><strong class="option">server_condition</strong></span> can be used as an additional authentication or authorization mechanism that is applied after the other authenticator conditions succeed. If it is set, it is expanded when the authenticator would otherwise return a success code. If the expansion is forced to fail, authentication fails. Any other expansion failure causes a temporary error code to be returned. If the result of a successful expansion is an empty string, “<span class="quote">0</span>”, “<span class="quote">no</span>”, or “<span class="quote">false</span>”, authentication fails. If the result of the expansion is “<span class="quote">1</span>”, “<span class="quote">yes</span>”, or “<span class="quote">true</span>”, authentication succeeds. For any other result, a temporary error code is returned, with the expanded string as the error text. </p> <p> <a id="id613931" class="indexterm"></a> </p> <div class="informaltable"> <table border="1"><colgroup><col align="left" /><col align="center" /><col align="center" /><col align="right" /></colgroup><tbody><tr><td align="left"><span><strong class="option">server_debug_print</strong></span></td><td align="center">Use: <span class="emphasis"><em>authenticators</em></span></td><td align="center">Type: <span class="emphasis"><em>string</em></span>†<span class="emphasis"><em></em></span></td><td align="right">Default: <span class="emphasis"><em>unset</em></span></td></tr></tbody></table></div> <p> If this option is set and authentication debugging is enabled (see the <span><strong class="option">-d</strong></span> command line option), the string is expanded and included in the debugging output when the authenticator is run as a server. This can help with checking out the values of variables. If expansion of the string fails, the error message is written to the debugging output, and Exim carries on processing. </p> <p> <a id="id614029" class="indexterm"></a> </p> <div class="informaltable"> <table border="1"><colgroup><col align="left" /><col align="center" /><col align="center" /><col align="right" /></colgroup><tbody><tr><td align="left"><span><strong class="option">server_set_id</strong></span></td><td align="center">Use: <span class="emphasis"><em>authenticators</em></span></td><td align="center">Type: <span class="emphasis"><em>string</em></span>†<span class="emphasis"><em></em></span></td><td align="right">Default: <span class="emphasis"><em>unset</em></span></td></tr></tbody></table></div> <p> <a id="id614113" class="indexterm"></a> 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 <em class="varname">$authenticated_id</em>. It is also included in the log lines for incoming messages. For example, a user/password authenticator configuration might preserve the user name that was used to authenticate, and refer to it subsequently during delivery of the message. If expansion fails, the option is ignored. </p> <p> <a id="id614140" class="indexterm"></a> </p> <div class="informaltable"> <table border="1"><colgroup><col align="left" /><col align="center" /><col align="center" /><col align="right" /></colgroup><tbody><tr><td align="left"><span><strong class="option">server_mail_auth_condition</strong></span></td><td align="center">Use: <span class="emphasis"><em>authenticators</em></span></td><td align="center">Type: <span class="emphasis"><em>string</em></span>†<span class="emphasis"><em></em></span></td><td align="right">Default: <span class="emphasis"><em>unset</em></span></td></tr></tbody></table></div> <p> This option allows a server to discard authenticated sender addresses supplied as part of MAIL commands in SMTP connections that are authenticated by the driver on which <span><strong class="option">server_mail_auth_condition</strong></span> is set. The option is not used as part of the authentication process; instead its (unexpanded) value is remembered for later use. How it is used is described in the following section. </p> </div> <div class="section" lang="en" xml:lang="en"> <div class="titlepage"> <div> <div> <h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0274" id="SECTauthparamail">33.2 The AUTH parameter on MAIL commands</a></h3></div> </div> </div> <p> <a id="id614250" class="indexterm"></a> <a id="id614264" class="indexterm"></a> When a client supplied an AUTH= item on a MAIL command, Exim applies the following checks before accepting it as the authenticated sender of the message: </p> <div class="itemizedlist"> <ul type="disc"><li><p> If the connection is not using extended SMTP (that is, HELO was used rather than EHLO), the use of AUTH= is a syntax error. </p> </li><li><p> If the value of the AUTH= parameter is “<span class="quote"><></span>”, it is ignored. </p> </li><li><p> <a id="id614308" class="indexterm"></a> If <span><strong class="option">acl_smtp_mailauth</strong></span> is defined, the ACL it specifies is run. While it is running, the value of <em class="varname">$authenticated_sender</em> is set to the value obtained from the AUTH= parameter. If the ACL does not yield “<span class="quote">accept</span>”, the value of <em class="varname">$authenticated_sender</em> is deleted. The <span><strong class="option">acl_smtp_mailauth</strong></span> ACL may not return “<span class="quote">drop</span>” or “<span class="quote">discard</span>”. If it defers, a temporary error code (451) is given for the MAIL command. </p> </li><li><p> If <span><strong class="option">acl_smtp_mailauth</strong></span> is not defined, the value of the AUTH= parameter is accepted and placed in <em class="varname">$authenticated_sender</em> only if the client has authenticated. </p> </li><li><p> If the AUTH= value was accepted by either of the two previous rules, and the client has authenticated, and the authenticator has a setting for the <span><strong class="option">server_mail_auth_condition</strong></span>, the condition is checked at this point. The valued that was saved from the authenticator is expanded. If the expansion fails, or yields an empty string, “<span class="quote">0</span>”, “<span class="quote">no</span>”, or “<span class="quote">false</span>”, the value of <em class="varname">$authenticated_sender</em> is deleted. If the expansion yields any other value, the value of <em class="varname">$authenticated_sender</em> is retained and passed on with the message. </p> </li></ul></div> <p> When <em class="varname">$authenticated_sender</em> is set for a message, it is passed on to other hosts to which Exim authenticates as a client. Do not confuse this value with <em class="varname">$authenticated_id</em>, which is a string obtained from the authentication process, and which is not usually a complete email address. </p> <p> <a id="id614424" class="indexterm"></a> Whenever an AUTH= value is ignored, the incident is logged. The ACL for MAIL, if defined, is run after AUTH= is accepted or ignored. It can therefore make use of <em class="varname">$authenticated_sender</em>. The converse is not true: the value of <em class="varname">$sender_address</em> is not yet set up when the <span><strong class="option">acl_smtp_mailauth</strong></span> ACL is run. </p> </div> <div class="section" lang="en" xml:lang="en"> <div class="titlepage"> <div> <div> <h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0275" id="SECTauthexiser">33.3 Authentication on an Exim server</a></h3></div> </div> </div> <p> <a id="id614466" class="indexterm"></a> When Exim receives an EHLO command, it advertises the public names of those authenticators that are configured as servers, subject to the following conditions: </p> <div class="itemizedlist"> <ul type="disc"><li><p> The client host must match <span><strong class="option">auth_advertise_hosts</strong></span> (default *). </p> </li><li><p> It the <span><strong class="option">server_advertise_condition</strong></span> option is set, its expansion must not yield the empty string, “<span class="quote">0</span>”, “<span class="quote">no</span>”, or “<span class="quote">false</span>”. </p> </li></ul></div> <p> The order in which the authenticators are defined controls the order in which the mechanisms are advertised. </p> <p> Some mail clients (for example, some versions of Netscape) require the user to provide a name and password for authentication whenever AUTH is advertised, even though authentication may not in fact be needed (for example, Exim may be set up to allow unconditional relaying from the client by an IP address check). You can make such clients more friendly by not advertising AUTH to them. For example, if clients on the 10.9.8.0/24 network are permitted (by the ACL that runs for RCPT) to relay without authentication, you should set </p> <pre class="literallayout">auth_advertise_hosts = ! 10.9.8.0/24 </pre><p> so that no authentication mechanisms are advertised to them. </p> <p> The <span><strong class="option">server_advertise_condition</strong></span> controls the advertisement of individual authentication mechanisms. For example, it can be used to restrict the advertisement of a particular mechanism to encrypted connections, by a setting such as: </p> <pre class="literallayout">server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}} </pre><p> <a id="id614562" class="indexterm"></a> If the session is encrypted, <em class="varname">$tls_cipher</em> is not empty, and so the expansion yields “<span class="quote">yes</span>”, which allows the advertisement to happen. </p> <p> When an Exim server receives an AUTH command from a client, it rejects it immediately if AUTH was not advertised in response to an earlier EHLO command. This is the case if </p> <div class="itemizedlist"> <ul type="disc"><li><p> The client host does not match <span><strong class="option">auth_advertise_hosts</strong></span>; or </p> </li><li><p> No authenticators are configured with server options; or </p> </li><li><p> Expansion of <span><strong class="option">server_advertise_condition</strong></span> blocked the advertising of all the server authenticators. </p> </li></ul></div> <p> Otherwise, Exim runs the ACL specified by <span><strong class="option">acl_smtp_auth</strong></span> in order to decide whether to accept the command. If <span><strong class="option">acl_smtp_auth</strong></span> is not set, AUTH is accepted from any client host. </p> <p> If AUTH is not rejected by the ACL, Exim searches its configuration for a server authentication mechanism that was advertised in response to EHLO and that matches the one named in the AUTH command. If it finds one, it runs the appropriate authentication protocol, and authentication either succeeds or fails. If there is no matching advertised mechanism, the AUTH command is rejected with a 504 error. </p> <p> <a id="id614649" class="indexterm"></a> <a id="id614661" class="indexterm"></a> When a message is received from an authenticated host, the value of <em class="varname">$received_protocol</em> is set to “<span class="quote">esmtpa</span>” or “<span class="quote">esmtpsa</span>” instead of “<span class="quote">esmtp</span>” or “<span class="quote">esmtps</span>”, and <em class="varname">$sender_host_authenticated</em> contains the name (not the public name) of the authenticator driver that successfully authenticated the client from which the message was received. This variable is empty if there was no successful authentication. </p> </div> <div class="section" lang="en" xml:lang="en"> <div class="titlepage"> <div> <div> <h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0276" id="SECID169">33.4 Testing server authentication</a></h3></div> </div> </div> <p> <a id="id614715" class="indexterm"></a> <a id="id614729" class="indexterm"></a> <a id="id614744" class="indexterm"></a> Exim’s <span><strong class="option">-bh</strong></span> option can be useful for testing server authentication configurations. The data for the AUTH command has to be sent using base64 encoding. A quick way to produce such data for testing is the following Perl script: </p> <pre class="literallayout">use MIME::Base64; printf ("%s", encode_base64(eval "\"$ARGV[0]\"")); </pre><p> <a id="id614778" class="indexterm"></a> 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 </p> <pre class="literallayout">encode '\0user\0password' </pre><p> Note the use of single quotes to prevent the shell interpreting the backslashes, so that they can be interpreted by Perl to specify characters whose code value is zero. </p> <p> <span class="bold"><strong>Warning 1</strong></span>: If either of the user or password strings starts with an octal digit, you must use three zeros instead of one after the leading backslash. If you do not, the octal digit that starts your string will be incorrectly interpreted as part of the code for the first character. </p> <p> <span class="bold"><strong>Warning 2</strong></span>: If there are characters in the strings that Perl interprets specially, you must use a Perl escape to prevent them being misinterpreted. For example, a command such as </p> <pre class="literallayout">encode '\0user@domain.com\0pas$$word' </pre><p> gives an incorrect answer because of the unescaped “<span class="quote">@</span>” and “<span class="quote">$</span>” characters. </p> <p> If you have the <span><strong class="option">mimencode</strong></span> command installed, another way to do produce base64-encoded strings is to run the command </p> <pre class="literallayout">echo -e -n `\0user\0password' | mimencode </pre><p> The <span><strong class="option">-e</strong></span> option of <span><strong class="option">echo</strong></span> enables the interpretation of backslash escapes in the argument, and the <span><strong class="option">-n</strong></span> option specifies no newline at the end of its output. However, not all versions of <span><strong class="option">echo</strong></span> recognize these options, so you should check your version before relying on this suggestion. </p> </div> <div class="section" lang="en" xml:lang="en"> <div class="titlepage"> <div> <div> <h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0277" id="SECID170">33.5 Authentication by an Exim client</a></h3></div> </div> </div> <p> <a id="id614909" class="indexterm"></a> The <span><strong class="command">smtp</strong></span> transport has two options called <span><strong class="option">hosts_require_auth</strong></span> and <span><strong class="option">hosts_try_auth</strong></span>. When the <span><strong class="command">smtp</strong></span> transport connects to a server that announces support for authentication, and the host matches an entry in either of these options, Exim (as a client) tries to authenticate as follows: </p> <div class="itemizedlist"> <ul type="disc"><li><p> For each authenticator that is configured as a client, in the order in which they are defined in the configuration, it searches the authentication mechanisms announced by the server for one whose name matches the public name of the authenticator. </p> </li><li><p> <a id="id614965" class="indexterm"></a> <a id="id614977" class="indexterm"></a> When it finds one that matches, it runs the authenticator’s client code. The variables <em class="varname">$host</em> and <em class="varname">$host_address</em> are available for any string expansions that the client might do. They are set to the server’s name and IP address. If any expansion is forced to fail, the authentication attempt is abandoned, and Exim moves on to the next authenticator. Otherwise an expansion failure causes delivery to be deferred. </p> </li><li><p> If the result of the authentication attempt is a temporary error or a timeout, Exim abandons trying to send the message to the host for the moment. It will try again later. If there are any backup hosts available, they are tried in the usual way. </p> </li><li><p> If the response to authentication is a permanent error (5<span class="emphasis"><em>xx</em></span> code), Exim carries on searching the list of authenticators and tries another one if possible. If all authentication attempts give permanent errors, or if there are no attempts because no mechanisms match (or option expansions force failure), what happens depends on whether the host matches <span><strong class="option">hosts_require_auth</strong></span> or <span><strong class="option">hosts_try_auth</strong></span>. In the first case, a temporary error is generated, and delivery is deferred. The error can be detected in the retry rules, and thereby turned into a permanent error if you wish. In the second case, Exim tries to deliver the message unauthenticated. </p> </li></ul></div> <p> <a id="id615045" class="indexterm"></a> When Exim has authenticated itself to a remote server, it adds the AUTH parameter to the MAIL commands it sends, if it has an authenticated sender for the message. If the message came from a remote host, the authenticated sender is the one that was receiving on an incoming MAIL command, provided that the incoming connection was authenticated and the <span><strong class="option">server_mail_auth</strong></span> condition allowed the authenticated sender to be retained. If a local process calls Exim to send a message, the sender address that is built from the login name and <span><strong class="option">qualify_domain</strong></span> is treated as authenticated. However, if the <span><strong class="option">authenticated_sender</strong></span> option is set on the <span><strong class="command">smtp</strong></span> transport, it overrides the authenticated sender that was received with the message. <a id="id615088" class="indexterm"></a> <a id="id615098" class="indexterm"></a> </p> </div> </div> <div class="navfooter"> <table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch32.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch34.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div> </body></html>