Community hub
Recent from talks
Contribute something
Nothing was collected or created yet.
Variable envelope return path
View on Wikipedia
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
[edit]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
[edit]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
[edit]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.[1]
Example
[edit]Assume there is a mailing list called wikipedians@example.net and that an individual with the address bob@example.org has subscribed to it. But since then, 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
[edit]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
[edit]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
[edit]- CiviCRM
- EspoCRM
- Courier Mail Server
- Discourse[2]
- exim, using a specialized Router/Transport combination
- ezmlm
- GNU Mailman
- G Suite
- Inxmail
- Mercury Mail Transport System
- mlmmj[3]
- Mahara
- Mailchimp[4]
- Maileon
- MediaWiki, using the BounceHandler extension
- Moodle
- Plesk[5]
- postfix
- qmail
- Sendmail, with a ruleset[6]
- STEdb
- StrongMail
- Sympa
- Thexyz
- Zimbra
- Target Box
- NotifyBC
- AWS SES (Simple Email Service)
Disadvantages
[edit]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
[edit]- 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
References
[edit]- ^ D. J. Bernstein qmail, February 1, 1997
- ^ "Handling bouncing e-mails". 17 May 2021.
- ^ mlmmj mailing list manager
- ^ "Email Delivery for IT Professionals. A MailChimp Guide" (PDF). Mailchimp. Archived from the original (PDF) on 2019-07-12.
- ^ "Plesk VERP Support since Version 18.0.30".
- ^ "Sendmail VERP ruleset - comp.mail.sendmail". Archived from the original on October 27, 2014.
Variable envelope return path
View on Grokipedia[email protected]—into a unique variant for each message, such as [email protected], where the appended data reveals the recipient upon bounce receipt.[1] Mail software, such as qmail, supports this by routing bounces through dedicated handlers that parse the encoded information to identify and process the faulty address, often removing it from the subscriber list to maintain hygiene.[1] This per-recipient customization can be implemented to comply with sender policy framework (SPF) authentication, provided the SPF records are configured appropriately, while providing detailed tracking, including per-message identifiers for enhanced diagnostics.[2][3]
The adoption of VERP has significantly improved email deliverability and reputation management for senders, as it enables precise bounce categorization—distinguishing hard bounces (permanent failures) from soft bounces (temporary issues)—and facilitates automated list maintenance without altering the visible "From" address seen by recipients.[2] By centralizing bounce data for analysis and reporting, VERP helps mitigate risks like domain blacklisting and supports scalable operations in high-volume environments, such as those used by email service providers.[2] Despite its effectiveness, implementation requires MTA-level support and careful handling to avoid issues with certain services, like e-fax gateways, underscoring its role as a targeted tool in modern email infrastructure.[2]
Email Delivery Basics
Envelope Sender and Return Path
In email transmission, the SMTP envelope represents the structural framework used by mail transfer agents (MTAs) to route messages, consisting of commands such as MAIL FROM and RCPT TO that specify the sender and recipients, respectively. This envelope is distinct from the message headers defined in RFC 5322, which form part of the visible content of the email and include fields like From, To, and Subject. The MAIL FROM command, issued at the start of an SMTP transaction, provides the reverse-path—a mailbox address indicating the envelope sender—and is essential for establishing the transaction's originator without altering the message body.[4][5] The return path, synonymous with the envelope sender, serves primarily to route error notifications, such as non-delivery reports, back to the message originator or a designated handling system. During SMTP delivery, this address ensures that any delivery failures are directed appropriately, preventing undeliverable messages from being lost and allowing the sender's domain to manage feedback effectively. For instance, if a recipient's mailbox is full or invalid, the receiving MTA uses the return path to generate and send a bounce message to this address.[6][7] Upon successful acceptance of the message, the receiving MTA responsible for final delivery adds a Return-Path header to the message, populating it with the reverse-path from the original MAIL FROM command. This process occurs after the DATA command completes and before the message is stored or forwarded to the recipient's mailbox, as outlined in RFC 5321. The header is inserted at the top of the message headers to preserve the delivery trace, ensuring traceability without modifying the sender's original content.[8] A standard return path format appears as a simple email address enclosed in angle brackets, such asReturn-Path: <[email protected]>, reflecting the unmodified envelope sender provided in the MAIL FROM command. This format maintains compatibility across MTAs and adheres to the syntactic rules for reverse-paths in SMTP.[8]
Bounce Messages and Non-Delivery Reports
Bounce messages, also known as non-delivery reports (NDRs), are automated notifications sent by mail servers when an email cannot be delivered to the intended recipient. These reports are generated in response to failures during the email transmission process, which relies on the envelope sender address to route the notification back to the originator.[9] Email bounces are categorized into two primary types: permanent (hard) bounces and transient (soft) bounces. Permanent bounces occur due to irreversible issues, such as invalid recipient email addresses, non-existent domains, or accounts that have been permanently disabled or rejected by the server.[10] Transient bounces, in contrast, result from temporary conditions, including full mailboxes, temporary server outages, or network connectivity problems that may resolve upon retry.[11] These distinctions help senders determine whether to remove the address from their list (for hard bounces) or attempt redelivery (for soft bounces).[12] The standard format for NDRs is defined by the Delivery Status Notifications (DSN) protocol, outlined in RFC 3464, which provides an extensible MIME content-type for reporting delivery status. This specification obsoletes the earlier RFC 1894, introducing improvements for better interoperability and handling of multilingual environments in status reports.[13] DSN reports typically include details such as the action taken (e.g., failed or delayed), the status code from the Simple Mail Transfer Protocol (SMTP), and diagnostic information to aid troubleshooting.[14] In bulk email scenarios, such as mailing lists, a significant challenge arises when multiple messages share the same return path address, making it difficult to identify which specific recipient caused the bounce. Without unique identifiers, administrators must manually parse the NDR content or message headers to trace the failure back to an individual subscriber, which becomes impractical at scale and can lead to delayed list maintenance. Per-campaign bounce rates in email marketing typically remain below 2%, with healthy lists under 1%; however, email lists experience an annual decay rate of approximately 22-28% as of 2024, reflecting gradual invalidation of subscriber addresses due to changes in employment, domain expirations, or user errors.[15][16] This accumulation of undeliverable emails not only hampers campaign effectiveness but also risks damaging sender reputation with internet service providers if not addressed.VERP Overview
Motivation for VERP
In large-scale email distribution systems, such as mailing lists with thousands of subscribers, a common issue is the invalidation of recipient addresses due to frequent changes, abandonments, or errors like typos, leading to a substantial portion of undeliverable messages.[1] For instance, in high-volume lists, bounces from these invalid addresses can overwhelm administrators, as identifying the specific failing subscriber becomes increasingly difficult without clear indicators in the bounce messages.[17] Manual processing of these bounces exacerbates the problem, requiring labor-intensive review of often uninformative or inconsistent non-delivery reports, which is impractical for lists handling hundreds or thousands of messages daily.[1] Continued delivery attempts to invalid addresses not only waste computational and bandwidth resources but also harm sender reputation, potentially resulting in IP blacklisting by internet service providers monitoring high bounce rates.[18] To maintain list hygiene, there is a critical need for automated mechanisms to detect and remove invalid addresses efficiently, without relying on the parsing of variable and error-prone bounce content that may omit the original recipient details.[1] Historically, pre-VERP approaches depended on analyzing message headers or emerging standards like Delivery Status Notifications (DSNs) outlined in RFC 1891, but these methods proved complex, inconsistently supported across mail transfer agents, and vulnerable to parsing errors, limiting their effectiveness for bulk operations.[1]Core Mechanism of VERP
The core mechanism of Variable Envelope Return Path (VERP) involves modifying the envelope sender address in SMTP transactions to embed recipient-specific information, enabling the identification of the intended recipient upon receipt of a bounce message. This is achieved without altering the message headers, such as the From field, which remains unchanged to preserve the sender's apparent identity. The envelope sender, specified in the SMTP MAIL FROM command, is customized uniquely for each recipient during message transmission from the sender's Mail Transfer Agent (MTA).[1][19] In the standard VERP format, the envelope sender takes the formowner-recipient=domain@host, where owner identifies the list or sender (e.g., a mailing list name), recipient=domain encodes the full recipient address by replacing the @ symbol with =, and @host is the domain of the sender's MTA. For instance, to send to user@[example.com](/page/Example.com), the envelope sender might be [email protected]. This simple substitution encoding avoids conflicts with email address syntax while allowing straightforward parsing at the receiving end. Alternative implementations leverage subaddressing extensions, such as the + tag, formatting the address as owner+recipient=domain@host (e.g., [email protected]), which is supported by many MTAs like Postfix and qmail.[1][20]
The operational process begins with the sender's MTA generating and using the unique VERP-formatted envelope sender for each outbound message during the SMTP session. If the message cannot be delivered, the receiving MTA generates a non-delivery report (NDR) or bounce, which is routed back to the specified envelope sender address per SMTP conventions in RFC 5321. Upon arrival at the sender's domain, the bounce is delivered to a handler script or service that decodes the embedded recipient information—typically by reversing the @-to-= substitution or parsing the subaddress tag—to identify the specific subscriber associated with the failure. This decoding enables automated actions, such as removing invalid addresses from lists, without relying on content analysis of the bounce message itself. The mechanism requires no modifications to receiving MTAs, as it operates solely within the sender's control and SMTP envelope handling.[1][20]
VERP integrates seamlessly with the SMTP protocol by exclusively altering the MAIL FROM parameter, leaving the message body, headers, and RCPT TO commands unaffected. This ensures compliance with email standards while facilitating precise bounce attribution, particularly in high-volume scenarios like mailing lists. Implementations in software such as GNU Mailman or qmail automate the encoding and decoding steps, routing bounces to dedicated addresses for processing.[1][20]
History and Standards
Origin and Development
The Variable Envelope Return Path (VERP) technique was introduced by Daniel J. Bernstein in 1997 to address challenges in automated bounce handling for large-scale mailing lists.[1] In his document VERPs: Variable Envelope Return Paths, dated February 1, 1997, Bernstein outlined a method for encoding recipient-specific information into the envelope sender address, enabling mailing list software to precisely identify undeliverable messages without relying on inconsistent Delivery Status Notification (DSN) implementations across email systems.[1] This approach aimed to simplify bounce processing in secure and efficient mail transfer agents (MTAs), particularly where universal DSN support—defined in RFC 1891, RFC 1892, and RFC 1894—was not yet widespread.[1] Bernstein first implemented VERP in qmail, his secure MTA that began public beta development in February 1996.[21] Qmail's architecture inherently supported envelope sender modifications, allowing VERP to route bounces through dedicated aliases like *user-list@domain for automated processing.[1] Concurrently, Bernstein integrated VERP into ezmlm, his mailing list manager, around 1997, where it facilitated per-recipient bounce tracking to maintain list hygiene without manual intervention.[22] These early implementations in qmail and ezmlm demonstrated VERP's practicality for high-volume, reliable email distribution in Unix-like environments.[1]Related Protocols and Informal Standardization
Variable Envelope Return Path (VERP) relates closely to Delivery Status Notifications (DSN) as defined in the original RFC 1891, RFC 1892, and RFC 1894, which enable detailed error reporting in email systems but saw incomplete adoption across mail transfer agents (MTAs) due to complexity. VERP emerged as a practical alternative or workaround, allowing senders to encode recipient-specific information directly in the envelope return path without relying on intermediate MTA support for enhanced notifications.[1] VERP is referenced in RFC 6449, published in 2011, which provides operational recommendations for complaint feedback loops (FBLs) in email ecosystems. The RFC describes VERP as an informally standardized method for embedding details about the original message recipient into the return path, facilitating automated processing of user complaints and bounces in scenarios where formal FBL mechanisms are unavailable.[23] The evolution of VERP reflects its integration into major MTAs without a dedicated RFC, establishing it as a de facto standard through widespread implementation. For instance, Postfix incorporated VERP support in 2001, enabling configurable bounce processing via parameters likeenable_verp_command, which has since been adopted in various other MTAs for reliable list maintenance and error handling.[22]
As of 2025, VERP continues to hold relevance in email delivery practices, particularly for legacy systems and scenarios requiring simple, immediate bounce identification, even as more structured protocols like the Abuse Reporting Format (ARF) in RFC 5965 advance abuse and failure reporting with standardized MIME types for feedback. RFC 6651 extends this by using ARF for reporting authentication failures tied to DomainKeys Identified Mail (DKIM). ARF has not fully supplanted VERP's utility in environments with partial DSN or FBL support. In March 2025, an IETF draft (draft-nurpmeso-smtp-verp-01) was published proposing a formal SMTP service extension for VERP, potentially leading to greater standardization.[24][25][26]
Practical Examples
Bounce Handling Without VERP
In traditional bulk email setups, such as mailing lists, a single shared return path—often something like[email protected]—is used for all outgoing messages to multiple recipients. This envelope sender address receives all non-delivery reports (NDRs) when delivery fails, regardless of which specific recipient caused the issue.[1]
When an invalid recipient address is encountered, the receiving mail server generates an NDR and routes it back to the shared return path. The list administrator or automated system then must manually or programmatically inspect the NDR's message body and headers to extract the failing recipient address, if it is included at all. For instance, in software like GNU Mailman, bounces return to a generic address like <listname>[email protected], requiring parsing to correlate the failure with a subscriber.
This process is highly error-prone because NDR formats vary widely across mail transfer agents (MTAs) and providers; some include the original recipient in the body or headers, while others omit it entirely, especially if the email was forwarded or rewritten en route. As a result, identifying and removing invalid addresses from the list is delayed, potentially leading to repeated delivery attempts that harm sender reputation.[1][27]
A typical ambiguous NDR might appear as follows, where the failing address is buried or absent, complicating automated parsing:
Return-Path: <[email protected]>
Received: from mx.example.com (mx.example.com [192.0.2.1]) by mail.domain.com
Date: Mon, 12 Nov 2025 10:00:00 +0000
Subject: Undelivered Mail Returned to Sender
This is the mail system at host mx.[example.com](/page/Example.com).
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to [postmaster](/page/Postmaster).
If you do so, please include this entire [message](/page/Message) in your report.
----------------- Original Message Follows -----------------
To: undisclosed-recipients:;
Subject: [Newsletter](/page/Newsletter) Update
[Original message body truncated...]
Local Postfix Configuration: The recipient domain does not exist.
Reporting-MTA: dns; mx.[example.com](/page/Example.com)
Original-Recipient: rfc822;[email protected]
Final-Recipient: rfc822;[email protected]
Action: failed
Status: 5.1.2
Diagnostic-Code: X-Postfix; host or [domain name](/page/Domain_name) not found
Return-Path: <[email protected]>
Received: from mx.example.com (mx.example.com [192.0.2.1]) by mail.domain.com
Date: Mon, 12 Nov 2025 10:00:00 +0000
Subject: Undelivered Mail Returned to Sender
This is the mail system at host mx.[example.com](/page/Example.com).
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to [postmaster](/page/Postmaster).
If you do so, please include this entire [message](/page/Message) in your report.
----------------- Original Message Follows -----------------
To: undisclosed-recipients:;
Subject: [Newsletter](/page/Newsletter) Update
[Original message body truncated...]
Local Postfix Configuration: The recipient domain does not exist.
Reporting-MTA: dns; mx.[example.com](/page/Example.com)
Original-Recipient: rfc822;[email protected]
Final-Recipient: rfc822;[email protected]
Action: failed
Status: 5.1.2
Diagnostic-Code: X-Postfix; host or [domain name](/page/Domain_name) not found
Original-Recipient header provides a clue, but in many cases—particularly with forwarding—the field may reference a rewritten address not matching any list subscriber, or the body might simply state "delivery failed" without specifics, forcing manual review.[1]
Bounce Handling With VERP
In a mailing list scenario utilizing VERP, each outgoing email incorporates a unique envelope return path that encodes the recipient's address, such as[email protected], allowing for precise bounce identification without relying on message body parsing.[22][1]
When an email to [email protected] fails delivery, the non-delivery report (NDR) is automatically routed to the VERP-modified return path, where server software—such as Postfix with recipient_delimiter = + configured—can deliver the bounce to a handler that decodes the tag by stripping the encoded portion to reveal the original recipient address, such as [email protected], enabling scripted or integrated actions like list removal or update.[22]
This process eliminates the need for complex bounce message analysis, enabling automated handling that directly maps the failure to the specific subscriber for swift remediation, such as unsubscribing the invalid address from the list. For instance, ezmlm uses VERP natively to automatically detect and remove bounced subscribers without additional parsing.[1]
For illustration, consider the following example email headers for a message sent from a mailing list:
From: [email protected]
To: [email protected]
Return-Path: [email protected]
From: [email protected]
To: [email protected]
Return-Path: [email protected]
To: [email protected]
From: [email protected]
Subject: Undelivered Mail Returned to Sender
To: [email protected]
From: [email protected]
Subject: Undelivered Mail Returned to Sender
To: address, decodes bob=example.com as the tagged recipient, confirms the bounce for [email protected], and can then process actions like removal accordingly, often via integrated mailing list tools.[22]
Implementation and Support
Mailing List and Server Software
The Variable Envelope Return Path (VERP) was originally implemented in the qmail mail transfer agent (MTA) and the ezmlm mailing list manager, both developed by Daniel J. Bernstein in the mid-1990s.[28] qmail incorporates VERP directly into its delivery mechanism, allowing mailing lists to generate unique return paths for each recipient to facilitate precise bounce identification.[29] ezmlm, designed specifically for qmail, leverages this feature to automate subscriber management by routing bounces back to the list owner with encoded recipient details.[30] Postfix introduced native VERP support starting with version 1.1 in 2002, enabling the MTA to handle variable return paths on a per-recipient basis during delivery.[22] To enable VERP in Postfix for self-hosted setups, administrators typically set therecipient_delimiter parameter to define address extensions (e.g., + for user+extension@domain), configure default_verp_delimiters to specify the VERP format (defaulting to +=), and use alias or forward files to process bounces. For mailing list integration, generic tables (via smtp_generic_maps or virtual_alias_maps) can rewrite envelope senders to VERP-compliant formats, such as mapping a list address to owner-list+user=domain@host, ensuring bounces are directed appropriately without requiring application-level changes.[22]
Among mailing list managers, GNU Mailman provides configurable VERP support to disambiguate bounces, often integrated with Postfix or Exim by setting dedicated return paths for list deliveries.[31] Sympa implements VERP selectively for a configurable percentage of subscribers (via the verp_rate parameter) to optimize performance while improving bounce detection accuracy.[32]
Other MTAs with VERP capabilities include the Courier Mail Server, which supports VERP through an SMTP service extension that allows bulk VERP messages across domains.[33] Exim achieves VERP functionality via custom router configurations or plugins, such as redirect routers that expand and rewrite return paths for list deliveries, though it lacks built-in support comparable to qmail or Postfix.[34] These tools enable self-hosted administrators to deploy VERP for robust email list maintenance without relying on external services.