File: spec_11.html

package info (click to toggle)
exim-html 3.20-1
links: PTS
area: main
in suites: etch, etch-m68k, sarge, woody
size: 2,868 kB
ctags: 4,188
sloc: makefile: 40; sh: 19
file content (5025 lines) | stat: -rw-r--r-- 135,487 bytes
<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.52
     from spec on 25 November 2000 -->

<TITLE>Exim Specification - 11. Main configuration</TITLE>
</HEAD>
<body bgcolor="#FFFFFF" text="#00005A" link="#FF6600" alink="#FF9933" vlink="#990000">
Go to the <A HREF="spec_1.html">first</A>, <A HREF="spec_10.html">previous</A>, <A HREF="spec_12.html">next</A>, <A HREF="spec_59.html">last</A> section, <A HREF="spec_toc.html">table of contents</A>.
<P><HR><P>


<H1><A NAME="SEC183" HREF="spec_toc.html#TOC183">11. Main configuration</A></H1>
<P>
<A NAME="IDX603"></A>
<A NAME="IDX604"></A>
<font color=green>
The first part of the run time configuration file contains the main
configuration settings. Each setting occupies one line of the file, possibly
continued by a terminating backslash. If any setting is preceded by the word
`hide', the -<EM>bP</EM> option displays its value to admin users only (see section
7.3).

</P>
<P>
All macro definitions must be in this part of the file -- they
differ from options settings by starting with an upper-case letter (see section
7.2).

</P>
<P>
The available options are listed in alphabetical order below, along with their
types and default values.
</font>

</P>

<P>

<P>
<A NAME="IDX605"></A>


<H3><A NAME="SEC184" HREF="spec_toc.html#TOC184">accept_8bitmime</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX606"></A>
<A NAME="IDX607"></A>
<A NAME="IDX608"></A>
This option causes Exim to send 8BITMIME in its response to an SMTP
EHLO command, and to accept the BODY= parameter on MAIL
commands. However, though Exim is 8-bit clean, it is not a protocol converter,
and it takes no steps to do anything special with messages received by this
route. Consequently, this option is turned off by default.

</P>
<P>
<A NAME="IDX609"></A>


<H3><A NAME="SEC185" HREF="spec_toc.html#TOC185">accept_timeout</A></H3>

<P>
Type: time<BR>
Default: 0s

</P>
<P>
<A NAME="IDX610"></A>
This sets the timeout for accepting a non-SMTP message, that is, the maximum
time that Exim waits when reading a message on the standard input. If the
value is zero, it will wait for ever. This setting is overridden by the -<EM>or</EM>
command option.
The timeout for incoming SMTP messages is controlled by
<EM>smtp_receive_timeout</EM>.

</P>
<P>
<A NAME="IDX611"></A>


<H3><A NAME="SEC186" HREF="spec_toc.html#TOC186">admin_groups</A></H3>

<P>
Type: string list<BR>
Default: unset

</P>
<P>
<A NAME="IDX612"></A>
If the current group or any of the supplementary groups of the caller is in
this list, the caller has admin privileges. If all your system programmers are
in a specific group, for example, you can give them all Exim admin privileges
by putting that group in <EM>admin_groups</EM>.
<font color=green>
However, this does not permit them to read Exim's spool files (whose group
owner is the Exim gid). To permit this, you have to add individuals to the Exim
group.
</font>

</P>
<P>
<font color=green>
<A NAME="IDX613"></A>


<H3><A NAME="SEC187" HREF="spec_toc.html#TOC187">allow_mx_to_ip</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX614"></A>
It appears that more and more DNS zones are breaking the rules and putting
IP addresses on the right hand side of MX records. Exim follows the rules and
rejects this, giving an error message that explains the mis-configuration.
However, some other MTAs support this practice, so to avoid `Why can't Exim do
this?' complaints, <EM>allow_mx_to_ip</EM> exists, in order to enable this
heinous activity. It is not recommended, except when you have no other choice.
</font>

</P>

<P>
<A NAME="IDX615"></A>


<H3><A NAME="SEC188" HREF="spec_toc.html#TOC188">always_bcc</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX616"></A>
<A NAME="IDX617"></A>
<A NAME="IDX618"></A>
Exim adds a <EM>To:</EM> header to messages whose recipients are given on the command
line when there is no <EM>To:</EM>, <EM>Cc:</EM>, or <EM>Bcc:</EM> in the message. In other cases of
missing recipient headers, it just adds an empty <EM>Bcc:</EM> header to make the
message conform with RFC 822. Setting <EM>always_bcc</EM> causes it to add an empty
<EM>Bcc:</EM> in all cases. This can be helpful in conjunction with mailing list
software that passes recipient addresses on the command line.

</P>
<P>
<font color=green>
<A NAME="IDX619"></A>


<H3><A NAME="SEC189" HREF="spec_toc.html#TOC189">auth_always_advertise</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
<A NAME="IDX620"></A>
This option is available only when Exim is compiled with authentication
support. Normally, if any server authentication mechanisms are configured, Exim
advertises them in response to any EHLO command. However, if
<EM>auth_always_advertise</EM> is set false, Exim
advertises availability of the AUTH command only if the calling host is in
<EM>auth_hosts</EM>, or if it is in <EM>host_auth_accept_relay</EM> and not in
<EM>host_accept_relay</EM>. In other words, it advertises only when the host is
required always to authenticate or to authenticate in order to relay.

</P>
<P>
Otherwise, Exim does not advertise AUTH, though it is always prepared to
accept it. Certain mail clients (for example, Netscape) require to the user to
provide a name and password for authentication if AUTH is advertised, even
though it may not be needed (the host may be in <EM>host_accept_relay</EM>).
Unsetting <EM>auth_always_advertise</EM> makes these clients more friendly in these
circumstances, while still allowing you to use combinations such as

<PRE>
host_auth_accept_relay = *
host_accept_relay = 10.9.8.0/24
</PRE>

<P>
without needing to fill up <EM>host_auth_accept_relay</EM> with exceptions.
</font>

</P>
<P>
<A NAME="IDX621"></A>


<H3><A NAME="SEC190" HREF="spec_toc.html#TOC190">auth_hosts</A></H3>

<P>
Type: host list<BR>
Default: unset

</P>
<P>
Any hosts in this list that connect to an Exim server as clients are required
to authenticate themselves using the SMTP AUTH command before any commands
other than HELO, EHLO, HELP, AUTH, NOOP, RSET, or
QUIT are accepted. See chapter 35 for details of SMTP
authentication.

</P>
<P>
<A NAME="IDX622"></A>


<H3><A NAME="SEC191" HREF="spec_toc.html#TOC191">auto_thaw</A></H3>

<P>
Type: time<BR>
Default: 0s

</P>
<P>
<A NAME="IDX623"></A>
<A NAME="IDX624"></A>
<font color=green>
If this option is set to a time greater than zero, a queue runner will try a
new delivery attempt on any frozen message if this much time has passed since
it was frozen. This may result in the message being re-frozen if nothing has
changed since the last attempt. It is a way of saying `keep on trying, even
though there are big problems'. See also <EM>timeout_frozen_after</EM>,
<EM>ignore_errmsg_errors</EM>, and <EM>ignore_errmsg_errors_after</EM>.
</font>

</P>
<P>
<A NAME="IDX625"></A>


<H3><A NAME="SEC192" HREF="spec_toc.html#TOC192">bi_command</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
This option supplies the name of a command that is run when Exim is called with
the -<EM>bi</EM> option (see chapter 5). The string value is just the
command name, it is not a complete command line. If an argument is required, it
must come from the -<EM>oA</EM> command line option.

</P>
<P>
<A NAME="IDX626"></A>


<H3><A NAME="SEC193" HREF="spec_toc.html#TOC193">check_log_inodes</A></H3>

<P>
Type: integer<BR>
Default: 0

</P>
<P>
See <EM>check_spool_space</EM> below.

</P>
<P>
<A NAME="IDX627"></A>


<H3><A NAME="SEC194" HREF="spec_toc.html#TOC194">check_log_space</A></H3>

<P>
Type: integer<BR>
Default: 0

</P>
<P>
See <EM>check_spool_space</EM> below.

</P>
<P>
<A NAME="IDX628"></A>


<H3><A NAME="SEC195" HREF="spec_toc.html#TOC195">check_spool_inodes</A></H3>

<P>
Type: integer<BR>
Default: 0

</P>
<P>
See <EM>check_spool_space</EM> below.

</P>
<P>
<A NAME="IDX629"></A>


<H3><A NAME="SEC196" HREF="spec_toc.html#TOC196">check_spool_space</A></H3>

<P>
Type: integer<BR>
Default: 0

</P>
<P>
<A NAME="IDX630"></A>
<A NAME="IDX631"></A>
<A NAME="IDX632"></A>
The four <EM>check_...</EM> options allow for checking of disc resources before a
message is accepted: <EM>check_spool_space</EM> and <EM>check_spool_inodes</EM> check the
spool partition if either value is greater than zero, for example:

<PRE>
check_spool_space = 10M
check_spool_inodes = 100
</PRE>

<P>
The spool partition is the one which contains the directory defined by
SPOOL_DIRECTORY in <TT>`Local/Makefile'</TT>.

</P>
<P>
<EM>check_log_space</EM> and <EM>check_log_inodes</EM>  check the partition
in which log files are written if either is greater than zero. These should be
set only if <EM>log_file_path</EM> is set to point to a different partition to the
spool directory.

</P>
<P>
If there is less space or fewer inodes than requested, Exim refuses to accept
incoming mail. In the case of SMTP input this is done by giving a 452 temporary
error response to the MAIL command. If ESMTP is in use and there was a
SIZE parameter on the MAIL command, its value is added to the
<EM>check_spool_space</EM> value, and the check is performed even if
<EM>check_spool_space</EM> is zero,
unless <EM>no_smtp_check_spool_space</EM> is set.

</P>
<P>
For non-SMTP input and for batched SMTP input, the test is done at start-up; on
failure a message is written to stderr and Exim exits with a non-zero code, as
it obviously cannot send an error message of any kind.

</P>
<P>
<A NAME="IDX633"></A>


<H3><A NAME="SEC197" HREF="spec_toc.html#TOC197">collapse_source_routes</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX634"></A>
<A NAME="IDX635"></A>
From version 3.10, this option is obsolete and does nothing. Formerly, it
caused source-routed mail addresses to be stripped down to their final
components. This now happens automatically, and cannot be suppressed.

</P>
<P>
<A NAME="IDX636"></A>


<H3><A NAME="SEC198" HREF="spec_toc.html#TOC198">daemon_smtp_port</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
This option specifies the numerical port number or the service name equivalent
on which the daemon is to listen for incoming SMTP calls. It is overridden by
-<EM>oX</EM> on the command line. If this option is not set, the service name `smtp'
is used.

</P>
<P>
<A NAME="IDX637"></A>


<H3><A NAME="SEC199" HREF="spec_toc.html#TOC199">daemon_smtp_service</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
This option is a synonym for <EM>daemon_smtp_port</EM>.

</P>
<P>
<A NAME="IDX638"></A>


<H3><A NAME="SEC200" HREF="spec_toc.html#TOC200">debug_level</A></H3>

<P>
Type: integer<BR>
Default: 0

</P>
<P>
This option sets the debug level, thus enabling it to be set when calling Exim
from an MUA, but it is overridden by the use of -<EM>d</EM> on the command line.

</P>
<P>
<A NAME="IDX639"></A>


<H3><A NAME="SEC201" HREF="spec_toc.html#TOC201">delay_warning</A></H3>

<P>
Type: time list<BR>
Default: 24h

</P>
<P>
<A NAME="IDX640"></A>
When a message is delayed, Exim sends a warning message to the sender at
intervals specified by this option. If it is set to a zero, no
warnings are sent. The data is a colon-separated list of times after which to
send warning messages. Up to 10 times may be given. If a message has been on
the queue for longer than the last time, the last interval between the times is
used to compute subsequent warning times. For example, with

<PRE>
delay_warning = 4h:8h:24h
</PRE>

<P>
the first message is sent after 4 hours, the second after 8 hours, and
subsequent ones every 16 hours thereafter. To stop warnings after a given time,
set a huge subsequent time.

</P>
<P>
<A NAME="IDX641"></A>


<H3><A NAME="SEC202" HREF="spec_toc.html#TOC202">delay_warning_condition</A></H3>

<P>
Type: string, expanded<BR>
Default: see below

</P>
<P>
The string is expanded at the time a warning message might be sent. If all the
deferred addresses have the same domain, it is set in $<EM>domain</EM> during the
expansion. Otherwise $<EM>domain</EM> is empty. If the result of the expansion is a
forced failure, an empty string, or a string matching any of `0', `no' or
`false' (the comparison being done caselessly) then the warning message is not
sent. The default is

<PRE>
delay_warning_condition = \
  ${if match{$h_precedence:}{(?i)bulk|list|junk}{no}{yes}}
</PRE>

<P>
which suppresses the sending of warnings about messages that have `bulk',
`list' or `junk' in a <EM>Precedence:</EM> header. Note that the colon to terminate
the header name cannot be omitted, because brace characters may legally occur
in header names.

</P>
<P>
<A NAME="IDX642"></A>


<H3><A NAME="SEC203" HREF="spec_toc.html#TOC203">deliver_load_max</A></H3>

<P>
Type: fixed-point<BR>
Default: unset

</P>
<P>
<A NAME="IDX643"></A>
When this option is set, no message deliveries are ever done if the system load
average is greater than its value, except for deliveries forced with the -<EM>M</EM>
option.
If <EM>deliver_queue_load_max</EM> is not set and
the load gets this high during a queue run, the run is abandoned.
There are some operating systems for which Exim cannot determine the load
average (see chapter 1); for these this option has no effect.

</P>
<P>
<A NAME="IDX644"></A>


<H3><A NAME="SEC204" HREF="spec_toc.html#TOC204">deliver_queue_load_max</A></H3>

<P>
Type: fixed-point<BR>
Default: unset

</P>
<P>
If this option is set, its value is used to determine whether to
abandon a queue run, instead of the value of <EM>deliver_load_max</EM>.

</P>
<P>
<A NAME="IDX645"></A>


<H3><A NAME="SEC205" HREF="spec_toc.html#TOC205">delivery_date_remove</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
<A NAME="IDX646"></A>
Exim's transports have an option for adding a <EM>Delivery-date:</EM> header to a
message when it is delivered -- in exactly the same way as <EM>Return-path:</EM> is
handled. <EM>Delivery-date:</EM> records the actual time of delivery. Such headers
should not be present in incoming messages, and this option causes them to be
removed, to avoid any problems that might occur when a delivered message is
subsequently sent on to some other recipient.

</P>
<P>
<A NAME="IDX647"></A>


<H3><A NAME="SEC206" HREF="spec_toc.html#TOC206">dns_again_means_nonexist</A></H3>

<P>
Type: domain list<BR>
Default: unset

</P>
<P>
DNS lookups give a `try again' response for the DNS error `non-Authoritive host
found or SERVERFAIL'. This can cause Exim to keep trying to deliver a
message, or to give repeated temporary errors to incoming mail. Sometimes the
effect is caused by a badly set up nameserver and may persist for a long time.
If a domain which exhibits this problem matches anything in
<EM>dns_again_means_nonexist</EM> then it is treated as if it did not
exist. This option should be used with care.

</P>
<P>
<A NAME="IDX648"></A>


<H3><A NAME="SEC207" HREF="spec_toc.html#TOC207">dns_check_names</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
This option causes Exim to check domain names for illegal characters before
handing them to the DNS resolver, because some resolvers give temporary errors
for bad names. If a domain name contains any illegal characters, a `not found'
result is forced.
The check is done by matching the domain name against the regular expression
specified by the <EM>dns_check_names_pattern</EM> option.

</P>
<P>
<A NAME="IDX649"></A>


<H3><A NAME="SEC208" HREF="spec_toc.html#TOC208">dns_check_names_pattern</A></H3>

<P>
Type: string<BR>
Default: see below

</P>
<P>
This option defines the regular expression that is used when the
<EM>dns_check_names</EM> option is set. The default value is

<PRE>
dns_check_names_pattern = \
  (?i)^(?&#62;(?(1)\.|())[^\W_](?&#62;[a-z0-9-]*[^\W_])?)+$
</PRE>

<P>
which permits only letters, digits, and hyphens in components, but they may not
start or end with a hyphen.

</P>
<P>
<A NAME="IDX650"></A>


<H3><A NAME="SEC209" HREF="spec_toc.html#TOC209">dns_retrans</A></H3>

<P>
Type: time<BR>
Default: 0s

</P>
<P>
The options <EM>dns_retrans</EM> and <EM>dns_retry</EM> can be used to set the
retransmission and retry parameters for DNS lookups. Values of zero (the
defaults) leave the system default settings unchanged. The first value is the
time between retries, and the second is the number of retries. It isn't
totally clear exactly how these settings affect the total time a DNS lookup may
take. I haven't found any documentation about timeouts on DNS lookups; these
parameter values are available in the external resolver interface structure,
but nowhere does it seem to describe how they are used or what you might want
to set in them.

</P>
<P>
<font color=green>
<A NAME="IDX651"></A>


<H3><A NAME="SEC210" HREF="spec_toc.html#TOC210">dns_ipv4_lookup</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX652"></A>
When Exim is compiled with IPv6 support, it looks for IPv6 address records
(AAAA and A6) as well as IPv4 address records when trying to find IP addresses
for hosts. However, if <EM>dns_ipv4_lookup</EM> is set, it disables DNS lookups for
AAAA and A6 records. This is a fudge to help with name servers that give big
delays or otherwise do not work for these new record types. If Exim is handed
either of these record types as part of an MX lookup (for example), it still
handles them, and may as a result make outgoing IPv6 calls. All this option
does is to make it look only for IPv4-style A records when it needs to find an
IP address for a host name. In due course, when the world's name servers have
all been upgraded, there should be no need for this option.
</font>

</P>
<P>
<A NAME="IDX653"></A>


<H3><A NAME="SEC211" HREF="spec_toc.html#TOC211">dns_retry</A></H3>

<P>
Type: integer<BR>
Default: 0

</P>
<P>
See <EM>dns_retrans</EM> above.

</P>
<P>
<A NAME="IDX654"></A>


<H3><A NAME="SEC212" HREF="spec_toc.html#TOC212">envelope_to_remove</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
<A NAME="IDX655"></A>
Exim's transports have an option for adding an
<EM>Envelope-to:</EM> header to a message when it is delivered -- in exactly the same
way as <EM>Return-path:</EM> is handled. <EM>Envelope-to:</EM> records the original recipient
address in the envelope that caused the delivery. Such headers should not be
present in incoming messages, and this option causes them to be removed, to
avoid any problems that might occur when a delivered message is subsequently
sent on to some other recipient.

</P>
<P>
<A NAME="IDX656"></A>


<H3><A NAME="SEC213" HREF="spec_toc.html#TOC213">errmsg_text</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
If <EM>errmsg_text</EM> is set, its contents are included in the default error
message immediately after `This message was created automatically by mail
delivery software.' It is not used if <EM>errmsg_file</EM> is set.

</P>
<P>
<A NAME="IDX657"></A>


<H3><A NAME="SEC214" HREF="spec_toc.html#TOC214">errmsg_file</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
<A NAME="IDX658"></A>
<A NAME="IDX659"></A>
This option defines a template file containing paragraphs of text to be used
for constructing the message which is sent by Exim in the case of a
delivery failure. Details of the file's contents are given in chapter
39. See also <EM>warnmsg_file</EM>.

</P>
<P>
<A NAME="IDX660"></A>


<H3><A NAME="SEC215" HREF="spec_toc.html#TOC215">errors_address</A></H3>

<P>
Type: string<BR>
Default: "postmaster"

</P>
<P>
<A NAME="IDX661"></A>
The mail address to which Exim will send certain error reports. As the default
is specified without a domain, it will be sent to the domain specified by the
<EM>qualify_recipient</EM> option. If this address is specified with a domain, it
must be a fully qualified domain.
<font color=green>
There are actually only a few situations where this address is used:

</P>

<UL>

<LI>

When <EM>freeze_tell_mailmaster</EM> is set, and a message that is not a failing,
locally generated bounce message is frozen. However, if the <EM>errors_address</EM>
is one of the recipients of the frozen message, nothing is sent, in order to
avoid potential loops.

<LI>

Delivery failed, and there is no other address to which a bounce message can be
sent, except for bounce messages that are timing out (they are just discarded).

<LI>

-<EM>Mg</EM> was used to cancel delivery, and there is no other address to which to
send a message.
</UL>

<P>
</font>

</P>
<P>
<A NAME="IDX662"></A>


<H3><A NAME="SEC216" HREF="spec_toc.html#TOC216">errors_copy</A></H3>

<P>
Type: string list, expanded<BR>
Default: unset

</P>
<P>
<A NAME="IDX663"></A>
Setting this option causes Exim to send bcc copies of delivery failure reports
that it generates
to other addresses. The value is a colon-separated list of items; each item
consists of a pattern and an address list, separated by white space. If the
pattern matches the recipient of the delivery error report, the message is
copied to the addresses on the list. The items are scanned in order, and once a
matching one is found, no further items are examined. For example:

<PRE>
errors_copy = spqr@mydomain   postmaster@mydomain :\
              rqps@mydomain   mailmaster@mydomain,\
                              postmaster@mydomain
</PRE>

<P>
Each pattern can be a single regular expression, indicated by starting it with
a circumflex; alternatively, either portion (local part, domain) can
start with an asterisk, or the domain can be in any format that is acceptable
as an item in a domain list, including a file lookup. A regular expression is
matched against the entire (fully qualified) recipient; non-regular expressions
must contain both a local part and domain, separated by @.

</P>
<P>
The address list is a string which is expanded, and must end up as a
comma-separated list of addresses. It is used to construct a <EM>Bcc:</EM> header which
is added to the error message. The expansion variables $<EM>local_part</EM> and
$<EM>domain</EM> are set from the original recipient of the error message, and if
there was any wildcard matching, the expansion variables $<EM>0</EM>, $<EM>1</EM>, etc. are
set in the normal way.

</P>
<P>
<A NAME="IDX664"></A>


<H3><A NAME="SEC217" HREF="spec_toc.html#TOC217">errors_reply_to</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
Exim's delivery error messages contain the header

<PRE>
From: Mail Delivery System &#60;Mailer-Daemon@${qualify_domain}&#62;
</PRE>

<P>
(where string expansion notation is used to show a variable substitution).
Experience shows that a large number of people reply to such messages. If the
<EM>errors_reply_to</EM> option is set, a <EM>Reply-To:</EM> header is added. The option
must specify the complete header body.

</P>
<P>
<A NAME="IDX665"></A>


<H3><A NAME="SEC218" HREF="spec_toc.html#TOC218">exim_group</A></H3>

<P>
Type: string<BR>
Default: compile-time configured (can be unset)

</P>
<P>
<A NAME="IDX666"></A>
This option sets the gid under which Exim runs when it gives up root privilege.
It is used only when <EM>exim_user</EM> is also set. Unless it consists entirely of
digits, the string is looked up using <EM>getgrnam()</EM>, and failure causes a
configuration error. See chapter 55 for a discussion of security
issues.

</P>
<P>
<A NAME="IDX667"></A>


<H3><A NAME="SEC219" HREF="spec_toc.html#TOC219">exim_path</A></H3>

<P>
Type: string<BR>
Default: see below

</P>
<P>
This option specifies the path name of the Exim binary, which is used when Exim
needs to re-exec itself. The default is set up to point to the file <EM>exim</EM> in
the directory configured at compile time by the BIN_DIRECTORY setting. It
is necessary to change <EM>exim_path</EM> if Exim is run from some other place.

</P>
<P>
<A NAME="IDX668"></A>


<H3><A NAME="SEC220" HREF="spec_toc.html#TOC220">exim_user</A></H3>

<P>
Type: string<BR>
Default: compile-time configured (can be unset)

</P>
<P>
<A NAME="IDX669"></A>
This option sets the uid under which Exim runs when it gives up root privilege.
However, unless there is some compelling reason for not doing so, it is best to
specify the uid by setting EXIM_UID in <TT>`Local/Makefile'</TT> rather than using
this option, because ownership of the run time configuration file and the use of
the -<EM>C</EM> and -<EM>D</EM> command line options is checked against the compile-time
setting of this parameter, not what is set here.

</P>
<P>
Unless it consists entirely of digits, the string is looked up using
<EM>getpwnam()</EM>, and failure causes a configuration error. If <EM>exim_group</EM> is not
also supplied, the gid is taken from the result of <EM>getpwnam()</EM> if it is used.
If the resulting uid is the root uid, it has the effect of unsetting this
option. See chapter 55 for a discussion of security issues.

</P>

<P>
<A NAME="IDX670"></A>


<H3><A NAME="SEC221" HREF="spec_toc.html#TOC221">extract_addresses_remove_arguments</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
According to Sendmail documentation, if any addresses are present on the
command line when the -<EM>t</EM> option is used to build an envelope from a message's
headers, they are removed from the recipients list. This is also how Smail
behaves. However, it has been reported that some versions of Sendmail in fact
add the argument addresses to the recipients list. By default Exim follows the
documented behaviour, but if this option is set false it adds rather than
removes argument addresses.

</P>
<P>
<A NAME="IDX671"></A>


<H3><A NAME="SEC222" HREF="spec_toc.html#TOC222">finduser_retries</A></H3>

<P>
Type: integer<BR>
Default: 0

</P>
<P>
On systems running NIS or other schemes in which user and group information is
distributed from a remote system, there can be times when <EM>getpwnam()</EM> and
related functions fail, even when given valid data, because things time out.
Unfortunately these failures cannot be distinguished from genuine `not found'
errors. If <EM>finduser_retries</EM> is set greater than zero, Exim will try that
many extra times to find a user or a group, waiting for one second between
tries.

</P>
<P>
<A NAME="IDX672"></A>


<H3><A NAME="SEC223" HREF="spec_toc.html#TOC223">forbid_domain_literals</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX673"></A>
If this option is set, the RFC 822 domain literal format is not permitted in
addresses.
The option is set in the default configuration file, because the domain literal
format is not normally required these days, and few people know about it.
It has, however, been exploited by mail abusers.

</P>
<P>
<A NAME="IDX674"></A>


<H3><A NAME="SEC224" HREF="spec_toc.html#TOC224">freeze_tell_mailmaster</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
On encountering certain errors, Exim freezes a message, which means that no
further delivery attempts take place until an administrator thaws it. If this
option is set, a message is sent to <EM>errors_address</EM> every time a message is
frozen, unless the message is itself a delivery error message. (Without this
exception there is the possibility of looping.)
If several of the message's addresses cause freezing, only a single message is
sent to the mail administrator. The reason(s) for freezing will be found in the
message log.

</P>
<P>
<A NAME="IDX675"></A>


<H3><A NAME="SEC225" HREF="spec_toc.html#TOC225">gecos_name</A></H3>

<P>
Type: string, expanded<BR>
Default: unset

</P>
<P>
<A NAME="IDX676"></A>
Some operating systems, notably HP-UX, use the `gecos' field in the system
password file to hold other information in addition to users' real names. Exim
looks up this field for use when it is creating <EM>Sender:</EM> or <EM>From:</EM> headers. If
either <EM>gecos_pattern</EM> or <EM>gecos_name</EM> are unset, the contents of the field
are used unchanged,
except that, if an ampersand is encountered, it is replaced by the user's
login name with the first character forced to upper-case, since this is a
convention that is observed on many systems.

</P>
<P>
When these options are set, <EM>gecos_pattern</EM> is treated as a regular
expression that is to be applied to the field
(again with &#38; replaced by the login name),
and if it matches, <EM>gecos_name</EM> is expanded and used as the user's name.
Numeric variables such as $<EM>1</EM>, $<EM>2</EM>, etc. can be used in the expansion to
pick up sub-fields that were matched by the pattern. In HP-UX, where the user's
name terminates at the first comma, the following can be used:

<PRE>
gecos_pattern = ([^,]*)
gecos_name = $1
</PRE>

<P>
<A NAME="IDX677"></A>


<H3><A NAME="SEC226" HREF="spec_toc.html#TOC226">gecos_pattern</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
See <EM>gecos_name</EM> above.

</P>
<P>
<A NAME="IDX678"></A>


<H3><A NAME="SEC227" HREF="spec_toc.html#TOC227">headers_check_syntax</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX679"></A>
<A NAME="IDX680"></A>
This option causes Exim to check the syntax of all headers that can contain
lists of addresses (<EM>Sender:</EM>, <EM>From:</EM>, <EM>Reply-To:</EM>, <EM>To:</EM>, <EM>Cc:</EM>, and <EM>Bcc:</EM>)
on all incoming messages (both local and SMTP). This is a syntax check only, to
catch real junk such as

<PRE>
To: user@
</PRE>

<P>
Like the <EM>headers_sender_verify</EM> options, the rejection happens after the end
of the data, but it is also controlled by <EM>headers_checks_fail</EM>; if that is
unset, the message is accepted and a warning is written to the reject log.

</P>
<P>
If the message contains any headers starting with <TT>`Resent-'</TT> then it is that
set of headers which is checked.

</P>
<P>
<A NAME="IDX681"></A>


<H3><A NAME="SEC228" HREF="spec_toc.html#TOC228">headers_checks_fail</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
If this option is true, failure of any header check (see below) causes the
message to be rejected. If it is false, a warning message is written to the
reject log.

</P>
<P>
<A NAME="IDX682"></A>


<H3><A NAME="SEC229" HREF="spec_toc.html#TOC229">headers_sender_verify</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX683"></A>
<A NAME="IDX684"></A>
If this option is set with <EM>sender_verify</EM>, and the sending host
matches <EM>sender_verify_hosts</EM>,
Exim insists on there being at least one verifyable address in one of the
<EM>Sender:</EM>, <EM>Reply-To:</EM>, or <EM>From:</EM> headers (which are checked in that order) on
all incoming SMTP messages. If one cannot be found, the message is rejected,
unless <EM>headers_checks_fail</EM> is unset, in which case a warning entry is
written to the reject log.

</P>
<P>
If there are any headers whose names start with <TT>`Resent-'</TT>, it is that set
of headers which is checked. If there is more than one instance of a particular
header, all of them are checked.

</P>

<P>
Unfortunately, because it has to read the message before doing this check, the
rejection happens after the end of the data, and it is known that some mailers
do not treat hard (5xx) errors correctly at this point -- they keep the message
on their spools and try again later, but that is their problem, though it does
waste some resources.

</P>
<P>
<A NAME="IDX685"></A>


<H3><A NAME="SEC230" HREF="spec_toc.html#TOC230">headers_sender_verify_errmsg</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
This option acts like <EM>headers_sender_verify</EM>, except that it applies only to
messages whose envelope sender is `&#60;&#62;', that is, delivery error messages whose
sender cannot be verified at the time the SMTP MAIL command is
received.

</P>
<P>
<A NAME="IDX686"></A>


<H3><A NAME="SEC231" HREF="spec_toc.html#TOC231">helo_accept_junk_hosts</A></H3>

<P>
Type: host list<BR>
Default: unset

</P>
<P>
<A NAME="IDX687"></A>
<A NAME="IDX688"></A>
Exim checks the syntax of HELO and EHLO commands for incoming SMTP
mail, and gives an error response for invalid data. Unfortunately, there are
some SMTP clients that send syntactic junk. They can be accommodated by setting
this option.

</P>
<P>
<A NAME="IDX689"></A>


<H3><A NAME="SEC232" HREF="spec_toc.html#TOC232">helo_strict_syntax</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
Because so many systems have been found to use underscores in the names they
send in the SMTP HELO command, Exim by default permits them, though it is
not in fact legal to use underscores in domain names
in SMTP.
If <EM>helo_strict_syntax</EM> is set, underscores are not permitted in HELO or
EHLO commands.

</P>
<P>
<A NAME="IDX690"></A>


<H3><A NAME="SEC233" HREF="spec_toc.html#TOC233">helo_verify</A></H3>

<P>
Type: host list<BR>
Default: unset

</P>
<P>
The RFCs mandate that a server must not reject a message because it doesn't
like the HELO or EHLO command. However, some sites like to be stricter.
If <EM>helo_verify</EM> is set, Exim checks each incoming call from any host that
matches it, and accepts the call only if:

</P>

<UL>

<LI>

A HELO or EHLO command is received;
</UL>

<P>
and

</P>

<UL>

<LI>

The host name given in that command either:


<OL>

<LI>

is an IP literal matching the calling address of the host (the RFCs
specifically allow this),
or

<LI>

<A NAME="IDX691"></A>
<A NAME="IDX692"></A>
matches the host name that Exim obtains by doing a reverse lookup
of the calling host address, or

<LI>

when looked up using <EM>gethostbyname()</EM> yields the calling host address.
</OL>

</UL>

<P>
If no HELO or EHLO is given, MAIL commands are rejected; if a
bad HELO or EHLO is given, it is rejected with a 550 error. Rejections
are logged in the main and reject logs.

</P>
<P>
<A NAME="IDX693"></A>


<H3><A NAME="SEC234" HREF="spec_toc.html#TOC234">hold_domains</A></H3>

<P>
Type: domain list<BR>
Default: unset

</P>
<P>
This option allows mail for particular domains to be held on the queue
manually. The option is overridden if a message delivery is forced with the
-<EM>M</EM>, -<EM>qf</EM>,
-<EM>Rf</EM> or -<EM>Sf</EM>
options. Otherwise, if a domain matches an item in <EM>hold_domains</EM>, no routing
or delivery for that address is done, and it is deferred every time the message
is looked at.

</P>
<P>
This option is intended as a temporary operational measure for delaying the
delivery of mail while some problem is being sorted out, or some new
configuration tested. It does not override Exim's message clearing away code,
which removes messages from the queue if they have been there longer than the
longest retry time in any retry rule. If you want to hold messages for longer
than the normal retry times, insert a dummy retry rule with a long retry time.

</P>
<P>
<A NAME="IDX694"></A>


<H3><A NAME="SEC235" HREF="spec_toc.html#TOC235">host_accept_relay</A></H3>

<P>
Type: host list<BR>
Default: unset

</P>
<P>
<A NAME="IDX695"></A>
<A NAME="IDX696"></A>
This option provides a list of hosts that are permitted to relay via the local
host to any arbitrary domains. Section 46.4 contains a discussion
of relay control.

</P>
<P>
<A NAME="IDX697"></A>


<H3><A NAME="SEC236" HREF="spec_toc.html#TOC236">host_auth_accept_relay</A></H3>

<P>
Type: host list<BR>
Default: unset 7

</P>
<P>
This option provides a list of hosts that are permitted to relay via the local
host to any arbitrary domains, provided the calling host has authenticated
itself. Section 46.4 contains a discussion of relay control, and
chapter 35 discusses authentication.

</P>

<P>
<A NAME="IDX698"></A>


<H3><A NAME="SEC237" HREF="spec_toc.html#TOC237">host_lookup</A></H3>

<P>
Type: host list<BR>
Default: unset

</P>
<P>
<A NAME="IDX699"></A>
Exim does not look up the name of a calling host from its IP address unless it
is required to compare against some host list, or <EM>helo_verify</EM> is set, or the
address matches this option (which normally contains IP addresses rather than
host names, since the presence of names in itself implies a DNS lookup). The
default configuration file contains
<font color=green>

<PRE>
host_lookup = *
</PRE>

<P>
</font>
which causes a lookup to happen for all hosts. If the expense of these lookups
is felt to be too great, the setting can be changed or removed. However, Exim
always does a lookup if the domain name quoted in a HELO or EHLO
command is the local host's own name or any of its local mail domains.

</P>
<P>
<A NAME="IDX700"></A>


<H3><A NAME="SEC238" HREF="spec_toc.html#TOC238">host_reject</A></H3>

<P>
Type: host list<BR>
Default: unset

</P>
<P>
If this option is set, incoming SMTP calls from the hosts listed (possibly also
qualified by an RFC 1413 identification) are rejected
as soon as the connection is made. See chapter 46 for more
details.

</P>
<P>
<A NAME="IDX701"></A>


<H3><A NAME="SEC239" HREF="spec_toc.html#TOC239">host_reject_recipients</A></H3>

<P>
Type: host list<BR>
Default: unset

</P>
<P>
If this option is set, all recipients in incoming SMTP calls from the hosts
listed, possibly also qualified by an RFC 1413 identification, are rejected.
Chapter 46 contains details of this facility, which differs
from <EM>host_reject</EM> only in the point in the SMTP dialogue at which the
rejection occurs.

</P>

<P>
<A NAME="IDX702"></A>


<H3><A NAME="SEC240" HREF="spec_toc.html#TOC240">hosts_treat_as_local</A></H3>

<P>
Type: domain list<BR>
Default: unset

</P>
<P>
<A NAME="IDX703"></A>
If this option is set, any host names that match the domain list are treated
as if they were the local host when Exim is scanning host lists obtained from
MX records,
and also at other times when it is checking whether a host to which a message
has been routed is the local host. If it is required that the matching host
names also be treated as local domains for mail delivery, they must appear
in <EM>local_domains</EM> as well as in this option.

</P>
<P>
See also the <EM>allow_localhost</EM> option in the <EM>smtp</EM> transport. Both these
options are needed in a setup with different hosts for incoming and outgoing
mail if the resulting system is used for MX backup.

</P>

<P>
<A NAME="IDX704"></A>


<H3><A NAME="SEC241" HREF="spec_toc.html#TOC241">ignore_errmsg_errors</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX705"></A>
<A NAME="IDX706"></A>
If this option is set, failed addresses in error reports (that is, bounce
messages, whose senders are `&#60;&#62;') are discarded (with a log entry). The default
action is to freeze such messages for human attention.

</P>
<P>
<A NAME="IDX707"></A>


<H3><A NAME="SEC242" HREF="spec_toc.html#TOC242">ignore_errmsg_errors_after</A></H3>

<P>
Type: time<BR>
Default: 0s

</P>
<P>
<A NAME="IDX708"></A>
<A NAME="IDX709"></A>
This option, if it is set to a non-zero time, acts as a delayed version of
<EM>ignore_errmsg_errors</EM>, which must be unset for this option to take effect.
<font color=green>
When an error message that was frozen because of delivery failure has been on
the queue for more than the given time, it it unfrozen at the next queue run,
and a further delivery it attempted. If delivery fails again, the error message
is discarded. This makes it possible to keep failed error messages around for a
shorter time than the normal maximum retry time for frozen messages. For
example,

<PRE>
ignore_errmsg_errors_after = 12h
</PRE>

<P>
retries failed error message deliveries after 12 hours, discarding any further
failures. For ways of automatically dealing with other kinds of frozen message,
see <EM>auto_thaw</EM> and <EM>timeout_frozen_after</EM>.
</font>

</P>
<P>
<A NAME="IDX710"></A>


<H3><A NAME="SEC243" HREF="spec_toc.html#TOC243">ignore_fromline_hosts</A></H3>

<P>
Type: host list<BR>
Default: unset

</P>
<P>
<A NAME="IDX711"></A>
<A NAME="IDX712"></A>
Some broken SMTP clients insist on sending a UUCP-like `From' line before the
headers of a message. By default this is treated as the start of the message's
body, which means that any following headers are not recognized as such. Exim
can be made to ignore it by setting <EM>ignore_fromline_hosts</EM> to match those
hosts that insist on sending it. If the sender is actually a local process
rather than a remote host, and is using -<EM>bs</EM> to inject the messages,
<EM>ignore_fromline_local</EM> can be set to deal with this case.

</P>
<P>
<A NAME="IDX713"></A>


<H3><A NAME="SEC244" HREF="spec_toc.html#TOC244">ignore_fromline_local</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
See <EM>ignore_fromline_hosts</EM> above.

</P>
<P>
<A NAME="IDX714"></A>


<H3><A NAME="SEC245" HREF="spec_toc.html#TOC245">keep_malformed</A></H3>

<P>
Type: time<BR>
Default: 4d

</P>
<P>
This option specifies the length of time to keep messages whose spool files
have been corrupted in some way. This should, of course, never happen. At the
next attempt to deliver such a message, it gets removed. The incident is
logged.

</P>
<P>
<A NAME="IDX715"></A>


<H3><A NAME="SEC246" HREF="spec_toc.html#TOC246">kill_ip_options</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
<A NAME="IDX716"></A>
<A NAME="IDX717"></A>
<A NAME="IDX718"></A>
IP packets can contain options which are <EM>source routing</EM> data that
enables one host to pretend to be another. (Don't confuse IP source routing
with source-routed mail addresses, which are something entirely different.)
IP source routing is an obvious security risk, and many sites lock out such
packets in their routers. Also, some operating systems are able to disable IP
source routing at the kernel level.

</P>
<P>
If Exim receives an SMTP call with IP options set, it logs the options if
<EM>log_ip_options</EM> is set. Then, if <EM>refuse_ip_options</EM> is set, it drops the
call; otherwise, if <EM>kill_ip_options</EM> is set, it unsets the options on the
outgoing socket and attempts to continue.
<A NAME="IDX719"></A>
To read the IP options, <EM>getsockopt()</EM> is used. On some versions of SunOS 4.1
this causes system crashes. There is a patch that fixes this problem, but it
can be avoided by setting all three Exim options false.

</P>
<P>
<A NAME="IDX720"></A>


<H3><A NAME="SEC247" HREF="spec_toc.html#TOC247">ldap_default_servers</A></H3>

<P>
Type: string list<BR>
Default: unset

</P>
<P>
This option provides a list of LDAP servers which are tried in turn when an
LDAP query does not contain a server. See section 6.11. The option is
available only when Exim has been built with LDAP support.

</P>

<P>
<A NAME="IDX721"></A>


<H3><A NAME="SEC248" HREF="spec_toc.html#TOC248">local_domains</A></H3>

<P>
Type: domain list<BR>
Default: see below

</P>
<P>
This specifies a list of domains which are recognized as `local', that is,
their delivery
is handled in a special way by this MTA using directors rather than routers.
If this option is not set, it defaults to the value of <EM>qualify_recipient</EM>.

</P>
<P>
The name of the local host is not by default recognized as a local mail
domain; either it must be included in <EM>local_domains</EM>, or the
<EM>local_domains_include_host</EM> option must be set.
<A NAME="IDX722"></A>
If you want to accept mail addressed to your host in RFC 822 domain literal
format, <EM>local_domains</EM> must also include the appropriate `domains',
consisting of IP addresses enclosed in square brackets. The
<EM>local_domains_include_host_literals</EM> option can be set to add all IP
addresses automatically.

</P>
<P>
It is possible to specify <EM>no</EM> local domains by specifying no data for this
option,
for example,

<PRE>
local_domains =
</PRE>

<P>
If there are very many local domains, they can be stored in a file and
looked up whenever this string is searched. See the discussion of domain lists
in section 7.12.

</P>
<P>
<A NAME="IDX723"></A>


<H3><A NAME="SEC249" HREF="spec_toc.html#TOC249">local_domains_include_host</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
If this option is set, the value of <EM>primary_hostname</EM> is added to the value
of <EM>local_domains</EM>, unless it is already present. This makes it possible to
use the same configuration file on a number of different hosts.
The same effect can be obtained by including the conventional item `@' (which
matches the primary host name) in <EM>local_domains</EM>.

</P>
<P>
<A NAME="IDX724"></A>


<H3><A NAME="SEC250" HREF="spec_toc.html#TOC250">local_domains_include_host_literals</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX725"></A>
<A NAME="IDX726"></A>
<A NAME="IDX727"></A>
If this option is set and <EM>local_interfaces</EM> is unset, the IP addresses of all
the interfaces on the local host, with the exception of 127.0.0.1 (and ::1 on
IPv6 systems), are added to the value of <EM>local_domains</EM>, in domain literal
format, that is, as strings enclosed in square brackets. If <EM>local_interfaces</EM>
is set, only those addresses it contains (again excluding 127.0.0.1 and
::1) are used.

</P>

<P>
<font color=green>
<A NAME="IDX728"></A>


<H3><A NAME="SEC251" HREF="spec_toc.html#TOC251">local_from_check</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
<A NAME="IDX729"></A>
<A NAME="IDX730"></A>
When a message is submitted locally (that is, not over a TCP/IP
connection) by a non-trusted user, Exim checks that the <EM>From:</EM> header line
matches the login of the calling user, and if not, it adds a <EM>Sender:</EM> header.
If <EM>local_from_check</EM> is set false, this checking is disabled, and no
<EM>Sender:</EM> header is ever added. Nevertheless, the envelope sender is still
forced to be the login id at the qualify domain.

</P>
<P>
<A NAME="IDX731"></A>


<H3><A NAME="SEC252" HREF="spec_toc.html#TOC252">local_from_prefix</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
When Exim checks the <EM>From:</EM> header line of locally submitted messages for
matching the login id (see <EM>local_from_check</EM> above), it can be
configured to ignore certain prefixes and suffixes in the local part of the
address. This is done by setting <EM>local_from_prefix</EM> and/or
<EM>local_from_suffix</EM> to appropriate lists, in the same form as the prefix and
suffix options of directors (see chapter 21).
For example, if

<PRE>
local_from_prefix = *-
</PRE>

<P>
is set, then a <EM>From:</EM> line containing

<PRE>
From: anything-user@your.domain
</PRE>

<P>
will not cause a <EM>Sender:</EM> header to be added if <EM>user@your.domain</EM> matches
the actual sender address that is constructed from the login name and qualify
domain.

</P>
<P>
<A NAME="IDX732"></A>


<H3><A NAME="SEC253" HREF="spec_toc.html#TOC253">local_from_suffix</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
See <EM>local_from_prefix</EM> above.
</font>

</P>

<P>
<A NAME="IDX733"></A>


<H3><A NAME="SEC254" HREF="spec_toc.html#TOC254">local_interfaces</A></H3>

<P>
Type: string list<BR>
Default: unset

</P>
<P>
<A NAME="IDX734"></A>
<A NAME="IDX735"></A>
<A NAME="IDX736"></A>
<A NAME="IDX737"></A>
The string must contain a list of IP addresses, in dotted-quad format for IPv4
addresses, or in colon-separated format (with colons doubled) for IPv6
addresses. These are used for two different purposes:

</P>

<UL>

<LI>

When a daemon is started to listen for incoming SMTP calls, it listens only on
the interfaces identified here, that is,
<A NAME="IDX738"></A>
<A NAME="IDX739"></A>
it calls <EM>bind()</EM> for these interfaces only. An error occurs if it is unable
to bind a listening socket to any interface.

<LI>

<A NAME="IDX740"></A>
Only the IP addresses listed here are taken as the local host's addresses when
routing mail and checking for mail loops.
</UL>

<P>
If <EM>local_interfaces</EM> is unset, the daemon issues a generic <EM>listen()</EM> that
accepts incoming calls from any interface, and it also gets a complete list of
available interfaces and treats them all as local when routing mail. On most
systems the default action is what is wanted. However, some systems set up
large numbers of virtual interfaces in order to provide many different virtual
web servers. In these cases <EM>local_interfaces</EM> can be used to restrict SMTP
traffic to one or two interfaces only. See also <EM>hosts_treat_as_local</EM>.

</P>

<P>
<A NAME="IDX741"></A>


<H3><A NAME="SEC255" HREF="spec_toc.html#TOC255">localhost_number</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
<A NAME="IDX742"></A>
<A NAME="IDX743"></A>
Exim's message ids are normally unique only within the local host. If
uniqueness among a set of hosts is required, each host must set a
different value for the <EM>localhost_number</EM> option. The string is expanded
immediately after reading the configuration file (so that a number can be
computed from the host name, for example) and the result of the expansion must
be a number in the range 0--255. This is available in subsequent string
expansions via the variable $<EM>localhost_number</EM>.
The final two characters of the message id, instead of just being a sequence
count of the number of messages received by one process in one second, are the
base 62 encoding of

<PRE>
&#60;<EM>sequence count</EM>&#62; * 256 + &#60;<EM>local host number</EM>&#62;
</PRE>

<P>
This reduces the possible range of the sequence count to 0--14. If the count
ever reaches 14 in a receiving process, a delay of one second is imposed to
allow the clock to tick, thereby allowing the count to be reset to zero.

</P>

<P>
<A NAME="IDX744"></A>


<H3><A NAME="SEC256" HREF="spec_toc.html#TOC256">locally_caseless</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
<A NAME="IDX745"></A>
<A NAME="IDX746"></A>
<font color=green>
Domains in mail addresses are specified as being case-independent, but this it
not true of local parts. For most Unix systems, however, it is desirable that
local parts of local mail addresses be treated in a case-independent manner,
since most users expect that mail to <EM>OBailey</EM> and <EM>obailey</EM>, for example, will
end up in the same mailbox. By default, when it is processing an address whose
domain is local, Exim lower-cases the local part at the start of processing,
</font>
on the assumption that account names in the password file are in lower-case.

</P>
<P>
For installations that want to draw case distinctions, this option is
provided. When turned off, local local parts are handled verbatim
during delivery. If there are names containing upper case letters in the
password file, the most convenient way to provide for caseless mail delivery is
to set up a <EM>smartuser</EM> director as the first director, and to make it do a
lowercased lookup of the local part, in order to translate it to the correctly
cased version, using the <EM>new_address</EM> option.

</P>
<P>
<A NAME="IDX747"></A>


<H3><A NAME="SEC257" HREF="spec_toc.html#TOC257">log_all_parents</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX748"></A>
This option applies to deliveries of local addresses, where the original
envelope address may be converted by (for example) an alias file into a `child'
address which might itself be an alias. Thus in general there can be a chain of
several addresses between the original one and the address to which the actual
delivery is made. By default Exim logs the final address, followed by the
original address in angle bracket.

</P>
<P>
Turning <EM>log_all_parents</EM> on causes all intermediate addresses between the
original envelope address and the final delivery address to be included in
delivery log lines in parentheses after the first address. Without this,
intermediate addresses are not included, except that if the final delivery is
to a pipe or file or autoreply, the immediately preceding parent address is
listed.

</P>
<P>
<A NAME="IDX749"></A>


<H3><A NAME="SEC258" HREF="spec_toc.html#TOC258">log_arguments</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX750"></A>
<A NAME="IDX751"></A>
Setting this option causes Exim to write the arguments with which it was called
to the main log. This is a debugging feature, added to make it easy to find out
with what arguments certain MUAs call <EM>/usr/lib/sendmail</EM>. The logging does not
happen if Exim has given up root privilege because it was called with the -<EM>C</EM>
or -<EM>D</EM> options.
This facility cannot log illegal arguments, because the arguments are checked
before the configuration file is read. The only way to log such cases is to
interpose a script such as <EM>util/logargs.sh</EM> between the caller and Exim.

</P>
<P>
<A NAME="IDX752"></A>


<H3><A NAME="SEC259" HREF="spec_toc.html#TOC259">log_file_path</A></H3>

<P>
Type: string list<BR>
Default: set at compile time

</P>
<P>
This option sets the path which is used to determine the names of Exim's log
files, or indicates that logging is to be to <EM>syslog</EM>, or both. Chapter
51 contains further details. If this string is fixed
at your installation (contains no expansion variables) it is recommended that
you do not set this option in the configuration file, but instead supply the
path using LOG_FILE_PATH in <TT>`Local/Makefile'</TT> so that it is available to
Exim for logging errors detected early on -- in particular failure to read the
configuration file.

</P>
<P>
If no specific path is set for the log files, they are written in a
sub-directory called <EM>log</EM> in Exim's spool directory.

</P>
<P>
<font color=green>
<A NAME="IDX753"></A>


<H3><A NAME="SEC260" HREF="spec_toc.html#TOC260">log_incoming_port</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX754"></A>
If this option is set, the remote port number (separated by a dot) is
added to the IP address of incoming calls in all log entries, and in <EM>Received:</EM>
header lines. For example:

<PRE>
127.0.0.1.48433
::1.48433
</PRE>

<P>
This is implemented by changing the value that is put in the
$<EM>sender_fullhost</EM> and $<EM>sender_rcvhost</EM> variables. Recording the remote
port number has become more important with the widening use of NAT (see RFC
2505).
</font>

</P>
<P>
<A NAME="IDX755"></A>


<H3><A NAME="SEC261" HREF="spec_toc.html#TOC261">log_ip_options</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
See <EM>kill_ip_options</EM> above.

</P>
<P>
<A NAME="IDX756"></A>


<H3><A NAME="SEC262" HREF="spec_toc.html#TOC262">log_level</A></H3>

<P>
Type: integer<BR>
Default: 5

</P>
<P>
This controls the amount of data written to the main log
and to the individual message logs
(see section 51.10). The higher the number, the more is written. At
present a value of 6 or higher causes all possible messages to appear.

</P>
<P>
<A NAME="IDX757"></A>


<H3><A NAME="SEC263" HREF="spec_toc.html#TOC263">log_queue_run_level</A></H3>

<P>
Type: integer<BR>
Default: 0

</P>
<P>
<A NAME="IDX758"></A>
<A NAME="IDX759"></A>
This option specifies the log level for the messages `start queue run' and `end
queue run'. Setting it higher than the value of <EM>log_level</EM> causes them to be
suppressed.

</P>
<P>
<A NAME="IDX760"></A>


<H3><A NAME="SEC264" HREF="spec_toc.html#TOC264">log_received_recipients</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
When this option is set, the recipients of a message are listed in the main log
as soon as the message is received. The list appears at the end of the log line
that is written when a message is received, preceded by the word `for'. The
addresses are listed after they have been qualified, but before any rewriting
has taken place.

</P>
<P>
<A NAME="IDX761"></A>


<H3><A NAME="SEC265" HREF="spec_toc.html#TOC265">log_received_sender</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
If this option is set, the unrewritten original sender of a message is added to
the end of the log line that records the message's arrival, after the word
`from' (before the recipients if <EM>log_received_recipients</EM> is also set).

</P>
<P>
<A NAME="IDX762"></A>


<H3><A NAME="SEC266" HREF="spec_toc.html#TOC266">log_refused_recipients</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
If this option is set, an entry is written in the main and reject logs for
each recipient that is refused for policy reasons. Otherwise cases where all
recipients are to be refused just cause a single log entry for the message.

</P>
<P>
<A NAME="IDX763"></A>


<H3><A NAME="SEC267" HREF="spec_toc.html#TOC267">log_rewrites</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX764"></A>
<A NAME="IDX765"></A>
This option causes all address rewriting to get logged, as an aid to debugging
rewriting rules.

</P>
<P>
<A NAME="IDX766"></A>


<H3><A NAME="SEC268" HREF="spec_toc.html#TOC268">log_smtp_confirmation</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
This option causes the response to the final `.' in the SMTP dialog for
outgoing messages to be added to delivery log lines in the form `C="&#60;<EM>text</EM>&#62;"'.
A number of MTAs (including Exim from release 1.60) return an identifying
string in this response, so logging this information allows messages to be
tracked more easily. This global option applies to all SMTP transports.

</P>
<P>
<A NAME="IDX767"></A>


<H3><A NAME="SEC269" HREF="spec_toc.html#TOC269">log_smtp_connections</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX768"></A>
<A NAME="IDX769"></A>
This option turns on more verbose logging of incoming SMTP connections, at log
level 4. This does not apply to batch SMTP, but it does apply to SMTP
connections from local processes that use the -<EM>bs</EM> option, including incoming
calls using <EM>inetd</EM>. A log line is written whenever a connection is established
or closed. If a connection is dropped in the middle of a message, a log line is
always written, but otherwise nothing is written at the start and end of
connections unless <EM>log_smtp_connections</EM> is set.

</P>
<P>
<A NAME="IDX770"></A>


<H3><A NAME="SEC270" HREF="spec_toc.html#TOC270">log_smtp_syntax_errors</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX771"></A>
<A NAME="IDX772"></A>
<A NAME="IDX773"></A>
<A NAME="IDX774"></A>
<A NAME="IDX775"></A>
If this option is set, syntax errors in incoming SMTP commands are logged at
level 4.
An unrecognized command is treated as a syntax error.
For an external connection, the host identity is given; for an
internal connection using -<EM>bs</EM> the sender identification (normally the calling
user) is given.

</P>
<P>
<A NAME="IDX776"></A>


<H3><A NAME="SEC271" HREF="spec_toc.html#TOC271">log_subject</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
This option causes a message's subject to be included in the arrival log line,
in the form `T="&#60;<EM>subject text</EM>&#62;"'. T stands for `topic' (S is already used for
`size').

</P>
<P>
<A NAME="IDX777"></A>


<H3><A NAME="SEC272" HREF="spec_toc.html#TOC272">lookup_open_max</A></H3>

<P>
Type: integer<BR>
Default: 25

</P>
<P>
<A NAME="IDX778"></A>
<A NAME="IDX779"></A>
<A NAME="IDX780"></A>
This option limits the number of simultaneously open lookup files. Exim
normally keeps files open during directing and routing, since often the same
file is required several times. This limit applies only to those lookup types
which use regular files, namely lsearch, dbm, and cdb. If the limit is
reached, Exim closes the least recently used file. Note that if you are using
the NDBM library, it actually opens two files for each logical DBM database,
though it still counts as one for the purposes of <EM>lookup_open_max</EM>. If you
are getting `too many open files' errors with NDBM, you need to reduce the
value of <EM>lookup_open_max</EM>.

</P>
<P>
<A NAME="IDX781"></A>


<H3><A NAME="SEC273" HREF="spec_toc.html#TOC273">max_username_length</A></H3>

<P>
Type: integer<BR>
Default: 0

</P>
<P>
<A NAME="IDX782"></A>
<A NAME="IDX783"></A>
Some operating systems are broken in that they truncate the argument to
<EM>getpwnam()</EM> to eight characters, instead of returning `no such user'. If this
option is set greater than zero, any attempt to call <EM>getpwnam()</EM> with an
argument that is longer behaves as if <EM>getpwnam()</EM> failed.

</P>

<P>
<A NAME="IDX784"></A>


<H3><A NAME="SEC274" HREF="spec_toc.html#TOC274">message_body_visible</A></H3>

<P>
Type: integer<BR>
Default: 500

</P>
<P>
<A NAME="IDX785"></A>
<A NAME="IDX786"></A>
This option specifies how much of a message's body is to be included in the
<EM>message_body</EM> expansion variable.

</P>

<P>
<A NAME="IDX787"></A>


<H3><A NAME="SEC275" HREF="spec_toc.html#TOC275">message_filter</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
<A NAME="IDX788"></A>
This option specifies a filter file which is applied to all messages before any
routing or directing is done. This is called the `system message filter'.
If the filter generates any deliveries to files or pipes, or any new mail
messages, the appropriate <EM>message_filter_..._transport</EM> option(s) must
be set, to define which transports are to be used.
Details of this facility are given in chapter 47.

</P>
<P>
<A NAME="IDX789"></A>


<H3><A NAME="SEC276" HREF="spec_toc.html#TOC276">message_filter_directory_transport</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
This sets the name of the transport driver that is to be used when the
<EM>save</EM> command in a system message filter specifies a path ending in `/',
implying delivery of each message into a separate file in some directory.

</P>
<P>
<A NAME="IDX790"></A>


<H3><A NAME="SEC277" HREF="spec_toc.html#TOC277">message_filter_directory2_transport</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
This sets the name of the transport driver that is to be used when the
<EM>save</EM> command in a system message filter specifies a path ending in `//'. The
reason for having both <EM>message_filter_directory</EM> and
<EM>message_filter_directory2</EM> is to allow for the rare circumstance in which
both maildir and non-maildir format delivery is required.

</P>
<P>
<A NAME="IDX791"></A>


<H3><A NAME="SEC278" HREF="spec_toc.html#TOC278">message_filter_file_transport</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
<A NAME="IDX792"></A>
This sets the name of the transport driver that is to be used when the
<EM>save</EM> command in a system message filter specifies a path not ending in `/'.

</P>
<P>
<A NAME="IDX793"></A>
<A NAME="IDX794"></A>


<H3><A NAME="SEC279" HREF="spec_toc.html#TOC279">message_filter_group</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
This option sets the gid under which the system message filter is run.
The <EM>seteuid()</EM> or <EM>setresuid()</EM> function must be available in the operating
system for a temporary change to be possible. If the filter generates any pipe,
file, or reply addresses, the gid under which the filter is run is used when
delivering to them. Unless the string consists entirely of digits, it is looked
up using <EM>getgrnam()</EM>, and failure causes a configuration error. If the option
is not set, and either <EM>message_filter_user</EM> is unset or consists entirely of
digits, the gid is not changed when running the filter. Otherwise the group is
taken from the result of <EM>getpwnam()</EM>.

</P>
<P>
<A NAME="IDX795"></A>


<H3><A NAME="SEC280" HREF="spec_toc.html#TOC280">message_filter_pipe_transport</A></H3>

<P>
Type: string<BR>
Default: unset 7

</P>
<P>
<A NAME="IDX796"></A>
This sets the name of the transport driver that is to be used when a
<EM>pipe</EM> command is used in a system message filter.

</P>
<P>
<A NAME="IDX797"></A>


<H3><A NAME="SEC281" HREF="spec_toc.html#TOC281">message_filter_reply_transport</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
<A NAME="IDX798"></A>
This sets the name of the transport driver that is to be used when a
<EM>mail</EM> command is used in a system message filter.

</P>

<P>
<A NAME="IDX799"></A>
<A NAME="IDX800"></A>


<H3><A NAME="SEC282" HREF="spec_toc.html#TOC282">message_filter_user</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
This option sets the uid under which the system message filter is run. The
<EM>seteuid()</EM> or <EM>setresuid()</EM> function must be available in the operating system
for a temporary change to be possible. If the filter generates any pipe, file,
or reply addresses, the uid under which the filter is run is used when
delivering to them. Unless it consists entirely of digits, the string is looked
up using <EM>getpwnam()</EM>, and failure causes a configuration error.
If the option is not set, the uid is not changed from the Exim user (or root if
there is no Exim user) when running the system filter.

</P>
<P>
<A NAME="IDX801"></A>


<H3><A NAME="SEC283" HREF="spec_toc.html#TOC283">message_id_header_text</A></H3>

<P>
Type: string, expanded<BR>
Default: unset

</P>
<P>
If this variable is set, the string is expanded and used to augment the text of
the <EM>Message-id:</EM> header that Exim creates if an incoming message does not have
one. The text of this header is required by RFC 822 to take the form of an
address. By default, Exim uses its internal message id as the local part, and
the primary host name as the domain. If this option is set, it is expanded and
provided the expansion does not yield an empty string, is is
inserted into the header immediately before the @, separated from the internal
message id by a dot. Any characters that are illegal in an address are
automatically converted into hyphens. This means that constructions like
<EM>${tod_log}</EM> can be used, as the spaces and colons will become hyphens.

</P>
<P>
<A NAME="IDX802"></A>


<H3><A NAME="SEC284" HREF="spec_toc.html#TOC284">message_size_limit</A></H3>

<P>
Type: integer<BR>
Default: 0

</P>
<P>
<A NAME="IDX803"></A>
<A NAME="IDX804"></A>
<A NAME="IDX805"></A>
This option limits the maximum size of message that Exim will process. Zero
means no limit. It should be set somewhat larger than <EM>return_size_limit</EM> if
the latter is non-zero. Incoming SMTP messages are failed with a 552 error if
the limit is exceeded; locally-generated messages either get a stderr message
or a delivery failure message to the sender, depending on the -<EM>oe</EM> setting, in
the normal way. Rejection of an oversized message is logged in both the main
and the reject logs. See also the generic transport option
<EM>message_size_limit</EM>, which limits the size of message that an individual
transport can process.

</P>
<P>
<A NAME="IDX806"></A>


<H3><A NAME="SEC285" HREF="spec_toc.html#TOC285">message_size_limit_count_recipients</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
If this option is set, the value of <EM>message_size_limit</EM> is a maximum
for the size of a message times the number of envelope recipients it has. For
example, if <EM>message_size_limit</EM> is set to 10M, a message with 4
recipients can be no bigger than 2.5M, and a message with 100 recipients is
limited to around 100K.

</P>
<P>
<A NAME="IDX807"></A>


<H3><A NAME="SEC286" HREF="spec_toc.html#TOC286">move_frozen_messages</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX808"></A>
This option, which is available only if Exim has been built with the setting

<PRE>
SUPPORT_MOVE_FROZEN_MESSAGES=yes
</PRE>

<P>
in <TT>`Local/Makefile'</TT>, causes frozen messages and their message logs to be moved
from the <EM>input</EM> and <EM>msglog</EM> directories on the spool to <EM>Finput</EM> and
<EM>Fmsglog</EM>. There is currently no support in Exim or the standard utilities for
handling such moved messages, and they do not show up in lists generated by
-<EM>bp</EM> or by the Exim monitor.

</P>
<P>
<A NAME="IDX809"></A>


<H3><A NAME="SEC287" HREF="spec_toc.html#TOC287">mysql_servers</A></H3>

<P>
Type: string list<BR>
Default: unset

</P>
<P>
This option provides a list of MySQL servers and associated connection data, to
be used in conjunction with <EM>mysql</EM> lookups (see section 6.12). The
option is available only if Exim has been built with MySQL support.

</P>
<P>
<A NAME="IDX810"></A>


<H3><A NAME="SEC288" HREF="spec_toc.html#TOC288">never_users</A></H3>

<P>
Type: string list<BR>
Default: unset

</P>
<P>
Local mail deliveries are run in processes that are setuid to the
recipient. However, it is usually desirable to lock out root from this, as a
safety precaution. If a message is to be delivered locally as any of the users
on the <EM>never_users</EM> list, the process is run as `nobody' instead (see
<EM>nobody_user</EM> below). A common example is

<PRE>
never_users = root:daemon:bin:exim
</PRE>

<P>
This option overrides the <EM>pipe_as_creator</EM> option of the <EM>pipe</EM> transport
driver. If Exim is unable to find a uid for `nobody', it panics.

</P>
<P>
<A NAME="IDX811"></A>


<H3><A NAME="SEC289" HREF="spec_toc.html#TOC289">nobody_group</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
This specifies the group to use when a process is to be run as `nobody'. If it
is unset, the value of the `nobody' user's default group is used.

</P>
<P>
<A NAME="IDX812"></A>


<H3><A NAME="SEC290" HREF="spec_toc.html#TOC290">nobody_user</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
This specifies the user to use when a process is to be run as `nobody'. If it is
unset, Exim looks up the user `nobody' using <EM>getpwnam()</EM>. If this fails,
Exim panics, writing a message to the panic log and exiting immediately.

</P>
<P>
<A NAME="IDX813"></A>


<H3><A NAME="SEC291" HREF="spec_toc.html#TOC291">percent_hack_domains</A></H3>

<P>
Type: domain list<BR>
Default: unset

</P>
<P>
<A NAME="IDX814"></A>
<A NAME="IDX815"></A>
<A NAME="IDX816"></A>
The `percent hack' is the convention whereby a local part containing a percent
sign is re-interpreted as a remote address, with the percent replaced by @.
This is sometimes called `source routing', though that term is also applied to
RFC 822 addresses that begin with an @ character. If this option is set, Exim
implements the percent facility for those local domains listed, but no others.
The option can be set to `*' to allow the percent hack for all local domains.

</P>
<P>
If options are set to control message relaying from incoming SMTP envelopes,
they are also applied to relaying that is requested via the `percent hack'.
See section 46.4.

</P>
<P>
<A NAME="IDX817"></A>


<H3><A NAME="SEC292" HREF="spec_toc.html#TOC292">perl_at_start</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
This option is available only when Exim is built with an embedded Perl
interpreter. See chapter 10 for details of its use.

</P>
<P>
<A NAME="IDX818"></A>


<H3><A NAME="SEC293" HREF="spec_toc.html#TOC293">perl_startup</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
This option is available only when Exim is built with an embedded Perl
interpreter. See chapter 10 for details of its use.

</P>
<P>
<font color=green>
<A NAME="IDX819"></A>


<H3><A NAME="SEC294" HREF="spec_toc.html#TOC294">pgsql_servers</A></H3>

<P>
Type: string list<BR>
Default: unset

</P>
<P>
This option provides a list of PostgreSQL servers and associated connection
data, to be used in conjunction with <EM>pgsql</EM> lookups (see section 6.12).
The option is available only if Exim has been built with PostgreSQL support.
</font>

</P>
<P>
<A NAME="IDX820"></A>


<H3><A NAME="SEC295" HREF="spec_toc.html#TOC295">pid_file_path</A></H3>

<P>
Type: string<BR>
Default: set at compile time

</P>
<P>
This option sets the path which is used to determine the name of the file to
which the Exim daemon writes its process id. The string is expanded, so it can
contain, for example, references to the host name. After expansion it must
contain the string `%s' somewhere within it; this will be replaced by the null
string or a non-standard port number to form the final file name. For example,

<PRE>
pid_file_path = /var/log/${primary_hostname}/exim%s.pid
</PRE>

<P>
If no specific path is set for the file, it is written in Exim's spool
directory.

</P>
<P>
<A NAME="IDX821"></A>


<H3><A NAME="SEC296" HREF="spec_toc.html#TOC296">preserve_message_logs</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
If this option is set, message log files are not deleted when messages are
completed. Instead, they are moved to a sub-directory of the spool directory
called <EM>msglog.OLD</EM>, where they remain available for statistical or debugging
purposes. This is a dangerous option to set on systems with any appreciable
volume of mail. Use with care!

</P>

<P>
<A NAME="IDX822"></A>


<H3><A NAME="SEC297" HREF="spec_toc.html#TOC297">primary_hostname</A></H3>

<P>
Type: string<BR>
Default: see below

</P>
<P>
This specifies the name of the current host. This is used in the HELO
command for outgoing SMTP messages, and as the default for <EM>qualify_domain</EM>.
If it is not set, Exim calls <EM>uname()</EM> to find it. If this fails, Exim panics
and dies.
If the name returned by <EM>uname()</EM> contains only one component, Exim passes it
to <EM>gethostbyname()</EM> in order to obtain the fully qualified version.

</P>

<P>
<A NAME="IDX823"></A>


<H3><A NAME="SEC298" HREF="spec_toc.html#TOC298">print_topbitchars</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX824"></A>
<A NAME="IDX825"></A>
<A NAME="IDX826"></A>
<A NAME="IDX827"></A>
By default, Exim considers only those characters whose codes lie in the range
32--126 to be printing characters. In a number of circumstances (for example,
when writing log entries) non-printing characters are converted into escape
sequences, primarily to avoid messing up the layout. If <EM>print_topbitchars</EM> is
set, code values of 128 and above are also considered to be printing
characters.

</P>

<P>
<A NAME="IDX828"></A>


<H3><A NAME="SEC299" HREF="spec_toc.html#TOC299">prod_requires_admin</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
The -<EM>M</EM>, -<EM>R</EM>, and -<EM>q</EM> command-line options require the caller to be an admin
user unless <EM>prod_requires_admin</EM> is set false. See also
<EM>queue_list_requires_admin</EM>.

</P>
<P>
<A NAME="IDX829"></A>


<H3><A NAME="SEC300" HREF="spec_toc.html#TOC300">prohibition_message</A></H3>

<P>
Type: string, expanded<BR>
Default: unset

</P>
<P>
This option adds a site-specific message to the error response that is sent
when an SMTP command fails for policy reasons, for example if the sending host
is in a host reject list. Details of this facility are given in chapter
46.

</P>
<P>
<A NAME="IDX830"></A>


<H3><A NAME="SEC301" HREF="spec_toc.html#TOC301">qualify_domain</A></H3>

<P>
Type: string<BR>
Default: see below

</P>
<P>
This specifies the domain name that is added to any sender addresses that do
not have a domain qualification. It also applies to recipient addresses if
<EM>qualify_recipient</EM> is not set. Such addresses are accepted by default only
for locally-generated messages -- messages from external sources must always
contain fully qualified addresses, unless the sending host matches one of the
<EM>receiver_unqualified</EM> or <EM>sender_unqualified</EM> options. If <EM>qualify_domain</EM>
is not set, it defaults to the <EM>primary_hostname</EM> value.

</P>
<P>
<A NAME="IDX831"></A>


<H3><A NAME="SEC302" HREF="spec_toc.html#TOC302">qualify_recipient</A></H3>

<P>
Type: string<BR>
Default: see below

</P>
<P>
This specifies the domain name that is added to any recipient addresses that do
not have a domain qualification. Such addresses are accepted by default only
for locally-generated messages -- messages from external sources must always
contain fully qualified addresses, unless the sending host matches one of the
<EM>receiver_unqualified</EM> or <EM>sender_unqualified</EM> options (see below). If
<EM>qualify_recipient</EM> is not set, it defaults to the <EM>qualify_domain</EM> value.

</P>
<P>
<A NAME="IDX832"></A>


<H3><A NAME="SEC303" HREF="spec_toc.html#TOC303">queue_list_requires_admin</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
The -<EM>bp</EM> command-line option requires the caller to be an admin user unless
<EM>queue_list_requires_admin</EM> is set false. Otherwise, only messages that the
caller submitted are displayed. See also <EM>prod_requires_admin</EM>.

</P>
<P>
<A NAME="IDX833"></A>


<H3><A NAME="SEC304" HREF="spec_toc.html#TOC304">queue_only</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX834"></A>
<A NAME="IDX835"></A>
If <EM>queue_only</EM> is set (which is equivalent to the -<EM>odq</EM> command line
option), a delivery process is not automatically started whenever a message has
been received. Instead, the message waits on the queue for the next queue run.
Even if <EM>queue_only</EM> is false, incoming SMTP messages may not get delivered
immediately if a lot of them arrive at once -- see the <EM>queue_only_load</EM> and
<EM>smtp_accept_queue</EM> options.

</P>
<P>
<A NAME="IDX836"></A>


<H3><A NAME="SEC305" HREF="spec_toc.html#TOC305">queue_only_file</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
<A NAME="IDX837"></A>
<A NAME="IDX838"></A>
This option can be set to a colon-separated list of absolute path names, each
one optionally preceded by `remote' or `smtp'. When it is receiving a message,
Exim tests for the existence of each listed path using a call to <EM>stat()</EM>, and
if this succeeds, the corresponding queuing option is set. If there is no
prefix to the path, <EM>queue_only</EM> is set; `remote' corresponds to
<font color=green>
<EM>queue_remote_domains</EM> and `smtp' to <EM>queue_smtp_domains</EM>.
</font>
So, for example,

<PRE>
queue_only_file = remote/some/file
</PRE>

<P>
causes Exim to behave as if
<font color=green>
<EM>queue_remote_domains</EM>
</font>
were set to `*' whenever <EM>/some/file</EM> exists.

</P>
<P>
<A NAME="IDX839"></A>


<H3><A NAME="SEC306" HREF="spec_toc.html#TOC306">queue_only_load</A></H3>

<P>
Type: fixed-point<BR>
Default: unset

</P>
<P>
<A NAME="IDX840"></A>
<A NAME="IDX841"></A>
<A NAME="IDX842"></A>
If the system load average is higher than this value, all incoming messages are
queued, and no automatic deliveries are started. If this happens during local
or remote SMTP input, all subsequent messages on the same connection are
queued. Deliveries will subsequently be performed by queue running processes,
unless the load is higher than <EM>deliver_load_max</EM>. There are some operating
systems for which Exim cannot determine the load average (see chapter 1); for
these this option has no effect. See also <EM>smtp_accept_queue</EM> and
<EM>smtp_load_reserve</EM>.

</P>
<P>
<A NAME="IDX843"></A>


<H3><A NAME="SEC307" HREF="spec_toc.html#TOC307">queue_remote_domains</A></H3>

<P>
Type: domain list<BR>
Default: unset

</P>
<P>
This option lists domains for which local delivery is not immediately required.
It is checked against the domains supplied in the incoming addresses, before
any widening is done (because that is part of routing). The -<EM>odqr</EM> option is
equivalent to setting <EM>queue_remote_domains</EM> to `*'. A delivery process is
started whenever a message is received, but only local addresses are handled,
and only local deliveries take place. All remote deliveries wait until the next
queue run. See also <EM>queue_smtp_domains</EM>, which is subtly different.

</P>
<P>
<A NAME="IDX844"></A>


<H3><A NAME="SEC308" HREF="spec_toc.html#TOC308">queue_run_in_order</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
If this option is set, queue runs happen in order of message arrival instead of
in an arbitrary order.
<font color=green>
In order for this to happen, a complete list of the entire queue must be set up
before the deliveries start. When the queue is all in a single directory (the
default), this happens anyway, but if <EM>split_spool_directory</EM> is set it does
not -- for delivery in random order, the sub-directories are processed one at a
time (in random order), to avoid setting up one huge list. Thus, setting
<EM>queue_run_in_order</EM> with <EM>split_spool_directory</EM> may degrade performance
when the queue is large. In most situations, <EM>queue_run_in_order</EM> should not
be set.
</font>

</P>
<P>
<A NAME="IDX845"></A>


<H3><A NAME="SEC309" HREF="spec_toc.html#TOC309">queue_run_max</A></H3>

<P>
Type: integer<BR>
Default: 5

</P>
<P>
<A NAME="IDX846"></A>
This controls the maximum number of queue-running processes that an Exim daemon
will run simultaneously. This does not mean that it starts them all at once,
but rather that if the maximum number are still running when the time comes to
start another one, it refrains from starting it. This can happen with very
large queues and/or very sluggish deliveries. This option does not, however,
interlock with other processes, so additional queue-runners can be started by
other means, or by killing and restarting the daemon.

</P>
<P>
<A NAME="IDX847"></A>


<H3><A NAME="SEC310" HREF="spec_toc.html#TOC310">queue_smtp_domains</A></H3>

<P>
Type: domain list<BR>
Default: unset

</P>
<P>
When this option is set, a delivery process is started whenever a message is
received, directing and routing is performed, and local deliveries take place.
However, if any SMTP deliveries are required for domains that match
<EM>queue_smtp_domains</EM>, they are not immediately delivered, but instead the
message waits on the queue for the next queue run. Since routing of the message
has taken place, Exim knows to which remote hosts it must be delivered, and so
when the queue run happens, multiple messages for the same host are delivered
over a single SMTP connection. This option is checked against the domains
supplied in the incoming addresses, before any widening is done (because that
is part of routing). The -<EM>odqs</EM> command line option causes all SMTP deliveries
to be queued in this way, and is equivalent to setting <EM>queue_smtp_domains</EM>
to `*'. See also <EM>queue_remote_domains</EM>, which is subtly different.

</P>
<P>
<A NAME="IDX848"></A>


<H3><A NAME="SEC311" HREF="spec_toc.html#TOC311">rbl_domains</A></H3>

<P>
Type: string list<BR>
Default: unset

</P>
<P>
<A NAME="IDX849"></A>
<A NAME="IDX850"></A>
<font color=green>
This option is part of the support for Realtime Blocking Lists (RBL). It can be
set to a colon-separated list of DNS domains in which to look up the IP address
of a calling host. A full description of how this is used is given in section
46.1.
</font>

</P>
<P>
<A NAME="IDX851"></A>


<H3><A NAME="SEC312" HREF="spec_toc.html#TOC312">rbl_hosts</A></H3>

<P>
Type: host list<BR>
Default: *

</P>
<P>
<A NAME="IDX852"></A>
This option specifies the set of hosts for which RBL checking is to be
performed when <EM>rbl_domains</EM> is set. The default matches all hosts. The normal
usage of this option is to specify exceptions to RBL checking by means of
negated items in the host list.

</P>
<P>
<A NAME="IDX853"></A>


<H3><A NAME="SEC313" HREF="spec_toc.html#TOC313">rbl_log_headers</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
When this option is set, the headers of each message received from a host that
matches an RBL domain are written to the reject log. This can occur only if the
recipients of the message are not rejected, that is, if the RBL check is
configured to warn only.

</P>
<P>
<A NAME="IDX854"></A>


<H3><A NAME="SEC314" HREF="spec_toc.html#TOC314">rbl_log_rcpt_count</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
When this option is set and <EM>rbl_reject_recipients</EM> is false, the number of
RCPT commands for each message received from a host that is in the RBL
is written to the reject log. This may be greater than the number of valid
recipients in the message.

</P>
<P>
<A NAME="IDX855"></A>


<H3><A NAME="SEC315" HREF="spec_toc.html#TOC315">rbl_reject_recipients</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
This option controls the action taken when a remote host is found in an RBL
domain that has neither `/warn' nor `/reject' following it. The default value
specifies rejection.

</P>
<P>
<A NAME="IDX856"></A>


<H3><A NAME="SEC316" HREF="spec_toc.html#TOC316">rbl_warn_header</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
When this option is set and a message from an RBL-matching host is not
rejected, an <EM>X-RBL-Warning:</EM> header is added. The header contains the contents
of the DNS TXT record, if one was found. Scanning of further RBL domains
continues, which means that more than one <EM>X-RBL-Warning:</EM> header may be added
to a message.

</P>

<P>
<A NAME="IDX857"></A>
<A NAME="IDX858"></A>


<H3><A NAME="SEC317" HREF="spec_toc.html#TOC317">received_header_text</A></H3>

<P>
Type: string, expanded<BR>
Default: see below

</P>
<P>
This string defines the contents of the <EM>Received:</EM> message header that is
added to each message, except for the timestamp, which is automatically added
on at the end, preceded by a semicolon. The string is expanded each time it is
used, and the default is:

<PRE>
received_header_text = "Received: \
    ${if def:sender_rcvhost {from ${sender_rcvhost}\n\t}\
    {${if def:sender_ident {from ${sender_ident} }}\
    ${if def:sender_helo_name {(helo=${sender_helo_name})\n\t}}}}\
    by ${primary_hostname} \
    ${if def:received_protocol {with ${received_protocol}}} \
    ${if def:tls_cipher {($tls_cipher)\n\t}}\
    (Exim ${version_number} #${compile_number})\n\t\
    id ${message_id}\
    ${if def:received_for {\n\tfor $received_for}}"
</PRE>

<P>
<font color=green>
Note the use of quotes, to allow the sequences <TT>`\n'</TT> and <TT>`\t'</TT> to be used
for newlines and tabs, respectively. The reference to the TLS cipher is omitted
when Exim is built without TLS support.
</font>
The use of conditional expansions ensures that this works for both locally
generated messages and messages received from remote hosts, giving header lines
such as the following:

<PRE>
Received: from scrooge.carol.book ([240.1.12.25] ident=root)
        by marley.carol.book with smtp (Exim 1.90 #1)
        id E0tS3Ga-0005C5-00
        for cratchit@dickens.book; Mon, 25 Dec 1995 14:43:44 +0000
Received: by scrooge.carol.book with local (Exim 1.90 #1)
        id E0tS3GW-0005C2-00; Mon, 25 Dec 1995 14:43:41 +0000
</PRE>

<P>
Note the automatic addition of the date and time in the required format.

</P>
<P>
<A NAME="IDX859"></A>


<H3><A NAME="SEC318" HREF="spec_toc.html#TOC318">received_headers_max</A></H3>

<P>
Type: integer<BR>
Default: 30

</P>
<P>
<A NAME="IDX860"></A>
<A NAME="IDX861"></A>
When a message is to be delivered, the number of <EM>Received:</EM> headers is counted,
and if it is greater than this parameter, a mail loop is assumed to have
occurred, the delivery is abandoned, and an error message is generated.
This applies to both local and remote deliveries. Earlier versions of Exim did
this test only for remote deliveries, but because local deliveries (as Exim
sees them) may in fact still cause a message to be transported to a remote
host, it was changed.

</P>
<P>
<A NAME="IDX862"></A>


<H3><A NAME="SEC319" HREF="spec_toc.html#TOC319">receiver_try_verify</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
See <EM>receiver_verify</EM>.

</P>
<P>
<A NAME="IDX863"></A>


<H3><A NAME="SEC320" HREF="spec_toc.html#TOC320">receiver_unqualified_hosts</A></H3>

<P>
Type: host list<BR>
Default: unset

</P>
<P>
<A NAME="IDX864"></A>
This option lists those hosts from which Exim is prepared to accept unqualified
receiver addresses
<font color=green>
in message envelopes.
</font>
The addresses are made fully qualified by the addition of the
<EM>qualify_recipient</EM> value. Typically the hosts are local ones, but if you want
to imitate the behaviour of mailers that accept unqualified addresses from
anywhere, specify

<PRE>
receiver_unqualified_hosts = *
</PRE>

<P>
<font color=green>
This option also affects message header lines. Exim does not reject unqualified
receiver addresses in headers, but qualifies them only if the message came from
a host that matches <EM>receiver_unqualified_hosts</EM>.
</font>

</P>
<P>
<A NAME="IDX865"></A>


<H3><A NAME="SEC321" HREF="spec_toc.html#TOC321">receiver_verify</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX866"></A>
When this option is set, the addresses of recipients received from a remote
host are verified as they are received,
provided the sending host matches <EM>receiver_verify_hosts</EM>, the incoming
address matches <EM>receiver_verify_addresses</EM>, and the sender address matches
<EM>receiver_verify_senders</EM>, if either of the last two are set.

</P>
<P>
If an address is invalid, an incoming SMTP call gets an error response to the
RCPT command. If an address cannot immediately be verified, a temporary
error code is given. The <EM>receiver_try_verify</EM> option is less severe: it
operates in the same way, except that an address is accepted if it cannot
immediately be verified. Verification failures are logged.

</P>
<P>
<A NAME="IDX867"></A>


<H3><A NAME="SEC322" HREF="spec_toc.html#TOC322">receiver_verify_addresses</A></H3>

<P>
Type: address list<BR>
Default: unset

</P>
<P>
If set, this option restricts receiver verification to those addresses it
matches. The option is inspected only if <EM>receiver_verify</EM> or
<EM>receiver_try_verify</EM> is set.

</P>
<P>
<A NAME="IDX868"></A>


<H3><A NAME="SEC323" HREF="spec_toc.html#TOC323">receiver_verify_hosts</A></H3>

<P>
Type: host list<BR>
Default: *

</P>
<P>
See <EM>receiver_verify</EM> above.

</P>
<P>
<A NAME="IDX869"></A>


<H3><A NAME="SEC324" HREF="spec_toc.html#TOC324">receiver_verify_senders</A></H3>

<P>
Type: address list<BR>
Default: unset

</P>
<P>
This option, if set, allows receiver verification to be conditional upon the
sender. It is inspected only if <EM>receiver_verify</EM> or <EM>receiver_try_verify</EM>
is set.

</P>
<P>
If the null sender is required in the list of addresses, it must
not be the last item, as a null last item in a list is ignored. It is best
placed at the start of the list. For example, to restrict receiver verification
to messages with null senders and senders in the <EM>.com</EM> and <EM>.org</EM> domains, you
could have

<PRE>
receiver_verify
receiver_verify_senders = :*.com:*.org
</PRE>

<P>
If the null sender is the only entry required, the list should
consist of a single colon.

</P>
<P>
<A NAME="IDX870"></A>


<H3><A NAME="SEC325" HREF="spec_toc.html#TOC325">recipients_max</A></H3>

<P>
Type: integer<BR>
Default: 0

</P>
<P>
<A NAME="IDX871"></A>
<A NAME="IDX872"></A>
If this is set greater than zero, it specifies the maximum number of recipients
for any message. This applies to the original list of recipients supplied with
the message. SMTP messages get a
452
response for all recipients over the limit; earlier recipients are delivered as
normal. Non-SMTP messages with too many recipients are failed, and no
deliveries are done.
Note that the RFCs specify that an SMTP server should accept at least 100
RCPT commands in a single message.

</P>
<P>
<A NAME="IDX873"></A>


<H3><A NAME="SEC326" HREF="spec_toc.html#TOC326">recipients_max_reject</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
If this option is set true, Exim rejects SMTP messages containing too many
recipients by giving 552 errors to the surplus RCPT commands, and a 554
error to the eventual DATA command. Otherwise (the default) it gives a 452
error to the surplus RCPT commands and accepts the message on behalf of the
initial set of recipients. The remote server should then re-send the message
for the remaining recipients at a later time.

</P>
<P>
<A NAME="IDX874"></A>


<H3><A NAME="SEC327" HREF="spec_toc.html#TOC327">recipients_reject_except</A></H3>

<P>
Type: address list<BR>
Default: unset

</P>
<P>
<A NAME="IDX875"></A>
This option lists recipient addresses which are exceptions to any policy for
recipient rejection, that is, as a result of <EM>sender_reject_recipients</EM>, etc.
This option is entirely independent of any checks for unwanted message
relaying. However, it does interact with the RBL options.

</P>
<P>
<A NAME="IDX876"></A>


<H3><A NAME="SEC328" HREF="spec_toc.html#TOC328">recipients_reject_except_senders</A></H3>

<P>
Type: address list<BR>
Default: unset

</P>
<P>
This option lists sender addresses for which recipients are excepted from any
policy rejections. That is, if a message comes from any of these senders, all
its recipients are excepted from policy rejections.

</P>
<P>
<A NAME="IDX877"></A>


<H3><A NAME="SEC329" HREF="spec_toc.html#TOC329">refuse_ip_options</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
See <EM>kill_ip_options</EM> above.

</P>
<P>
<A NAME="IDX878"></A>


<H3><A NAME="SEC330" HREF="spec_toc.html#TOC330">relay_domains</A></H3>

<P>
Type: domain list<BR>
Default: unset

</P>
<P>
This option lists domains for which the local host is prepared to relay.
See section 46.4 for details of relay control.

</P>
<P>
<A NAME="IDX879"></A>


<H3><A NAME="SEC331" HREF="spec_toc.html#TOC331">relay_domains_include_local_mx</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
This option permits any host to relay to any domain that has an MX record
pointing at the local host. It causes any domain with an MX record pointing at
the local host to be treated as if it were in <EM>relay_domains</EM>. See section
46.4 for details of relay control.

</P>
<P>
<A NAME="IDX880"></A>


<H3><A NAME="SEC332" HREF="spec_toc.html#TOC332">relay_match_host_or_sender</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
By default, if relaying controls are specified on both the remote host and the
sender address, a message is accepted only if both conditions are met. If
<EM>relay_match_host_or_sender</EM> is set, either condition is good enough.
It does not make sense to set this option without setting
<EM>sender_address_relay</EM>, since if that option is unset it matches all senders.
Exim therefore diagnoses a configuration error in this case. See section
46.4 for details of relay control.

</P>

<P>
<A NAME="IDX881"></A>


<H3><A NAME="SEC333" HREF="spec_toc.html#TOC333">remote_max_parallel</A></H3>

<P>
Type: integer<BR>
Default: 1

</P>
<P>
This option controls parallel delivery to remote sites. If the value is less
than 2, parallel delivery is disabled, and Exim does all the remote deliveries
for a message one by one, from a single delivery process. Otherwise, if a
message has to be delivered to more than one remote host,
or if several copies have to be sent to the same remote host,
then up to <EM>remote_max_parallel</EM> deliveries are done simultaneously, each in
a separate process. If more than <EM>remote_max_parallel</EM> deliveries are
required, the maximum number of processes are started, and as each one
finishes, another is begun. The order of starting processes is the same as if
sequential delivery were being done, and can be controlled by the
<EM>remote_sort</EM> option. If parallel delivery takes place while running with
debugging turned on, the debugging output from each delivery process is tagged
with its process id.

</P>
<P>
The overhead in doing this is a fork to set up a separate process for each
delivery, and the associated management of the subprocess (including getting
back the result of the delivery attempt). As well as the process overhead,
there may be a small additional penalty paid for parallel delivery. If a host
is found to be down, this fact cannot be communicated to any deliveries that
are running in parallel, though it will be passed on to any that start
afterwards. This is no worse than if there were two separate messages being
delivered simultaneously.

</P>
<P>
The option controls only the maximum number of parallel deliveries from one
Exim process. Since Exim has no central queue manager, there is no way of
controlling the total number of simultaneous deliveries if the configuration
allows a delivery attempt as soon as a message is received.
<A NAME="IDX882"></A>
<A NAME="IDX883"></A>
If you want to control the total number of deliveries on the system, you
need to set the <EM>queue_only</EM> option, which ensures that all incoming messages
are simply added to the queue. Then set up an Exim daemon to start queue runner
processes at appropriate intervals (probably fairly often, for example, every
minute), and limit the total number of queue runners by setting the
<EM>queue_run_max</EM> parameter. Because each queue runner delivers only one
message at a time, the maximum number of deliveries that can then take place at
once is <EM>queue_run_max</EM> multiplied by <EM>remote_max_parallel</EM>.

</P>
<P>
If it is purely remote deliveries you want to control, use <EM>queue_smtp</EM>
instead of <EM>queue_only</EM>. This has the added benefit of doing the SMTP routing
before queuing, so that several messages for the same host will eventually get
delivered down the same connection.

</P>

<P>
<A NAME="IDX884"></A>


<H3><A NAME="SEC334" HREF="spec_toc.html#TOC334">remote_sort</A></H3>

<P>
Type: domain list<BR>
Default: unset

</P>
<P>
<A NAME="IDX885"></A>
<A NAME="IDX886"></A>
When there are a number of remote deliveries for a message, they are sorted by
domain into the order given by this list. For example,

<PRE>
remote_sort = *.cam.ac.uk:*.uk
</PRE>

<P>
would attempt to deliver to all addresses in the <EM>cam.ac.uk</EM> domain first, then
to those in the <EM>uk</EM> domain, then to any others.

</P>
<P>
<A NAME="IDX887"></A>


<H3><A NAME="SEC335" HREF="spec_toc.html#TOC335">retry_data_expire</A></H3>

<P>
Type: time<BR>
Default: 7d

</P>
<P>
This option sets a `use before' time on retry information in Exim's hints
database. Any older retry data is ignored. This means that, for example, once a
host has not been tried for 7 days, Exim behaves as if it has no knowledge of
past failures.

</P>
<P>
<A NAME="IDX888"></A>


<H3><A NAME="SEC336" HREF="spec_toc.html#TOC336">retry_interval_max</A></H3>

<P>
Type: time<BR>
Default: 24h

</P>
<P>
Chapter 33 describes Exim's mechanisms for controlling the intervals
between delivery attempts for messages that cannot be delivered straight away.
This option sets an overall limit to the length of time between retries.

</P>
<P>
<A NAME="IDX889"></A>


<H3><A NAME="SEC337" HREF="spec_toc.html#TOC337">return_path_remove</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
<A NAME="IDX890"></A>
RFC 822 states that the <EM>Return-path:</EM> header is `added by the final transport
system that delivers the message to its recipient' (section 4.3.1), which
implies that this header should not be present in an incoming message,
where the return path is carried in the envelope.
If this option is true, any existing <EM>Return-path:</EM> headers are removed from
messages as they are read. Exim's transports have options for adding
<EM>Return-path:</EM> headers at the time of delivery. They are normally used only for
final local deliveries.

</P>
<P>
<A NAME="IDX891"></A>


<H3><A NAME="SEC338" HREF="spec_toc.html#TOC338">return_size_limit</A></H3>

<P>
Type: integer<BR>
Default: 100K

</P>
<P>
<A NAME="IDX892"></A>
<A NAME="IDX893"></A>
<A NAME="IDX894"></A>
<A NAME="IDX895"></A>
This option sets a limit in bytes on the size of messages that are returned to
senders. If it is set to zero there is no limit. If the body of any message
that is to be included in an error report is greater than the limit, it is
truncated, and a comment pointing this out is added at the top. The actual
cutoff may be greater than the value given, owing to the use of buffering for
transferring the message in chunks. The idea is just to save bandwidth on those
undeliverable 15-megabyte messages. If either the global or generic transport
<EM>message_size_limit</EM> is set, the value of <EM>return_size_limit</EM> should be
somewhat smaller.

</P>
<P>
<A NAME="IDX896"></A>


<H3><A NAME="SEC339" HREF="spec_toc.html#TOC339">rfc1413_hosts</A></H3>

<P>
Type: host list<BR>
Default: *

</P>
<P>
<A NAME="IDX897"></A>
<A NAME="IDX898"></A>
RFC 1413 identification calls are made to any host which matches an item in the
list. The items in the host list should not themselves contain ident data.

</P>
<P>
<A NAME="IDX899"></A>


<H3><A NAME="SEC340" HREF="spec_toc.html#TOC340">rfc1413_query_timeout</A></H3>

<P>
Type: time<BR>
Default: 30s

</P>
<P>
This sets the timeout on RFC 1413 identification calls. If it is set to zero,
no RFC 1413 calls are ever made.

</P>
<P>
<A NAME="IDX900"></A>


<H3><A NAME="SEC341" HREF="spec_toc.html#TOC341">security</A></H3>

<P>
Type: string<BR>
Default: see below

</P>
<P>
When <EM>exim_user</EM> is set non-zero in the run time configuration or an Exim uid
is compiled into the binary, Exim gives up root privilege for some of the time.
As there are trade-offs between increased security and efficiency, this option
is provided to control exactly how this is done. The option can be set to one
of the strings `seteuid', `setuid', `setuid+seteuid'
<font color=green>
or `unprivileged',
</font>
provided that a uid for Exim is defined. Otherwise it must be left unset. A
full description of what these values mean is given in chapter 55.
The default for this option is unset if no special Exim uid is defined,
otherwise it is either `setuid+seteuid' or `setuid', depending on whether the
<EM>seteuid()</EM> function is configured as being available or not.

</P>
<P>
<A NAME="IDX901"></A>


<H3><A NAME="SEC342" HREF="spec_toc.html#TOC342">sender_address_relay</A></H3>

<P>
Type: address list<BR>
Default: unset

</P>
<P>
This option specifies a set of address patterns, one of which the sender of a
message must match in order for the message to be accepted for relaying. If it
is not set, all sender addresses are permitted. By default, this check operates
in addition to any relaying checks on the sending host (see
<EM>host_accept_relay</EM> above). However, if <EM>relay_match_host_or_sender</EM> is
set, <EM>either</EM> a host match <EM>or</EM> a sender match is sufficient to allow the
relaying to proceed. For this reason, <EM>sender_address_relay</EM> is required to
be set if <EM>relay_match_host_or_sender</EM> is set.
<font color=green>
<b>Warning</b>: Sender addresses can be trivially forged. For this reason, setting
<EM>relay_match_host_or_sender</EM> is strongly discouraged.
</font>

</P>
<P>
The rewrite flag X (see section 34.9) provides a special-purpose
facility we have a use for in Cambridge. It adds additional checking to
<EM>sender_address_relay</EM>. Whenever a sender address passes the check,
if there are any rewriting rules with the X flag set, the
address is rewritten using those rules, and if this makes any change to the
address, the new address must verify successfully for the relaying to be
permitted.

</P>
<P>
<font color=green>
<A NAME="IDX902"></A>


<H3><A NAME="SEC343" HREF="spec_toc.html#TOC343">sender_address_relay_hosts</A></H3>

<P>
Type: host list<BR>
Default: *

</P>
<P>
The hosts to which <EM>sender_address_relay</EM> is applies can be controlled by
this option. This is useful in a cluster where one host is delegated as a
fallback to hold all the delayed deliveries. It needs to be able to relay from
the other hosts without sender checking (for example, for messages forwarded by
local users) but might want to check senders in messages relayed from other
hosts.
</font>

</P>

<P>
<A NAME="IDX903"></A>


<H3><A NAME="SEC344" HREF="spec_toc.html#TOC344">sender_reject</A></H3>

<P>
Type: address list<BR>
Default: unset

</P>
<P>
This option can be set in order to reject mail from certain senders.
The check is done on the sender's address as given in the MAIL command in
SMTP, but not for local senders where the logged-in user's address is going to
override anyway.

</P>
<P>
The check is not done for batch SMTP input. If the check fails, a 550 return
code is given to MAIL. This doesn't always stop remote mailers from trying
again. See <EM>sender_reject_recipients</EM> for an alternative. Typical examples of
the use of this option might be:

<PRE>
sender_reject = spamuser@some.domain:spam.domain
sender_reject = partial-dbm;/etc/mail/blocked/senders
</PRE>

<P>
Note that this check operates on sender address domains independently of the
sending host; <EM>host_reject</EM> can be used to block all mail from particular
hosts, while <EM>host_accept_relay</EM>, and <EM>sender_address_relay</EM> can be used to
prevent unwanted relaying.

</P>
<P>
<A NAME="IDX904"></A>


<H3><A NAME="SEC345" HREF="spec_toc.html#TOC345">sender_reject_recipients</A></H3>

<P>
Type: address list<BR>
Default: unset

</P>
<P>
This operates in exactly the same way as <EM>sender_reject</EM> except that the
rejection is given in the form of a 550 error code to every RCPT command
instead of rejecting MAIL. This seems to be the only way of saying `no' to
some mailers. Note that this is not an option for rejecting specific
recipients. The way to do that is to set <EM>receiver_verify</EM> and arrange for
those recipients to fail verification.

</P>
<P>
<A NAME="IDX905"></A>


<H3><A NAME="SEC346" HREF="spec_toc.html#TOC346">sender_try_verify</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
See <EM>sender_verify</EM>.

</P>
<P>
<A NAME="IDX906"></A>


<H3><A NAME="SEC347" HREF="spec_toc.html#TOC347">sender_unqualified_hosts</A></H3>

<P>
Type: host list<BR>
Default: unset

</P>
<P>
<A NAME="IDX907"></A>
This option lists those hosts from which Exim is prepared to accept unqualified
sender addresses. The addresses are made fully qualified by the addition of
<EM>qualify_domain</EM>. Typically the hosts are local ones, but if you want to
imitate the behaviour of mailers that accept unqualified addresses from
anywhere, specify

<PRE>
sender_unqualified_hosts = *
</PRE>

<P>
<font color=green>
This option also affects message header lines. Exim does not reject unqualified
addresses in headers containing sender addresses, but qualifies them only if
the message came from a host that matches <EM>sender_unqualified_hosts</EM>.
</font>

</P>
<P>
<A NAME="IDX908"></A>


<H3><A NAME="SEC348" HREF="spec_toc.html#TOC348">sender_verify</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX909"></A>
<A NAME="IDX910"></A>
If this option is true, envelope sender addresses on incoming SMTP messages are
checked to ensure that they are valid. Messages with invalid envelope senders
are rejected with a permanent error code if <EM>sender_verify_reject</EM> is set
(the default). Otherwise a warning is logged. See section
45.2 for details of the rejection, which can happen at
three different points in the SMTP dialogue. If a sender cannot immediately be
verified, a temporary error code is returned after reading the data (so the
headers can be logged). The <EM>sender_try_verify</EM> option is less severe: it
operates in exactly the same way as <EM>sender_verify</EM> except that if an address
cannot immediately be verified, it is accepted instead of being temporarily
rejected.

</P>
<P>
<A NAME="IDX911"></A>


<H3><A NAME="SEC349" HREF="spec_toc.html#TOC349">sender_verify_batch</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
If this option is unset, the <EM>sender_verify</EM> options are not applied to
batched SMTP input.

</P>
<P>
<A NAME="IDX912"></A>


<H3><A NAME="SEC350" HREF="spec_toc.html#TOC350">sender_verify_hosts</A></H3>

<P>
Type: host list<BR>
Default: *

</P>
<P>
<A NAME="IDX913"></A>
If <EM>sender_verify</EM> or <EM>sender_try_verify</EM> is true, this option specifies a
list of hosts and RFC 1413 identifications to which sender verification
applies. The check caused by <EM>headers_sender_verify</EM> also happens only for
matching hosts. See chapter 45 for further details.

</P>
<P>
<A NAME="IDX914"></A>


<H3><A NAME="SEC351" HREF="spec_toc.html#TOC351">sender_verify_fixup</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX915"></A>
Experience shows that many messages are sent out onto the Internet with invalid
sender addresses in the envelopes (that is, in the MAIL command of the
SMTP dialogue), but with valid addresses in the <EM>Sender:</EM>, <EM>From:</EM>, or
<EM>Reply-To:</EM> header fields. If <EM>sender_verify</EM> and <EM>sender_verify_reject</EM> are
true and this option is also true, an invalid envelope sender or one that
cannot immediately be verified is replaced by a valid value from the headers.
If <EM>sender_verify_reject</EM> is false, the envelope sender is not changed, but
Exim writes a log entry giving the correction it would have made. See chapter
45 for details.

</P>
<P>
<A NAME="IDX916"></A>


<H3><A NAME="SEC352" HREF="spec_toc.html#TOC352">sender_verify_max_retry_rate</A></H3>

<P>
Type: integer<BR>
Default: 12

</P>
<P>
If this option is greater than zero, and the rate of temporary rejection of a
specific incoming sender address from a specific host, in units of rejections
per hour, exceeds it, the temporary error is converted into a permanent
verification error. Temporary rejections most commonly occur when a sender
address cannot be verified because a DNS lookup fails to complete.

</P>
<P>
The intent of this option is to stop hosts hammering too frequently with
temporarily failing sender addresses. The default value of 12 means that a
sender address that has a temporary verification error more than once every 5
minutes will eventually get permanently rejected. Once permanent rejection has
been triggered, subsequent temporary failures all cause permanent errors, until
there has been an interval of at least 24 hours since the last failure. After
24 hours, the hint expires.

</P>
<P>
<A NAME="IDX917"></A>


<H3><A NAME="SEC353" HREF="spec_toc.html#TOC353">sender_verify_reject</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
<A NAME="IDX918"></A>
When this is set, a message is rejected if sender verification fails. If it is
not set, a warning message is written to the main and reject logs, and the
message is accepted (unless some other error occurs).

</P>
<P>
<A NAME="IDX919"></A>


<H3><A NAME="SEC354" HREF="spec_toc.html#TOC354">smtp_accept_keepalive</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
This option controls the setting of the SO_KEEPALIVE option on incoming
TCP/IP socket connections. This causes the kernel periodically to send some OOB
(out-of-band) data on idle connections. The reason for doing this is that it
has the beneficial effect of freeing up certain types of connection that can
get stuck when the remote host is disconnected without tidying up the TCP/IP
call properly.

</P>
<P>
<A NAME="IDX920"></A>


<H3><A NAME="SEC355" HREF="spec_toc.html#TOC355">smtp_accept_max</A></H3>

<P>
Type: integer<BR>
Default: 20

</P>
<P>
<A NAME="IDX921"></A>
<A NAME="IDX922"></A>
<A NAME="IDX923"></A>
This specifies the maximum number of simultaneous incoming SMTP calls that Exim
will accept. It applies only to the listening daemon; there is no control (in
Exim) when incoming SMTP is being handled by <EM>inetd</EM>. If the value is set to
zero, no limit is applied.
However, it is required to be non-zero if <EM>smtp_accept_max_per_host</EM> or
<EM>smtp_accept_queue</EM> is set.

</P>
<P>
<A NAME="IDX924"></A>


<H3><A NAME="SEC356" HREF="spec_toc.html#TOC356">smtp_accept_max_per_host</A></H3>

<P>
Type: integer<BR>
Default: 0

</P>
<P>
This option restricts the number of simultaneous IP connections from a single
host (strictly, from a single IP address) to the Exim daemon.
Once the limit is reached, additional connection attempts are rejected with
error code 421.
The default value of zero imposes no limit. If this option is not zero, it is
required that <EM>smtp_accept_max</EM> also be non-zero.

</P>

<P>
<A NAME="IDX925"></A>


<H3><A NAME="SEC357" HREF="spec_toc.html#TOC357">smtp_accept_queue</A></H3>

<P>
Type: integer<BR>
Default: 0

</P>
<P>
<A NAME="IDX926"></A>
<A NAME="IDX927"></A>
<A NAME="IDX928"></A>
If the number of simultaneous incoming SMTP calls handled via the listening
daemon exceeds this value, messages received are simply placed on
the queue, and no delivery processes are started automatically. A value of zero
implies no limit, and clearly any non-zero value is useful only if it is less
than the <EM>smtp_accept_max</EM> value (unless that is zero). See also
<EM>queue_only</EM>, <EM>queue_only_load</EM>, <EM>queue_smtp_domains</EM>, and the various
-<EM>od</EM> command line options.

</P>

<P>
<A NAME="IDX929"></A>


<H3><A NAME="SEC358" HREF="spec_toc.html#TOC358">smtp_accept_queue_per_connection</A></H3>

<P>
Type: integer<BR>
Default: 10

</P>
<P>
<A NAME="IDX930"></A>
<A NAME="IDX931"></A>
This option limits the number of delivery processes that Exim starts
automatically when receiving messages via SMTP, whether via the daemon or by
the use of -<EM>bs</EM> or -<EM>bS</EM>. If the value of the option is greater than zero, and
the number of messages received in a single SMTP session exceeds this number,
subsequent messages are placed on the spool, but no delivery process is
started. This helps to limit the number of Exim processes when a server
restarts after downtime and there is a lot of mail waiting for it on other
systems. On large systems the default should probably be increased,
while on dial-in client systems it should probably be set to zero (that is,
disabled).

</P>

<P>
<A NAME="IDX932"></A>


<H3><A NAME="SEC359" HREF="spec_toc.html#TOC359">smtp_accept_reserve</A></H3>

<P>
Type: integer<BR>
Default: 0

</P>
<P>
<A NAME="IDX933"></A>
When <EM>smtp_accept_max</EM> is set greater than zero, this option specifies a
number of SMTP connections that are reserved for connections from the
hosts
that are specified in <EM>smtp_reserve_hosts</EM>. The value set in
<EM>smtp_accept_max</EM> includes this reserve pool. For example, if
<EM>smtp_accept_max</EM> is set to 50 and <EM>smtp_accept_reserve</EM> is set to 5,
once there are 45 active connections, new ones are accepted only from hosts
listed in <EM>smtp_reserve_hosts</EM>.

</P>
<P>
<A NAME="IDX934"></A>


<H3><A NAME="SEC360" HREF="spec_toc.html#TOC360">smtp_banner</A></H3>

<P>
Type: string, expanded<BR>
Default: see below

</P>
<P>
<A NAME="IDX935"></A>
<A NAME="IDX936"></A>
<A NAME="IDX937"></A>
<A NAME="IDX938"></A>
This string, which is expanded every time it is used, is output as the initial
positive response to an SMTP connection. The default setting is:

<PRE>
smtp_banner = $primary_hostname ESMTP Exim $version_number \
  #$compile_number $tod_full
</PRE>

<P>
Failure to expand the string causes a panic error. If you want to create a
multiline response to the initial SMTP connection, use `\n' in the string at
appropriate points,
but not at the end.
Note that the 220 code is not included in this string. Exim adds it
automatically (several times in the case of a multiline response).

</P>
<P>
<A NAME="IDX939"></A>


<H3><A NAME="SEC361" HREF="spec_toc.html#TOC361">smtp_check_spool_space</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
<A NAME="IDX940"></A>
<A NAME="IDX941"></A>
<A NAME="IDX942"></A>
When this option is set, if an incoming SMTP session encounters the SIZE
option on a MAIL command, it checks that there is enough space in the
spool directory's partition to accept a message of that size, while still
leaving free the amount specified by <EM>check_spool_space</EM> (even if that value
is zero). If there isn't enough space, a temporary error code is returned.

</P>
<P>
<A NAME="IDX943"></A>


<H3><A NAME="SEC362" HREF="spec_toc.html#TOC362">smtp_connect_backlog</A></H3>

<P>
Type: integer<BR>
Default: 5

</P>
<P>
<A NAME="IDX944"></A>
<A NAME="IDX945"></A>
This specifies a maximum number of waiting SMTP connections. Exim passes this
value to the TCP/IP system when it sets up its listener. Once this number of
connections are waiting for the daemon's attention, subsequent connection
attempts are refused at the TCP/IP level. At least, that is what the manuals
say. In Solaris 2.4 such connection attempts have been observed to time out.
The default value of 5 is a conservative one, suitable for older and smaller
systems.
For large systems is it probably a good idea to increase this, possibly
substantially (to 50, say). It also gives some protection against
denial-of-service attacks by SYN flooding.

</P>

<P>
<A NAME="IDX946"></A>


<H3><A NAME="SEC363" HREF="spec_toc.html#TOC363">smtp_etrn_command</A></H3>

<P>
Type: string, expanded<BR>
Default: unset

</P>
<P>
<A NAME="IDX947"></A>
<A NAME="IDX948"></A>
If this option is set, the given command is run whenever an SMTP ETRN
command is received from a host that is permitted to issue such commands (see
<EM>smtp_etrn_hosts</EM> below). The string is split up into separate arguments
which are independently expanded. The expansion variable $<EM>domain</EM> is set to
the argument of the ETRN command, and no syntax checking is done on it. For
example:

<PRE>
smtp_etrn_command = /etc/etrn_command $domain $sender_host_address
</PRE>

<P>
A new process is created to run the command, and Exim does not wait for it to
complete. Consequently, its status cannot be checked.
If the <EM>exec</EM> of the command fails, a line is written to the panic log, but the
ETRN caller still receives a 250 success response.
Exim is normally running under its own uid when receiving SMTP, so it is not
possible for it to change the uid before running the command.

</P>
<P>
You must disable <EM>smtp_etrn_serialize</EM> if you use this option to run
something other than a call of Exim with the -<EM>R</EM> option, because otherwise the
serialization lock never gets removed.

</P>

<P>
<A NAME="IDX949"></A>


<H3><A NAME="SEC364" HREF="spec_toc.html#TOC364">smtp_etrn_hosts</A></H3>

<P>
Type: host list<BR>
Default: unset

</P>
<P>
<A NAME="IDX950"></A>
<A NAME="IDX951"></A>
This option lists hosts that are permitted to issue an SMTP ETRN to the
local host. See section 48.6 for details.

</P>
<P>
<A NAME="IDX952"></A>


<H3><A NAME="SEC365" HREF="spec_toc.html#TOC365">smtp_etrn_serialize</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
<A NAME="IDX953"></A>
When this option is set, it prevents the simultaneous execution of more than
one queue run for the same argument string as a result of an ETRN command.
See section 48.6 for details.

</P>

<P>
<A NAME="IDX954"></A>


<H3><A NAME="SEC366" HREF="spec_toc.html#TOC366">smtp_expn_hosts</A></H3>

<P>
Type: host list<BR>
Default: unset

</P>
<P>
<A NAME="IDX955"></A>
The SMTP EXPN command is supported only if the calling host matches
<EM>smtp_expn_hosts</EM>. You must add `localhost' explicitly if you want calls to
127.0.0.1 to be able to use it. A single-level expansion of the address is
done, as if the address were being tested using the -<EM>bt</EM> option. If an
unqualified local part is given, it is qualified with <EM>qualify_domain</EM>. There
is a generic option for directors which permits them to be skipped when
processing an EXPN command (compare with verification).

</P>
<P>
<A NAME="IDX956"></A>


<H3><A NAME="SEC367" HREF="spec_toc.html#TOC367">smtp_load_reserve</A></H3>

<P>
Type: fixed-point<BR>
Default: unset

</P>
<P>
<A NAME="IDX957"></A>
If the system load average ever gets higher than this, incoming SMTP calls are
accepted only from those hosts that match an entry in <EM>smtp_reserve_hosts</EM>.
<font color=green>
If <EM>smtp_reserve_hosts</EM> is not set, no incoming SMTP calls are accepted when
the load is over the limit.
</font>
There are some operating systems for which Exim cannot determine the load
average (see chapter 1); for these this option has no effect.

</P>
<P>
<A NAME="IDX958"></A>


<H3><A NAME="SEC368" HREF="spec_toc.html#TOC368">smtp_receive_timeout</A></H3>

<P>
Type: time<BR>
Default: 5m

</P>
<P>
<A NAME="IDX959"></A>
<A NAME="IDX960"></A>
This sets a timeout value for SMTP reception. If a line of input (either an
SMTP command or a data line) is not received within this time, the SMTP
connection is dropped and the message is abandoned.
For non-SMTP input, the reception timeout is controlled by <EM>accept_timeout</EM>.

</P>
<P>
<A NAME="IDX961"></A>


<H3><A NAME="SEC369" HREF="spec_toc.html#TOC369">smtp_reserve_hosts</A></H3>

<P>
Type: host list<BR>
Default: unset

</P>
<P>
This option defines hosts for which SMTP connections are reserved; see
<EM>smtp_accept_reserve</EM> and <EM>smtp_load_reserve</EM> above.

</P>
<P>
<A NAME="IDX962"></A>


<H3><A NAME="SEC370" HREF="spec_toc.html#TOC370">smtp_verify</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX963"></A>
If this option is true, the SMTP command VRFY is supported on incoming SMTP
connections; otherwise it is not.

</P>
<P>
<A NAME="IDX964"></A>


<H3><A NAME="SEC371" HREF="spec_toc.html#TOC371">split_spool_directory</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX965"></A>
<A NAME="IDX966"></A>
<A NAME="IDX967"></A>
<A NAME="IDX968"></A>
<A NAME="IDX969"></A>
If this option is set, it causes Exim to split its input directory into 62
subdirectories, each with a single alphanumeric character as its name. The
<font color=green>
sixth
</font>
character of the message id is used to allocate messages to subdirectories;
this is the least significant base-62 digit of the time of arrival of the
message.

</P>
<P>
Splitting up the spool in this way may provide better performance on systems
where there are long mail queues, by reducing the number of files in any one
directory. The msglog directory is also split up in a similar way to the input
directory; however, if <EM>preserve_message_logs</EM> is set, all old msglog files
are still placed in the single directory <EM>msglog.OLD</EM>.

</P>
<P>
It is not necessary to take any special action for existing messages when
changing <EM>split_spool_directory</EM>. Exim notices messages that are in the
`wrong' place, and continues to process them. If the option is turned off after
a period of being on, the subdirectories will eventually empty and be
automatically deleted.

</P>
<P>
<font color=green>
When <EM>split_spool_directory</EM> is set, the behaviour of queue runner processes
changes. Instead of creating a list of all messages in the queue, and then
trying to deliver each one in turn, it constructs a list of those in one
sub-directory and tries to deliver them, before moving on to the next
sub-directory. The sub-directories are processed in a random order. This
spreads out the scanning of the input directories, and is beneficial when there
are lots of messages on the queue. However, if <EM>queue_run_in_order</EM> is set,
none of this new processing happens. The entire queue is scanned and sorted
before any deliveries start.
</font>

</P>
<P>
<A NAME="IDX970"></A>


<H3><A NAME="SEC372" HREF="spec_toc.html#TOC372">spool_directory</A></H3>

<P>
Type: string<BR>
Default: set at compile time

</P>
<P>
This defines the directory in which Exim keeps its mail spool. The default
value is taken from the compile-time configuration setting, if there is one. If
not, this option must be set. The string is expanded, so it can contain, for
example, a reference to $<EM>primary_hostname</EM>.

</P>
<P>
If the spool directory name is fixed on your installation, it is
recommended that you set it at build time rather than from this option,
particularly if the log files are being written to the spool directory (see
<EM>log_file_path</EM>). Otherwise log files cannot be used for errors that are
detected early on, such as failures in the configuration file.

</P>
<P>
Even with a compiled-in path, however, this option makes it possible to run
testing configurations of Exim without using the standard spool.

</P>
<P>
<A NAME="IDX971"></A>


<H3><A NAME="SEC373" HREF="spec_toc.html#TOC373">strip_excess_angle_brackets</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX972"></A>
If this option is set, redundant pairs of angle brackets round
`route-addr' items in addresses are stripped. For example,
<EM>&#60;&#60;xxx@a.b.c.d&#62;&#62;</EM> is treated as <EM>&#60;xxx@a.b.c.d&#62;</EM>. If this is in the
envelope and the message is passed on to another MTA, the excess angle brackets
are not passed on. If this option is not set, multiple pairs of angle brackets
cause a syntax error.

</P>
<P>
<A NAME="IDX973"></A>


<H3><A NAME="SEC374" HREF="spec_toc.html#TOC374">strip_trailing_dot</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX974"></A>
<A NAME="IDX975"></A>
<A NAME="IDX976"></A>
If this option is set, a trailing dot at the end of a domain in an address is
ignored. If this is in the envelope and the message is passed on to another
MTA, the dot is not passed on. If this option is not set, a dot at the end of a
domain causes a syntax error.

</P>

<P>
<font color=green>
<A NAME="IDX977"></A>


<H3><A NAME="SEC375" HREF="spec_toc.html#TOC375">timeout_frozen_after</A></H3>

<P>
Type: time<BR>
Default: 0s

</P>
<P>
<A NAME="IDX978"></A>
<A NAME="IDX979"></A>
If <EM>timeout_frozen_after</EM> is set to a time greater than zero, a frozen
message of any description that has been on the queue for longer than the given
time is automatically cancelled at the next queue run. If it is a bounce
message, it is just discarded; otherwise, a bounce is sent to the sender, in a
similar manner to cancellation by the -<EM>Mg</EM> command line option. If you want to
timeout frozen bounce messages earlier than other kinds of frozen message, see
<EM>ignore_errmsg_errors_after</EM>.

</P>
<P>
<A NAME="IDX980"></A>


<H3><A NAME="SEC376" HREF="spec_toc.html#TOC376">timestamps_utc</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX981"></A>
<A NAME="IDX982"></A>
If <EM>timestamps_utc</EM> is set, all timestamps generated by Exim (for example, in
log entries and <EM>Received:</EM> header lines) are in UTC (aka GMT) rather than in
local wall-clock time.

</P>
<P>
<A NAME="IDX983"></A>


<H3><A NAME="SEC377" HREF="spec_toc.html#TOC377">timezone</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
<A NAME="IDX984"></A>
When <EM>timestamps_utc</EM> is not set, the value of <EM>timezone</EM> is used to set the
environment variable TZ while running Exim (if it is different on entry).
This ensures that all timestamps created by Exim are in the required timezone.
The default value is taken from TIMEZONE_DEFAULT in <TT>`Local/Makefile'</TT>,
or, if that is not set, from the value of the TZ environment variable when Exim
is built. If <EM>timezone</EM> is set to the empty string, either at build or run
time, then any existing TZ variable is removed from the environment when
Exim runs. This is appropriate behaviour for obtaining wall-clock time on some,
but unfortunately not all, operating systems.

</P>
<P>
<A NAME="IDX985"></A>


<H3><A NAME="SEC378" HREF="spec_toc.html#TOC378">tls_advertise_hosts</A></H3>

<P>
Type: host list<BR>
Default: unset

</P>
<P>
<A NAME="IDX986"></A>
<A NAME="IDX987"></A>
<A NAME="IDX988"></A>
<A NAME="IDX989"></A>
When Exim is built with support for TLS encrypted connections, the availability
of the STARTTLS command to set up an encrypted session is advertised only
to those client hosts that match this option. See chapter 38 for details
of Exim's support for TLS.

</P>
<P>
<A NAME="IDX990"></A>


<H3><A NAME="SEC379" HREF="spec_toc.html#TOC379">tls_certificate</A></H3>

<P>
Type: string, expanded<BR>
Default: unset

</P>
<P>
The value of this option is expanded, and must then be the absolute path to
a file which contains the server's certificate.

</P>
<P>
<A NAME="IDX991"></A>


<H3><A NAME="SEC380" HREF="spec_toc.html#TOC380">tls_dhparam</A></H3>

<P>
Type: string, expanded<BR>
Default: unset

</P>
<P>
The value of this option is expanded, and must then be the absolute path to
a file which contains the server's DH parameter values.

</P>
<P>
<A NAME="IDX992"></A>


<H3><A NAME="SEC381" HREF="spec_toc.html#TOC381">tls_host_accept_relay</A></H3>

<P>
Type: host list<BR>
Default: unset

</P>
<P>
Client hosts which match this list are allowed to relay, provided they make
use of TLS to send the message over an encrypted channel.

</P>
<P>
<A NAME="IDX993"></A>


<H3><A NAME="SEC382" HREF="spec_toc.html#TOC382">tls_hosts</A></H3>

<P>
Type: host list<BR>
Default: unset

</P>
<P>
Client hosts which match this list are required to use TLS to set up an
encrypted channel before Exim will accept any messages from them.

</P>
<P>
<A NAME="IDX994"></A>


<H3><A NAME="SEC383" HREF="spec_toc.html#TOC383">tls_log_cipher</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
If this option is set set, the cipher which was used to transmit a message is
logged using the tag `X='. This applies to both incoming and outgoing messages.

</P>
<P>
<A NAME="IDX995"></A>


<H3><A NAME="SEC384" HREF="spec_toc.html#TOC384">tls_log_peerdn</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
If this option is set, the Distinguished Name of the server's certificate is
logged, using the tag `DN=', for all outgoing messages delivered over TLS. For
incoming messages, the DN from the client's certificate is logged if a
certificate was requested from the client (see <EM>tls_verify_certificates</EM>).

</P>
<P>
<A NAME="IDX996"></A>


<H3><A NAME="SEC385" HREF="spec_toc.html#TOC385">tls_privatekey</A></H3>

<P>
Type: string, expanded<BR>
Default: unset

</P>
<P>
The value of this option is expanded, and must then be the absolute path to
a file which contains the server's private key.

</P>
<P>
<A NAME="IDX997"></A>


<H3><A NAME="SEC386" HREF="spec_toc.html#TOC386">tls_verify_certificates</A></H3>

<P>
Type: string, expanded<BR>
Default: unset

</P>
<P>
The value of this option is expanded, and must then be the absolute path to
a file or a directory containing permitted certificates for clients that
match <EM>tls_verify_hosts</EM>.

</P>
<P>
<A NAME="IDX998"></A>


<H3><A NAME="SEC387" HREF="spec_toc.html#TOC387">tls_verify_ciphers</A></H3>

<P>
Type: string, expanded<BR>
Default: unset

</P>
<P>
The value of this option is expanded, and must then be a list of permitted
ciphers for the clients that match <EM>tls_verify_hosts</EM>.

</P>
<P>
<A NAME="IDX999"></A>


<H3><A NAME="SEC388" HREF="spec_toc.html#TOC388">tls_verify_hosts</A></H3>

<P>
Type: host list<BR>
Default: unset

</P>
<P>
Any client that matches this list is constrained by <EM>tls_verify_certificates</EM>
and <EM>tls_verify_ciphers</EM>, that is, it must use one of the permitted ciphers,
and present one of the listed certificates. Client hosts that do not match the
list are not so constrained.
</font>

</P>
<P>
<A NAME="IDX1000"></A>


<H3><A NAME="SEC389" HREF="spec_toc.html#TOC389">trusted_groups</A></H3>

<P>
Type: string list<BR>
Default: unset

</P>
<P>
<font color=green>
If this option is set, any process that is running in one of the listed groups,
or which has one of them as a supplementary group, is trusted. See section
5.2 for details what trusted callers are permitted to do. If
neither <EM>trusted_groups</EM> nor <EM>trusted_users</EM> is set, only root and the Exim
user are trusted.
</font>

</P>
<P>
<A NAME="IDX1001"></A>


<H3><A NAME="SEC390" HREF="spec_toc.html#TOC390">trusted_users</A></H3>

<P>
Type: string list<BR>
Default: unset

</P>
<P>
<font color=green>
If this option is set, any process that is running as one of the listed users
is trusted. See section 5.2 for details what trusted callers are
permitted to do. If neither <EM>trusted_groups</EM> nor <EM>trusted_users</EM> is set, only
root and the Exim user are trusted.
</font>

</P>
<P>
<A NAME="IDX1002"></A>
<A NAME="IDX1003"></A>


<H3><A NAME="SEC391" HREF="spec_toc.html#TOC391">unknown_login</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
This is a specialized feature for use in unusual configurations. By default, if
the uid of the caller of Exim cannot be looked up using <EM>getpwuid()</EM>, Exim
gives up. The <EM>unknown_login</EM> option can be used to set a login name to be
used in this circumstance. It is expanded, so values like <EM>user$caller_uid</EM>
can be set. When <EM>unknown_login</EM> is used, the value of <EM>unknown_username</EM> is
used for the user's real name (gecos field), unless this has been set by the
-<EM>F</EM> option.

</P>
<P>
<A NAME="IDX1004"></A>


<H3><A NAME="SEC392" HREF="spec_toc.html#TOC392">unknown_username</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
See <EM>unknown_login</EM>.

</P>
<P>
<font color=green>
<A NAME="IDX1005"></A>


<H3><A NAME="SEC393" HREF="spec_toc.html#TOC393">untrusted_set_sender</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
<A NAME="IDX1006"></A>
By default, the only form in which untrusted users can use the -<EM>f</EM> command
line option when submitting a local message is with an empty address, to
declare that a message should never generate any bounces. If
<EM>untrusted_set_sender</EM> is true, this restriction is lifted, and untrusted
users may set any sender value using -<EM>f</EM>. This does not make all users
trusted; they may use only -<EM>f</EM>, not the other options which override message
parameters. Furthermore, this does not stop Exim from adding a <EM>Sender:</EM> header
if necessary (unless this is disabled by <EM>no_local_from_check</EM>).

</P>
<P>
The log line for a message's arrival shows the envelope sender following `&#60;='
but for local messages, the user's login always follows, after `U='.
In -<EM>bp</EM> displays, and in the Exim monitor, if an untrusted user sets a sender
address by this method, the user's login is shown in parentheses after the
sender address.
</font>

</P>
<P>
<A NAME="IDX1007"></A>


<H3><A NAME="SEC394" HREF="spec_toc.html#TOC394">uucp_from_pattern</A></H3>

<P>
Type: string<BR>
Default: see below

</P>
<P>
<A NAME="IDX1008"></A>
<A NAME="IDX1009"></A>
Some applications that pass messages to an MTA via a command line interface use
an initial line starting with `From' to pass the envelope sender. In
particular, this is used by UUCP software. Exim recognizes such a line by means
of a regular expression that is set in <EM>uucp_from_pattern</EM>, and when the
pattern matches, the sender address is constructed by expanding the contents of
<EM>uucp_from_sender</EM>, provided that the caller of Exim is a trusted user. The
default pattern recognizes lines in the following two forms:

<PRE>
   From ph10 Fri Jan  5 12:35 GMT 1996
   From ph10 Fri, 7 Jan 97 14:00:00 GMT
</PRE>

<P>
The pattern can be seen by running `exim -bP uucp_from_pattern'.
It checks only up to the hours and minutes, and allows for a 2-digit or 4-digit
year in the second case. The first word after `From' is matched in the regular
expression by a parenthesized subpattern. The default value for
<EM>uucp_from_sender</EM> is `$1', which therefore just uses this first word (`ph10'
in the example above) as the message's sender.
See also <EM>ignore_fromline_hosts</EM>.

</P>
<P>
<A NAME="IDX1010"></A>


<H3><A NAME="SEC395" HREF="spec_toc.html#TOC395">uucp_from_sender</A></H3>

<P>
Type: string, expanded<BR>
Default: "$1"

</P>
<P>
See <EM>uucp_from_pattern</EM> above.

</P>
<P>
<A NAME="IDX1011"></A>


<H3><A NAME="SEC396" HREF="spec_toc.html#TOC396">warnmsg_file</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
<A NAME="IDX1012"></A>
This option defines a template file containing paragraphs of text to be used
for constructing the warning message which is sent by Exim when a message has
been on the queue for a specified amount of time, as specified by
<EM>delay_warning</EM>. Details of the file's contents are given in chapter
39. See also <EM>errmsg_file</EM>.

</P>

<P><HR><P>
Go to the <A HREF="spec_1.html">first</A>, <A HREF="spec_10.html">previous</A>, <A HREF="spec_12.html">next</A>, <A HREF="spec_59.html">last</A> section, <A HREF="spec_toc.html">table of contents</A>.
</BODY>
</HTML>