+.section "Variable Envelope Return Paths (VERP)" "SECTverp"
+.cindex "VERP"
+.cindex "Variable Envelope Return Paths"
+.cindex "envelope sender"
+Variable Envelope Return Paths &-- see &url(http://cr.yp.to/proto/verp.txt) &--
+are a way of helping mailing list administrators discover which subscription
+address is the cause of a particular delivery failure. The idea is to encode
+the original recipient address in the outgoing envelope sender address, so that
+if the message is forwarded by another host and then subsequently bounces, the
+original recipient can be extracted from the recipient address of the bounce.
+
+.oindex &%errors_to%&
+.oindex &%return_path%&
+Envelope sender addresses can be modified by Exim using two different
+facilities: the &%errors_to%& option on a router (as shown in previous mailing
+list examples), or the &%return_path%& option on a transport. The second of
+these is effective only if the message is successfully delivered to another
+host; it is not used for errors detected on the local host (see the description
+of &%return_path%& in chapter &<<CHAPtransportgeneric>>&). Here is an example
+of the use of &%return_path%& to implement VERP on an &(smtp)& transport:
+.code
+verp_smtp:
+ driver = smtp
+ max_rcpt = 1
+ return_path = \
+ ${if match {$return_path}{^(.+?)-request@your.dom.example\$}\
+ {$1-request=$local_part%$domain@your.dom.example}fail}
+.endd
+This has the effect of rewriting the return path (envelope sender) on outgoing
+SMTP messages, if the local part of the original return path ends in
+&"-request"&, and the domain is &'your.dom.example'&. The rewriting inserts the
+local part and domain of the recipient into the return path. Suppose, for
+example, that a message whose return path has been set to
+&'somelist-request@your.dom.example'& is sent to
+&'subscriber@other.dom.example'&. In the transport, the return path is
+rewritten as
+.code
+somelist-request=subscriber%other.dom.example@your.dom.example
+.endd
+.new
+.cindex "&$local_part$&"
+For this to work, you must tell Exim to send multiple copies of messages that
+have more than one recipient, so that each copy has just one recipient. This is
+achieved by setting &%max_rcpt%& to 1. Without this, a single copy of a message
+might be sent to several different recipients in the same domain, in which case
+&$local_part$& is not available in the transport, because it is not unique.
+
+Unless your host is doing nothing but mailing list deliveries, you should
+probably use a separate transport for the VERP deliveries, so as not to use
+extra resources in making one-per-recipient copies for other deliveries. This
+can easily be done by expanding the &%transport%& option in the router:
+.wen
+.code
+dnslookup:
+ driver = dnslookup
+ domains = ! +local_domains
+ transport = \
+ ${if match {$return_path}{^(.+?)-request@your.dom.example\$}\
+ {verp_smtp}{remote_smtp}}
+ no_more
+.endd
+If you want to change the return path using &%errors_to%& in a router instead
+of using &%return_path%& in the transport, you need to set &%errors_to%& on all
+routers that handle mailing list addresses. This will ensure that all delivery
+errors, including those detected on the local host, are sent to the VERP
+address.
+
+On a host that does no local deliveries and has no manual routing, only the
+&(dnslookup)& router needs to be changed. A special transport is not needed for
+SMTP deliveries. Every mailing list recipient has its own return path value,
+and so Exim must hand them to the transport one at a time. Here is an example
+of a &(dnslookup)& router that implements VERP:
+.code
+verp_dnslookup:
+ driver = dnslookup
+ domains = ! +local_domains
+ transport = remote_smtp
+ errors_to = \
+ ${if match {$return_path}{^(.+?)-request@your.dom.example\$}}
+ {$1-request=$local_part%$domain@your.dom.example}fail}
+ no_more
+.endd
+Before you start sending out messages with VERPed return paths, you must also
+configure Exim to accept the bounce messages that come back to those paths.
+Typically this is done by setting a &%local_part_suffix%& option for a
+router, and using this to route the messages to wherever you want to handle
+them.
+
+The overhead incurred in using VERP depends very much on the size of the
+message, the number of recipient addresses that resolve to the same remote
+host, and the speed of the connection over which the message is being sent. If
+a lot of addresses resolve to the same host and the connection is slow, sending
+a separate copy of the message for each address may take substantially longer
+than sending a single copy with many recipients (for which VERP cannot be
+used).
+
+
+
+
+
+