Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.57.5

dummy-smtp-has-pipelining

Global

Whether the fake receiver announces the PIPELINING extension
in the configuration this is a linedummy-smtp-has-pipelining falseinside the block Global
The difference that changes a run’s result the most

The PIPELINING extension lets the sender send commands in a row without waiting for a reply to each. This line decides whether the fake receiver announces support for it. The default is false.

The other side of the same agreement. On the sending side the extension is controlled by ignore-pipelining: there it is decided whether to use it; here — whether to announce it.

Of the three has-* lines this one weighs the most. Pipelining removes the wait after each command, and for a message with many recipients the conversation becomes several times shorter. A run without it measures a long conversation — and hits the ceiling earlier than production sending will.

The main trap is that latency multiplies the error. If dummy-smtp-latency is set next to it, every command without pipelining costs a full round trip. A hundred milliseconds of latency and a dozen commands give an extra second per conversation — which would not be there with pipelining. The two settings together distort the result more than each one separately.
What the Hub does. It does not write it: the mechanism is not brought up on the nodes. If it appears, this line should be enabled first: large mailbox providers announce pipelining, and without it the run describes a conversation that does not happen.
Recommended values

Enable it almost always. Large receivers announce the extension, and production mail goes through it.

Especially with latency set. Without pipelining the latency is multiplied by the number of commands, and the run’s result drifts several-fold.

The default — only for a lower bound. Measuring the heaviest possible conversation also makes sense, but it cannot be used for planning.

The remark about latency being multiplied by the number of commands is ours. From the manual come the default and the purpose of the line: whether fake connections support this extension.
Example configuration
# pipelining and latency together — otherwise the run drifts several-fold
dummy-smtp-port 2525
dummy-smtp-latency 100
dummy-smtp-has-pipelining true
Without the highlighted line every command would cost a hundred milliseconds of waiting, and the conversation in the run would stretch several-fold compared with production.
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▶

Keeping the default with latency set

our experience

What it costsEvery command costs a full network round trip. The conversation in the run stretches several-fold compared with production, and the ceiling comes out understated — planning based on it is excessively cautious.
How to spot itThe measured throughput is noticeably lower than real sending with the same limits.
How to do it rightEnable pipelining — the same way real receivers announce it.

Editing the sending side instead of the fake

our experience

What it costsignore-pipelining controls our behavior with foreign receivers, not what the fake announces. An edit in the wrong place looks applied and does not affect the run.
How to spot itThe value was changed, the conversation length in the run is the same.
How to do it rightFor the fake edit this line, for production sending — that one.
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-pipelining <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.1.57.5
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

Works together with

ignore-pipelining<domain>Two sides of one agreement: there we decide whether to use a foreign receiver’s extension, here — whether to announce it as our own. § 3.3.10.79

Applies to

A fake receiver inside the node itselfOne of the eight lines configuring the fake receiver: this one decides whether to announce command pipelining. § 3.3.1.57.5

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-pipelining /etc/pmta/config
printf 'EHLO test\r\nQUIT\r\n' | nc 127.0.0.1 2525
The line with the extension appears in the fake’s reply only when the setting is on. The Hub does not use this mechanism.
◇

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-verphost-namepostmastersmtp-source-hostAll 108 directives of the block →