Demo
Demo

Knowledge base

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

ignore-pipelining

<domain>

Do not use the PIPELINING extension even if the receiver announced it
in the configuration this is a lineignore-pipelining falseinside the block <domain>
Commands one at a time instead of a batch

The PIPELINING extension lets several commands be sent in a row without waiting for a reply to each. This noticeably speeds up the conversation, especially with many recipients in one message. The line cancels its use.

The manual gives the same reason as for ignore-chunking — debugging. When transfer behaves strangely, a one-command-at-a-time conversation reads unambiguously in the log: you can see exactly which command the receiver answered and how.

The price is speed. Without pipelining each command costs a full network round trip. For a message with a hundred recipients that is a hundred waits instead of a few.

The main trap is enabling it “just in case” and leaving it. Unlike ignore-chunking, the loss here is measurable: the conversation with the receiver becomes as many times longer as there were commands in it. With large messages and a high rate this shows at once — but not in bounces, in dropped speed.
What the Hub does. It does not write it — the vendor false stays. Like its paired line, this is an investigation tool: its place is in a temporary edit, not in the permanent configuration.
Recommended values

Only for the duration of an investigation. And with a comment explaining why.

Together with ignore-chunking. Turning both off, you get the simplest possible conversation: command — reply, DATA, body, dot.

Remember the price. For this line it is measurable — speed, unlike the paired one, where only the transfer mechanism is lost.

The estimate of the price in speed and the requirement of a comment are ours. From the manual come the default and the only named reason: debugging transfer problems.
Example configuration
# TEMPORARY: investigating transfer drops, 28.08 — remove afterwards
<domain problem.example.com>
    ignore-chunking true
    ignore-pipelining true</domain>
The pair of switches gives the simplest possible conversation — convenient to read in the log line by line.
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▶

Leaving it on under load

our experience

What it costsEach command costs a full network round trip. With messages that have many recipients the conversation stretches several-fold, and the rate drops without a single error in the log.
How to spot itDelivery speed to one recipient is noticeably lower than to the others, with the same limits.
How to do it rightRemove the line after the investigation.

Turning off pipelining to “reduce the load on the receiver”

our experience

What it costsIt does not reduce the load: there are as many messages and commands, the conversation is just longer. The connection, however, is held longer, which means it occupies a max-smtp-out slot and loads more in total.
How to spot itAfter turning it off, the number of simultaneous connections grew at the same rate.
How to do it rightReduce load with the rate (max-msg-rate), not by turning off extensions.
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
ignore-pipelining <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.10.79
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 is merged across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file. It is picked up by pmta reload; it does not affect open connections.
⇄

Related directives

0 relations

Referenced from

dummy-smtp-has-pipeliningGlobalTwo 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.79ignore-chunking<domain>The manual gives both the same reason — to sort out strange transfer. § 3.3.10.79

How to check on the node
The value is printed by the queue settings command; whether the node uses the extension is visible from whether commands go in batches:
pmta show settings problem.example.com/vmta1 | grep -i ignore-pipelining
grep -i 'PIPELINING' /var/log/pmta/pmta.log | tail -10
The extension is announced by the receiver in its reply to EHLO; if it is not there, the line will not take effect. The Hub does not collect conversation commands.
◇

What else to read

3 articles

◇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.◇Backoff mode — the queue's second personalityA queue that a receiver has started refusing switches to a parallel set of limits, retries and routes — ten directives that act only in this mode.◇Reputation monitoring inside the nodeThe engine itself watches the receiving servers’ replies and changes the queue mode on a pattern match — a reaction within the connection, not through telemetry.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Troubleshoot deliverability · 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 →