<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><style xmlns="" type="text/css">
div.added { background-color: #ffff99; }
div.deleted { text-decoration: line-through;
background-color: #FF7F7F; }
div.changed { background-color: #99ff99; }
div.off { }
span.added { background-color: #ffff99; }
span.deleted { text-decoration: line-through;
background-color: #FF7F7F; }
span.changed { background-color: #99ff99; }
span.off { }
pre.literallayout {
background-color: #E8E8D0;
padding-left: 0.5cm;
padding-top: 5px;
padding-bottom: 5px;
}
div[class=changed] pre.literallayout {
background-color: #99ff99;
padding-left: 0.5cm;
padding-top: 5px;
padding-bottom: 5px;
}
div.literallayout {
background-color: #E8E8D0;
padding-left: 0.5cm;
padding-top: 5px;
padding-bottom: 5px;
}
div[class=changed] div.literallayout {
background-color: #99ff99;
padding-left: 0.5cm;
padding-top: 5px;
padding-bottom: 5px;
}
</style><title>44. Message processing</title><meta name="generator" content="DocBook XSL Stylesheets V1.72.0" /><link rel="start" href="index.html" title="Specification of the Exim Mail Transfer Agent" /><link rel="up" href="index.html" title="Specification of the Exim Mail Transfer Agent" /><link rel="prev" href="ch43.html" title="43. System-wide message filtering" /><link rel="next" href="ch45.html" title="45. SMTP processing" /></head><body><div class="navheader">
<table width="100%" summary="Navigation header"><tr><td width="20%" align="left"><a accesskey="p" href="ch43.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch45.html">Next</a></td></tr></table></div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a href="index.html#toc0383" id="CHAPmsgproc">44. Message processing</a></h2></div>
</div>
</div>
<p>
<a id="IIDmesproc" class="indexterm"></a>
Exim performs various transformations on the sender and recipient addresses of
all messages that it handles, and also on the messages’ header lines. Some of
these are optional and configurable, while others always take place. All of
this processing, except rewriting as a result of routing, and the addition or
removal of header lines while delivering, happens when a message is received,
before it is placed on Exim’s queue.
</p>
<p>
Some of the automatic processing takes place by default only for
“<span class="quote">locally-originated</span>” messages. This adjective is used to describe messages
that are not received over TCP/IP, but instead are passed to an Exim process on
its standard input. This includes the interactive “<span class="quote">local SMTP</span>” case that is
set up by the <span><strong class="option">-bs</strong></span> command line option.
</p>
<p>
<span class="bold"><strong>Note</strong></span>: Messages received over TCP/IP on the loopback interface (127.0.0.1
or ::1) are not considered to be locally-originated. Exim does not treat the
loopback interface specially in any way.
</p>
<p>
If you want the loopback interface to be treated specially, you must ensure
that there are appropriate entries in your ACLs.
</p>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0384" id="SECTsubmodnon">44.1 Submission mode for non-local messages</a></h3></div>
</div>
</div>
<p>
<a id="id641450" class="indexterm"></a>
<a id="id641464" class="indexterm"></a>
Processing that happens automatically for locally-originated messages (unless
<span><strong class="option">suppress_local_fixups</strong></span> is set) can also be requested for messages that are
received over TCP/IP. The term “<span class="quote">submission mode</span>” is used to describe this
state. Submission mode is set by the modifier
</p>
<pre class="literallayout">control = submission
</pre><p>
in a MAIL, RCPT, or pre-data ACL for an incoming message (see sections
<a href="ch40.html#SECTACLmodi" title="40.19 ACL modifiers">40.19</a> and <a href="ch40.html#SECTcontrols" title="40.20 Use of the control modifier">40.20</a>). This makes Exim treat the message as
a local submission, and is normally used when the source of the message is
known to be an MUA running on a client host (as opposed to an MTA). For
example, to set submission mode for messages originating on the IPv4 loopback
interface, you could include the following in the MAIL ACL:
</p>
<pre class="literallayout">warn hosts = 127.0.0.1
control = submission
</pre><p>
<a id="id641529" class="indexterm"></a>
There are some options that can be used when setting submission mode. A slash
is used to separate options. For example:
</p>
<pre class="literallayout">control = submission/sender_retain
</pre><p>
Specifying <span><strong class="option">sender_retain</strong></span> has the effect of setting <span><strong class="option">local_sender_retain</strong></span>
true and <span><strong class="option">local_from_check</strong></span> false for the current incoming message. The first
of these allows an existing <span class="emphasis"><em>Sender:</em></span> header in the message to remain, and
the second suppresses the check to ensure that <span class="emphasis"><em>From:</em></span> matches the
authenticated sender. With this setting, Exim still fixes up messages by adding
<span class="emphasis"><em>Date:</em></span> and <span class="emphasis"><em>Message-ID:</em></span> header lines if they are missing, but makes no
attempt to check sender authenticity in header lines.
</p>
<p>
When <span><strong class="option">sender_retain</strong></span> is not set, a submission mode setting may specify a
domain to be used when generating a <span class="emphasis"><em>From:</em></span> or <span class="emphasis"><em>Sender:</em></span> header line. For
example:
</p>
<pre class="literallayout">control = submission/domain=some.domain
</pre><p>
The domain may be empty. How this value is used is described in sections
<a href="ch44.html#SECTthefrohea" title="44.11 The From: header line">44.11</a> and <a href="ch44.html#SECTthesenhea" title="44.16 The Sender: header line">44.16</a>. There is also a <span><strong class="option">name</strong></span> option
that allows you to specify the user’s full name for inclusion in a created
<span class="emphasis"><em>Sender:</em></span> or <span class="emphasis"><em>From:</em></span> header line. For example:
</p>
<pre class="literallayout">accept authenticated = *
control = submission/domain=wonderland.example/\
name=${lookup {$authenticated_id} \
lsearch {/etc/exim/namelist}}
</pre><p>
Because the name may contain any characters, including slashes, the <span><strong class="option">name</strong></span>
option must be given last. The remainder of the string is used as the name. For
the example above, if <em class="filename">/etc/exim/namelist</em> contains:
</p>
<pre class="literallayout">bigegg: Humpty Dumpty
</pre><p>
then when the sender has authenticated as <span class="emphasis"><em>bigegg</em></span>, the generated <span class="emphasis"><em>Sender:</em></span>
line would be:
</p>
<pre class="literallayout">Sender: Humpty Dumpty <bigegg@wonderland.example>
</pre><p>
<a id="id641704" class="indexterm"></a>
By default, submission mode forces the return path to the same address as is
used to create the <span class="emphasis"><em>Sender:</em></span> header. However, if <span><strong class="option">sender_retain</strong></span> is
specified, the return path is also left unchanged.
</p>
<p>
<span class="bold"><strong>Note</strong></span>: The changes caused by submission mode take effect after the predata
ACL. This means that any sender checks performed before the fix-ups use the
untrusted sender address specified by the user, not the trusted sender address
specified by submission mode. Although this might be slightly unexpected, it
does mean that you can configure ACL checks to spot that a user is trying to
spoof another’s address.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0385" id="SECTlineendings">44.2 Line endings</a></h3></div>
</div>
</div>
<p>
<a id="id641750" class="indexterm"></a>
<a id="id641761" class="indexterm"></a>
<a id="id641772" class="indexterm"></a>
RFC 2821 specifies that CRLF (two characters: carriage-return, followed by
linefeed) is the line ending for messages transmitted over the Internet using
SMTP over TCP/IP. However, within individual operating systems, different
conventions are used. For example, Unix-like systems use just LF, but others
use CRLF or just CR.
</p>
<p>
Exim was designed for Unix-like systems, and internally, it stores messages
using the system’s convention of a single LF as a line terminator. When
receiving a message, all line endings are translated to this standard format.
Originally, it was thought that programs that passed messages directly to an
MTA within an operating system would use that system’s convention. Experience
has shown that this is not the case; for example, there are Unix applications
that use CRLF in this circumstance. For this reason, and for compatibility with
other MTAs, the way Exim handles line endings for all messages is now as
follows:
</p>
<div class="itemizedlist">
<ul type="disc"><li><p>
LF not preceded by CR is treated as a line ending.
</p>
</li><li><p>
CR is treated as a line ending; if it is immediately followed by LF, the LF
is ignored.
</p>
</li><li><p>
The sequence “<span class="quote">CR, dot, CR</span>” does not terminate an incoming SMTP message,
nor a local message in the state where a line containing only a dot is a
terminator.
</p>
</li><li><p>
If a bare CR is encountered within a header line, an extra space is added after
the line terminator so as not to end the header line. The reasoning behind this
is that bare CRs in header lines are most likely either to be mistakes, or
people trying to play silly games.
</p>
</li><li><p>
If the first header line received in a message ends with CRLF, a subsequent
bare LF in a header line is treated in the same way as a bare CR in a header
line.
</p>
</li></ul></div>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0386" id="SECID218">44.3 Unqualified addresses</a></h3></div>
</div>
</div>
<p>
<a id="id641858" class="indexterm"></a>
<a id="id641868" class="indexterm"></a>
By default, Exim expects every envelope address it receives from an external
host to be fully qualified. Unqualified addresses cause negative responses to
SMTP commands. However, because SMTP is used as a means of transporting
messages from MUAs running on personal workstations, there is sometimes a
requirement to accept unqualified addresses from specific hosts or IP networks.
</p>
<p>
Exim has two options that separately control which hosts may send unqualified
sender or recipient addresses in SMTP commands, namely
<span><strong class="option">sender_unqualified_hosts</strong></span> and <span><strong class="option">recipient_unqualified_hosts</strong></span>. In both
cases, if an unqualified address is accepted, it is qualified by adding the
value of <span><strong class="option">qualify_domain</strong></span> or <span><strong class="option">qualify_recipient</strong></span>, as appropriate.
</p>
<p>
<a id="id641915" class="indexterm"></a>
<a id="id641927" class="indexterm"></a>
Unqualified addresses in header lines are automatically qualified for messages
that are locally originated, unless the <span><strong class="option">-bnq</strong></span> option is given on the command
line. For messages received over SMTP, unqualified addresses in header lines
are qualified only if unqualified addresses are permitted in SMTP commands. In
other words, such qualification is also controlled by
<span><strong class="option">sender_unqualified_hosts</strong></span> and <span><strong class="option">recipient_unqualified_hosts</strong></span>,
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0387" id="SECID219">44.4 The UUCP From line</a></h3></div>
</div>
</div>
<p>
<a id="id641971" class="indexterm"></a>
<a id="id641984" class="indexterm"></a>
<a id="id642001" class="indexterm"></a>
<a id="id642016" class="indexterm"></a>
<a id="id642028" class="indexterm"></a>
<a id="id642040" class="indexterm"></a>
<a id="id642051" class="indexterm"></a>
Messages that have come from UUCP (and some other applications) often begin
with a line containing the envelope sender and a timestamp, following the word
“<span class="quote">From</span>”. Examples of two common formats are:
</p>
<pre class="literallayout">From a.oakley@berlin.mus Fri Jan 5 12:35 GMT 1996
From f.butler@berlin.mus Fri, 7 Jan 97 14:00:00 GMT
</pre><p>
This line precedes the RFC 2822 header lines. For compatibility with Sendmail,
Exim recognizes such lines at the start of messages that are submitted to it
via the command line (that is, on the standard input). It does not recognize
such lines in incoming SMTP messages, unless the sending host matches
<span><strong class="option">ignore_fromline_hosts</strong></span> or the <span><strong class="option">-bs</strong></span> option was used for a local message
and <span><strong class="option">ignore_fromline_local</strong></span> is set. The recognition is controlled by a
regular expression that is defined by the <span><strong class="option">uucp_from_pattern</strong></span> option, whose
default value matches the two common cases shown above and puts the address
that follows “<span class="quote">From</span>” into <em class="varname">$1</em>.
</p>
<p>
<a id="id642122" class="indexterm"></a>
When the caller of Exim for a non-SMTP message that contains a “<span class="quote">From</span>” line is
a trusted user, the message’s sender address is constructed by expanding the
contents of <span><strong class="option">uucp_sender_address</strong></span>, whose default value is “<span class="quote">$1</span>”. This is
then parsed as an RFC 2822 address. If there is no domain, the local part is
qualified with <span><strong class="option">qualify_domain</strong></span> unless it is the empty string. However, if
the command line <span><strong class="option">-f</strong></span> option is used, it overrides the “<span class="quote">From</span>” line.
</p>
<p>
If the caller of Exim is not trusted, the “<span class="quote">From</span>” line is recognized, but the
sender address is not changed. This is also the case for incoming SMTP messages
that are permitted to contain “<span class="quote">From</span>” lines.
</p>
<p>
Only one “<span class="quote">From</span>” line is recognized. If there is more than one, the second is
treated as a data line that starts the body of the message, as it is not valid
as a header line. This also happens if a “<span class="quote">From</span>” line is present in an
incoming SMTP message from a source that is not permitted to send them.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0388" id="SECID220">44.5 Resent- header lines</a></h3></div>
</div>
</div>
<p>
<a id="id642221" class="indexterm"></a>
RFC 2822 makes provision for sets of header lines starting with the string
<code class="literal">Resent-</code> to be added to a message when it is resent by the original
recipient to somebody else. These headers are <span class="emphasis"><em>Resent-Date:</em></span>,
<span class="emphasis"><em>Resent-From:</em></span>, <span class="emphasis"><em>Resent-Sender:</em></span>, <span class="emphasis"><em>Resent-To:</em></span>, <span class="emphasis"><em>Resent-Cc:</em></span>,
<span class="emphasis"><em>Resent-Bcc:</em></span> and <span class="emphasis"><em>Resent-Message-ID:</em></span>. The RFC says:
</p>
<div class="blockquote">
<blockquote class="blockquote"><p>
<span class="emphasis"><em>Resent fields are strictly informational. They MUST NOT be used in the normal
processing of replies or other such automatic actions on messages.</em></span>
</p>
</blockquote></div>
<p>
This leaves things a bit vague as far as other processing actions such as
address rewriting are concerned. Exim treats <span><strong class="option">Resent-</strong></span> header lines as
follows:
</p>
<div class="itemizedlist">
<ul type="disc"><li><p>
A <span class="emphasis"><em>Resent-From:</em></span> line that just contains the login id of the submitting user
is automatically rewritten in the same way as <span class="emphasis"><em>From:</em></span> (see below).
</p>
</li><li><p>
If there’s a rewriting rule for a particular header line, it is also applied to
<span><strong class="option">Resent-</strong></span> header lines of the same type. For example, a rule that rewrites
<span class="emphasis"><em>From:</em></span> also rewrites <span class="emphasis"><em>Resent-From:</em></span>.
</p>
</li><li><p>
For local messages, if <span class="emphasis"><em>Sender:</em></span> is removed on input, <span class="emphasis"><em>Resent-Sender:</em></span> is
also removed.
</p>
</li><li><p>
For a locally-submitted message,
if there are any <span><strong class="option">Resent-</strong></span> header lines but no <span class="emphasis"><em>Resent-Date:</em></span>,
<span class="emphasis"><em>Resent-From:</em></span>, or <span class="emphasis"><em>Resent-Message-Id:</em></span>, they are added as necessary. It is
the contents of <span class="emphasis"><em>Resent-Message-Id:</em></span> (rather than <span class="emphasis"><em>Message-Id:</em></span>) which are
included in log lines in this case.
</p>
</li><li><p>
The logic for adding <span class="emphasis"><em>Sender:</em></span> is duplicated for <span class="emphasis"><em>Resent-Sender:</em></span> when any
<span><strong class="option">Resent-</strong></span> header lines are present.
</p>
</li></ul></div>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0389" id="SECID221">44.6 The Auto-Submitted: header line</a></h3></div>
</div>
</div>
<p>
Whenever Exim generates an autoreply, a bounce, or a delay warning message, it
includes the header line:
</p>
<pre class="literallayout">Auto-Submitted: auto-replied
</pre></div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0390" id="SECID222">44.7 The Bcc: header line</a></h3></div>
</div>
</div>
<p>
<a id="id642434" class="indexterm"></a>
If Exim is called with the <span><strong class="option">-t</strong></span> option, to take recipient addresses from a
message’s header, it removes any <span class="emphasis"><em>Bcc:</em></span> header line that may exist (after
extracting its addresses). If <span><strong class="option">-t</strong></span> is not present on the command line, any
existing <span class="emphasis"><em>Bcc:</em></span> is not removed.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0391" id="SECID223">44.8 The Date: header line</a></h3></div>
</div>
</div>
<p>
<a id="id642480" class="indexterm"></a>
If a locally-generated or submission-mode message has no <span class="emphasis"><em>Date:</em></span> header line,
Exim adds one, using the current date and time, unless the
<span><strong class="option">suppress_local_fixups</strong></span> control has been specified.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0392" id="SECID224">44.9 The Delivery-date: header line</a></h3></div>
</div>
</div>
<p>
<a id="id642517" class="indexterm"></a>
<a id="id642530" class="indexterm"></a>
<span class="emphasis"><em>Delivery-date:</em></span> header lines are not part of the standard RFC 2822 header
set. Exim can be configured to add them to the final delivery of messages. (See
the generic <span><strong class="option">delivery_date_add</strong></span> transport option.) They should not be present
in messages in transit. If the <span><strong class="option">delivery_date_remove</strong></span> configuration option is
set (the default), Exim removes <span class="emphasis"><em>Delivery-date:</em></span> header lines from incoming
messages.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0393" id="SECID225">44.10 The Envelope-to: header line</a></h3></div>
</div>
</div>
<p>
<a id="id642577" class="indexterm"></a>
<a id="id642590" class="indexterm"></a>
<span class="emphasis"><em>Envelope-to:</em></span> header lines are not part of the standard RFC 2822 header set.
Exim can be configured to add them to the final delivery of messages. (See the
generic <span><strong class="option">envelope_to_add</strong></span> transport option.) They should not be present in
messages in transit. If the <span><strong class="option">envelope_to_remove</strong></span> configuration option is set
(the default), Exim removes <span class="emphasis"><em>Envelope-to:</em></span> header lines from incoming
messages.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0394" id="SECTthefrohea">44.11 The From: header line</a></h3></div>
</div>
</div>
<p>
<a id="id642636" class="indexterm"></a>
<a id="id642649" class="indexterm"></a>
<a id="id642666" class="indexterm"></a>
<a id="id642680" class="indexterm"></a>
If a submission-mode message does not contain a <span class="emphasis"><em>From:</em></span> header line, Exim
adds one if either of the following conditions is true:
</p>
<div class="itemizedlist">
<ul type="disc"><li><p>
The envelope sender address is not empty (that is, this is not a bounce
message). The added header line copies the envelope sender address.
</p>
</li><li><p>
<a id="id642713" class="indexterm"></a>
The SMTP session is authenticated and <em class="varname">$authenticated_id</em> is not empty.
</p>
<div class="orderedlist">
<ol type="1"><li><p>
<a id="id642744" class="indexterm"></a>
If no domain is specified by the submission control, the local part is
<em class="varname">$authenticated_id</em> and the domain is <em class="varname">$qualify_domain</em>.
</p>
</li><li><p>
If a non-empty domain is specified by the submission control, the local
part is <em class="varname">$authenticated_id</em>, and the domain is the specified domain.
</p>
</li><li><p>
If an empty domain is specified by the submission control,
<em class="varname">$authenticated_id</em> is assumed to be the complete address.
</p>
</li></ol></div>
</li></ul></div>
<p>
A non-empty envelope sender takes precedence.
</p>
<p>
If a locally-generated incoming message does not contain a <span class="emphasis"><em>From:</em></span> header
line, and the <span><strong class="option">suppress_local_fixups</strong></span> control is not set, Exim adds one
containing the sender’s address. The calling user’s login name and full name
are used to construct the address, as described in section <a href="ch44.html#SECTconstr" title="44.18 Constructed addresses">44.18</a>.
They are obtained from the password data by calling <em class="function">getpwuid()</em> (but see the
<span><strong class="option">unknown_login</strong></span> configuration option). The address is qualified with
<span><strong class="option">qualify_domain</strong></span>.
</p>
<p>
For compatibility with Sendmail, if an incoming, non-SMTP message has a
<span class="emphasis"><em>From:</em></span> header line containing just the unqualified login name of the calling
user, this is replaced by an address containing the user’s login name and full
name as described in section <a href="ch44.html#SECTconstr" title="44.18 Constructed addresses">44.18</a>.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0395" id="SECID226">44.12 The Message-ID: header line</a></h3></div>
</div>
</div>
<p>
<a id="id642869" class="indexterm"></a>
<a id="id642882" class="indexterm"></a>
<a id="id642897" class="indexterm"></a>
If a locally-generated or submission-mode incoming message does not contain a
<span class="emphasis"><em>Message-ID:</em></span> or <span class="emphasis"><em>Resent-Message-ID:</em></span> header line, and the
<span><strong class="option">suppress_local_fixups</strong></span> control is not set, Exim adds a suitable header line
to the message. If there are any <span class="emphasis"><em>Resent-:</em></span> headers in the message, it
creates <span class="emphasis"><em>Resent-Message-ID:</em></span>. The id is constructed from Exim’s internal
message id, preceded by the letter E to ensure it starts with a letter, and
followed by @ and the primary host name. Additional information can be included
in this header line by setting the <span><strong class="option">message_id_header_text</strong></span> and/or
<span><strong class="option">message_id_header_domain</strong></span> options.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0396" id="SECID227">44.13 The Received: header line</a></h3></div>
</div>
</div>
<p>
<a id="id642954" class="indexterm"></a>
A <span class="emphasis"><em>Received:</em></span> header line is added at the start of every message. The
contents are defined by the <span><strong class="option">received_header_text</strong></span> configuration option, and
Exim automatically adds a semicolon and a timestamp to the configured string.
</p>
<p>
The <span class="emphasis"><em>Received:</em></span> header is generated as soon as the message’s header lines
have been received. At this stage, the timestamp in the <span class="emphasis"><em>Received:</em></span> header
line is the time that the message started to be received. This is the value
that is seen by the DATA ACL and by the <em class="function">local_scan()</em> function.
</p>
<p>
Once a message is accepted, the timestamp in the <span class="emphasis"><em>Received:</em></span> header line is
changed to the time of acceptance, which is (apart from a small delay while the
-H spool file is written) the earliest time at which delivery could start.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0397" id="SECID228">44.14 The References: header line</a></h3></div>
</div>
</div>
<p>
<a id="id643026" class="indexterm"></a>
Messages created by the <span><strong class="command">autoreply</strong></span> transport include a <span class="emphasis"><em>References:</em></span>
header line. This is constructed according to the rules that are described in
section 3.64 of RFC 2822 (which states that replies should contain such a
header line), and section 3.14 of RFC 3834 (which states that automatic
responses are not different in this respect). However, because some mail
processing software does not cope well with very long header lines, no more
than 12 message IDs are copied from the <span class="emphasis"><em>References:</em></span> header line in the
incoming message. If there are more than 12, the first one and then the final
11 are copied, before adding the message ID of the incoming message.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0398" id="SECID229">44.15 The Return-path: header line</a></h3></div>
</div>
</div>
<p>
<a id="id643077" class="indexterm"></a>
<a id="id643090" class="indexterm"></a>
<span class="emphasis"><em>Return-path:</em></span> header lines are defined as something an MTA may insert when
it does the final delivery of messages. (See the generic <span><strong class="option">return_path_add</strong></span>
transport option.) Therefore, they should not be present in messages in
transit. If the <span><strong class="option">return_path_remove</strong></span> configuration option is set (the
default), Exim removes <span class="emphasis"><em>Return-path:</em></span> header lines from incoming messages.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0399" id="SECTthesenhea">44.16 The Sender: header line</a></h3></div>
</div>
</div>
<p>
<a id="id643135" class="indexterm"></a>
<a id="id643148" class="indexterm"></a>
For a locally-originated message from an untrusted user, Exim may remove an
existing <span class="emphasis"><em>Sender:</em></span> header line, and it may add a new one. You can modify
these actions by setting the <span><strong class="option">local_sender_retain</strong></span> option true, the
<span><strong class="option">local_from_check</strong></span> option false, or by using the <span><strong class="option">suppress_local_fixups</strong></span>
control setting.
</p>
<p>
When a local message is received from an untrusted user and
<span><strong class="option">local_from_check</strong></span> is true (the default), and the <span><strong class="option">suppress_local_fixups</strong></span>
control has not been set, a check is made to see if the address given in the
<span class="emphasis"><em>From:</em></span> header line is the correct (local) sender of the message. The address
that is expected has the login name as the local part and the value of
<span><strong class="option">qualify_domain</strong></span> as the domain. Prefixes and suffixes for the local part can
be permitted by setting <span><strong class="option">local_from_prefix</strong></span> and <span><strong class="option">local_from_suffix</strong></span>
appropriately. If <span class="emphasis"><em>From:</em></span> does not contain the correct sender, a <span class="emphasis"><em>Sender:</em></span>
line is added to the message.
</p>
<p>
If you set <span><strong class="option">local_from_check</strong></span> false, this checking does not occur. However,
the removal of an existing <span class="emphasis"><em>Sender:</em></span> line still happens, unless you also set
<span><strong class="option">local_sender_retain</strong></span> to be true. It is not possible to set both of these
options true at the same time.
</p>
<p>
<a id="id643245" class="indexterm"></a>
By default, no processing of <span class="emphasis"><em>Sender:</em></span> header lines is done for messages
received over TCP/IP or for messages submitted by trusted users. However, when
a message is received over TCP/IP in submission mode, and <span><strong class="option">sender_retain</strong></span> is
not specified on the submission control, the following processing takes place:
</p>
<p>
<a id="id643271" class="indexterm"></a>
First, any existing <span class="emphasis"><em>Sender:</em></span> lines are removed. Then, if the SMTP session is
authenticated, and <em class="varname">$authenticated_id</em> is not empty, a sender address is
created as follows:
</p>
<div class="itemizedlist">
<ul type="disc"><li><p>
<a id="id643301" class="indexterm"></a>
If no domain is specified by the submission control, the local part is
<em class="varname">$authenticated_id</em> and the domain is <em class="varname">$qualify_domain</em>.
</p>
</li><li><p>
If a non-empty domain is specified by the submission control, the local part
is <em class="varname">$authenticated_id</em>, and the domain is the specified domain.
</p>
</li><li><p>
If an empty domain is specified by the submission control,
<em class="varname">$authenticated_id</em> is assumed to be the complete address.
</p>
</li></ul></div>
<p>
This address is compared with the address in the <span class="emphasis"><em>From:</em></span> header line. If they
are different, a <span class="emphasis"><em>Sender:</em></span> header line containing the created address is
added. Prefixes and suffixes for the local part in <span class="emphasis"><em>From:</em></span> can be permitted
by setting <span><strong class="option">local_from_prefix</strong></span> and <span><strong class="option">local_from_suffix</strong></span> appropriately.
</p>
<p>
<a id="id643378" class="indexterm"></a>
<span class="bold"><strong>Note</strong></span>: Whenever a <span class="emphasis"><em>Sender:</em></span> header line is created, the return path for
the message (the envelope sender address) is changed to be the same address,
except in the case of submission mode when <span><strong class="option">sender_retain</strong></span> is specified.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0400" id="SECTheadersaddrem">44.17 Adding and removing header lines in routers and transports</a></h3></div>
</div>
</div>
<p>
<a id="id643426" class="indexterm"></a>
<a id="id643440" class="indexterm"></a>
When a message is delivered, the addition and removal of header lines can be
specified in a system filter, or on any of the routers and transports that
process the message. Section <a href="ch43.html#SECTaddremheasys" title="43.6 Adding and removing headers in a system filter">43.6</a> contains details about
modifying headers in a system filter. Header lines can also be added in an ACL
as a message is received (see section <a href="ch40.html#SECTaddheadacl" title="40.22 Adding header lines in ACLs">40.22</a>).
</p>
<p>
In contrast to what happens in a system filter, header modifications that are
specified on routers and transports apply only to the particular recipient
addresses that are being processed by those routers and transports. These
changes do not actually take place until a copy of the message is being
transported. Therefore, they do not affect the basic set of header lines, and
they do not affect the values of the variables that refer to header lines.
</p>
<p>
<span class="bold"><strong>Note</strong></span>: In particular, this means that any expansions in the configuration of
the transport cannot refer to the modified header lines, because such
expansions all occur before the message is actually transported.
</p>
<p>
For both routers and transports, the result of expanding a <span><strong class="option">headers_add</strong></span>
option must be in the form of one or more RFC 2822 header lines, separated by
newlines (coded as “<span class="quote">\n</span>”). For example:
</p>
<pre class="literallayout">headers_add = X-added-header: added by $primary_hostname\n\
X-added-second: another added header line
</pre><p>
Exim does not check the syntax of these added header lines.
</p>
<p>
The result of expanding <span><strong class="option">headers_remove</strong></span> must consist of a colon-separated
list of header names. This is confusing, because header names themselves are
often terminated by colons. In this case, the colons are the list separators,
not part of the names. For example:
</p>
<pre class="literallayout">headers_remove = return-receipt-to:acknowledge-to
</pre><p>
When <span><strong class="option">headers_add</strong></span> or <span><strong class="option">headers_remove</strong></span> is specified on a router, its value
is expanded at routing time, and then associated with all addresses that are
accepted by that router, and also with any new addresses that it generates. If
an address passes through several routers as a result of aliasing or
forwarding, the changes are cumulative.
</p>
<p>
<a id="id643562" class="indexterm"></a>
However, this does not apply to multiple routers that result from the use of
the <span><strong class="option">unseen</strong></span> option. Any header modifications that were specified by the
“<span class="quote">unseen</span>” router or its predecessors apply only to the “<span class="quote">unseen</span>” delivery.
</p>
<p>
Addresses that end up with different <span><strong class="option">headers_add</strong></span> or <span><strong class="option">headers_remove</strong></span>
settings cannot be delivered together in a batch, so a transport is always
dealing with a set of addresses that have the same header-processing
requirements.
</p>
<p>
The transport starts by writing the original set of header lines that arrived
with the message, possibly modified by the system filter. As it writes out
these lines, it consults the list of header names that were attached to the
recipient address(es) by <span><strong class="option">headers_remove</strong></span> options in routers, and it also
consults the transport’s own <span><strong class="option">headers_remove</strong></span> option. Header lines whose
names are on either of these lists are not written out. If there are multiple
instances of any listed header, they are all skipped.
</p>
<p>
After the remaining original header lines have been written, new header
lines that were specified by routers’ <span><strong class="option">headers_add</strong></span> options are written, in
the order in which they were attached to the address. These are followed by any
header lines specified by the transport’s <span><strong class="option">headers_add</strong></span> option.
</p>
<p>
This way of handling header line modifications in routers and transports has
the following consequences:
</p>
<div class="itemizedlist">
<ul type="disc"><li><p>
The original set of header lines, possibly modified by the system filter,
remains “<span class="quote">visible</span>”, in the sense that the <em class="varname">$header_</em><span class="emphasis"><em>xxx</em></span> variables refer
to it, at all times.
</p>
</li><li><p>
Header lines that are added by a router’s
<span><strong class="option">headers_add</strong></span> option are not accessible by means of the <em class="varname">$header_</em><span class="emphasis"><em>xxx</em></span>
expansion syntax in subsequent routers or the transport.
</p>
</li><li><p>
Conversely, header lines that are specified for removal by <span><strong class="option">headers_remove</strong></span>
in a router remain visible to subsequent routers and the transport.
</p>
</li><li><p>
Headers added to an address by <span><strong class="option">headers_add</strong></span> in a router cannot be removed by
a later router or by a transport.
</p>
</li><li><p>
An added header can refer to the contents of an original header that is to be
removed, even it has the same name as the added header. For example:
</p>
<pre class="literallayout">headers_remove = subject
headers_add = Subject: new subject (was: $h_subject:)
</pre></li></ul></div>
<p>
<span class="bold"><strong>Warning</strong></span>: The <span><strong class="option">headers_add</strong></span> and <span><strong class="option">headers_remove</strong></span> options cannot be used
for a <span><strong class="command">redirect</strong></span> router that has the <span><strong class="option">one_time</strong></span> option set.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0401" id="SECTconstr">44.18 Constructed addresses</a></h3></div>
</div>
</div>
<p>
<a id="id643769" class="indexterm"></a>
<a id="id643783" class="indexterm"></a>
When Exim constructs a sender address for a locally-generated message, it uses
the form
</p>
<div class="literallayout">
<<span class="emphasis"><em>user name</em></span>> <<span class="emphasis"><em>login</em></span><code class="literal">@</code><span class="emphasis"><em>qualify_domain</em></span>><br />
</div>
<p>
For example:
</p>
<pre class="literallayout">Zaphod Beeblebrox <zaphod@end.univ.example>
</pre><p>
The user name is obtained from the <span><strong class="option">-F</strong></span> command line option if set, or
otherwise by looking up the calling user by <em class="function">getpwuid()</em> and extracting the
“<span class="quote">gecos</span>” field from the password entry. If the “<span class="quote">gecos</span>” field contains an
ampersand character, this is replaced by the login name with the first letter
upper cased, as is conventional in a number of operating systems. See the
<span><strong class="option">gecos_name</strong></span> option for a way to tailor the handling of the “<span class="quote">gecos</span>” field.
The <span><strong class="option">unknown_username</strong></span> option can be used to specify user names in cases when
there is no password file entry.
</p>
<p>
<a id="id643873" class="indexterm"></a>
In all cases, the user name is made to conform to RFC 2822 by quoting all or
parts of it if necessary. In addition, if it contains any non-printing
characters, it is encoded as described in RFC 2047, which defines a way of
including non-ASCII characters in header lines. The value of the
<span><strong class="option">headers_charset</strong></span> option specifies the name of the encoding that is used (the
characters are assumed to be in this encoding). The setting of
<span><strong class="option">print_topbitchars</strong></span> controls whether characters with the top bit set (that
is, with codes greater than 127) count as printing characters or not.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0402" id="SECID230">44.19 Case of local parts</a></h3></div>
</div>
</div>
<p>
<a id="id643914" class="indexterm"></a>
<a id="id643925" class="indexterm"></a>
RFC 2822 states that the case of letters in the local parts of addresses cannot
be assumed to be non-significant. Exim preserves the case of local parts of
addresses, but by default it uses a lower-cased form when it is routing,
because on most Unix systems, usernames are in lower case and case-insensitive
routing is required. However, any particular router can be made to use the
original case for local parts by setting the <span><strong class="option">caseful_local_part</strong></span> generic
router option.
</p>
<p>
<a id="id643954" class="indexterm"></a>
If you must have mixed-case user names on your system, the best way to proceed,
assuming you want case-independent handling of incoming email, is to set up
your first router to convert incoming local parts in your domains to the
correct case by means of a file lookup. For example:
</p>
<pre class="literallayout">correct_case:
driver = redirect
domains = +local_domains
data = ${lookup{$local_part}cdb\
{/etc/usercased.cdb}{$value}fail}\
@$domain
</pre><p>
For this router, the local part is forced to lower case by the default action
(<span><strong class="option">caseful_local_part</strong></span> is not set). The lower-cased local part is used to look
up a new local part in the correct case. If you then set <span><strong class="option">caseful_local_part</strong></span>
on any subsequent routers which process your domains, they will operate on
local parts with the correct case in a case-sensitive manner.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0403" id="SECID231">44.20 Dots in local parts</a></h3></div>
</div>
</div>
<p>
<a id="id644011" class="indexterm"></a>
<a id="id644025" class="indexterm"></a>
RFC 2822 forbids empty components in local parts. That is, an unquoted local
part may not begin or end with a dot, nor have two consecutive dots in the
middle. However, it seems that many MTAs do not enforce this, so Exim permits
empty components for compatibility.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0404" id="SECID232">44.21 Rewriting addresses</a></h3></div>
</div>
</div>
<p>
<a id="id644058" class="indexterm"></a>
Rewriting of sender and recipient addresses, and addresses in headers, can
happen automatically, or as the result of configuration options, as described
in chapter <a href="ch31.html" title="31. Address rewriting">31</a>. The headers that may be affected by this are
<span class="emphasis"><em>Bcc:</em></span>, <span class="emphasis"><em>Cc:</em></span>, <span class="emphasis"><em>From:</em></span>, <span class="emphasis"><em>Reply-To:</em></span>, <span class="emphasis"><em>Sender:</em></span>, and <span class="emphasis"><em>To:</em></span>.
</p>
<p>
Automatic rewriting includes qualification, as mentioned above. The other case
in which it can happen is when an incomplete non-local domain is given. The
routing process may cause this to be expanded into the full domain name. For
example, a header such as
</p>
<pre class="literallayout">To: hare@teaparty
</pre><p>
might get rewritten as
</p>
<pre class="literallayout">To: hare@teaparty.wonderland.fict.example
</pre><p>
Rewriting as a result of routing is the one kind of message processing that
does not happen at input time, as it cannot be done until the address has
been routed.
</p>
<p>
Strictly, one should not do <span class="emphasis"><em>any</em></span> deliveries of a message until all its
addresses have been routed, in case any of the headers get changed as a
result of routing. However, doing this in practice would hold up many
deliveries for unreasonable amounts of time, just because one address could not
immediately be routed. Exim therefore does not delay other deliveries when
routing of one or more addresses is deferred.
<a id="id644149" class="indexterm"></a>
</p>
</div>
</div>
<div class="navfooter">
<table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch43.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch45.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div>
</body></html>
