Demo
Demo

Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.106

verp-default

<domain>

Whether to write the recipient into the return address of messages to this recipient domain
in the configuration this is a lineverp-default falseinside the block <domain>
The same name 1:<domain><source>— some of them are other settings, some are the same one
Targeted enabling for one recipient domain

The same setting as in the submission block, but from the other side: here the mechanism is enabled for messages to a specific recipient domain, not for everything submitted.

The address scheme is the same and cannot be configured: the sender’s local part, a hyphen, the recipient’s address with an equals sign instead of the at sign.

Targeted enabling is usually the right choice. Parsing bounces by the return address makes sense where bounces arrive unreadable: from one mailbox provider without the attached message, from another in a garbled form. For the rest the return address can stay constant.

The main trap is bounce acceptance set up for a constant address. Having enabled the mechanism even for one recipient domain, you start receiving bounces at addresses that are not in any list. If acceptance works by an exact mailbox name match, these bounces simply will not arrive — and it will look as if the bounces stopped.
What the Hub does. It does not write it. It links bounces to the recipient by the recipient field in accounting records: synchronous ones the engine writes itself, asynchronous ones are parsed by the bounce processor. Switching to VERP would require rebuilding acceptance: today the node accepts bounces at a single address bounce@bounce.<domain>, not at addresses with the recipient inside.
Recommended values

Targeted is better than for the whole stream. The return address stays constant everywhere except for the recipient domains where it gets in the way.

Acceptance first, then enabling. Bounces must be accepted by the whole return address domain, not by the mailbox name.

The sign by which it is enabled. Bounces from this mailbox provider arrive without the attached message or in a form from which the recipient cannot be extracted.

The sign for enabling and the targeting rule are ours. From the manual here come the default and the fact that the address scheme matches the one set on the submission side.
Example configuration
# this provider's bounces are unreadable — identify the recipient by the address
<domain yahoo.com>
    verp-default yes</domain>
For other recipient domains the return address will stay constant: enabling it here changes nothing outside this block.
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 touching bounce acceptance

our experience

What it costsBounces arrive at addresses that are not in the acceptance lists. The feedback stream from this mailbox provider breaks off, and it looks like an absence of bounces rather than their loss.
How to spot itBounces from one mailbox provider disappeared right after the edit.
How to do it rightSet up acceptance by the whole return address domain.

Expecting the address format to be configurable

our experience

What it costsThe scheme is fixed. A handler written for a different encoding will not extract the recipient from the address.
How to spot itThe handler does not parse the return addresses.
How to do it rightParse by the vendor’s scheme — there is one, and it does not change.
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.
Reference data
Syntax
verp-default <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.10.106
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The value merges across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file. The paired line in the <source> block enables the mechanism for everything submitted by the source. It is picked up by pmta reload; it does not affect messages already submitted.
⇄

Related directives

1 relation

Same name in other blocks

verp-default<source>The same mechanism from the other side: that line enables it for everything submitted by the source, this one for messages to one recipient domain. § 3.3.10.106

How to check on the node
The value is printed by the queue settings command; the result is visible from the return address in the conversation log:
pmta show settings yahoo.com/vmta1 | grep -i verp-default
grep -i 'MAIL FROM' /var/log/pmta/pmta.log | tail -10
If the return address in the log is unchanged while the line is enabled, check whether it is also being rewritten by a rewrite rule. The Hub does not use this mechanism.
◇

What else to read

3 articles

◇Four value types the whole config is written inBoolean, domain pattern, regular expression and time interval — defined once in § 3.2 and then used by all directives.◇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.◇How the policy for a receiver is assembledSettings are assembled from the most general pattern to the most precise; the order of blocks in the file means nothing.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Bounce classification · Tune the pace for a provider
Neighboring settings of the block <domain>:connect-timeoutauth-usernamecommandallow-cancel-during-transferassume-delivery-upon-data-termination-timeoutAll 135 directives of the block →