Demo
Demo

Knowledge base

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

allow-priority-interruption-during-transfer

<domain>

Interrupt a connection at once or wait until it frees up
in the configuration this is a lineallow-priority-interruption-during-transfer noinside the block <domain>
Cut off mid-word or wait

The default is no. The line specifies how exactly the interruption allowed by the neighboring allow-priority-interruption happens.

With the default the interruption is postponed until the connection frees up — that is, the current message is finished, and only then is the connection handed over.

With the value yes the interruption happens immediately — in the middle of a transfer.

A separate caveat: the line concerns only SMTP queues.

The main trap is that immediate interruption cuts a message off mid-word. The receiver sees a drop in the middle of the data transfer and interprets it in its own way: most often as a network error, sometimes as a sign of a dishonest sender. The message will then have to be sent again in full.

So the time gained for the urgent queue is paid for with a retransmission in the slow one — and with a reputation risk at the receiver that saw the drop.

The vendor chose the default deliberately: waiting for the connection to free up is almost always cheaper.

What the Hub does. It does not write it — the vendor no stays.

The Hub does not set priorities at all, so there is nothing to interrupt: the line will not show up at any value.

Recommended values

What to set. The default is almost always right:

Value When
no (default) the usual case: waiting for the connection to free up is cheaper than sending the message again
yes urgency outweighs the cost of retransmission — a rare case, usually transactional mail in a separate stream

The second is worth weighing twice: a drop in the middle of a transfer is visible to the receiver, and the message will be sent again anyway.

The no default, the “postpone until free versus immediately” analysis and the “only for SMTP queues” caveat come from the manual, § 3.3.10.13. The estimate of the retransmission cost is ours.
Example configuration
# an urgent queue does not wait for a connection to free up — at the cost of a retransmission
<domain transactional.example>
    queue-priority 90
    allow-priority-interruption-during-transfer true</domain>
The line concerns the queues whose connections are taken away, not the one they are taken for. It should be set where a dropped connection is acceptable.
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▶

Enabling immediate interruption in the general block

§ 3.3.10.13

What it costsDrops in the middle of a transfer are allowed for all receivers at once. Each such drop means retransmitting the whole message and a disconnect the receiver sees and interprets in its own way.
How to spot itThe number of dropped connections in the log grows, and outgoing traffic volume exceeds the mailing volume.
How to do it rightKeep the default everywhere except the queues where a drop is really acceptable.

Setting the line on the queue the interruption is for

§ 3.3.10.13

What it costsIt concerns the queues whose connections are taken away, not the one this is done for. Put in the wrong place, it changes nothing.
How to spot itThe line is on for a high-priority queue, the behavior has not changed.
How to do it rightMove it to the receivers whose connections may be cut.
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-priority-interruption-during-transfer <boolean>
Values
yes | no | true | false
Default
no § 3.3.10.13
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 directive lives in <domain> and obeys the merging of receiver blocks: a narrower block overrides a wider one. A value in the * block will allow immediate drops for all receivers at once — which is rarely what was wanted.
⇄

Related directives

1 relation

Depends on

queue-priority<domain>Interruption happens only when priorities differ; this line specifies how exactly it happens. § 3.3.10.13

How to check on the node
The line is read together with the priorities and the permission to interrupt:
grep -n 'allow-priority-interruption' /etc/pmta/config /etc/pmta/virtualhost.txt
grep -i 'connection.*reset\|abort' /var/log/pmta/pmta.log | tail -10
Records of dropped connections in the log are a sign that immediate interruption fires. If there are none while the line is on, priorities do not differ and there is nothing to interrupt.
◇

What else to read

3 articles

◇What the node tells about itself and through which channelsSeven observation surfaces: the web monitor, the console in four formats, the log, accounting, accounting search, metrics and export to external analytics.◇The watchdog that restarts the engineKeeps an eye on the engine and brings it back up after a crash by itself, sending a crash report to the postmaster address.◇What makes a virtual machine riskyRunning on a virtual machine is possible, but the manual does not recommend it without sufficient hardware and properly tuned hypervisor settings: under load the node may stop responding.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Untangle a stuck queue
Neighboring settings of the block <domain>:queue-priorityallow-priority-interruptiondelivery-prioritydisable-acct-recordsdkim-signAll 135 directives of the block →