<!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: 3. How Exim receives and delivers mail</title>
<meta name="description" content="Specification of the Exim Mail Transfer Agent: 3. How Exim receives and delivers mail">
<meta name="keywords" content="Specification of the Exim Mail Transfer Agent: 3. How Exim receives and delivers mail">
<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="Receiving-and-delivering-mail"></a>
<a name="SEC13"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="spec_2.html#SEC12" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC14" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec_2.html#SEC12" 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_4.html#SEC31" 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"> 3. How Exim receives and delivers mail </h1>
<table class="menu" border="0" cellspacing="0">
<tr><td align="left" valign="top"><a href="#SEC14">3.1 Overall philosophy</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC15">3.2 Policy control</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC16">3.3 User filters</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC17">3.4 Message identification</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC18">3.5 Receiving mail</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC19">3.6 Handling an incoming message</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC20">3.7 Life of a message</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC21">3.8 Processing an address for delivery</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC22">3.9 Processing an address for verification</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC23">3.10 Running an individual router</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC24">3.11 Duplicate addresses</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC25">3.12 Router preconditions</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC26">3.13 Delivery in detail</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC27">3.14 Retry mechanism</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC28">3.15 Temporary delivery failure</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC29">3.16 Permanent delivery failure</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC30">3.17 Failures to deliver bounce messages</a></td><td> </td><td align="left" valign="top">
</td></tr>
</table>
<hr size="6">
<a name="Overall-philosophy"></a>
<a name="SEC14"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC13" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC15" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC13" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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"> 3.1 Overall philosophy </h2>
<p>Exim is designed to work efficiently on systems that are permanently connected
to the Internet and are handling a general mix of mail. In such circumstances,
most messages can be delivered immediately. Consequently, Exim does not
maintain independent queues of messages for specific domains or hosts, though
it does try to send several messages in a single SMTP connection after a host
has been down, and it also maintains per-host retry information.
</p>
<hr size="6">
<a name="Policy-control"></a>
<a name="SEC15"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC14" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC16" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC13" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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"> 3.2 Policy control </h2>
<p>Policy controls are now an important feature of MTAs that are connected to the
Internet. Perhaps their most important job is to stop MTAs being abused as
"open relays" by misguided individuals who send out vast amounts of
unsolicited junk, and want to disguise its source. Exim provides flexible
facilities for specifying policy controls on incoming mail:
</p>
<ul class="toc">
<li>
<a name="IDX42"></a>
Exim 4 (unlike previous versions of Exim) implements policy controls on
incoming mail by means of <em>Access Control Lists</em> (ACLs). Each list is a
series of statements that may either grant or deny access. ACLs can be used at
several places in the SMTP dialogue while receiving a message from a remote
host. However, the most common places are after each RCPT command, and at the
very end of the message. The sysadmin can specify conditions for accepting or
rejecting individual recipients or the entire message, respectively, at these
two points (see chapter <a href="spec_40.html#SEC308">Access control lists</a>). Denial of access results in an SMTP
error code.
</li><li>
An ACL is also available for locally generated, non-SMTP messages. In this
case, the only available actions are to accept or deny the entire message.
</li><li>
When Exim is compiled with the content-scanning extension, facilities are
provided in the ACL mechanism for passing the message to external virus and/or
spam scanning software. The result of such a scan is passed back to the ACL,
which can then use it to decide what to do with the message.
</li><li>
When a message has been received, either from a remote host or from the local
host, but before the final acknowledgment has been sent, a locally supplied C
function called <code>local_scan()</code> can be run to inspect the message and decide
whether to accept it or not (see chapter <a href="spec_42.html#SEC365">Adding a local scan function to Exim</a>). If the message
is accepted, the list of recipients can be modified by the function.
</li><li>
Using the <code>local_scan()</code> mechanism is another way of calling external scanner
software. The <code>SA-Exim</code> add-on package works this way. It does not require
Exim to be compiled with the content-scanning extension.
</li><li>
After a message has been accepted, a further checking mechanism is available in
the form of the <em>system filter</em> (see chapter <a href="spec_43.html#SEC374">System-wide message filtering</a>). This
runs at the start of every delivery process.
</li></ul>
<hr size="6">
<a name="User-filters"></a>
<a name="SEC16"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC15" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC17" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC13" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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"> 3.3 User filters </h2>
<p>In a conventional Exim configuration, users are able to run private filters by
setting up appropriate ‘<tt>.forward</tt>’ files in their home directories. See
chapter <a href="spec_22.html#SEC204">The redirect router</a> (about the <code>redirect</code> router) for the
configuration needed to support this, and the separate document entitled
<em>Exim's interfaces to mail filtering</em> for user details. Two different kinds
of filtering are available:
</p>
<ul class="toc">
<li>
Sieve filters are written in the standard filtering language that is defined
by RFC 3028.
</li><li>
Exim filters are written in a syntax that is unique to Exim, but which is more
powerful than Sieve, which it pre-dates.
</li></ul>
<p>User filters are run as part of the routing process, described below.
</p>
<hr size="6">
<a name="Message-identification"></a>
<a name="SEC17"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC16" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC18" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC13" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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"> 3.4 Message identification </h2>
<p>Every message handled by Exim is given a <em>message id</em> which is sixteen
characters long. It is divided into three parts, separated by hyphens, for
example ‘<samp>16VDhn-0001bo-D3</samp>’. Each part is a sequence of letters and digits,
normally encoding numbers in base 62. However, in the Darwin operating
system (Mac OS X) and when Exim is compiled to run under Cygwin, base 36
(avoiding the use of lower case letters) is used instead, because the message
id is used to construct file names, and the names of files in those systems are
not always case-sensitive.
</p>
<a name="IDX43"></a>
<p>The detail of the contents of the message id have changed as Exim has evolved.
Earlier versions relied on the operating system not re-using a process id (pid)
within one second. On modern operating systems, this assumption can no longer
be made, so the algorithm had to be changed. To retain backward compatibility,
the format of the message id was retained, which is why the following rules are
somewhat eccentric:
</p>
<ul class="toc">
<li>
The first six characters of the message id are the time at which the message
started to be received, to a granularity of one second. That is, this field
contains the number of seconds since the start of the epoch (the normal Unix
way of representing the date and time of day).
</li><li>
After the first hyphen, the next six characters are the id of the process that
received the message.
</li><li>
There are two different possibilities for the final two characters:
<ol>
<li>
<a name="IDX44"></a>
If <code>localhost_number</code> is not set, this value is the fractional part of the
time of reception, normally in units of 1/2000 of a second, but for systems
that must use base 36 instead of base 62 (because of case-insensitive file
systems), the units are 1/1000 of a second.
</li><li>
If <code>localhost_number</code> is set, it is multiplied by 200 (100) and added to
the fractional part of the time, which in this case is in units of 1/200
(1/100) of a second.
</li></ol>
</li></ul>
<p>After a message has been received, Exim waits for the clock to tick at the
appropriate resolution before proceeding, so that if another message is
received by the same process, or by another process with the same (re-used)
pid, it is guaranteed that the time will be different. In most cases, the clock
will already have ticked while the message was being received.
</p>
<hr size="6">
<a name="Receiving-mail"></a>
<a name="SEC18"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC17" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC19" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC13" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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"> 3.5 Receiving mail </h2>
<p>The only way Exim can receive mail from another host is using SMTP over
TCP/IP, in which case the sender and recipient addresses are transferred using
SMTP commands. However, from a locally running process (such as a user's MUA),
there are several possibilities:
</p>
<ul class="toc">
<li>
If the process runs Exim with the <code>-bm</code> option, the message is read
non-interactively (usually via a pipe), with the recipients taken from the
command line, or from the body of the message if <code>-t</code> is also used.
</li><li>
If the process runs Exim with the <code>-bS</code> option, the message is also read
non-interactively, but in this case the recipients are listed at the start of
the message in a series of SMTP RCPT commands, terminated by a DATA
command. This is so-called "batch SMTP" format,
but it isn't really SMTP. The SMTP commands are just another way of passing
envelope addresses in a non-interactive submission.
</li><li>
If the process runs Exim with the <code>-bs</code> option, the message is read
interactively, using the SMTP protocol. A two-way pipe is normally used for
passing data between the local process and the Exim process.
This is "real" SMTP and is handled in the same way as SMTP over TCP/IP. For
example, the ACLs for SMTP commands are used for this form of submission.
</li><li>
A local process may also make a TCP/IP call to the host's loopback address
(127.0.0.1) or any other of its IP addresses. When receiving messages, Exim
does not treat the loopback address specially. It treats all such connections
in the same way as connections from other hosts.
</li></ul>
<a name="IDX45"></a>
<a name="IDX46"></a>
<p>In the three cases that do not involve TCP/IP, the sender address is
constructed from the login name of the user that called Exim and a default
qualification domain (which can be set by the <code>qualify_domain</code> configuration
option). For local or batch SMTP, a sender address that is passed using the
SMTP MAIL command is ignored. However, the system administrator may allow
certain users ("trusted users") to specify a different sender address
unconditionally, or all users to specify certain forms of different sender
address. The <code>-f</code> option or the SMTP MAIL command is used to specify these
different addresses. See section <a href="spec_5.html#SEC54">Trusted and admin users</a> for details of trusted
users, and the <code>untrusted_set_sender</code> option for a way of allowing untrusted
users to change sender addresses.
</p>
<p>Messages received by either of the non-interactive mechanisms are subject to
checking by the non-SMTP ACL, if one is defined. Messages received using SMTP
(either over TCP/IP, or interacting with a local process) can be checked by a
number of ACLs that operate at different times during the SMTP session. Either
individual recipients, or the entire message, can be rejected if local policy
requirements are not met. The <code>local_scan()</code> function (see chapter
<a href="spec_42.html#SEC365">Adding a local scan function to Exim</a>) is run for all incoming messages.
</p>
<p>Exim can be configured not to start a delivery process when a message is
received; this can be unconditional, or depend on the number of incoming SMTP
connections or the system load. In these situations, new messages wait on the
queue until a queue runner process picks them up. However, in standard
configurations under normal conditions, delivery is started as soon as a
message is received.
</p>
<hr size="6">
<a name="Handling-an-incoming-message"></a>
<a name="SEC19"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC18" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC20" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC13" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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"> 3.6 Handling an incoming message </h2>
<p>When Exim accepts a message, it writes two files in its spool directory. The
first contains the envelope information, the current status of the message, and
the header lines, and the second contains the body of the message. The names of
the two spool files consist of the message id, followed by ‘<samp>-H</samp>’ for the
file containing the envelope and header, and ‘<samp>-D</samp>’ for the data file.
</p>
<a name="IDX47"></a>
<p>By default all these message files are held in a single directory called
‘<tt>input</tt>’ inside the general Exim spool directory. Some operating systems do
not perform very well if the number of files in a directory gets large; to
improve performance in such cases, the <code>split_spool_directory</code> option can be
used. This causes Exim to split up the input files into 62 sub-directories
whose names are single letters or digits. When this is done, the queue is
processed one sub-directory at a time instead of all at once, which can improve
overall performance even when there are not enough files in each directory to
affect file system performance.
</p>
<p>The envelope information consists of the address of the message's sender and
the addresses of the recipients. This information is entirely separate from
any addresses contained in the header lines. The status of the message includes
a list of recipients who have already received the message. The format of the
first spool file is described in chapter <a href="spec_53.html#SEC490">Format of spool files</a>.
</p>
<a name="IDX48"></a>
<p>Address rewriting that is specified in the rewrite section of the configuration
(see chapter <a href="spec_31.html#SEC248">Address rewriting</a>) is done once and for all on incoming addresses,
both in the header lines and the envelope, at the time the message is accepted.
If during the course of delivery additional addresses are generated (for
example, via aliasing), these new addresses are rewritten as soon as they are
generated. At the time a message is actually delivered (transported) further
rewriting can take place; because this is a transport option, it can be
different for different forms of delivery. It is also possible to specify the
addition or removal of certain header lines at the time the message is
delivered (see chapters <a href="spec_15.html#SEC186">Generic options for routers</a> and
<a href="spec_24.html#SEC220">Generic options for transports</a>).
</p>
<hr size="6">
<a name="Life-of-a-message"></a>
<a name="SEC20"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC19" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC21" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC13" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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"> 3.7 Life of a message </h2>
<p>A message remains in the spool directory until it is completely delivered to
its recipients or to an error address, or until it is deleted by an
administrator or by the user who originally created it. In cases when delivery
cannot proceed - for example, when a message can neither be delivered to its
recipients nor returned to its sender, the message is marked "frozen" on the
spool, and no more deliveries are attempted.
</p>
<a name="IDX49"></a>
<a name="IDX50"></a>
<p>An administrator can "thaw" such messages when the problem has been
corrected, and can also freeze individual messages by hand if necessary. In
addition, an administrator can force a delivery error, causing a bounce message
to be sent.
</p>
<a name="IDX51"></a>
<a name="IDX52"></a>
<p>There are options called <code>ignore_bounce_errors_after</code> and
<code>timeout_frozen_after</code>, which discard frozen messages after a certain time.
The first applies only to frozen bounces, the second to any frozen messages.
</p>
<a name="IDX53"></a>
<a name="IDX54"></a>
<p>While Exim is working on a message, it writes information about each delivery
attempt to its main log file. This includes successful, unsuccessful, and
delayed deliveries for each recipient (see chapter <a href="spec_49.html#SEC435">Log files</a>). The log
lines are also written to a separate <em>message log</em> file for each message.
These logs are solely for the benefit of the administrator, and are normally
deleted along with the spool files when processing of a message is complete.
The use of individual message logs can be disabled by setting
<code>no_message_logs</code>; this might give an improvement in performance on very busy
systems.
</p>
<a name="IDX55"></a>
<a name="IDX56"></a>
<p>All the information Exim itself needs to set up a delivery is kept in the first
spool file, along with the header lines. When a successful delivery occurs, the
address is immediately written at the end of a journal file, whose name is the
message id followed by ‘<samp>-J</samp>’. At the end of a delivery run, if there are some
addresses left to be tried again later, the first spool file (the ‘<samp>-H</samp>’ file)
is updated to indicate which these are, and the journal file is then deleted.
Updating the spool file is done by writing a new file and renaming it, to
minimize the possibility of data loss.
</p>
<p>Should the system or the program crash after a successful delivery but before
the spool file has been updated, the journal is left lying around. The next
time Exim attempts to deliver the message, it reads the journal file and
updates the spool file before proceeding. This minimizes the chances of double
deliveries caused by crashes.
</p>
<hr size="6">
<a name="Processing-an-address-for-delivery"></a>
<a name="SEC21"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC20" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC22" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC13" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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"> 3.8 Processing an address for delivery </h2>
<p>The main delivery processing elements of Exim are called <em>routers</em> and
<em>transports</em>, and collectively these are known as <em>drivers</em>. Code for a
number of them is provided in the source distribution, and compile-time options
specify which ones are included in the binary. Run time options specify which
ones are actually used for delivering messages.
</p>
<a name="IDX57"></a>
<p>Each driver that is specified in the run time configuration is an <em>instance</em>
of that particular driver type. Multiple instances are allowed; for example,
you can set up several different <code>smtp</code> transports, each with different
option values that might specify different ports or different timeouts. Each
instance has its own identifying name. In what follows we will normally use the
instance name when discussing one particular instance (that is, one specific
configuration of the driver), and the generic driver name when discussing
the driver's features in general.
</p>
<p>A <em>router</em> is a driver that operates on an address, either determining how
its delivery should happen, by assigning it to a specific transport, or
converting the address into one or more new addresses (for example, via an
alias file). A router may also explicitly choose to fail an address, causing it
to be bounced.
</p>
<p>A <em>transport</em> is a driver that transmits a copy of the message from Exim's
spool to some destination. There are two kinds of transport: for a <em>local</em>
transport, the destination is a file or a pipe on the local host, whereas for a
<em>remote</em> transport the destination is some other host. A message is passed
to a specific transport as a result of successful routing. If a message has
several recipients, it may be passed to a number of different transports.
</p>
<a name="IDX58"></a>
<p>An address is processed by passing it to each configured router instance in
turn, subject to certain preconditions, until a router accepts the address or
specifies that it should be bounced. We will describe this process in more
detail shortly. First, as a simple example, we consider how each recipient
address in a message is processed in a small configuration of three routers.
</p>
<p>To make this a more concrete example, it is described in terms of some actual
routers, but remember, this is only an example. You can configure Exim's
routers in many different ways, and there may be any number of routers in a
configuration.
</p>
<p>The first router that is specified in a configuration is often one that handles
addresses in domains that are not recognized specially by the local host. These
are typically addresses for arbitrary domains on the Internet. A precondition
is set up which looks for the special domains known to the host (for example,
its own domain name), and the router is run for addresses that do <em>not</em>
match. Typically, this is a router that looks up domains in the DNS in order to
find the hosts to which this address routes. If it succeeds, the address is
assigned to a suitable SMTP transport; if it does not succeed, the router is
configured to fail the address.
</p>
<p>The second router is reached only when the domain is recognized as one that
"belongs" to the local host. This router does redirection - also known as
aliasing and forwarding. When it generates one or more new addresses from the
original, each of them is routed independently from the start. Otherwise, the
router may cause an address to fail, or it may simply decline to handle the
address, in which case the address is passed to the next router.
</p>
<p>The final router in many configurations is one that checks to see if the
address belongs to a local mailbox. The precondition may involve a check to
see if the local part is the name of a login account, or it may look up the
local part in a file or a database. If its preconditions are not met, or if
the router declines, we have reached the end of the routers. When this happens,
the address is bounced.
</p>
<hr size="6">
<a name="Processing-an-address-for-verification"></a>
<a name="SEC22"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC21" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC23" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC13" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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"> 3.9 Processing an address for verification </h2>
<p>As well as being used to decide how to deliver to an address, Exim's routers
are also used for <em>address verification</em>. Verification can be requested as
one of the checks to be performed in an ACL for incoming messages, on both
sender and recipient addresses, and it can be tested using the <code>-bv</code> and
<code>-bvs</code> command line options.
</p>
<p>When an address is being verified, the routers are run in "verify mode". This
does not affect the way the routers work, but it is a state that can be
detected. By this means, a router can be skipped or made to behave differently
when verifying. A common example is a configuration in which the first router
sends all messages to a message-scanning program, unless they have been
previously scanned. Thus, the first router accepts all addresses without any
checking, making it useless for verifying. Normally, the <code>no_verify</code> option
would be set for such a router, causing it to be skipped in verify mode.
</p>
<hr size="6">
<a name="Running-an-individual-router"></a>
<a name="SEC23"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC22" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC24" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC13" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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"> 3.10 Running an individual router </h2>
<p>As explained in the example above, a number of preconditions are checked before
running a router. If any are not met, the router is skipped, and the address is
passed to the next router. When all the preconditions on a router <em>are</em> met,
the router is run. What happens next depends on the outcome, which is one of
the following:
</p>
<ul class="toc">
<li>
<em>accept</em>: The router accepts the address, and either assigns it to a
transport, or generates one or more "child" addresses. Processing the
original address ceases,
<a name="IDX59"></a>
unless the <code>unseen</code> option is set on the router. This option
can be used to set up multiple deliveries with different routing (for example,
for keeping archive copies of messages). When <code>unseen</code> is set, the address is
passed to the next router. Normally, however, an <em>accept</em> return marks the
end of routing.
<p>Any child addresses generated by the router are processed independently,
starting with the first router by default. It is possible to change this by
setting the <code>redirect_router</code> option to specify which router to start at for
child addresses. Unlike <code>pass_router</code> (see below) the router specified by
<code>redirect_router</code> may be anywhere in the router configuration.
</p>
</li><li>
<em>pass</em>: The router recognizes the address, but cannot handle it itself. It
requests that the address be passed to another router. By default the address
is passed to the next router, but this can be changed by setting the
<code>pass_router</code> option. However, (unlike <code>redirect_router</code>) the named router
must be below the current router (to avoid loops).
</li><li>
<em>decline</em>: The router declines to accept the address because it does not
recognize it at all. By default, the address is passed to the next router, but
this can be prevented by setting the <code>no_more</code> option. When <code>no_more</code> is
set, all the remaining routers are skipped. In effect, <code>no_more</code> converts
<em>decline</em> into <em>fail</em>.
</li><li>
<em>fail</em>: The router determines that the address should fail, and queues it for
the generation of a bounce message. There is no further processing of the
original address unless <code>unseen</code> is set on the router.
</li><li>
<em>defer</em>: The router cannot handle the address at the present time. (A
database may be offline, or a DNS lookup may have timed out.) No further
processing of the address happens in this delivery attempt. It is tried again
next time the message is considered for delivery.
</li><li>
<em>error</em>: There is some error in the router (for example, a syntax error in
its configuration). The action is as for defer.
</li></ul>
<p>If an address reaches the end of the routers without having been accepted by
any of them, it is bounced as unrouteable. The default error message in this
situation is "unrouteable address", but you can set your own message by
making use of the <code>cannot_route_message</code> option. This can be set for any
router; the value from the last router that "saw" the address is used.
</p>
<p>Sometimes while routing you want to fail a delivery when some conditions are
met but others are not, instead of passing the address on for further routing.
You can do this by having a second router that explicitly fails the delivery
when the relevant conditions are met. The <code>redirect</code> router has a "fail"
facility for this purpose.
</p>
<hr size="6">
<a name="Duplicate-addresses"></a>
<a name="SEC24"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC23" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC25" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC13" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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"> 3.11 Duplicate addresses </h2>
<p>Once routing is complete, Exim scans the addresses that are assigned to local
and remote transports, and discards any duplicates that it finds. During this
check, local parts are treated as case-sensitive. This happens only when
actually delivering a message; when testing routers with <code>-bt</code>, all the
routed addresses are shown.
</p>
<hr size="6">
<a name="Router-preconditions"></a>
<a name="SEC25"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC24" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC26" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC13" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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"> 3.12 Router preconditions </h2>
<p>The preconditions that are tested for each router are listed below, in the
order in which they are tested. The individual configuration options are
described in more detail in chapter <a href="spec_15.html#SEC186">Generic options for routers</a>.
</p>
<ul class="toc">
<li>
The <code>local_part_prefix</code> and <code>local_part_suffix</code> options can specify that
the local parts handled by the router may or must have certain prefixes and/or
suffixes. If a mandatory affix (prefix or suffix) is not present, the router is
skipped. These conditions are tested first. When an affix is present, it is
removed from the local part before further processing, including the evaluation
of any other conditions.
</li><li>
Routers can be designated for use only when not verifying an address, that is,
only when routing it for delivery (or testing its delivery routing). If the
<code>verify</code> option is set false, the router is skipped when Exim is verifying an
address.
Setting the <code>verify</code> option actually sets two options, <code>verify_sender</code> and
<code>verify_recipient</code>, which independently control the use of the router for
sender and recipient verification. You can set these options directly if
you want a router to be used for only one type of verification.
</li><li>
If the <code>address_test</code> option is set false, the router is skipped when Exim is
run with the <code>-bt</code> option to test an address routing. This can be helpful
when the first router sends all new messages to a scanner of some sort; it
makes it possible to use <code>-bt</code> to test subsequent delivery routing without
having to simulate the effect of the scanner.
</li><li>
Routers can be designated for use only when verifying an address, as
opposed to routing it for delivery. The <code>verify_only</code> option controls this.
</li><li>
Individual routers can be explicitly skipped when running the routers to
check an address given in the SMTP EXPN command (see the <code>expn</code> option).
</li><li>
If the <code>domains</code> option is set, the domain of the address must be in the set
of domains that it defines.
</li><li>
<a name="IDX60"></a>
<a name="IDX61"></a>
<a name="IDX62"></a>
If the <code>local_parts</code> option is set, the local part of the address must be in
the set of local parts that it defines. If <code>local_part_prefix</code> or
<code>local_part_suffix</code> is in use, the prefix or suffix is removed from the local
part before this check. If you want to do precondition tests on local parts
that include affixes, you can do so by using a <code>condition</code> option (see below)
that uses the variables <code>$local_part</code>, <code>$local_part_prefix</code>, and
<code>$local_part_suffix</code> as necessary.
</li><li>
<a name="IDX63"></a>
<a name="IDX64"></a>
<a name="IDX65"></a>
If the <code>check_local_user</code> option is set, the local part must be the name of
an account on the local host. If this check succeeds, the uid and gid of the
local user are placed in <code>$local_user_uid</code> and <code>$local_user_gid</code> and the
user's home directory is placed in <code>$home</code>; these values can be used in the
remaining preconditions.
</li><li>
If the <code>router_home_directory</code> option is set, it is expanded at this point,
because it overrides the value of <code>$home</code>. If this expansion were left till
later, the value of <code>$home</code> as set by <code>check_local_user</code> would be used in
subsequent tests. Having two different values of <code>$home</code> in the same router
could lead to confusion.
</li><li>
If the <code>senders</code> option is set, the envelope sender address must be in the
set of addresses that it defines.
</li><li>
If the <code>require_files</code> option is set, the existence or non-existence of
specified files is tested.
</li><li>
<a name="IDX66"></a>
If the <code>condition</code> option is set, it is evaluated and tested. This option
uses an expanded string to allow you to set up your own custom preconditions.
Expanded strings are described in chapter <a href="spec_11.html#SEC137">String expansions</a>.
</li></ul>
<p>Note that <code>require_files</code> comes near the end of the list, so you cannot use
it to check for the existence of a file in which to lookup up a domain, local
part, or sender. However, as these options are all expanded, you can use the
<code>exists</code> expansion condition to make such tests within each condition. The
<code>require_files</code> option is intended for checking files that the router may be
going to use internally, or which are needed by a specific transport (for
example, ‘<tt>.procmailrc</tt>’).
</p>
<hr size="6">
<a name="Delivery-in-detail"></a>
<a name="SEC26"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC25" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC27" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC13" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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"> 3.13 Delivery in detail </h2>
<p>When a message is to be delivered, the sequence of events is as follows:
</p>
<ul class="toc">
<li>
If a system-wide filter file is specified, the message is passed to it. The
filter may add recipients to the message, replace the recipients, discard the
message, cause a new message to be generated, or cause the message delivery to
fail. The format of the system filter file is the same as for Exim user filter
files, described in the separate document entitled <em>Exim's interfaces to mail
filtering</em>.
<a name="IDX67"></a>
(<strong>Note</strong>: Sieve cannot be used for system filter files.)
<p>Some additional features are available in system filters - see chapter
<a href="spec_43.html#SEC374">System-wide message filtering</a> for details. Note that a message is passed to the system
filter only once per delivery attempt, however many recipients it has. However,
if there are several delivery attempts because one or more addresses could not
be immediately delivered, the system filter is run each time. The filter
condition <code>first_delivery</code> can be used to detect the first run of the system
filter.
</p>
</li><li>
Each recipient address is offered to each configured router in turn, subject to
its preconditions, until one is able to handle it. If no router can handle the
address, that is, if they all decline, the address is failed. Because routers
can be targeted at particular domains, several locally handled domains can be
processed entirely independently of each other.
</li><li>
<a name="IDX68"></a>
<a name="IDX69"></a>
A router that accepts an address may assign it to a local or a remote
transport. However, the transport is not run at this time. Instead, the address
is placed on a list for the particular transport, which will be run later.
Alternatively, the router may generate one or more new addresses (typically
from alias, forward, or filter files). New addresses are fed back into this
process from the top, but in order to avoid loops, a router ignores any address
which has an identically-named ancestor that was processed by itself.
</li><li>
When all the routing has been done, addresses that have been successfully
handled are passed to their assigned transports. When local transports are
doing real local deliveries, they handle only one address at a time, but if a
local transport is being used as a pseudo-remote transport (for example, to
collect batched SMTP messages for transmission by some other means) multiple
addresses can be handled. Remote transports can always handle more than one
address at a time, but can be configured not to do so, or to restrict multiple
addresses to the same domain.
</li><li>
Each local delivery to a file or a pipe runs in a separate process under a
non-privileged uid, and these deliveries are run one at a time. Remote
deliveries also run in separate processes, normally under a uid that is private
to Exim ("the Exim user"), but in this case, several remote deliveries can be
run in parallel. The maximum number of simultaneous remote deliveries for any
one message is set by the <code>remote_max_parallel</code> option.
The order in which deliveries are done is not defined, except that all local
deliveries happen before any remote deliveries.
</li><li>
<a name="IDX70"></a>
When it encounters a local delivery during a queue run, Exim checks its retry
database to see if there has been a previous temporary delivery failure for the
address before running the local transport. If there was a previous failure,
Exim does not attempt a new delivery until the retry time for the address is
reached. However, this happens only for delivery attempts that are part of a
queue run. Local deliveries are always attempted when delivery immediately
follows message reception, even if retry times are set for them. This makes for
better behaviour if one particular message is causing problems (for example,
causing quota overflow, or provoking an error in a filter file).
</li><li>
<a name="IDX71"></a>
Remote transports do their own retry handling, since an address may be
deliverable to one of a number of hosts, each of which may have a different
retry time. If there have been previous temporary failures and no host has
reached its retry time, no delivery is attempted, whether in a queue run or
not. See chapter <a href="spec_32.html#SEC260">Retry configuration</a> for details of retry strategies.
</li><li>
If there were any permanent errors, a bounce message is returned to an
appropriate address (the sender in the common case), with details of the error
for each failing address. Exim can be configured to send copies of bounce
messages to other addresses.
</li><li>
<a name="IDX72"></a>
If one or more addresses suffered a temporary failure, the message is left on
the queue, to be tried again later. Delivery of these addresses is said to be
<em>deferred</em>.
</li><li>
When all the recipient addresses have either been delivered or bounced,
handling of the message is complete. The spool files and message log are
deleted, though the message log can optionally be preserved if required.
</li></ul>
<hr size="6">
<a name="Retry-mechanism"></a>
<a name="SEC27"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC26" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC28" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC13" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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"> 3.14 Retry mechanism </h2>
<p>Exim's mechanism for retrying messages that fail to get delivered at the first
attempt is the queue runner process. You must either run an Exim daemon that
uses the <code>-q</code> option with a time interval to start queue runners at regular
intervals, or use some other means (such as <em>cron</em>) to start them. If you do
not arrange for queue runners to be run, messages that fail temporarily at the
first attempt will remain on your queue for ever. A queue runner process works
its way through the queue, one message at a time, trying each delivery that has
passed its retry time.
You can run several queue runners at once.
</p>
<p>Exim uses a set of configured rules to determine when next to retry the failing
address (see chapter <a href="spec_32.html#SEC260">Retry configuration</a>). These rules also specify when Exim
should give up trying to deliver to the address, at which point it generates a
bounce message. If no retry rules are set for a particular host, address, and
error combination, no retries are attempted, and temporary errors are treated
as permanent.
</p>
<hr size="6">
<a name="Temporary-delivery-failure"></a>
<a name="SEC28"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC27" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC29" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC13" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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"> 3.15 Temporary delivery failure </h2>
<p>There are many reasons why a message may not be immediately deliverable to a
particular address. Failure to connect to a remote machine (because it, or the
connection to it, is down) is one of the most common. Temporary failures may be
detected during routing as well as during the transport stage of delivery.
Local deliveries may be delayed if NFS files are unavailable, or if a mailbox
is on a file system where the user is over quota. Exim can be configured to
impose its own quotas on local mailboxes; where system quotas are set they will
also apply.
</p>
<p>If a host is unreachable for a period of time, a number of messages may be
waiting for it by the time it recovers, and sending them in a single SMTP
connection is clearly beneficial. Whenever a delivery to a remote host is
deferred,
</p>
<a name="IDX73"></a>
<p>Exim makes a note in its hints database, and whenever a successful
SMTP delivery has happened, it looks to see if any other messages are waiting
for the same host. If any are found, they are sent over the same SMTP
connection, subject to a configuration limit as to the maximum number in any
one connection.
</p>
<hr size="6">
<a name="Permanent-delivery-failure"></a>
<a name="SEC29"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC28" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC30" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC13" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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"> 3.16 Permanent delivery failure </h2>
<p>When a message cannot be delivered to some or all of its intended recipients, a
bounce message is generated. Temporary delivery failures turn into permanent
errors when their timeout expires. All the addresses that fail in a given
delivery attempt are listed in a single message. If the original message has
many recipients, it is possible for some addresses to fail in one delivery
attempt and others to fail subsequently, giving rise to more than one bounce
message. The wording of bounce messages can be customized by the administrator.
See chapter <a href="spec_46.html#SEC417">Customizing bounce and warning messages</a> for details.
</p>
<a name="IDX74"></a>
<p>Bounce messages contain an <em>X-Failed-Recipients:</em> header line that lists the
failed addresses, for the benefit of programs that try to analyse such messages
automatically.
</p>
<a name="IDX75"></a>
<p>A bounce message is normally sent to the sender of the original message, as
obtained from the message's envelope. For incoming SMTP messages, this is the
address given in the MAIL command. However, when an address is expanded via a
forward or alias file, an alternative address can be specified for delivery
failures of the generated addresses. For a mailing list expansion (see section
<a href="spec_47.html#SEC422">Using Exim to handle mailing lists</a>) it is common to direct bounce messages to the manager
of the list.
</p>
<hr size="6">
<a name="Failures-to-deliver-bounce-messages"></a>
<a name="SEC30"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC29" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC13" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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"> 3.17 Failures to deliver bounce messages </h2>
<p>If a bounce message (either locally generated or received from a remote host)
itself suffers a permanent delivery failure, the message is left on the queue,
but it is frozen, awaiting the attention of an administrator. There are options
that can be used to make Exim discard such failed messages, or to keep them
for only a short time (see <code>timeout_frozen_after</code> and
<code>ignore_bounce_errors_after</code>).
</p>
<hr size="6">
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC13" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="spec_4.html#SEC31" 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
>
132
