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, usually
as the result of mail filtering. A traditional `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 "Environment for running local transports"). 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.

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, then 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 DBM database in which a record of each recipient is kept
when the message is specified by the transport. The string is expanded. If a
potential recipient is already in the database, no message is sent.

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.