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, happens when a
message is received, before it is first written to the spool.

RFC 822 makes provision for headers starting with the string `Resent-'. It
states that in general, the `Resent-' fields should be treated as containing a
set of information that is independent of the set of original fields, and that
information for one set should not automatically be taken from the other. If
Exim finds any `Resent-' headers in the message, it applies the header
transformations described below only to the `Resent-' header set, leaving the
unqualified set alone.

By default, Exim expects every 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.

Exim has two pairs of options that separately control which hosts or networks
may send unqualified sender or receiver addresses in SMTP commands, namely
`sender_unqualified_hosts' and `sender_unqualified_nets', and
`receiver_unqualified_hosts' and `receiver_unqualified_nets'. In all cases,
if an unqualified address is accepted, it is qualified by adding the value of
`qualify_domain' or `qualify_receiver', as appropriate.

Any addresses that are unqualified are made fully qualified by adding
`qualify_domain' or `qualify_recipient', as appropriate. Unqualified
addresses are accepted only from local sources or from hosts that match one of
the `receiver_unqualified' or `sender_unqualified' options, as appropriate.

This line precedes the RFC 822 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 on incoming SMTP messages. The recognition is controlled by a
regular expression that is defined by the `uucp_from_pattern' option, whose
default value matches the two common cases shown above and puts the address
that follows `From' into `$1'.

If the caller of Exim is a trusted user, the message's sender address is
constructed by expanding the contents of `uucp_sender_address', whose default
value is `$1'. This is then parsed as an RFC 822 address. If there is no
domain, the local part is qualified with `qualify_domain' unless it is the
empty string.

However, if the command line `-f' option is used, it
overrides the `From' line. If the caller of Exim is not trusted, the line is
still recognized, but the sender address is not changed.

Only one `From' 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 is it not valid
as a header line. This also happens if a `From' line is present in an incoming
SMTP message.

If Exim is called with the `-t' option, to take recipient addresses from a
message's headers, it removes any `Bcc:' header that may exist (after extracting
its addresses), unless the message has no `To:' or `Cc:' header, in which case a
`Bcc:' header with no addresses is left in the message, in accordance with RFC
822. If `-t' is not present on the command line, any existing `Bcc:' header is
not removed.

If Exim is called to receive a message with the recipient addresses given on
the command line, and there is no `Bcc:', `To:', or `Cc:' header in the message,
it normally adds a `To:' header, listing the recipients. Some mailing list
software is known to submit messages in this way, and in this case the creation
of a `To:' header is not what is wanted. If the `always_bcc' option is set,
Exim adds an empty `Bcc:' header instead in this circumstance.

`Delivery-date:' headers are not part of the standard RFC 822 header set. Exim
can be configured to add them to the final delivery of messages. (See the
generic `delivery_date_add' transport option.) They should not be present in
messages in transit. If the `delivery_date_remove' configuration option is
set (the default), Exim removes `Delivery-date:' headers from incoming
messages.

`Envelope-to:' headers are not part of the standard RFC 822 header set. Exim
can be configured to add them to the final delivery of messages. (See the
generic `envelope_to_add' transport option.) They should not be present in
messages in transit. If the `envelope_to_remove' configuration option is set
(the default), Exim removes `Envelope-to:' headers from incoming messages.

If an incoming message does not contain a `From:' header, Exim adds one
containing the sender's address. This is obtained from the message's envelope
in the case of remote messages; for locally-generated messages the calling
user's login name and full name are used to construct an address, as described
in section "Constructed addresses". They are obtained from the password file entry by
calling `getpwuid()' (but see the `unknown_login' configuration option). The
address is qualified with `qualify_domain'.

For compatibility with Sendmail, if an incoming, non-SMTP message has a `From:'
header 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 "Constructed addresses".

If an incoming message does not contain a `Message-id:' header, Exim constructs
one and adds it to the message. 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 by setting the
`message_id_header_text' option.

A `Received:' header is added at the start of every message. The contents of
this header are defined by the `received_header_text' configuration option,
and Exim automatically adds a semicolon and a timestamp to the configured
string.

`Return-path:' headers are defined as something the MTA may insert when it does
the final delivery of messages. (See the generic `return_path_add' transport
option.) Therefore, they should not be present in messages in transit. If the
`return_path_remove' configuration option is set (the default), Exim removes
`Return-path:' headers from incoming messages.

For locally-originated messages, unless originated by a trusted user using the
`-f' or `-bs' command line option, any existing `Sender:' header is removed. A
check is then made to see if the address given in the `From:' header is the
correct (local) sender of the message. If not, a `Sender:' header giving the
true sender address is added to the message. No processing of the `Sender:'
header is done for messages originating externally.

If a message has no `To:', `Cc:', or `Bcc:' header, Exim adds an empty `Bcc:'
header, in accordance with RFC 822,
except when the message is being received locally with the recipients supplied
on the command line. In this case, a `To:' header listing the recipients is
normally added. Some mailing list software is known to submit messages in this
way, and in this case the creation of a `To:' header is not what is wanted. If
the `always_bcc' option is set, Exim adds an empty `Bcc:' header instead in
this circumstance. An `Apparently-to:' header is never added.

The addition and removal of headers can be specified on any of the drivers, and
also in system filter files. Changes specified in the system filter affect all
deliveries of a message.

Header changes specified on a director or router affect all addresses handled
by that driver, and also any new addresses it generates. If an address passes
through several directors and/or routers, the changes are cumulative. When a
message is processed by a transport, the message's original set of headers is
output, except for those named in any `headers_remove' options that the
address has encountered as it was processed, and any in the transport's own
`headers_remove' option. Then any new headers from any `headers_add' options
are output.

When Exim constructs a sender address for a locally-generated message, it uses
the form

<user name> <<login>@<qualify_domain>>

For example:

Zaphod Beeblebrox <zaphod@end.univ>

The user name is obtained from the `-F' command line option if set, or
otherwise by looking up the calling user by `getpwuid()' and extracing the
`gecos' field from the password entry. If the `gecos' 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
`gecos_name' option for a way to tailor the handling of the `gecos' field. The
`unknown_username' option can be used to specify user names in cases when
there is no password file entry. In all cases the user name is made to conform
to RFC 822 by quoting all or parts of it if necessary.

RFC 822 states that the case of letters in the local parts of addresses cannot
be assumed not to be significant. Exim preserves the case of local parts of
remote addresses. However, when it is processing an address in one of its local
domains, the case of letters in the local part is significant only when
the `locally_caseless' option is unset. It is set by default.

Rewriting of sender and recipient addresses, and addresses in headers, can
happen automatically, or as the result of configuration options, as described
in chapter "Address rewriting".
The headers that may be affected by this are `Bcc:', `Cc:', `From:',
`Reply-to:', `Sender:', and `To:'.

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

To: hare@teaparty

might get rewritten as

To: hare@teaparty.wonderland.fict.book

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.

Strictly, one should not do any 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.