Chapter 27 - The autoreply transport
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 23).
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.
1. Private options for autoreply
| bcc | 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.
| cc | 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.
| file | 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.
| file_expand | 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.
| file_optional | 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.
| from | Use: autoreply | Type: string† | Default: unset |
This specifies the contents of the From: header when the message is specified by the transport.
| headers | 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.
| log | 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.
| mode | Use: autoreply | Type: octal integer | Default: 0600 |
If either the log file or the “once” file has to be created, this mode is used.
| never_mail | 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.
| once | 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 filename, 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.
| once_file_size | Use: autoreply | Type: integer | Default: 0 |
See once above.
| once_repeat | Use: autoreply | Type: time† | Default: 0s |
See once above. After expansion, the value of this option must be a valid time value.
| reply_to | Use: autoreply | Type: string† | Default: unset |
This specifies the contents of the Reply-To: header when the message is specified by the transport.
| return_message | 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.
| subject | 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.
| text | 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.
| to | 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.
