Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 7.4.4

A return address with the recipient written into it

VERP
Identify the recipient by the address, not by the bounce text

Usually a whole mailing has one return address, and when a bounce arrives, the recipient has to be figured out from its content — parsing the text, looking for the attached message, matching identifiers. This works, but depends on how carefully the bounce was composed on the other side.

VERP turns the task around. The return address is made unique for each recipient: the node writes the recipient’s address into it by a fixed scheme. The bounce arrives at this unique address — and the recipient is visible from the address itself, with nothing to parse.

The scheme is rigid: from the sender jsmith@example.com and the recipient jdoe@yahoo.com you get jsmith-jdoe=yahoo.com@example.com — the at sign in the recipient’s address is replaced with an equals sign, and all of it becomes the local part of the new address.

The main trap is that the return address stops being constant. Everything set up around it breaks: exact-match acceptance rules, lists in other people’s systems, the signature of the return address domain. The domain stays the same, but the local part is unique for each message, and such mail has to be accepted by the whole domain.
What the Hub does. It does not use it. Bounces reach the Hub as accounting records: synchronous ones are written by the engine, asynchronous ones are parsed by its bounce processor, and the recipient is taken from the record field, not from the return address. VERP is an alternative to this parsing, and switching to it makes sense only together with the whole bounce acceptance chain.
Example configuration
# enabling for all submitters
<source 0/0>
    verp-default true</source>

# or targeted, for one recipient domain
<domain yahoo.com>
    verp-default yes</domain>
Two sides of one mechanism: in the submission block it is enabled for everything submitted by that source, in the recipient block for messages to that domain specifically.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Enabling it without preparing bounce acceptance

our experience

What it costsBounces start arriving at addresses that are not in any list. Exact-match acceptance does not let them through, and all feedback is lost at once.
How to spot itAfter enabling it, the bounce stream dropped almost to zero.
How to do it rightSet up acceptance by the whole return address domain, not by a specific mailbox name.

Believing the scheme can be chosen

our experience

What it costsThe address format is fixed and cannot be configured. A handler designed for a different encoding will parse nothing in it.
How to spot itThe handler does not extract the recipient from the return address.
How to do it rightParse by the vendor’s scheme: the sender’s local part, a hyphen, the recipient’s address with an equals sign instead of the at sign.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
⇄

Related entries

1 relation

Works together with

Two inbound report processors and what to do with themWhat the bounce processor gets depends on whether the mechanism is enabled: the recipient’s address or parsing of the content. inference

Referenced from

dummy-smtp-has-verpGlobalThe mechanism the fake is told to announce support for. § 7.4.4Parsing bounces that arrive as messagesA related mechanism: they work together. inference

How to check on the node
Whether the scheme works is visible from the return address in sent messages — it should contain the recipient’s address:
pmta show settings yahoo.com/vmta1 | grep -i verp-default
grep -i 'MAIL FROM' /var/log/pmta/pmta.log | tail -10
The log shows the return address in full: with VERP enabled it contains the recipient’s address with an equals sign instead of the at sign. The Hub does not use this mechanism.
◇

What else to read

3 articles

◇Two inbound report processors and what to do with themBounces by message and complaints are parsed by two identically structured blocks; each has its own address list and its own pair of decisions about the message’s fate.◇What to return in a bounce reportWhat to enclose in a bounce report: the whole message or only its headers.◇Which outcomes produce a report — each recipient decidesFor each recipient separately a report on success, failure, delay, any combination of them or nothing is requested; the default is failure only.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Bounce classification