Variable envelope return path

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 is going to eventually contain addresses that can't be reached. Addresses that were once valid can become unusable because the person receiving the mail there has switched to a different provider (possibly as a result of changing jobs or schools). 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.

Unfortunately, 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. Having said that, there are several common formats RFC 3464, qmail's [http://cr.yp.to/proto/qsbmf.txt 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 him, it omits his 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 of being able 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 which 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 destination. 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. See [http://cr.yp.to/proto/verp.txt his original explanation] , dated February 1, 1997.

Example

Assume there is 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 that supports VERP

* CiviCRM, module Civimail
* ezmlm
* [http://www.socketlabs.com/hurricane/ Hurricane Server]
* [http://www.inxmail.com/ Inxmail]
* [http://mlmmj.mmj.dk/ Mlmmj]
* GNU Mailman
* Moodle
* postfix
* qmail
* Sendmail, with a ruleset.
* Mercury Mail Transport System
* Zimbra
* MessageSystems www.messagesystems.com
* Port25

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 will always be some recalcitrant MTAs on the Internet that fail to follow even the simplest 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 (See [http://jamesthornton.com/writing/imail-envelope-sender.html Imail] for an example).

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 message
* 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)


Wikimedia Foundation. 2010.

Игры ⚽ Поможем написать курсовую

Look at other dictionaries:

  • VERP — Variable Envelope Return Path (Academic & Science » Electronics) * Viragen Europe, LTD. (Business » NASDAQ Symbols) …   Abbreviations dictionary

  • Bounce message — A bounce message, or (failed) Delivery Status Notification (DSN) message, aka Non Delivery Report/Receipt (NDR), Non Delivery Notification (NDN), or simply a bounce is an automated electronic mail message from a mail system informing the sender… …   Wikipedia

  • Non delivery report — In the Internet s standard e mail protocol SMTP, a bounce message, also called a Non Delivery Report/Receipt (NDR), a (failed) Delivery Status Notification (DSN) message, a Non Delivery Notification (NDN) or simply a bounce, is an automated… …   Wikipedia

  • Bounce address — A bounce address is an e mail address to which bounce messages are delivered. There are many variants of the name, none of them used universally, including return path, reverse path, envelope from, envelope sender, MAIL FROM, 5321 FROM, return… …   Wikipedia

  • Simple Mail Transfer Protocol — This article is about the Internet standard for electronic mail transmission. For the email delivery company, see SMTP (company). Internet protocol suite Application layer …   Wikipedia

  • Bounce Address Tag Validation — In computing, Bounce Address Tag Validation (BATV) is the name of a method, defined in an Internet Draft, for determining whether the bounce address specified in an E mail messageis valid. It is designed to reject backscatter, that is, bounce… …   Wikipedia

  • Greylisting — (or graylisting) is a method of defending e mail users against spam. A mail transfer agent (MTA) using greylisting will temporarily reject any email from a sender it does not recognize. If the mail is legitimate, the originating server will try… …   Wikipedia

  • Extended SMTP — (ESMTP), sometimes referred to as Enhanced SMTP, is a definition of protocol extensions to the Simple Mail Transfer Protocol standard. The extension format was defined in RFC 1869 in 1995.RFC 1869 established a structure for all existing and… …   Wikipedia

  • VERP — abbr. Variable Envelope Return Path (SMTP) …   United dictionary of abbreviations and acronyms

  • motion-picture technology — Introduction       the means for the production and showing of motion pictures. It includes not only the motion picture camera and projector but also such technologies as those involved in recording sound, in editing both picture and sound, in… …   Universalium

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”