[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The autoreply
transport is not a true transport in that it does not cause
the message to be transmitted. Instead, it generates a new mail message as an
automatic reply to the incoming message. References: and
Auto-Submitted: header lines are included. These are constructed according
to the rules in RFCs 2822 and 3834, respectively.
If the router that passes the message to this transport does not have the
unseen
option set, the original message (for the current recipient) is not
delivered anywhere. However, when the unseen
option is set on the router
that passes the message to this transport, routing of the address continues, so
another router can set up a normal message delivery.
The autoreply
transport is usually run as the result of mail filtering, a
"vacation" message being the standard example. However, it can also be run
directly from a router like any other transport. To reduce the possibility of
message cascades, messages created by the autoreply
transport always have
empty envelope sender addresses, like bounce messages.
The parameters of the message to be sent can be specified in the configuration
by options described below. However, these are used only when the address
passed to the transport does not contain its own reply information. When the
transport is run as a consequence of a
mail
or vacation
command in a filter file, the parameters of the message are
supplied by the filter, and passed with the address. The transport's options
that define the message are then ignored (so they are not usually set in this
case). The message is specified entirely by the filter or by the transport; it
is never built from a mixture of options. However, the file_optional
,
mode
, and return_message
options apply in all cases.
Autoreply
is implemented as a local transport. When used as a result of a
command in a user's filter file, autoreply
normally runs under the uid and
gid of the user, and with appropriate current and home directories (see chapter
Environment for running local transports).
There is a subtle difference between routing a message to a pipe
transport
that generates some text to be returned to the sender, and routing 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, whereas if autoreply
is used, a separate
message is generated for each address that is passed to it.
Non-printing characters are not permitted in the header lines generated for the
message that autoreply
creates, with the exception of newlines that are
immediately followed by white space. If any non-printing characters are found,
the transport defers.
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 bounce message) do not cause
problems. They are just discarded.
27.1 Private options for autoreply |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| Use: autoreply | Type: string* | Default: unset |
This specifies the addresses that are to receive "blind carbon copies" of the message when the message is specified by the transport.
| Use: autoreply | Type: string* | Default: unset |
This specifies recipients of the message and the contents of the Cc: header when the message is specified by the transport.
| Use: autoreply | Type: string* | Default: unset |
The contents of the file are sent as the body of the message when the message
is specified by the transport. If both file
and text
are set, the text
string comes first.
| Use: autoreply | Type: boolean | Default: false |
If this is set, the contents of the file named by the file
option are
subjected to string expansion as they are added to the message.
| Use: autoreply | Type: boolean | Default: false |
If this option is true, no error is generated if the file named by the file
option or passed with the address does not exist or cannot be read.
| Use: autoreply | Type: string* | Default: unset |
This specifies the contents of the From: header when the message is specified by the transport.
| Use: autoreply | Type: string* | Default: unset |
This specifies additional RFC 2822 headers that are to be added to the message when the message is specified by the transport. Several can be given by using "\n" to separate them. There is no check on the format.
| Use: autoreply | Type: string* | Default: unset |
This option names a file in which a record of every message sent is logged when the message is specified by the transport.
| Use: autoreply | Type: octal integer | Default: 0600 |
If either the log file or the "once" file has to be created, this mode is used.
| Use: autoreply | Type: address list* | Default: unset |
If any run of the transport creates a message with a recipient that matches any item in the list, that recipient is quietly discarded. If all recipients are discarded, no message is created. This applies both when the recipients are generated by a filter and when they are specified in the transport.
| Use: autoreply | Type: string* | Default: unset |
This option names a file or DBM database in which a record of each To: recipient is kept when the message is specified by the transport. Note: This does not apply to Cc: or Bcc: recipients.
If once
is unset, or is set to an empty string, the message is always sent.
By default, if once
is set to a non-empty file name, the message
is not sent if a potential recipient is already listed in the database.
However, if the once_repeat
option 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. A setting of zero time for once_repeat
(the default)
prevents a message from being sent a second time - in this case, zero means
infinity.
If once_file_size
is zero, a DBM database is used to remember recipients,
and it is allowed to grow as large as necessary. 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, Exim keeps a linear list of recipient addresses and the 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.
| Use: autoreply | Type: integer | Default: 0 |
See once
above.
| Use: autoreply | Type: time* | Default: 0s |
See once
above.
After expansion, the value of this option must be a valid time value.
| Use: autoreply | Type: string* | Default: unset |
This specifies the contents of the Reply-To: header when the message is specified by the transport.
| Use: autoreply | Type: boolean | Default: false |
If this is set, a copy of the original message is returned with the new
message, subject to the maximum size set in the return_size_limit
global
configuration option.
| Use: autoreply | Type: string* | Default: unset |
This specifies the contents of the Subject: header when the message is specified by the transport. It is tempting to quote the original subject in automatic responses. For example:
subject = Re: $h_subject: |
There is a danger in doing this, however. It may allow a third party to subscribe your users to an opt-in mailing list, provided that the list accepts bounce messages as subscription confirmations. Well-managed lists require a non-bounce message to confirm a subscription, so the danger is relatively small.
| Use: autoreply | Type: string* | Default: unset |
This specifies a single string to be used as the body of the message when the
message is specified by the transport. If both text
and file
are set,
the text comes first.
| Use: autoreply | Type: string* | Default: unset |
This specifies recipients of the message and the contents of the To: header when the message is specified by the transport.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated on September, 10 2009 using texi2html 1.78.