Demo
Demo

Knowledge base

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

ignore-chunking

<domain>

Do not use the CHUNKING extension even if the receiver announced it
in the configuration this is a lineignore-chunking falseinside the block <domain>
Return the transfer to the ordinary DATA command

The CHUNKING extension (the BDAT command) transfers the message body in pieces of known length instead of the ordinary DATA command with a dot at the end. The line cancels its use, even if the receiver announced the extension.

The manual names one reason — debugging. When message transfer to a specific receiver behaves strangely, turning the extension off returns the conversation to a simple, well-understood form: DATA, body, dot.

The transfer method also changes how the conversation ends: with BDAT the node waits for the reply to the last chunk, with DATA — for the reply to the dot. Both waits are timed by smtp-data-termination-timeout.

The main trap is leaving it on after debugging. The line is meant to be temporary. Forgotten in the configuration, it deprives the transfer of the regular mechanism — and half a year later it is impossible to remember why it was set.
What the Hub does. It does not write it — the vendor false stays. This is an investigation tool, not a setting: in the Hub its place is in a temporary configuration edit, not a permanent one.
Recommended values

Enable it only for the duration of an investigation. And immediately set a reminder to remove it.

Together with ignore-pipelining. The manual gives both the same reason; when investigating strange transfer, they are usually turned off as a pair to simplify the whole conversation.

A comment next to it is mandatory. A line without an explanation of why it is here will outlive its author and stay forever.

The requirement of a comment and the advice to turn them off as a pair 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>
A comment with a date is not decoration: without it the line will stay in the configuration forever, and the reason will be forgotten.
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 after debugging

our experience

What it costsThe transfer loses the regular mechanism for good. Half a year later nobody remembers why the line is there, and people are afraid to remove it.
How to spot itA line in the configuration without a comment and without a date.
How to do it rightRemove it; for the duration of an investigation, set it with a comment and a date.

Enabling it at random when there are bounces

our experience

What it costsThe extension is almost never the cause of receiver bounces: those come because of content, reputation or rate. Turning it off changes nothing, and the investigation goes in the wrong direction.
How to spot itThe line is on, the bounce share has not changed.
How to do it rightFirst look at the bounce text: it almost always names the real cause.
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-chunking <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.10.78
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

1 relation

Often used with

ignore-pipelining<domain>The manual gives both the same reason — to sort out strange transfer. § 3.3.10.79

Referenced from

dummy-smtp-has-chunkingGlobalTwo 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.78ignore-8bitmime<domain>The same switch for another extension — but this one has its own reason: gateway incompatibility, not debugging. § 3.3.10.77

How to check on the node
The value is printed by the queue settings command; whether the node uses the extension is visible from the commands in the conversation log:
pmta show settings problem.example.com/vmta1 | grep -i ignore-chunking
grep -E 'BDAT|^DATA' /var/log/pmta/pmta.log | tail -10
BDAT commands in the log mean the extension is in use; with the line on there should be none. 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 →