Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.57.4

dummy-smtp-has-chunking

Global

Whether the fake receiver announces the CHUNKING extension
in the configuration this is a linedummy-smtp-has-chunking falseinside the block Global
How convincingly the fake presents itself

The CHUNKING extension (the BDAT command) transfers the message body in pieces of known length instead of the ordinary DATA command. This line decides whether the fake receiver announces support for this method. The default is false, it does not announce it.

This is the other side of the same agreement. On the sending side the extension is controlled by ignore-chunking: it decides whether to use it when a receiver has announced it. Here it is decided whether to announce it.

The point is the run’s realism. Large mailbox providers announce the extension, and production mail goes to them via BDAT. A run with the default goes via DATA — a different code path, with different costs, and it will measure something other than real life.

The main trap is that the defaults of the three has-* lines make the fake unrealistic. All three are off, and the fake receiver comes out as the simplest possible one: no pipelining, no chunked transfer, no VERP. The run measures the lightest case for the node, while production sending goes the heaviest way.
What the Hub does. It does not write it: the mechanism is not brought up on the nodes. If it appears, the set of announced extensions is worth taking from real receivers — from their reply to EHLO. The Hub itself does not collect that reply: the proxy check reads only the banner from mailbox providers and says goodbye.
Recommended values

Enable it if production mail goes through this extension. It is checked by the real receiver’s reply to EHLO.

All three has-* lines — together. Separately they give partial realism; the point is for the conversation in the run to match the production one.

The default is kept for one task — measuring the node on the simplest conversation, as a lower bound.

The rule “take the set from real receivers” is ours. From the manual come the default and the purpose of the line: whether fake connections support this extension.
Example configuration
# the fake must hold the conversation the same way as a real mailbox provider
dummy-smtp-port 2525
dummy-smtp-has-chunking truedummy-smtp-has-pipelining true
The two lines sit together for a reason: large receivers announce both extensions, and without them the run measures a conversation that will not happen in real life.
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▶

Running with the defaults of all three lines

our experience

What it costsThe fake holds the simplest conversation, while production mail holds the most loaded one. The measurement describes a case that does not occur in real life.
How to spot itThe measured ceiling is noticeably higher than real sending with the same limits.
How to do it rightTake the set of extensions from a real receiver and repeat it in the fake.

Enabling an extension receivers do not announce

our experience

What it costsThe run measures a conversation heavier than production. The error goes the other way, but the result is the same — the figure does not describe real life.
How to spot itThe measured ceiling is noticeably lower than real sending.
How to do it rightCheck the set against a real receiver’s reply to EHLO.
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-chunking <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.1.57.4
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.
How to check on the node
The value is set in the configuration; what the fake announces is visible from its reply to EHLO:
grep -n dummy-smtp-has- /etc/pmta/config
printf 'EHLO test\r\nQUIT\r\n' | nc 127.0.0.1 2525
The second command prints the fake receiver’s reply in full — it is what the set of extensions is checked against a real mailbox provider by. The Hub does not use this mechanism.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Capacity planning