Demo
Demo

Knowledge base

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

allow-cancel-during-transfer

<domain>

Whether a connection may be cut while the message body is being transferred
in the configuration this is a lineallow-cancel-during-transfer trueinside the block <domain>
Fast shutdown versus a clean transfer

This is about our disconnect, not someone else’s. When the node is stopped, it closes connections — including those over which a message body is being transferred right now. This line decides whether it is allowed to do so.

The default true — allowed. The service stops quickly. The price is that the receiver got the message incompletely, and some mail servers deliver such a message anyway. On retry the node will send it again — the recipient will see two messages, one of them truncated.

false — not allowed. The transfer is completed, and no duplicates arise. The manual honestly names the price: stopping the node may take noticeably longer.

The main trap is that the price is paid where you do not expect. The setting looks like it is “about stopping the service,” but it hits recipients: every node restart with the default leaves behind a batch of truncated messages that will then arrive a second time. On a node that is restarted often, this is a regular source of duplicate complaints.
What the Hub does. It does not write it — the vendor true stays. The Hub applies the configuration with a reload (pmta reload), not by stopping the service. The service stops during a restart operation from the cabinet and during an engine upgrade — and with the default, each such stop can leave truncated messages behind.
Recommended values

false — for nodes that are restarted often. The more often the service is stopped, the more often the default cuts transfers.

The default — for nodes that are stopped rarely and urgently. There a fast shutdown matters more, and a truncated message is a once-in-six-months event.

Look at the pairing with the bounce on disconnect. The same uncertainty from the other side is covered by bounce-upon-transfer-failure: it decides what to do with a message after someone else’s disconnect.

The split by restart frequency is ours. From the manual here come the true default, the duplicate mechanics at receivers that deliver incomplete messages and the direct caveat that turning it off slows down shutdown.
Example configuration
# a node that is restarted often: do not cut the transfer
<domain *>
    allow-cancel-during-transfer false</domain>
Stopping the service will take longer after this — exactly as long as needed to finish the ongoing transfers.
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 on a node that is restarted often

our experience

What it costsEvery restart cuts ongoing transfers. Receivers that deliver incomplete messages hand recipients a truncated copy, and the retry brings a second one.
How to spot itComplaints about duplicates arriving in waves — matching the update dates.
How to do it rightSet false and accept a slower shutdown.

Turning it off on a node that must be able to shut down fast

§ 3.3.10.61

What it costsShutdown stretches out for the duration of the longest ongoing transfer. In an emergency shutdown this may matter more than duplicates.
How to spot itThe service does not stop within the expected time.
How to do it rightRestore the default where shutdown speed matters more, and cover the duplicate risk from the bounce-on-disconnect side.
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-cancel-during-transfer <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
true § 3.3.10.61
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 merges 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 takes effect at the next service stop, not immediately.
⇄

Related directives

1 relation

Works together with

bounce-upon-transfer-failure<domain>The same uncertainty from the other side: this line decides whether to cut the transfer ourselves, that one — what to do after someone else’s disconnect. § 3.3.10.61

How to check on the node
The value is printed by the queue settings command; the consequences are visible only from recipients’ complaints about repeated messages:
pmta show settings gmail.com/vmta1 | grep -i allow-cancel
A disconnect made by the node itself during shutdown does not differ from a network one in accounting. The Hub does not tell them apart and does not track duplicates.
◇

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>:file-destinationcommandconnect-timeoutassume-delivery-upon-data-termination-timeoutauth-usernameAll 135 directives of the block →