Demo
Demo

Knowledge base

PMTA knowledge base›Block <source>›Directive§ 3.3.7.17

verp-default

<source>

Whether to put the recipient into the return address of all mail from this source
in the configuration this is a lineverp-default noinside the block <source>
The same name 1:<domain><source>— some of them are other settings, some are the same one
Enabling on the submission side

Enables VERP for everything submitted through this source: the return address of each message is rebuilt so that the recipient is visible in it.

The scheme is fixed. Sender jsmith@example.com, recipient jdoe@yahoo.com — the return address becomes jsmith-jdoe=yahoo.com@example.com. The sender’s local part, a hyphen, and the recipient’s address with an equals sign instead of the at sign. The format cannot be configured.

This is the broad side of the switch. Here the mechanism is enabled for the whole submission stream; the paired line in a <domain> block enables it pointwise, for messages to one recipient domain.

The main trap is that return address rewriting comes into conflict. If you have sender rewriting configured via <rewrite-list>, the two settings fight over the same field. The result depends on the order of application, and it is not worth predicting from the configuration — check on a live message.
What the Hub does. It does not write it. The Hub links bounces to recipients by the recipient field in accounting records, not by the return address, and it needs the return address to stay constant: the node accepts asynchronous bounces at a single address, bounce@bounce.<domain>.
Recommended values

Enable it on the submission side if all mail needs the mechanism. Pointwise enabling is the job of the paired line in the recipient block.

Prepare bounce receiving in advance. Return addresses will become unique; they have to be accepted for the whole domain.

Do not combine it with sender rewriting. Both settings change the same field, and the order of application is not visible from the configuration.

The “receiving first, then enabling” order and the warning about the conflict with rewriting are ours. From the manual here come the default and the exact address scheme with an example.
Example configuration
# the whole stream of this source goes out with unique return addresses
<source 0/0>
    verp-default true</source>
The 0/0 source means “any submitter”: enabling it here covers all of the node’s submission.
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 for the whole node for the sake of one recipient domain

our experience

What it costsThe return addresses of all mail become unique, not only of messages to the recipient domain it was enabled for. Bounce receiving has to be rebuilt entirely.
How to spot itReturn addresses changed for the whole mailing.
How to do it rightEnable it in the recipient block, not in the submission block.

Enabling it together with sender rewriting

our experience

What it costsBoth settings change the return address. What ends up in the message depends on the order of application, and this is not visible from the configuration.
How to spot itThe return address matches neither of the two schemes.
How to do it rightKeep only one of them and check the result on a live message.
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
no § 3.3.7.17
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<source>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The value is set in a <source> block and applies to everything submitted through a matching source; with several matching blocks the most specific wins. The paired line in a <domain> block enables the mechanism for messages to a specific recipient domain. It is picked up by pmta reload; it does not affect messages already submitted.
⇄

Related directives

1 relation

Works together with

Two inbound report processors and what to do with themAn alternative to parsing the bounce content: the recipient is visible from the address the bounce arrived at. § 3.3.7.17

Referenced from

verp-default<domain>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.106mail-from<rewrite-list>Both lines rewrite the envelope return address, and enabling them together is pointless: one will rewrite after the other. § 3.3.7.17

How to check on the node
The value is printed by the source settings command; the result is visible from the return address in the conversation log:
grep -n verp-default /etc/pmta/config
grep -i 'MAIL FROM' /var/log/pmta/pmta.log | tail -10
With the mechanism on, the return address 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 do with an accepted messageWhat the node does with an accepted inbound message: forwards it, writes it to a file, discards it, passes it to a program or parses it as a bounce or complaint.◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Bounce classification · Receiving inbound mail
Neighboring settings of the block <source>:suppress-local-dsndsn-return-defaultretain-x-dkim-keyprocess-x-dkim-keysmtp-serviceAll 74 directives of the block →