The only remote transport (smtp) is normally configured to handle more than one address at a time, so that when several addresses are routed to the same remote host, just one copy of the message is sent. Local transports, however, normally handle one address at a time. That is, a separate instance of the transport is run for each address that is routed to the transport. A separate copy of the message is delivered each time.
In special cases, it may be desirable to handle several addresses at once in a local transport, for example:
In an appendfile transport, when storing messages in files for later delivery by some other means, a single copy of the message with multiple recipients saves space.
In an lmtp transport, when delivering over “local SMTP” to some process, a single copy saves time, and is the normal way LMTP is expected to work.
In a pipe transport, when passing the message to a scanner program or to some other delivery mechanism such as UUCP, multiple recipients may be acceptable.
These three local transports all have the same options for controlling multiple (“batched”) deliveries, namely batch_max and batch_id. To save repeating the information for each transport, these options are described here.
The batch_max option specifies the maximum number of addresses that can be delivered together in a single run of the transport. Its default value is one (no batching). When more than one address is routed to a transport that has a batch_max value greater than one, the addresses are delivered in a batch (that is, in a single run of the transport with multiple recipients), subject to certain conditions:
If any of the transport’s options contain a reference to $local_part, no batching is possible.
If any of the transport’s options contain a reference to $domain, only addresses with the same domain are batched.
If batch_id is set, it is expanded for each address, and only those addresses with the same expanded value are batched. This allows you to specify customized batching conditions. Failure of the expansion for any reason, including forced failure, disables batching, but it does not stop the delivery from taking place.
Batched addresses must also have the same errors address (where to send delivery errors), the same header additions and removals, the same user and group for the transport, and if a host list is present, the first host must be the same.
In the case of the appendfile and pipe transports, batching applies both when the file or pipe command is specified in the transport, and when it is specified by a redirect router, but all the batched addresses must of course be routed to the same file or pipe command. These two transports have an option called use_bsmtp, which causes them to deliver the message in “batched SMTP” format, with the envelope represented as SMTP commands. The check_string and escape_string options are forced to the values
check_string = "." escape_string = ".."
when batched SMTP is in use. A full description of the batch SMTP mechanism is given in section 45.10. The lmtp transport does not have a use_bsmtp option, because it always delivers using the SMTP protocol.
If the generic envelope_to_add option is set for a batching transport, the Envelope-to: header that is added to the message contains all the addresses that are being processed together. If you are using a batching appendfile transport without use_bsmtp, the only way to preserve the recipient addresses is to set the envelope_to_add option.
If you are using a pipe transport without BSMTP, and setting the transport’s command option, you can include $pipe_addresses as part of the command. This is not a true variable; it is a bit of magic that causes each of the recipient addresses to be inserted into the command as a separate argument. This provides a way of accessing all the addresses that are being delivered in the batch. Note: This is not possible for pipe commands that are specified by a redirect router.