<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html401/loose.dtd">
<html>
<!-- Created on September, 10 2009 by texi2html 1.78 -->
<!--
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
Karl Berry <karl@freefriends.org>
Olaf Bachmann <obachman@mathematik.uni-kl.de>
and many others.
Maintained by: Many creative people.
Send bugs and suggestions to <texi2html-bug@nongnu.org>
-->
<head>
<title>Specification of the Exim Mail Transfer Agent: 33. SMTP authentication</title>
<meta name="description" content="Specification of the Exim Mail Transfer Agent: 33. SMTP authentication">
<meta name="keywords" content="Specification of the Exim Mail Transfer Agent: 33. SMTP authentication">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="texi2html 1.78">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
pre.display {font-family: serif}
pre.format {font-family: serif}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
pre.smalldisplay {font-family: serif; font-size: smaller}
pre.smallexample {font-size: smaller}
pre.smallformat {font-family: serif; font-size: smaller}
pre.smalllisp {font-size: smaller}
span.roman {font-family:serif; font-weight:normal;}
span.sansserif {font-family:sans-serif; font-weight:normal;}
ul.toc {list-style: none}
-->
</style>
</head>
<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
<a name="SMTP-authentication"></a>
<a name="SEC272"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="spec_32.html#SEC271" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC273" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec_32.html#SEC260" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_34.html#SEC278" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h1 class="chapter"> 33. SMTP authentication </h1>
<p>The "authenticators" 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>
<a name="IDX2411"></a>
<p>Very briefly, the way SMTP authentication works is as follows:
</p>
<ul class="toc">
<li>
The server advertises a number of authentication <em>mechanisms</em> in response to
the client's EHLO command.
</li><li>
The client issues an AUTH command, naming a specific mechanism. The command
may, optionally, contain some authentication data.
</li><li>
The server may issue one or more <em>challenges</em>, 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.
</li><li>
The server either accepts or denies authentication.
</li><li>
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.
</li><li>
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.
</li></ul>
<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>
<table><tr><td> </td><td><pre class="display">$ telnet server.example 25
Trying 192.168.34.25...
Connected to server.example.
Escape character is '^]'.
220 server.example ESMTP Exim 4.20 ...
ehlo client.example
250-server.example Hello client.example [10.8.4.5]
250-SIZE 52428800
250-PIPELINING
250-AUTH PLAIN
250 HELP
</pre></td></tr></table>
<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 <em>authenticator</em> 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>
<table><tr><td> </td><td><pre class="example">AUTH_CRAM_MD5=yes
AUTH_CYRUS_SASL=yes
AUTH_PLAINTEXT=yes
AUTH_SPA=yes
</pre></td></tr></table>
<p>in ‘<tt>Local/Makefile</tt>’, 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 <em>Secure Password Authentication</em> mechanism.
</p>
<p>The authenticators are configured using the same syntax as other drivers (see
section <a href="spec_6.html#SEC78">Format of driver configurations</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
<code>server_</code> and <code>client_</code> 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>
<table><tr><td> </td><td><pre class="example">cram:
driver = cram_md5
public_name = CRAM-MD5
server_secret = ${if eq{$auth1}{ph10}{secret1}fail}
client_name = ph10
client_secret = secret2
</pre></td></tr></table>
<p>The <code>server_</code> option is used when Exim is acting as a server, and the
<code>client_</code> 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>
<table class="menu" border="0" cellspacing="0">
<tr><td align="left" valign="top"><a href="#SEC273">33.1 Generic options for authenticators</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC274">33.2 The AUTH parameter on MAIL commands</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC275">33.3 Authentication on an Exim server</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC276">33.4 Testing server authentication</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC277">33.5 Authentication by an Exim client</a></td><td> </td><td align="left" valign="top">
</td></tr>
</table>
<hr size="6">
<a name="Generic-options-for-authenticators"></a>
<a name="SEC273"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC272" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC274" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC272" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC272" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_34.html#SEC278" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 33.1 Generic options for authenticators </h2>
<table>
<tr><td>
<p><code>client_condition</code></p></td><td><p> Use: <em>authenticators</em></p></td><td><p> Type: <em>string</em>*<em></em></p></td><td><p> Default: <em>unset</em>
</p></td></tr>
</table>
<p>When Exim is authenticating as a client, it skips any authenticator whose
<code>client_condition</code> expansion yields "0", "no", or "false". This can be
used, for example, to skip plain text authenticators when the connection is not
encrypted by a setting such as:
</p>
<table><tr><td> </td><td><pre class="example">client_condition = ${if !eq{$tls_cipher}{}}
</pre></td></tr></table>
<p>(Older documentation incorrectly states that <code>$tls_cipher</code> contains the cipher
used for incoming messages. In fact, during SMTP delivery, it contains the
cipher used for the delivery.)
</p>
<a name="IDX2412"></a>
<table>
<tr><td>
<p><code>driver</code></p></td><td><p> Use: <em>authenticators</em></p></td><td><p> Type: <em>string</em></p></td><td><p> Default: <em>unset</em>
</p></td></tr>
</table>
<p>This option must always be set. It specifies which of the available
authenticators is to be used.
</p>
<a name="IDX2413"></a>
<table>
<tr><td>
<p><code>public_name</code></p></td><td><p> Use: <em>authenticators</em></p></td><td><p> Type: <em>string</em></p></td><td><p> Default: <em>unset</em>
</p></td></tr>
</table>
<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 <code>public_name</code> is not set, it
defaults to the driver's instance name.
</p>
<a name="IDX2414"></a>
<table>
<tr><td>
<p><code>server_advertise_condition</code></p></td><td><p> Use: <em>authenticators</em></p></td><td><p> Type: <em>string</em>*<em></em></p></td><td><p> Default: <em>unset</em>
</p></td></tr>
</table>
<p>When a server is about to advertise an authentication mechanism, the condition
is expanded. If it yields the empty string, "0", "no", or "false", 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="#SEC275">Authentication on an Exim server</a> below for further discussion.
</p>
<a name="IDX2415"></a>
<table>
<tr><td>
<p><code>server_condition</code></p></td><td><p> Use: <em>authenticators</em></p></td><td><p> Type: <em>string</em>*<em></em></p></td><td><p> Default: <em>unset</em>
</p></td></tr>
</table>
<p>This option must be set for a <code>plaintext</code> server authenticator, where it
is used directly to control authentication. See section <a href="spec_34.html#SEC280">Using plaintext in a server</a>
for details.
</p>
<p>For the other authenticators, <code>server_condition</code> 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, "0", "no", or "false", authentication fails. If the result of the
expansion is "1", "yes", or "true", authentication succeeds. For any
other result, a temporary error code is returned, with the expanded string as
the error text.
</p>
<a name="IDX2416"></a>
<table>
<tr><td>
<p><code>server_debug_print</code></p></td><td><p> Use: <em>authenticators</em></p></td><td><p> Type: <em>string</em>*<em></em></p></td><td><p> Default: <em>unset</em>
</p></td></tr>
</table>
<p>If this option is set and authentication debugging is enabled (see the <code>-d</code>
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>
<a name="IDX2417"></a>
<table>
<tr><td>
<p><code>server_set_id</code></p></td><td><p> Use: <em>authenticators</em></p></td><td><p> Type: <em>string</em>*<em></em></p></td><td><p> Default: <em>unset</em>
</p></td></tr>
</table>
<a name="IDX2418"></a>
<p>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 <code>$authenticated_id</code>. 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>
<a name="IDX2419"></a>
<table>
<tr><td>
<p><code>server_mail_auth_condition</code></p></td><td><p> Use: <em>authenticators</em></p></td><td><p> Type: <em>string</em>*<em></em></p></td><td><p> Default: <em>unset</em>
</p></td></tr>
</table>
<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 <code>server_mail_auth_condition</code> 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>
<hr size="6">
<a name="The-AUTH-parameter-on-MAIL-commands"></a>
<a name="SEC274"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC273" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC275" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC272" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC272" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_34.html#SEC278" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 33.2 The AUTH parameter on MAIL commands </h2>
<p>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>
<ul class="toc">
<li>
If the connection is not using extended SMTP (that is, HELO was used rather
than EHLO), the use of AUTH= is a syntax error.
</li><li>
If the value of the AUTH= parameter is "<>", it is ignored.
</li><li>
<a name="IDX2420"></a>
If <code>acl_smtp_mailauth</code> is defined, the ACL it specifies is run. While it is
running, the value of <code>$authenticated_sender</code> is set to the value obtained
from the AUTH= parameter. If the ACL does not yield "accept", the value of
<code>$authenticated_sender</code> is deleted. The <code>acl_smtp_mailauth</code> ACL may not
return "drop" or "discard". If it defers, a temporary error code (451) is
given for the MAIL command.
</li><li>
If <code>acl_smtp_mailauth</code> is not defined, the value of the AUTH= parameter
is accepted and placed in <code>$authenticated_sender</code> only if the client has
authenticated.
</li><li>
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
<code>server_mail_auth_condition</code>, 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, "0", "no", or "false", the value of
<code>$authenticated_sender</code> is deleted. If the expansion yields any other value,
the value of <code>$authenticated_sender</code> is retained and passed on with the
message.
</li></ul>
<p>When <code>$authenticated_sender</code> 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
<code>$authenticated_id</code>, which is a string obtained from the authentication
process, and which is not usually a complete email address.
</p>
<a name="IDX2421"></a>
<p>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 <code>$authenticated_sender</code>. The converse is not true: the
value of <code>$sender_address</code> is not yet set up when the <code>acl_smtp_mailauth</code>
ACL is run.
</p>
<hr size="6">
<a name="Authentication-on-an-Exim-server"></a>
<a name="SEC275"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC274" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC276" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC272" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC272" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_34.html#SEC278" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 33.3 Authentication on an Exim server </h2>
<p>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>
<ul class="toc">
<li>
The client host must match <code>auth_advertise_hosts</code> (default *).
</li><li>
It the <code>server_advertise_condition</code> option is set, its expansion must not
yield the empty string, "0", "no", or "false".
</li></ul>
<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>
<table><tr><td> </td><td><pre class="example">auth_advertise_hosts = ! 10.9.8.0/24
</pre></td></tr></table>
<p>so that no authentication mechanisms are advertised to them.
</p>
<p>The <code>server_advertise_condition</code> 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>
<table><tr><td> </td><td><pre class="example">server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}}
</pre></td></tr></table>
<a name="IDX2422"></a>
<p>If the session is encrypted, <code>$tls_cipher</code> is not empty, and so the expansion
yields "yes", 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>
<ul class="toc">
<li>
The client host does not match <code>auth_advertise_hosts</code>; or
</li><li>
No authenticators are configured with server options; or
</li><li>
Expansion of <code>server_advertise_condition</code> blocked the advertising of all the
server authenticators.
</li></ul>
<p>Otherwise, Exim runs the ACL specified by <code>acl_smtp_auth</code> in order
to decide whether to accept the command. If <code>acl_smtp_auth</code> 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>
<a name="IDX2423"></a>
<a name="IDX2424"></a>
<p>When a message is received from an authenticated host, the value of
<code>$received_protocol</code> is set to "esmtpa" or "esmtpsa" instead of "esmtp"
or "esmtps", and <code>$sender_host_authenticated</code> 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>
<hr size="6">
<a name="Testing-server-authentication"></a>
<a name="SEC276"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC275" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC277" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC272" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC272" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_34.html#SEC278" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 33.4 Testing server authentication </h2>
<p>Exim's <code>-bh</code> 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>
<table><tr><td> </td><td><pre class="example">use MIME::Base64;
printf ("%s", encode_base64(eval "\"$ARGV[0]\""));
</pre></td></tr></table>
<a name="IDX2425"></a>
<p>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>
<table><tr><td> </td><td><pre class="example">encode '\0user\0password'
</pre></td></tr></table>
<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><strong>Warning 1</strong>: 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><strong>Warning 2</strong>: 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>
<table><tr><td> </td><td><pre class="example">encode '\0user@domain.com\0pas$$word'
</pre></td></tr></table>
<p>gives an incorrect answer because of the unescaped "@" and "$" characters.
</p>
<p>If you have the <code>mimencode</code> command installed, another way to do produce
base64-encoded strings is to run the command
</p>
<table><tr><td> </td><td><pre class="example">echo -e -n `\0user\0password' | mimencode
</pre></td></tr></table>
<p>The <code>-e</code> option of <code>echo</code> enables the interpretation of backslash escapes
in the argument, and the <code>-n</code> option specifies no newline at the end of its
output. However, not all versions of <code>echo</code> recognize these options, so you
should check your version before relying on this suggestion.
</p>
<hr size="6">
<a name="Authentication-by-an-Exim-client"></a>
<a name="SEC277"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC276" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="spec_34.html#SEC278" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC272" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC272" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_34.html#SEC278" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 33.5 Authentication by an Exim client </h2>
<p>The <code>smtp</code> transport has two options called <code>hosts_require_auth</code> and
<code>hosts_try_auth</code>. When the <code>smtp</code> 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>
<ul class="toc">
<li>
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.
</li><li>
<a name="IDX2426"></a>
<a name="IDX2427"></a>
When it finds one that matches, it runs the authenticator's client code. The
variables <code>$host</code> and <code>$host_address</code> 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.
</li><li>
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.
</li><li>
If the response to authentication is a permanent error (5<em>xx</em> 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 <code>hosts_require_auth</code> or
<code>hosts_try_auth</code>. 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.
</li></ul>
<a name="IDX2428"></a>
<p>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 <code>server_mail_auth</code> 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
<code>qualify_domain</code> is treated as authenticated. However, if the
<code>authenticated_sender</code> option is set on the <code>smtp</code> transport, it overrides
the authenticated sender that was received with the message.
<a name="IDX2429"></a>
<a name="IDX2430"></a>
</p>
<hr size="6">
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC272" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="spec_34.html#SEC278" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<p>
<font size="-1">
This document was generated on <i>September, 10 2009</i> using <a href="http://www.nongnu.org/texi2html/"><i>texi2html 1.78</i></a>.
</font>
<br>
</p>
</body>
</html>
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
a4080654d049ad31b216b761b9173c1f
>
files
>
136
