Demo
Demo

Knowledge base

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

allow-chunking

<source>

Whether the CHUNKING extension is offered to this source
in the configuration this is a lineallow-chunking trueinside the block <source>
A second way to transfer the message body

The default is true. The line decides whether the node announces the CHUNKING extension to incoming connections from this source, that is, whether it allows the BDAT command.

BDAT differs from DATA in that the size of each chunk is declared in advance, and the transfer does not need to end with a dot on a line of its own. This removes the need to escape a dot at the start of a line and makes transferring binary data more honest.

The extension concerns only incoming connections — how a message arrives at the node. How the node hands a message to the recipient is decided on the other side.

The main trap is turning it off at random. The default is permissive, and submitting libraries choose what to use by themselves. By turning the extension off, you force them back to DATA — usually silently and without loss, but not always: some clients, having seen CHUNKING in one environment and not in another, behave differently at the boundary of large messages.

The reason to touch this line must be clear. “Just in case” is not a reason.

What the Hub does. It does not write it — the vendor true stays. Submission goes through a library that chooses the method itself, and there is no reason to force one of the two on it.
Recommended values

What to set. The default is almost always right:

Value When
true (default) the usual case: let the submitting side choose
false investigating the behavior of a specific client that makes errors with BDAT

The second is a temporary measure for the duration of the investigation, not a permanent setting.

The true default and the fact that the extension concerns incoming connections come from the manual, § 3.3.7.61. The analysis of the client’s choice is ours.
Example configuration
# turned off while investigating the behavior of a specific client
<source 10.0.0.5>
    allow-chunking false</source>
A client from this subnet will not see CHUNKING in the greeting and will fall back to ordinary transfer via DATA.
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▶

Turning the extension off in a wide block

our experience

What it costsBy the merge rule, the ban goes to every subnet that did not say otherwise itself. Submitting libraries fall back to ordinary transfer — usually silently, but on large messages the difference in client behavior sometimes shows.
How to spot itThe extension disappeared from the greeting for everyone, although it was turned off for one client.
How to do it rightPut the ban in the block the client under investigation falls under.

Expecting the line to affect sending

§ 3.3.7.61

What it costsThe extension concerns only incoming connections. How the node hands a message to the receiver is not decided by this line at all.
How to spot itThe line is edited for the sake of delivery behavior, and nothing changes.
How to do it rightLook at the receiver settings: they are responsible for the outgoing side, not the source block.
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
allow-chunking <boolean>
Values
yes | no | true | false
Default
true § 3.3.7.61
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 directive lives in <source> and follows source merging: a connection falls under all address blocks that cover it, and a narrow one overrides a broad one. For submission under a login the named block applies, and the line has to be repeated in it — we did not see inheritance from address blocks into a named one on our installation.
⇄

Related directives

1 relation

Same name in other blocks

dummy-smtp-has-chunkingGlobalThe same setting on the fake receiver: there it decides whether to announce the extension in tests. § 3.3.1.57.4

How to check on the node
Whether the node announces the extension is visible right in the receiver’s greeting:
printf 'EHLO test\r\nQUIT\r\n' | nc <node-address> 2525 | grep -i chunking
A 250-CHUNKING line in the reply means the extension is offered. Check from the address submission comes from: the source block is selected by it.
◇

What else to read

3 articles

◇How a message gets into the engineSix described submission methods: extended SMTP, four language bindings and a directory the node watches on disk.◇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.◇Headers the sender uses to control deliverySix control headers let the submitting side choose a stream, tag a message with a job, set signing options and the key, the envelope identifier and the schedule; each is allowed separately and per source.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Connect a sending platform
Neighboring settings of the block <source>:always-allow-api-submissiondisconnect-on-transient-errorallow-smtputf8allow-authaccept-invalid-recipientsAll 74 directives of the block →