File: spec_15.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 (1630 lines) | stat: -rw-r--r-- 50,602 bytes
<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.52
     from spec on 25 November 2000 -->

<TITLE>Exim Specification - 15. The appendfile transport</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_14.html">previous</A>, <A HREF="spec_16.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="SEC418" HREF="spec_toc.html#TOC418">15. The appendfile transport</A></H1>
<P>
<A NAME="IDX1072"></A>
<A NAME="IDX1073"></A>
<A NAME="IDX1074"></A>
<A NAME="IDX1075"></A>
The <EM>appendfile</EM> transport delivers a message by appending it to a file in the
local file system, or by creating an entirely new file in a specified
directory. Single files to which messages are appended can be in the
traditional Unix mailbox format, or optionally in the MBX format supported by
the Pine MUA and University of Washington IMAP daemon, <EM>inter alia</EM>. When
each message is being delivered as a separate file, `maildir' format can
optionally be used to give added protection against failures that happen
part-way through the delivery. A third form of separate-file delivery known as
`mailstore' is also supported. For
all
file formats, Exim attempts to create as many levels of directory as necessary,
provided that <EM>create_directory</EM> is set.

</P>
<P>
The code for the optional formats is not included in the Exim binary by
default. It is necessary to set SUPPORT_MBX, SUPPORT_MAILDIR and/or
SUPPORT_MAILSTORE in <TT>`Local/Makefile'</TT> to have the appropriate code
included.

</P>
<P>
<EM>Appendfile</EM> can be used by routers as a pseudo-remote transport for putting
messages into files for remote delivery by some means other than Exim, though
it is more commonly used by directors for local deliveries to users' mailboxes.
It is also used for delivering messages to files or directories whose names are
obtained directly from alias, forwarding, or filtering operations. In these
cases, $<EM>local_part</EM> contains the local part that was aliased or forwarded,
while $<EM>address_file</EM> contains the name of the file or directory.

</P>
<P>
As <EM>appendfile</EM> is a local transport, it is always run in a separate process,
under a non-privileged uid and gid, which are set by <EM>setuid()</EM>. In the common
local delivery case, these are the uid and gid belonging to the user to whom
the mail is being delivered. The current directory is also normally set to the
user's home directory. See chapter 13 for a discussion of the
local delivery environment.

</P>
<P>
If the transport fails for any reason, the message remains on the input queue
so that there can be another delivery attempt later. If there is an error while
appending to a file (for example, quota exceeded or partition filled), Exim
attempts to reset the file's length and last modification time back to what
they were before. Exim supports a local quota, for use when the system facility
is unavailable or cannot be used for some reason.

</P>
<P>
Before appending to a file, a number of security checks are made, and the
file is locked. A detailed description is given below, after the list of
private options.

</P>

<P>



<H2><A NAME="SEC419" HREF="spec_toc.html#TOC419">15.1 Private options for appendfile</A></H2>

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

</P>

<P>

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


<H3><A NAME="SEC420" HREF="spec_toc.html#TOC420">allow_fifo (appendfile)</A></H3>

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

</P>
<P>
<A NAME="IDX1078"></A>
<A NAME="IDX1079"></A>
<A NAME="IDX1080"></A>
Setting this option permits delivery to named pipes (FIFOs) as well as to
regular files. If no process is reading the named pipe at delivery time, the
delivery is deferred.
</font>

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


<H3><A NAME="SEC421" HREF="spec_toc.html#TOC421">allow_symlink (appendfile)</A></H3>

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

</P>
<P>
<A NAME="IDX1082"></A>
<A NAME="IDX1083"></A>
<A NAME="IDX1084"></A>
By default, <EM>appendfile</EM> will not deliver if the path name for the file is that
of a symbolic link. Setting this option relaxes that constraint, but there are
security issues involved in the use of symbolic links. Be sure you know what
you are doing if you set this. Details of exactly what this option affects are
included in the discussion which follows this list of options.

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


<H3><A NAME="SEC422" HREF="spec_toc.html#TOC422">batch (appendfile)</A></H3>

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

</P>
<P>
Normally, each address that is directed or routed to an <EM>appendfile</EM> transport
is handled separately. In special cases it may be desirable to handle several
addresses at once, for example, when passing a message with several addresses
to a different mail regime (for example, UUCP), though this is more often done
using the <EM>pipe</EM> transport. If this option is set to the string `domain',
all addresses with the same domain that are directed or routed to the transport
are handled in a single delivery. If it is set to `all' then multiple domains
are batched. The list of addresses is included in the <EM>Envelope-to:</EM> header
<A NAME="IDX1086"></A>
if the generic <EM>envelope_to_add</EM> option is set.
When more than one address is being delivered, $<EM>local_part</EM> is not set, and
$<EM>domain</EM> is set only if they all have the same domain.
The only difference between this option and <EM>bsmtp</EM> is the inclusion of SMTP
command lines in the output for <EM>bsmtp</EM>, and the escaping of lines that begin
with a full stop (period).

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


<H3><A NAME="SEC423" HREF="spec_toc.html#TOC423">batch_max (appendfile)</A></H3>

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

</P>
<P>
This limits the number of addresses that can be handled in a batch, and applies
to both the <EM>batch</EM> and the <EM>bsmtp</EM> options.

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


<H3><A NAME="SEC424" HREF="spec_toc.html#TOC424">bsmtp (appendfile)</A></H3>

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

</P>
<P>
This option is used to set up an <EM>appendfile</EM> transport as a pseudo-remote
transport for delivering messages into local files in batch SMTP format for
onward transmission by some non-Exim means. It is usually necessary to suppress
the default settings of the <EM>prefix</EM> and <EM>suffix</EM> options when using batch
SMTP.
The <EM>check_string</EM> and <EM>escape_string</EM> options are forced to the values

<PRE>
check_string = "."
escape_string = ".."
</PRE>

<P>
when batched SMTP is in use.
The value of <EM>bsmtp</EM> must be one of the strings `none', `one', `domain', or
`all'. The first of these turns the feature off. A full description of the
batch SMTP mechanism is given in section 48.8. When <EM>bstmp</EM> is set,
the <EM>batch</EM> option automatically takes the same value. See also the <EM>use_crlf</EM>
option.

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


<H3><A NAME="SEC425" HREF="spec_toc.html#TOC425">bsmtp_helo (appendfile)</A></H3>

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

</P>
<P>
When this option is set, a HELO line is added to the output at the
start of each message written in batch SMTP format. Some software that reads
batch SMTP is unhappy without this.

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


<H3><A NAME="SEC426" HREF="spec_toc.html#TOC426">check_group (appendfile)</A></H3>

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

</P>
<P>
The group owner of the file is checked to see that it is the same as the group
under which the delivery process is running when this option is set. The
default setting is false because the default file mode is 0600, which means
that the group is irrelevant.

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


<H3><A NAME="SEC427" HREF="spec_toc.html#TOC427">check_owner (appendfile)</A></H3>

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

</P>
<P>
The owner of the file is checked to ensure that it is the same as the user
under which the delivery process is running when this option is set.
</font>

</P>

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


<H3><A NAME="SEC428" HREF="spec_toc.html#TOC428">check_string (appendfile)</A></H3>

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

</P>
<P>
<A NAME="IDX1093"></A>
As <EM>appendfile</EM> writes the message, the start of each line is tested for
matching <EM>check_string</EM>, and if it does, the initial matching characters are
replaced by the contents of <EM>escape_string</EM>. The value of <EM>check_string</EM> is a
literal string, not a regular expression,
<font color=green>
and the case of any letters it contains is significant.
</font>
For backwards compatibility, if <EM>no_from_hack</EM> is specified, the values of
<EM>check_string</EM> and <EM>escape_string</EM> are forced to be unset.

</P>
<P>
The default settings, along with <EM>prefix</EM> and <EM>suffix</EM>, are suitable for
traditional `BSD' mailboxes, where a line beginning with `From ' indicates the
start of a new message. All four options need changing if another format is
used. For example, to deliver to mailboxes in MMDF format:
<A NAME="IDX1094"></A>
<A NAME="IDX1095"></A>

<PRE>
check_string = "\1\1\1\1\n"
escape_string = "\1\1\1\1 \n"
prefix = "\1\1\1\1\n"
suffix = "\1\1\1\1\n"
</PRE>

<P>
When the <EM>bsmtp</EM> option is set, the contents of <EM>check_string</EM> and
<EM>escape_string</EM> are forced to values that implement the SMTP escaping
protocol. Any settings made in the configuration file are ignored.

</P>

<P>
<A NAME="IDX1096"></A>
<A NAME="IDX1097"></A>


<H3><A NAME="SEC429" HREF="spec_toc.html#TOC429">create_directory (appendfile)</A></H3>

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

</P>
<P>
When this option is true, Exim creates any missing superior directories for the
file that it is about to write. A created directory's mode is given by the
<EM>directory_mode</EM> option.

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


<H3><A NAME="SEC430" HREF="spec_toc.html#TOC430">create_file (appendfile)</A></H3>

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

</P>
<P>
This option constrains the location of files that are created by this
transport. It must be set to one of the words `anywhere', `inhome', or
`belowhome'. In the second and third cases, a home directory must have been set
up for the address by the director that handled it. This option isn't useful
when an explicit file name is given for normal mailbox deliveries; it is
intended for the case when file names have been generated from user's
<TT>`.forward'</TT> files, which are usually handled by an <EM>appendfile</EM> transport called
<EM>address_file</EM>. See also <EM>file_must_exist</EM>.

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


<H3><A NAME="SEC431" HREF="spec_toc.html#TOC431">current_directory (appendfile)</A></H3>

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

</P>
<P>
If this option is set, it specifies the directory to make current when running
the delivery process. The string is expanded at the time the transport is run.
See chapter 13 for details of the local delivery environment.

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


<H3><A NAME="SEC432" HREF="spec_toc.html#TOC432">directory (appendfile)</A></H3>

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

</P>
<P>
This option is mutually exclusive with the <EM>file</EM> option. When it is set, the
string is expanded, and the message is delivered into a new file or files in or
below the given directory, instead of being appended to a single mailbox file.
A number of different formats are provided (see <EM>maildir_format</EM> and
<EM>mailstore_format</EM>), and see section 15.3 for further details of this
form of delivery.

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


<H3><A NAME="SEC433" HREF="spec_toc.html#TOC433">directory_mode (appendfile)</A></H3>

<P>
Type: octal integer<BR>
Default: 0700

</P>
<P>
If <EM>appendfile</EM> creates any directories as a result of the <EM>create_directory</EM>
option, their mode is specified by this option.

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


<H3><A NAME="SEC434" HREF="spec_toc.html#TOC434">escape_string (appendfile)</A></H3>

<P>
Type: string<BR>
Default: "&#62;From "

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

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


<H3><A NAME="SEC435" HREF="spec_toc.html#TOC435">file (appendfile)</A></H3>

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

</P>
<P>
This option is mutually exclusive with the <EM>directory</EM> option. It
need not be set when <EM>appendfile</EM> is being used to deliver to files whose names
are obtained from forwarding, filtering, or aliasing address expansions (by
default under the instance name <EM>address_file</EM>), as in those cases the file
name is associated with the address. Otherwise, the <EM>file</EM> option must be set
unless the <EM>directory</EM> option is set. Either <EM>use_fcntl_lock</EM> or
<EM>use_lockfile</EM> (or both) must be set with <EM>file</EM>.
<A NAME="IDX1104"></A>
<A NAME="IDX1105"></A>
<A NAME="IDX1106"></A>
If you are using more than one host to deliver over NFS into the same
mailboxes, you should always use lock files.

</P>
<P>
<font color=green>
The string value is expanded for each delivery, and must yield an absolute
path. The most common settings of this option are variations on one of these
examples:
</font>

<PRE>
file = /var/spool/mail/$local_part
file = /home/$local_part/inbox
file = $home/inbox
</PRE>

<P>
<A NAME="IDX1107"></A>
In the first example, all deliveries are done into the same directory. If Exim
is configured to use lock files (see <EM>use_lockfile</EM> below) it must be able to
create a file in the directory, so the `sticky' bit must be turned on for
deliveries to be possible, or alternatively the <EM>group</EM> option can be used to
run the delivery under a group id which has write access to the directory.

</P>
<P>
If there is no file name, or the expansion fails, or a local part contains a
forward slash character, a delivery error occurs.

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


<H3><A NAME="SEC436" HREF="spec_toc.html#TOC436">file_format (appendfile)</A></H3>

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

</P>
<P>
<A NAME="IDX1109"></A>
This option requests the transport to check the format of an existing
file before adding to it. The check consists of matching a specific string at
the start of the file. A list of check strings may be given, and associated
with each is the the name of a transport. If the transport associated with a
matched string is not the current transport, control is passed over to the
other transport. There should always be an even number of items in a
<EM>file_format</EM> setting. For example, if the standard <EM>local_delivery</EM>
transport has this added to it:

<PRE>
file_format = "From       : local_delivery :\
               \1\1\1\1\n : local_mmdf_delivery"
</PRE>

<P>
then mailboxes that begin with `From' are handled by this transport, but if a
mailbox begins with four binary ones followed by a newline, control is passed
to a transport called <EM>local_mmdf_delivery</EM> which presumably is configured to
do the delivery in MMDF format. If a mailbox does not exist or is empty, it is
assumed to match the current transport. If the start of a mailbox doesn't match
any string, or if the transport named for a given string is not defined,
delivery is deferred.

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


<H3><A NAME="SEC437" HREF="spec_toc.html#TOC437">file_must_exist (appendfile)</A></H3>

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

</P>
<P>
If this option is true, the file specified by the <EM>file</EM> option must exist, and
an error occurs if it does not. Otherwise, it is created if it does not exist.

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


<H3><A NAME="SEC438" HREF="spec_toc.html#TOC438">from_hack (appendfile)</A></H3>

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

</P>
<P>
This option is obsolete and is retained only for backwards compatibility. It
has been replaced by <EM>check_string</EM> and <EM>escape_string</EM>. If it is explicitly
unset (that is, if <EM>no_from_hack</EM> is specified), it causes both the new
options to be unset. Otherwise it is ignored.

</P>

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


<H3><A NAME="SEC439" HREF="spec_toc.html#TOC439">group (appendfile)</A></H3>

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

</P>
<P>
<A NAME="IDX1113"></A>
If this option is set, it specifies the group under whose gid the delivery
process is to be run,
and, if <EM>check_group</EM> is set, the group owner of an existing file to which the
message is to be appended.
If the option is not set, a value associated with a user may be used (see
below); otherwise a value must have been associated with the address by the
director which handled it. If the string contains no $ characters, it is
resolved when Exim starts up. Otherwise, the string is expanded at the time the
transport is run, and must yield either a digit string or a name which can be
looked up using <EM>getgrnam()</EM>.

</P>
<P>
The <EM>group</EM> option is commonly set for local deliveries on systems where the
set of user mailboxes is in a single directory owned by a group such as `mail'.
Note that it should <EM>not</EM> be set on the instance of <EM>appendfile</EM> that is
used for deliveries to files specified by users in their forward files (called
<EM>address_file</EM> in the default configuration), because such deliveries should
take place under the individual users' personal uids and gids.

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


<H3><A NAME="SEC440" HREF="spec_toc.html#TOC440">lock_fcntl_timeout (appendfile)</A></H3>

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

</P>
<P>
<A NAME="IDX1115"></A>
<A NAME="IDX1116"></A>
<A NAME="IDX1117"></A>
By default, the <EM>appendfile</EM> transport uses non-blocking calls to <EM>fcntl()</EM>
when locking an open mailbox file. If the call fails, it sleeps for
<EM>lock_interval</EM> and tries again, up to <EM>lock_retries</EM> times. Non-blocking
calls are used so that the file is not kept open during the wait for the lock;
the reason for this is to make it as safe as possible for deliveries over NFS
in the case when processes might be accessing an NFS mailbox without using a
lock file. This should not be done, but misunderstandings and hence
misconfigurations are not unknown.

</P>
<P>
On a busy system, however, the performance of a non-blocking lock approach is
not as good as using a blocking lock with a timeout. In this case, the waiting
is done inside the system call, and Exim's delivery process acquires the lock
and can proceed as soon as the previous lock holder releases it.

</P>
<P>
If <EM>lock_fcntl_timeout</EM> is set to a non-zero time, blocking locks, with that
timeout, are used. There may still be some retrying: the maximum number of
retries is

<PRE>
(lock_retries * lock_interval) / lock_fcntl_timeout
</PRE>

<P>
rounded up to the next whole number. In other words, the total time during
which <EM>appendfile</EM> is trying to get a lock is roughly the same, unless
<EM>lock_fcntl_timeout</EM> is set very large.

</P>
<P>
You should consider setting this option if you are getting a lot of delayed
local deliveries because of errors of the form

<PRE>
failed to lock mailbox /some/file (fcntl)
</PRE>

<P>
</font>

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


<H3><A NAME="SEC441" HREF="spec_toc.html#TOC441">lock_interval (appendfile)</A></H3>

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

</P>
<P>
This specifies the time to wait between attempts to lock the file. See below
for details of locking.

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


<H3><A NAME="SEC442" HREF="spec_toc.html#TOC442">lock_retries (appendfile)</A></H3>

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

</P>
<P>
This specifies the maximum number of attempts to lock the file. A value of zero
is treated as 1. See below for details of locking.

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


<H3><A NAME="SEC443" HREF="spec_toc.html#TOC443">lockfile_mode (appendfile)</A></H3>

<P>
Type: octal integer<BR>
Default: 0600

</P>
<P>
This specifies the mode of the created lock file, when a lock file is being
used (see <EM>use_lockfile</EM>).

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


<H3><A NAME="SEC444" HREF="spec_toc.html#TOC444">lockfile_timeout (appendfile)</A></H3>

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

</P>
<P>
When a lock file is being used (see <EM>use_lockfile</EM>), if a lock file already
exists and is older than this value, it is assumed to have been left behind by
accident, and Exim attempts to remove it.

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


<H3><A NAME="SEC445" HREF="spec_toc.html#TOC445">maildir_format (appendfile)</A></H3>

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

</P>
<P>
If this option is set with the <EM>directory</EM> option, the delivery is into a
new file in the `maildir' format that is used by some other mail software.
The option is available only if SUPPORT_MAILDIR is present in
<TT>`Local/Makefile'</TT>.
See section 15.3 below for further details.

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


<H3><A NAME="SEC446" HREF="spec_toc.html#TOC446">maildir_retries (appendfile)</A></H3>

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

</P>
<P>
This option specifies the number of times to retry when writing a file in
`maildir' format. See section 15.3 below.

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


<H3><A NAME="SEC447" HREF="spec_toc.html#TOC447">maildir_tag (appendfile)</A></H3>

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

</P>
<P>
This option applies only to deliveries in maildir format, and is described in
section 15.3 below.

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


<H3><A NAME="SEC448" HREF="spec_toc.html#TOC448">mailstore_format (appendfile)</A></H3>

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

</P>
<P>
If this option is set with the <EM>directory</EM> option, the delivery is into
two new files in  `mailstore' format. The option is available only if
SUPPORT_MAILSTORE is present in <TT>`Local/Makefile'</TT>. See section 15.3
below for further details.

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


<H3><A NAME="SEC449" HREF="spec_toc.html#TOC449">mailstore_prefix (appendfile)</A></H3>

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

</P>
<P>
This option applies only to deliveries in mailstore format, and is described in
section 15.3 below.

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


<H3><A NAME="SEC450" HREF="spec_toc.html#TOC450">mailstore_suffix (appendfile)</A></H3>

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

</P>
<P>
This option applies only to deliveries in mailstore format, and is described in
section 15.3 below.

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


<H3><A NAME="SEC451" HREF="spec_toc.html#TOC451">mbx_format (appendfile)</A></H3>

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

</P>
<P>
<A NAME="IDX1129"></A>
<A NAME="IDX1130"></A>
<A NAME="IDX1131"></A>
This option is available only if Exim has been compiled with SUPPORT_MBX
set in <TT>`Local/Makefile'</TT>. If <EM>mbx_format</EM> is set with the <EM>file</EM> option,
the message is appended to the mailbox file in MBX format instead of
traditional Unix format. This format is supported by Pine4 and its associated
IMAP and POP daemons, and is implemented by the <EM>c-client</EM> library that they
all use. The <EM>prefix</EM> and <EM>suffix</EM> options are not automatically changed by
the use of <EM>mbx_format</EM>; they should normally be set empty.

</P>
<P>
If none of the locking options are mentioned in the configuration,
<EM>use_mbx_lock</EM> is assumed and the other locking options default to false. It
is possible to specify the other kinds of locking with <EM>mbx_format</EM>, but
<EM>use_fcntl_lock</EM> and <EM>use_mbx_lock</EM> are mutually exclusive. MBX locking
inter~works with <EM>c-client</EM>, providing for shared access to the mailbox. It
should not be used if any program that does not use this form of locking is
going to access the mailbox, nor should it be used if the mailbox file is NFS
mounted, because it works only when the mailbox is accessed from a single host.

</P>
<P>
If you set <EM>use_fcntl_lock</EM> with an MBX-format mailbox, you cannot use
the standard version of <EM>c-client</EM>, because as long as it has a mailbox open
(this means for the whole of a Pine or IMAP session), Exim will not be able to
append messages to it.

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


<H3><A NAME="SEC452" HREF="spec_toc.html#TOC452">mode (appendfile)</A></H3>

<P>
Type: octal integer<BR>
Default: 0600

</P>
<P>
If the output file is created, it is given this mode. If it already exists and
has wider permissions, they are reduced to this mode. If it has narrower
permissions, an error occurs unless <EM>mode_fail_narrower</EM> is false. However,
if the delivery is the result of a <EM>save</EM> command in a filter file specifing a
particular mode, the mode of the output file is always forced to take that
value, and this option is ignored.

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


<H3><A NAME="SEC453" HREF="spec_toc.html#TOC453">mode_fail_narrower (appendfile)</A></H3>

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

</P>
<P>
This option applies in the case when an existing mailbox file has a narrower
mode than that specified by the <EM>mode</EM> option. If <EM>mode_fail_narrower</EM> is
true, the delivery is frozen (`mailbox has the wrong mode'); otherwise Exim
continues with the delivery attempt, using the existing mode of the file.

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


<H3><A NAME="SEC454" HREF="spec_toc.html#TOC454">notify_comsat (appendfile)</A></H3>

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

</P>
<P>
If this option is true, the <EM>comsat</EM> daemon is notified after every successful
delivery to a user mailbox. This is the daemon that notifies logged on users
about incoming mail.

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


<H3><A NAME="SEC455" HREF="spec_toc.html#TOC455">prefix (appendfile)</A></H3>

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

</P>
<P>
The string specified here is expanded and output at the start of every message.
The default is

<PRE>
prefix = "From ${if def:return_path{$return_path}{MAILER-DAEMON}}\
  ${tod_bsdinbox}\n"
</PRE>

<P>
This line can be suppressed by setting

<PRE>
prefix =
</PRE>

<P>
and this is usually necessary when doing batch SMTP deliveries, or delivering
into individual files or MBX-format mailboxes.

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


<H3><A NAME="SEC456" HREF="spec_toc.html#TOC456">quota (appendfile)</A></H3>

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

</P>
<P>
<A NAME="IDX1137"></A>
This option imposes a limit on the size of the file to which Exim is appending,
or to the total space used in the directory tree if the <EM>directory</EM> option is
set. In the latter case, computation of the space used is expensive, as all the
files in the directory (and any sub-directories) have to be individually
inspected and their sizes summed
<font color=green>
(but see <EM>quota_size_regex</EM> below). Also, there is no interlock against two
simultaneous deliveries into a multi-file mailbox. For single-file mailboxes,
of course, an interlock is a necessity.

</P>
<P>
A file's size is take as its <EM>used</EM> value. Because of blocking effects, this
may be a lot less than the actual amount of disc space allocated to the file.
If the sizes of a number of files are being added up, the rounding effect can
become quite noticeable, especially on systems that have large block sizes.
Nevertheless, it seems best to stick to the <EM>used</EM> figure, because this is
the obvious value which users will understand most easily.
</font>

</P>
<P>
The value of the option is expanded, and must then be a numerical value
(decimal point allowed), optionally followed by one of the letters K or M. The
expansion happens while Exim is running as root or the Exim user, before
<EM>setuid()</EM> is called for the delivery, so files that are inaccessible to the
end user can be used to hold quota values that are looked up in the expansion.
When delivery fails because this quota is exceeded, the handling of the error
is as for system quota failures.

</P>
<P>
<font color=green>
By default, Exim's quota checking mimics system quotas, and restricts the
mailbox to the specified maximum size, though the value is not accurate to the
last byte, owing to separator lines and additional headers that may get added
during message delivery. When a mailbox is nearly full, large messages may get
refused even though small ones are accepted, because the size of the current
message is added to the quota when the check is made. This behaviour can be
changed by setting <EM>quota_is_inclusive</EM> false. When this is done, the check
for exceeding the quota does not include the current message. Thus, deliveries
continue until the quota has been exceeded; thereafter, no futher messages
are delivered.
</font>
See also <EM>quota_warn_threshold</EM>.

</P>

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


<H3><A NAME="SEC457" HREF="spec_toc.html#TOC457">quota_filecount (appendfile)</A></H3>

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

</P>
<P>
This option applies when the <EM>directory</EM> option is set. It limits the total
number of files in the directory (compare the inode limit in system quotas). It
can only be used if <EM>quota</EM> is also set.

</P>

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


<H3><A NAME="SEC458" HREF="spec_toc.html#TOC458">quota_is_inclusive (appendfile)</A></H3>

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

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

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


<H3><A NAME="SEC459" HREF="spec_toc.html#TOC459">quota_size_regex (appendfile)</A></H3>

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

</P>
<P>
This option applies when one of the delivery modes that writes a separate file
for each message is being used. When Exim wants to find the size of one of
these files in order to test the quota, it first checks <EM>quota_size_regex</EM>.
If this is set to a regular expression that matches the file name, and it
captures one string, that string is interpreted as a representation of the
file's size. This feature is useful only when users have no shell access to
their mailboxes -- otherwise they could defeat the quota simply by renaming the
files. This facility can be used with maildir deliveries, by setting
<EM>maildir_tag</EM> to add the file length to the file name. For example:

<PRE>
maildir_tag = ,S=$message_size
quota_size_regex = S=(\d+)$
</PRE>

<P>
The string is not expanded.
</font>

</P>

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


<H3><A NAME="SEC460" HREF="spec_toc.html#TOC460">quota_warn_message (appendfile)</A></H3>

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

</P>
<P>
See below for the use of this option. If it is not set when
<EM>quota_warn_threshold</EM> is set, it defaults to

<PRE>
quota_warn_message = "\
  To: $local_part@$domain\n\
  Subject: Your mailbox\n\n\
  This message is automatically created \
  by mail delivery software.\n\n\
  The size of your mailbox has exceeded \
  a warning threshold that is\n\
  set by the system administrator.\n"
</PRE>

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


<H3><A NAME="SEC461" HREF="spec_toc.html#TOC461">quota_warn_threshold (appendfile)</A></H3>

<P>
Type: string, expanded<BR>
Default: "0"

</P>
<P>
<A NAME="IDX1143"></A>
<A NAME="IDX1144"></A>
<A NAME="IDX1145"></A>
This option is expanded in the same way as <EM>quota</EM> (see above). If the
resulting value is greater than zero, and delivery of the message causes the
size of the file or total space in the directory tree to cross the given
threshold, a warning message is sent. If <EM>quota</EM> is also set, the threshold may
be specified as a percentage of it by following the value with a percent sign.
For example:

<PRE>
quota_warn_threshold = 75%
</PRE>

<P>
The warning message itself is specified by the <EM>quota_warn_message</EM> option,
and it must start with a <EM>To:</EM> header line containing the recipient(s). A
<EM>Subject:</EM> line should also normally be supplied. The <EM>quota</EM> option does not
have to be set in order to use this option; they are independent of one
another except when the threshold is specified as a percentage.

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


<H3><A NAME="SEC462" HREF="spec_toc.html#TOC462">require_lockfile (appendfile)</A></H3>

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

</P>
<P>
When a lock file is being used (see <EM>use_lockfile</EM>) and <EM>require_lockfile</EM> is
true, a lock file must be created before delivery can proceed. If the option is
not true, failure to create a lock file
<font color=green>
because of a `permission denied' error
</font>
is not treated as an error, though failure of the <EM>fcntl()</EM> locking function
is. This option should always be set when delivering from more than one host
over NFS.
<A NAME="IDX1147"></A>
It is required to be set if the <EM>file</EM> option is set and <EM>use_fcntl_lock</EM> is
not set, except when <EM>mbx_format</EM> is set.

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


<H3><A NAME="SEC463" HREF="spec_toc.html#TOC463">retry_use_local_part (appendfile)</A></H3>

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

</P>
<P>
When a local delivery suffers a temporary failure, both the local part and the
domain are normally used to form a key that is used to determine when next to
try the address. This handles common cases such as exceeding a quota, where the
failure applies to the specific local part. However, when local delivery is
being used to collect messages for onward transmission by some other means, a
temporary failure may not depend on the local part at all. Setting this option
false causes Exim to use only the domain when handling retries for this
transport.

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


<H3><A NAME="SEC464" HREF="spec_toc.html#TOC464">suffix (appendfile)</A></H3>

<P>
Type: string, expanded<BR>
Default: "\n"

</P>
<P>
The string specified here is expanded and output at the end of every message.
The default blank line can be suppressed by setting

<PRE>
suffix =
</PRE>

<P>
and this is usually necessary when doing batch SMTP deliveries, or delivering
into individual files or MBX-format mailboxes.

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


<H3><A NAME="SEC465" HREF="spec_toc.html#TOC465">use_crlf (appendfile)</A></H3>

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

</P>
<P>
<A NAME="IDX1151"></A>
<A NAME="IDX1152"></A>
<A NAME="IDX1153"></A>
<A NAME="IDX1154"></A>
This option causes lines to be terminated with the two-character CRLF sequence
(carriage return, linefeed) instead of just a linefeed character. In the case
of batched SMTP, the byte sequence written to the file is then an exact image
of what would be sent down a real SMTP connection.

</P>
<P>
The contents of the <EM>prefix</EM> and <EM>suffix</EM> options are written verbatim, so must
contain their own carriage return characters if these are needed. Since the
default values for both <EM>prefix</EM> and <EM>suffix</EM> end with a single linefeed, their
values almost always need to be changed if <EM>use_crlf</EM> is set.

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


<H3><A NAME="SEC466" HREF="spec_toc.html#TOC466">use_fcntl_lock (appendfile)</A></H3>

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

</P>
<P>
This option controls the use of the <EM>fcntl()</EM> function to lock a file for
exclusive use when a message is being appended. It is set by default unless
<EM>use_mbx_lock</EM> is set. Otherwise, it should be turned off only if you know
that all your MUAs use lock file locking. When <EM>use_fcntl_lock</EM> is off,
<EM>use_lockfile</EM> and <EM>require_lockfile</EM> must both be on if <EM>mbx_format</EM> is
not set.

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


<H3><A NAME="SEC467" HREF="spec_toc.html#TOC467">use_lockfile (appendfile)</A></H3>

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

</P>
<P>
If this option is turned off, Exim does not attempt to create a lock file when
appending to a file. Thus the only locking is by <EM>fcntl()</EM>. This option is set
by default unless <EM>use_mbx_lock</EM> is set. It is not possible to turn both
<EM>use_lockfile</EM> and <EM>use_fcntl_lock</EM> off, except when <EM>mbx_format</EM> is set.
You should only turn <EM>use_lockfile</EM> off if you are absolutely sure that every
MUA that is ever going to look at your users' mailboxes uses <EM>fcntl()</EM> rather
than a lock file, and even then only when you are not delivering over NFS from
more than one host.
<A NAME="IDX1157"></A>
In order to append to an NFS file safely from more than one host, it is
necessary to take out a lock <EM>before</EM> opening the file, and the lock file
achieves this. Otherwise, even with <EM>fcntl()</EM> locking, there is a risk of file
corruption. See also the <EM>require_lockfile</EM> option.

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


<H3><A NAME="SEC468" HREF="spec_toc.html#TOC468">use_mbx_lock (appendfile)</A></H3>

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

</P>
<P>
This option is available only if Exim has been compiled with SUPPORT_MBX
set in <TT>`Local/Makefile'</TT>. Setting the option specifies that special MBX locking
rules be used. It is set by default if <EM>mbx_format</EM> is set and none of the
locking options are mentioned in the configuration. The locking rules are the
same as are used by the <EM>c-client</EM> library that underlies Pine4 and the IMAP4
and POP daemons that come with it (see the discussion below). The rules allow
for shared access to the mailbox. However, this kind of locking does not work
when the mailbox is NFS mounted.

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


<H3><A NAME="SEC469" HREF="spec_toc.html#TOC469">user (appendfile)</A></H3>

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

</P>
<P>
<A NAME="IDX1160"></A>
If this option is set, it specifies the user under whose uid the delivery
process is to be run,
and which must be the owner of an existing file to which the message is
appended.
If the option is not set, a value must have been associated with the address by
the director that handled it. If the string contains no $ characters, it is
resolved when Exim starts up. Otherwise, the string is expanded at the time the
transport is run, and must yield either a digit string or a name which can be
looked up using <EM>getpwnam()</EM>. When <EM>getpwnam()</EM> is used, either at start-up
time or later, the group id value associated with the user is taken as the
value to be used if the <EM>group</EM> option is not set.

</P>



<H2><A NAME="SEC470" HREF="spec_toc.html#TOC470">15.2 Operational details for appending</A></H2>

<P>
<A NAME="IDX1161"></A>
<A NAME="IDX1162"></A>
Before appending to a file, Exim proceeds as follows:

</P>

<UL>

<LI>

If the name of the file is <EM>/dev/null</EM>, no action is taken, and a success
return is given.

<LI>

<A NAME="IDX1163"></A>
If any directories on the file's path are missing, Exim creates them if the
<EM>create_directory</EM> option is set. A created directory's mode is given by the
<EM>directory_mode</EM> option.

<LI>

If <EM>file_format</EM> is set, the format of an existing file is checked. If this
indicates that a different transport should be used, control is passed to that
transport.

<LI>

<A NAME="IDX1164"></A>
<A NAME="IDX1165"></A>
<A NAME="IDX1166"></A>
If <EM>use_lockfile</EM> is set, a lock file is built in a way that will work
reliably over NFS, as follows:


<UL>

<LI>

Create a `hitching post' file whose name is that of the lock file with the
current time, primary host name, and process id added, by opening for writing
as a new file. If this fails with an access error, the message is frozen unless
<EM>require_lockfile</EM> is false. Otherwise delivery is deferred.

<LI>

Close the hitching post file, and hard link it to the lock file name.

<LI>

If the call to <EM>link()</EM> succeeds, creation of the lock file has succeeded.
Unlink the hitching post name.

<LI>

Otherwise, use <EM>stat()</EM> to get information about the hitching post file, and
then unlink hitching post name. If the number of links is exactly two, creation
of the lock file succeeded but something (for example, an NFS server crash and
restart) caused this fact not to be communicated to the <EM>link()</EM> call.

<LI>

If creation of the lock file failed, wait for <EM>lock_interval</EM> and try again,
up to <EM>lock_retries</EM> times. However, since any program that writes to a
mailbox should complete its task very quickly, it is reasonable to time out old
lock files that are normally the result of user agent and system crashes. If an
existing lock file is older than <EM>lockfile_timeout</EM> Exim attempts to unlink it
before trying again.
</UL>

<LI>

A call is made to <EM>lstat()</EM> to discover whether the main file exists, and if so,
what its characteristics are. If <EM>lstat()</EM> fails for any reason other than
non-existence, delivery is deferred.

<LI>

<A NAME="IDX1167"></A>
<A NAME="IDX1168"></A>
<A NAME="IDX1169"></A>
If the file does exist and is a symbolic link, delivery is deferred and the
message is frozen, unless the <EM>allow_symlinks</EM> option is set, in which case
the ownership of the link is checked, and then <EM>stat()</EM> is called to find out
about the real file, which is then subjected to the checks below. The check on
the top-level link ownership prevents one user creating a link for another's
mailbox in a sticky directory, though allowing symbolic links in this case is
definitely not a good idea. If there is a chain of symbolic links, the
intermediate ones are not checked.

<LI>

If the file already exists but is not a regular file, or if the file's owner
and group (if the group is being checked -- see <EM>check_group</EM> above) are
different from the user and group under which the delivery is running,
delivery is deferred, and the message is frozen.

<LI>

If the file's permissions are more generous than specified, they are reduced.
If they are insufficient, delivery is deferred, and the message is frozen,
unless <EM>mode_fail_narrower</EM> is set false,
in which case the delivery is tried using the existing permissions.

<LI>

The file's inode number is saved, and it is then opened for appending. If this
fails because the file has vanished, <EM>appendfile</EM> behaves as if it hadn't
existed (see below). If the open failure is EWOULDBLOCK, just defer
delivery; otherwise defer and freeze the message.

<LI>

If the file is opened successfully, check that the inode number hasn't
changed, that it is still a regular file, and that the owner and permissions
have not changed. If anything is wrong, defer and freeze the message.

<LI>

If the file did not exist originally, defer delivery and freeze the message if
the <EM>file_must_exist</EM> option is set. Otherwise, check that the file is being
created in a permitted directory if the <EM>create_file</EM> option is set
(deferring and freezing on failure), and then open for writing as a new file,
with the O_EXCL and O_CREAT options, except when dealing with a
symbolic link (the <EM>allow_symlinks</EM> option must be set). In this case, which
can happen if the link points to a non-existent file, the file is opened for
writing using O_CREAT but not O_EXCL, because that prevents link
following.

<LI>

<A NAME="IDX1170"></A>
If opening fails because the file exists, obey the tests given above for
existing files. However, to avoid looping in a situation where the file is
being continuously created and destroyed, the exists/not-exists loop is broken
after 10 repetitions, and the message is then frozen.

<LI>

If opening fails with any other error, defer delivery.

<LI>

<A NAME="IDX1171"></A>
<A NAME="IDX1172"></A>
Once the file is open, unless both <EM>use_fcntl_lock</EM> and <EM>use_mbx_lock</EM> are
false, it is locked using <EM>fcntl()</EM>. In the former case, an exclusive lock is
requested, while in the latter, Exim takes out a shared lock on the open file,
and an exclusive lock on the file whose name is

<PRE>
/tmp/.&#60;<EM>device-number</EM>&#62;.&#60;<EM>inode-number</EM>&#62;
</PRE>

using the device and inode numbers of the open mailbox file, in accordance with
the MBX locking rules.

<font color=green>
If <EM>fcntl()</EM> locking fails, there are two possible courses of action, depending
on the value of <EM>lock_fcntl_timeout</EM>. If its value is zero, the file is
closed, Exim waits for <EM>lock_interval</EM> and then goes back and re-opens it as
above and tries to lock it again. This happens up to <EM>lock_retries</EM> times,
after which the delivery is deferred.

If <EM>lock_fcntl_timeout</EM> has a value greater than zero, a blocking call to
<EM>fcntl()</EM> with that timeout is used, so there has already been some waiting
involved. Nevertheless, Exim does not give up immediately. It retries up to

<PRE>
(lock_retries * lock_interval) / lock_fcntl_timeout
</PRE>

times (rounded up).
</font>
</UL>

<P>
At the end of delivery, Exim closes the file (which releases the <EM>fcntl()</EM>
lock) and then deletes the lock file if one was created.

</P>



<H2><A NAME="SEC471" HREF="spec_toc.html#TOC471">15.3 Operational details for delivery to a new file</A></H2>

<P>
<A NAME="IDX1173"></A>
When the <EM>directory</EM> option is set, each message is delivered into a
newly-created file or set of files. No locking is required while writing the
message, so the various locking options of the transport are ignored. The
`From' line that by default separates messages in a single file is not normally
needed, nor is the escaping of message lines that start with `From', and there
is no need to ensure a newline at the end of each message. Consequently, the
default settings in <EM>appendfile</EM> need changing as follows:

<PRE>
  check_string = ""
  prefix = ""
  suffix = ""
</PRE>

<P>
<A NAME="IDX1174"></A>
<A NAME="IDX1175"></A>
There are three different ways in which delivery to individual files can be
done, depending on the settings of the <EM>maildir_format</EM> and
<EM>mailstore_format</EM> options. Note that code to support maildir and
mailstore formats is not included in the binary unless SUPPORT_MAILDIR
or SUPPORT_MAILSTORE, respectively, are set in <TT>`Local/Makefile'</TT>.

</P>
<P>
<A NAME="IDX1176"></A>
In all three cases an attempt is made to create the directory and any necessary
sub-directories if they do not exist, provided that the <EM>create_directory</EM>
option is set (the default). A created directory's mode is given by the
<EM>directory_mode</EM> option. If creation fails, or if the <EM>create_directory</EM>
option is not set when creation is required, the delivery is deferred.

</P>


<UL>

<LI>

If neither <EM>maildir_format</EM> nor <EM>mailstore_format</EM> is set, a single new file
is created directly in the named directory. For example, when delivering
messages into files using the <EM>bsmtp</EM> option (see section 48.8), a
setting such as

<PRE>
directory = /var/bsmtp/${host}
</PRE>

might be used. A message is written to a file with a temporary name, which is
then renamed when the delivery is complete. The final name is constructed from
the time and the file's inode number, and starts with the letter `q' for
compatibility with <EM>smail</EM>.

<LI>

If the <EM>maildir_format</EM> option is true, Exim delivers each message by writing
it to a file whose name is <EM>tmp/&#60;<EM>time</EM>&#62;.&#60;<EM>pid</EM>&#62;.&#60;<EM>host</EM>&#62;</EM> in the given
directory, and then renaming it into the <EM>new</EM> sub-directory if all goes well.

Before opening the temporary file, Exim calls <EM>stat()</EM> on its name. If any
response other than ENOENT (does not exist) is given, it waits 2 seconds
and tries again, up to <EM>maildir_retries</EM> times.

<font color=green>
If Exim is required to check a <EM>quota</EM> setting before a maildir delivery,
it looks for a file called <EM>maildirfolder</EM> in the maildir directory
(alongside <EM>new</EM>, <EM>cur</EM>, <EM>tmp</EM>). If this exists, it assumes the directory is a
maildir++ folder directory, which is one level down from the user's toplevel
mailbox directory. This causes it start at the parent directory instead of the
current directory when calculating the amount of space used.

If <EM>maildir_tag</EM> is set, the string is expanded for each delivery. This is
done after the message has been written, so that the value of the
$<EM>message_size</EM> variable can be set accurately during the expansion. If the
expansion is forced to fail, the tag is ignored, but a non-forced failure
causes delivery to be deferred. The expanded tag may contain any printing
characters except `/'. Any other characters in the string are ignored; if the
resulting string is empty, it is ignored. If it starts with an alphanumeric
character, a leading colon is inserted.

When the temporary maildir file is renamed into the <EM>new</EM> sub-directory, the
tag is added to its name. However, if adding the tag takes the length of the
name to the point where the test <EM>stat()</EM> call fails with ENAMETOOLONG, the
tag is dropped and the maildir file is created with no tag. Tags can be used to
encode the size of files in their names; see <EM>quota_size_regex</EM> above for an
example.
</font>

<LI>

If the <EM>mailstore_format</EM> option is true, each message is written as two files
in the given directory. A unique base name is constructed from the message id
and the current delivery process, and the files that are written use this base
name plus the suffixes <EM>.env</EM> and <EM>.msg</EM>. The <EM>.env</EM> file contains the
message's envelope, and the <EM>.msg</EM> file contains the message itself.

During delivery, the envelope is first written to a file with the suffix
<EM>.tmp</EM>. The <EM>.msg</EM> file is then written, and when it is complete, the <EM>.tmp</EM>
file is renamed as the <EM>.env</EM> file. Programs that access messages in mailstore
format should wait for the presence of both a <EM>.msg</EM> and a <EM>.env</EM> file before
accessing either of them. An alternative approach is to wait for the absence of
a <EM>.tmp</EM> file.

The envelope file starts with any text defined by the <EM>mailstore_prefix</EM>
option, expanded and terminated by a newline if there isn't one. Then follows
the sender address on one line, then all the recipient addresses, one per line.
There can be more than one recipient only if the <EM>batch</EM> option is set.
Finally, <EM>mailstore_suffix</EM> is expanded and the result appended to the file,
followed by a newline if it does not end with one.

If expansion of the prefix or suffix ends with a forced failure, it is
ignored. Other expansion errors are treated as serious configuration errors,
and delivery is deferred.
</UL>

<P><HR><P>
Go to the <A HREF="spec_1.html">first</A>, <A HREF="spec_14.html">previous</A>, <A HREF="spec_16.html">next</A>, <A HREF="spec_59.html">last</A> section, <A HREF="spec_toc.html">table of contents</A>.
</BODY>
</HTML>