The autoreply transport is not a true transport in that it does not cause the
message to be transmitted. Instead, it generates another mail message. It is
usually run as the result of mail filtering. A `vacation' message is the
standard example.

Autoreply is implemented as a local transport so that it runs under the uid
and gid of the local user and with appropriate current and home directories
(see chapter 13). The parameters of the message to be sent can
be specified in the configuration by the options described below, but in the
common case when autoreply is activated as a result of filtering, none of
them are normally set, because all the information is obtained from the filter
file.

In an attempt to reduce the possibility of message cascades, messages created
by the autoreply transport always take the form of delivery error messages.
That is, the envelope sender field is empty.

There is a subtle difference between directing a message to a pipe transport
that generates some text to be returned to the sender, and directing it to an
autoreply transport. This difference is noticeable only if more than one
address from the same message is so handled. In the case of a pipe, the
separate outputs from the different addresses are gathered up and returned to
the sender in a single message, while if autoreply is used, a separate
message is generated for each address passed to it.

The private options of the autoreply transport that describe the message are
used only when the address passed to it does not contain any reply information.
Thus the message is specified entirely by the director or by the transport; it
is never built from a mixture of options. The remaining private options
(file_optional, group, initgroups, mode, return_message, and
user) apply in all cases.

Non-printing characters are not permitted in the header lines generated for the
message that autoreply creates, with the exception of space and tab. Other
non-printing characters are converted into escape sequences. Whether characters
with the top bit set count as printing characters or not is controlled by the
print_topbitchars global option.

If any of the generic options for manipulating headers (for example,
headers_add) are set on an autoreply transport, they apply to the copy of
the original message that is included in the generated message when
return_message is set. They do not apply to the generated message itself.

If the autoreply transport receives return code 2 from Exim when it submits
the message, indicating that there were no recipients, it does not treat this
as an error. This means that autoreplies sent to $sender_address when this
is empty (because the incoming message is a delivery failure report) do not
cause problems.

If this option is set, it specifies the group under whose gid the delivery
process is to be run. If it 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 getgrnam().

Specified additional RFC 822 headers that are to be added to the message when
the message is specified by the transport. The string is expanded. Several can
be given by using `\n' to separate them. There is no check on the format.

If this option is true and the uid is provided by the transport, the
initgroups() function is called when running the transport to ensure that any
additional groups associated with the uid are set up. By default no additional
groups are present.

This option names a file or DBM database in which a record of each recipient is
kept when the message is specified by the transport. The string is expanded. If
once_file_size is not set, a DBM database is used, and it is allowed to
grow as large as necessary. If a potential recipient is already in the
database, no message is sent by default. However, if once_repeat specifies a
time greater than zero, the message is sent if that much time has elapsed since
a message was last sent to this recipient. If once is unset, the message is
always sent.

If once_file_size is set greater than zero, it changes the way Exim
implements the once option. Instead of using a DBM file to record every
recipient it sends to, it uses a regular file, whose size will never get larger
than the given value. In the file, it keeps a linear list of recipient
addresses and times at which they were sent messages. If the file is full when
a new address needs to be added, the oldest address is dropped. If
once_repeat is not set, this means that a given recipient may receive
multiple messages, but at unpredictable intervals that depend on the rate of
turnover of addresses in the file. If once_repeat is set, it specifies a
maximum time between repeats.

If this option is set, it specifies the user under whose uid the delivery
process is to be run. If it 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 getpwnam(). When getpwnam() 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 group option is not set.