Using Variable Envelope Return Path Addresses

_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.

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.

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.

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. http://en.wikipedia.org/wiki/Variable_envelope_return_path

In previous versions of Campaign Enterprise, each subscriber list had to have its own POP or IMAP account to collect the bounced emails which could then be removed from that list. This was very inefficient and difficult to manage especially when using a lot of accounts. With the traditional method, the subscriber's email address is difficult to harvest from these emails, with about 70% accuracy at best.

How To Implement

Using VERPs, you can have one email account to handle all your bounce handling needs (if capacity is sufficient and your mail server allows variables). For the "bounced email address" setting on the Message tab in Campaign Enterprise you would entered something like this:

Sales{VERPS}@arialsoftware.com

When sending, this will case the Campaign Enterprise system to replace the {VERPS} merge field here with encoded information concerning the campaign and the unique ID used for the subscriber. The result may look like this:

Sales--000120E0F14512@arialsoftware.com

As you can see, this is not a very readable email address, but it is something you and the recipient never see and it has all the information the Campaign Enterprise system needs to be 100% accurate in remove the bounce.

So, to use this new ability, you will need to create an email account that has a "catch-all" ability. The purpose of this type of account is so that any emails that come in to a certain domain that cannot be matched up to a specific POP account will be dropped into this "catch-all" account. For instances, say an address like johnsmith@arialsoftware.com did not have a pop account associated with it on the arialsoftware.com domain. Then this message would be dropped into the "catch-all" account.

Some email systems will allow you to set up multiple "catch-all" accounts based on a wild card. For instance, you could create an account like john*@arialsoftware.com and any emails that did not have a specific POP account but started with John would be send to this pop account.

On the Bounce tab in Campaign Enterprise, you will need to specify the POP account you have set up for bounces. You may only have already set up this bounce account for other campaigns so it will only be a matter of selected the account from the list.

That's it! Now, one issue VERPs does not address is determining if a bounce is hard (500 series error) or soft (400 or less series error). What the current system does is examine the bounced email for any indications of error numbers, and if not found, then keywords are searched for. As stated above, formats for bounced emails vary wildly and as many formats as possible are examined. -- Arial Software