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.
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 `From'. Examples of two common formats are:
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
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 in incoming SMTP messages, unless the sending host's IP address matches `ignore_fromline_nets' or the `-bs' option was used for a local message and `ignore_fromline_local' is set. 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'.
When the caller of Exim for a non-SMTP message 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 `From' line is recognized, but the sender address is not changed. This is also the case for incoming SMTP messages that are permitted to contain `From' lines.
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 it is not valid as a header line. This also happens if a `From' line is present in an incoming SMTP message from a source that is not permitted to send them.
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.
If a message has no `Date:' header, Exim adds one, giving the current date and time.
`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.
RFC 822 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.
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.
Go to the first, previous, next, last section, table of contents.