2.2. So what is this VERP stuff
See also <4.12 What about VERP?> and <What MTA features are required for use with Mailman 2.1.5?>.
VERP = "Variable Envelope Return Paths"
The purpose of VERP'ing is primarily to improve bounce detection; to help identify to which subscriber's e-mail address a piece of returned mail was sent.
Any e-mail has a return path which remains the same until it is either delivered or bounced. This is distinct from the From: header and the Sender: header (although MS Outlook seems to have a penchant for, at times, conflating the Sender: and From: headers when it displays information about incoming e-mail).
In Mailman 2.0.x outgoing mail from lists normally has a return path of <listname>-admin@mailman.domain.com
With Mailman 2.1 outgoing mail from lists normally has a return path of <listname>-bounces@mailman.domain.com
When a piece of e-mail cannot be delivered, it is e-mailed back to the e-mail address in the return path of the rejected e-mail.
The change in aliases between MM 2.0.x and MM 2.1 was to separate incoming bounced e-mail from other administrative inputs received by Mailman.
So, with stock MM 2.1 bounces are sent back to the e-mail address <listname>-bounces@mailman.domain.com
E-mails delivered to this address on the Mailman server are analysed with the objective of identifying to whom the outgoing mail was addressed and taking steps to disable distribution to them if e-mail to them exceeds bounce limits set by the list administrator.
Problems can arise with bounce detection if an MTA (Mail Transfer Agent) handling a piece of e-mail sent out by Mailman rewrites the destination address of that e-mail from that which Mailman originally used. This might happen if, for instance, someone has moved from one service provider to another and arranged to have their e-mail forwarded.
Without VERP'ing, an e-mail with a rewritten destination, which then bounces, is sent back to the Mailman return path OK but it has lost its original destination. If Mailman only sees the rewritten destination in the returned mail and it cannot correlate that with any known subscriber of the list, it cannot handle the bounce appropriately or automatically.
With VERP'ing the return path of each outgoing mail is specific to the destination e-mail address and encodes that destination in the e-mail's return path. So, for instance, VERP'ed e-mail to me from a list would have a return path of:
<listname>-bounces+r.barrett=openinfo.demon.co.uk@mailman.domain.com.
Note how my e-mail address of r.barrett@openinfo.demon.co.uk is encoded in that return path.
With a VERP'ed return path the original destination is embedded in the address to which the bounced e-mail is returned. Thus regardless of re-writing of the destination of mail going out, if it is returned, Mailman can reliably identify the subscriber whose mail is being bounced.
So, why not do it with every outgoing e-mail? Well there is a price for VERP'ing everything outgoing. Instead of being able to pass a single message for say 500 subscribers to an MTA in the one go, Mailman has to pass a single message for a single addressee to an MTA, 500 times. This impacts on performance and the load applied to both the Mailman software and the SMTP server it passes its mail to and potentially other, downstream, MTAs.
If you turn on VERP'ing for everything and have lengthy subscriber lists, do not be surprised if your ISP shouts at you.
If you decide to use personalization for a list, then you have committed to sending out to your subscribers one-at-a-time anyway, so you might as well VERP such outgoing mail as doing so will not add to the cost of doing the personalization: see the VERP_PERSONALIZED_DELIVERIES configuration variable in $prefix/Mailman/Defaults.py (but make your changes in mm_cfg.py)
Likewise, if you send out monthly password reminders to subscribers, Mailman has to do message personalization and will send out an individual message to each subscriber anyway, so VERP'ing these message doesn't carry any extra cost: see the VERP_PASSWORD_REMINDERS configuration variable in $prefix/Mailman/Defaults.py (but make your changes in mm_cfg.py)
Mailman can also do VERP'ing on a sampling basis, so that over time it should capture all those hard to find bouncing subscriber addresses: see the VERP_DELIVERY_INTERVAL configuration variable in $prefix/Mailman/Defaults.py (but make your changes in mm_cfg.py)
Finally, you could alter the way return paths are changed for VERP'ing by altering (very carefully) the VERP_FORMAT and VERP_REGEXP variables in $prefix/Mailman/Defaults.py (but making your changes in mm_cfg.py). But you would need a very good reason and lots of confidence if you are going this route.
Oh, and do not forget to check that your incoming MTA can handle VERP'ed return addresses OK.
Note that Mailman 2.1.5 has a new bounce processor. Now when an address's bounce score reaches the threshold, that address will be sent a probe message. Only if the probe bounces will the address be disabled. The score is reset to zero when the probe is sent. Mailman 2.1.5 also supports the variables VERP_PROBE_FORMAT and VERP_PROBE_REGEXP in Defaults.py.
A/the seminal document on VERP'ing is at http://cr.yp.to/proto/verp.txt
Converted from the Mailman FAQ Wizard
This is one of many Frequently Asked Questions.