Variable envelope return path

Variable envelope return path (VERP) is a technique used by some electronic mailing list software to enable automatic detection and removal of undeliverable e-mail addresses. It works by using a different return path (also called "envelope sender") for each recipient of a message.

Motivation

Any long-lived mailing list eventually contains addresses that can't be reached. Addresses that were once valid can become unusable because the person receiving the mail switched to a different provider. In another scenario, the address may still exist but be abandoned, with unread mail accumulating until there is not enough room left to accept any more.

When a message is sent to a mailing list, the mailing list software re-sends it to all of the addresses on the list. The presence of invalid addresses in the list results in bounce messages being sent to the owner of the list. If the mailing list is small, the owner can read the bounce messages and manually remove the invalid addresses from the list. With a larger mailing list, this is a tedious, unpleasant job, so it is desirable to automate the process.

However, most bounce messages have historically been designed to be read by human users, not automatically handled by software. They all convey the same basic idea ("the message from X to Y could not be delivered because of reason Z") but with so many variations that it would be nearly impossible to write a program to reliably interpret the meaning of every bounce message. RFC 1894 (obsoleted by RFC 3464) defines a standard format to fix this problem, but support for the standard is far from universal. However, there are several common formats (e.g., RFC 3464, qmail's qsbmf, and Microsoft's DSN format for Exchange) that cover large proportion of bounces.

Microsoft Exchange can sometimes bounce a message without providing any indication of the address to which the original message was sent. When Exchange knows the intended recipient, but is not willing to accept email for them, it omits their address. If a message is sent to joe@example.com and the server knows that this is "Joe User", it will bounce the message saying that the message to "Joe User" could not be delivered, leaving out the joe@example.com address altogether. VERP is the only viable way to handle such bounces correctly.

How VERP solves the bounce handling problem

The hard part of bounce handling is matching up a bounce message with the undeliverable address that caused the bounce. If the mailing list software can see that a bounce resulted from an attempt to send a message to user@example.com, then it doesn't need to understand the rest of the information in the bounce. It can simply count how many messages were recently sent to user@example.com, and how many bounces resulted; and if the proportion of bounced messages is too high, the address is removed from the list.

While bounce message formats in general vary wildly, there is one aspect of a bounce message that is highly predictable: the address to which it will be sent. VERP takes full advantage of this. In a mailing list that uses VERP, a different sender address is used for each recipient.

The mailing list manager knows that it sent a message from X to Y, so if a bounce message is received at address X, it can only be because address Y was undeliverable, because nothing was sent from X to any other address. Thus the important information has been extracted from the bounce message, without any need to understand its contents, which means the person in charge of the list does not need to deal with it manually.

Origin

The first serious advocate of this solution, and the originator of the term VERP to describe it, was Daniel J. Bernstein, who first put the idea into practice in his qmail MTA and ezmlm mailing list manager.

Example

Assume there is a mailing list called wikipedians@example.net and that an individual, bob@example.org has subscribed to it, but later on, Bob has left example.org, so his address is no longer valid. Consider what happens when someone sends a message to the list.

Without VERP

Without VERP, the mailing list manager might send a message with the following characteristics:

• envelope sender: wikipedians-owner@example.net
• recipient: bob@example.org

This would result in a bounce, generated by the MTA of either example.net or example.org, with the following characteristics:

• envelope sender: empty
• recipient: wikipedians-owner@example.net
• contents: example.org was unable to deliver the following message to bob: ...

The mailing list manager can't be expected to understand the contents of this bounce, and can't deduce anything from the recipient address because hundreds of other people besides Bob were also sent messages from wikipedians-owner@example.net.

With VERP

With VERP, the original message would be different:

• envelope sender: wikipedians-owner+bob=example.org@example.net
• recipient: bob@example.org

The bounce, then, will be more useful:

• envelope sender: empty
• recipient: wikipedians-owner+bob=example.org@example.net
• contents: example.org was unable to deliver the following message to bob: ...

From this bounce message the mailing list manager can deduce that a message to bob@example.org must have failed.

This example shows the simplest possible method of matching a VERP to a list subscriber: the entire recipient address is included within the return path, with the at sign replaced by an equals sign because a return path with two at signs would be invalid. Other encoding schemes are possible.

Software supporting VERP

• CiviCRM
• EspoCRM
• Courier Mail Server
• Discourse
• exim, using a specialized Router/Transport combination
• ezmlm
• GNU Mailman
• G Suite
• Inxmail
• Mercury Mail Transport System
• mlmmj
• Mahara
• Mailchimp
• Maileon
• MediaWiki, using the BounceHandler extension
• Moodle
• Plesk
• postfix
• qmail
• Sendmail, with a ruleset
• STEdb
• StrongMail
• Sympa
• Thexyz
• Zimbra
• Target Box
• NotifyBC
• AWS SES (Simple Email Service)

Disadvantages

The use of VERP requires each message to be sent once for every recipient, instead of once to each receiving SMTP server. This is because of a limitation of SMTP, which allows multiple recipient addresses to be specified in a single transaction, but only one sender address. When there are many subscribers in the same domain, a mailing list that is not using VERP can combine multiple deliveries into a single transaction. It connects to the appropriate server for the domain, gives the single sender address, the recipient addresses, and then sends the message contents only once.

A mailing list using VERP, on the other hand, must send the entire message body repeatedly, which leads to an overall increase in bandwidth usage. This inefficiency is usually not considered a big problem, especially by qmail users, since qmail always sends messages once per recipient, even when VERP is not being used. Some packages mitigate the impact of VERP by applying it selectively, for example a mailing list manager might only use VERP on 1 in 10 mailings. This way you can gain much of VERP's tight bounce control and accurate feedback without incurring the processing and network overhead every time.

Another problem with VERP (and with any automatic bounce handling scheme) is that there are MTAs on the Internet that fail to follow basic SMTP standards. VERP depends on the recipients' MTAs following the rule that bounces are sent to the envelope sender. This has been a standard requirement since the dawn of SMTP in 1982 (see RFC 821), but still there are MTAs that get it wrong, usually by bouncing to the address in the From: header.

Systems that implement greylisting work fine with VERP if the envelope sender follows the above-mentioned format. However, some VERP implementations use message number or random key as part of VERP, which causes each post to the mailing list to be delayed unless the greylisting system treats "similar" sender addresses as being equivalent.

See also

• Bounce Address Tag Validation (BATV) – for bounces from backscatter
• Sender Rewriting Scheme (SRS) – for bounces from e-mail forwarding and SPF
• Simple Mail Transfer Protocol (SMTP)
• draft SMTP extension to streamline VERP