Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.57.6

dummy-smtp-has-verp

Global

Whether the fake receiver announces the VERP extension
in the configuration this is a linedummy-smtp-has-verp falseinside the block Global
When the run goes with unique return addresses

Decides whether the fake receiver announces support for VERP — the mechanism in which a message’s return address contains the recipient’s address. The default is false.

Of the three lines in the set, this one is needed least often. Pipelining and chunked transfer affect any run; VERP only the one where sending goes with verp-default enabled. If your return address is constant, there is no reason to announce the extension.

But with VERP enabled it is mandatory. Otherwise the fake presents itself as a receiver that does not understand the mechanism, and the sending side will hold the conversation differently than it would with a real mailbox provider.

The main trap is a mismatch with the production configuration. VERP is enabled in the sending configuration, and the announcement is here, in another section of the file. It is easy to enable one and forget the other, and then the run measures a conversation that will not happen even once in real life.
What the Hub does. It writes neither this line nor VERP itself: it links bounces to the recipient by the recipient field in accounting records, not by the return address. As long as this is so, the line is not needed.
Recommended values

Enable it only if you run mail with VERP. In other cases the default is right.

Check it against the sending configuration. The sign is verp-default set in a submission or receiver block.

Do not enable it “for completeness”. An announced but unused extension makes the conversation unlike what it will be in real life.

The rule of checking against the sending configuration is ours. From the manual come the default and the purpose of the line: whether fake connections support this extension.
Example configuration
# running mail with unique return addresses
dummy-smtp-port 2525
dummy-smtp-has-verp true
<source 0/0>
    verp-default true
</source>
Two settings in different sections of the file describe one run: by enabling VERP at submission and forgetting the announcement here, you measure someone else’s scenario.
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 VERP at submission and forgetting the announcement

our experience

What it costsThe fake presents itself as a receiver without support for the mechanism, and the conversation goes differently than it would with a real mailbox provider. The run measures a scenario that will not happen.
How to spot itIn the configuration verp-default is on, but there is no announcement.
How to do it rightKeep both sides in agreement — check them with one command.

Enabling it “for completeness” without using VERP

our experience

What it costsThe fake announces an extension the sending does not use. The conversation becomes unlike production in the other direction.
How to spot itThe announcement is on, verp-default is not set anywhere.
How to do it rightReturn the default: the fake’s set of extensions must repeat what actually happens.
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
dummy-smtp-has-verp <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.1.57.6
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
Global
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
A node-level line: it is written at the root of the file, not inside a block. It has no inheritance. It is picked up by pmta reload; it does not affect connections already established.
⇄

Related directives

2 relations

Applies to

A return address with the recipient written into itThe mechanism the fake is told to announce support for. § 7.4.4A fake receiver inside the node itselfOne of the eight lines configuring the fake receiver: this one decides whether to announce support for unique return addresses. § 3.3.1.57.6

How to check on the node
The value is set in the configuration; whether the fake announces the extension is visible from its reply to EHLO:
grep -n 'dummy-smtp-has-verp\|verp-default' /etc/pmta/config
printf 'EHLO test\r\nQUIT\r\n' | nc 127.0.0.1 2525
The first command shows both sides at once: if one is on and the other is not, the run does not match production sending. The Hub sets neither.
◇

What else to read

3 articles

◇The activation key is a prerequisite for installation, not a step after itWithout an activation key from SparkPost support the engine neither installs nor runs, and the license tier sets the outbound connection ceiling: on Standard everything above 200 is ignored.◇Cloud restrictionsClouds restrict outbound mail on port 25 until you ask them to lift the limit, and mailbox providers treat their address ranges with suspicion.◇How to turn a sending plan into hardwareTwo constants for sizing any node: about 2 KB of memory per queued recipient and spool space proportional to the total size of the messages.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Capacity planning
Neighboring settings of the block Global:dummy-smtp-has-chunkingdummy-smtp-has-pipelininghost-namepostmastersmtp-source-hostAll 108 directives of the block →