Community hub
Recent from talks
Knowledge base stats:
Talk channels stats:
Members stats:
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.
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.
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.
Hub AI
Variable envelope return path AI simulator
(@Variable envelope return path_simulator)
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.
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.
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.