Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 6.3.11

Recipients deferred after a temporary refusal

Await Retry bucket
There are messages in the queue, but they cannot be sent

A queue mechanism the configuration chapter does not mention at all. A temporary refusal at the recipient level — the manual gives a full mailbox as an example — does not leave the recipient in the queue waiting for the next attempt. It moves into a separate waiting area and stays there until the deadline set per receiver.

Hence an important distinction: the number of recipients in a queue and its readiness to send are different quantities. Mail can be in place and at the same time deliberately not eligible for sending. The queue looks full and does not move — and this is not a stall but the mechanism at work.

The waiting period is set per receiver — with its own directive, not with the common retry schedule.

Two commands can release deferred recipients early. Both have an option that cancels the hold: the one that schedules delivery and the one that runs a trace. This is a way to test a hypothesis without waiting for the deadline.

The main trap is taking a full, motionless queue for a stall. Recipients deferred after a temporary refusal are counted in the total, but they cannot be sent before the deadline. The investigation turns into a hunt for network problems and limits, while the node is doing exactly what it should: waiting. The two can be told apart only if you know about this area — by recipient count it is indistinguishable.
What the Hub does. It does not set the hold period — the vendor value remains. And its telemetry does not distinguish this area: the number of recipients in a queue arrives as a total, without splitting into ready to send and deferred.

⚠️ This has a consequence for our charts: queue growth with soft bounces looks the same for us as queue growth during a stall. They can be told apart only by the share of soft bounces next to it — and even then indirectly.

The Hub does not call the commands that release deferred recipients early either: that is a manual verification tool.

Recommended values

What is worth distinguishing when looking at a queue:

What you see What it may be
many recipients, no sending deferred after a soft bounce — or a stall
many recipients, sending is going on normal work under load
few recipients, no sending held back by a limit or stopped

The first case is exactly the one that requires knowing about this area. It should be checked not via the network or limits but via the share of soft bounces to this receiver: if it is high, the node is simply waiting for the deadline.

The deadline is worth touching only with a reason. Speeding up retries to a receiver that said “later” is a sure way to get something other than a soft bounce from it.

The distinction table and the advice about the deadline are ours. From the manual here come the very existence of a separate waiting area, the full mailbox example, the per-receiver interval and the two options that release deferred recipients early.
Example configuration
# release deferred recipients early — two commands have the option
pmta schedule --retry-recipients gmail.compmta trace --retry-recipients --to-log gmail.com
The highlighted line cancels the hold and makes deferred recipients available immediately. It is a way to test the hypothesis “the problem is the receiver, not us” without waiting for the deadline.
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 ends3 mistakes▶

Taking waiting for a stall

§ 6.3.11

What it costsDeferred recipients are counted in the total, but they cannot be sent before the deadline. The investigation goes into the network and limits, while the node is doing exactly what it should.
How to spot itThe queue is full and nothing is sent, yet connections open normally and there are no transport errors.
How to do it rightLook at the queue’s recent events: a series of soft bounces means waiting. The hypothesis can be tested by releasing the deferred recipients with the option.

Shortening the hold period to “stir up” the queue

§ 6.3.11

What it costsThe receiver said “later” — and it will take a retry before the deadline worse than the first attempt. Speeding up retries to someone who asked to wait usually turns a soft bounce into a hard one.
How to spot itAfter the period was shortened, the bounce rate at the receiver grew.
How to do it rightTouch the deadline only with a reason. For a one-off check there is an option that cancels the hold — it does not change the setting.

Treating the recipient count as a measure of readiness to send

§ 6.3.11

What it costsThese are different quantities: mail can be in place and deliberately not eligible for sending. A metric built on the recipient count will be the same during a stall and during normal waiting.
How to spot itThe queue depth chart grows, but the cause cannot be determined from it.
How to do it rightLook at queue depth together with the share of soft bounces — neither answers the question on its own.
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.
Inheritance
The waiting area is not configurable — it always exists. What is inherited is the hold period: it is set by a directive in a receiver block and merges by the usual rule — from the general pattern to the specific one and across the node, pool and sending address levels.
⇄

Related entries

5 relations

Depends on

retry-recipients-after<domain>The directive that sets the hold period. § 6.3.11

Works together with

Backoff mode — the queue's second personalityBackoff mode holds back a whole queue, while this holds back individual recipients: a queue can be in normal mode and still send almost nothing. inference

Where you can see it

Attempt delivery ahead of scheduleWith the option, cancels the hold and releases deferred recipients immediately. § 6.3.11Delivery attempt with the session loggedThe same hold cancellation option exists here too. § 6.3.23The list of recipients in a queueLists a queue’s recipients — including deferred ones. § 6.3.29

Referenced from

Sending windows set in the message itselfA queue’s retry mode is stronger than the schedule: while the queue is in it, the window passes without attempts. inferenceTemporary failureA temporary recipient failure is what sends the recipient to the waiting area. inference

How to check on the node
Two views of the same queue help tell waiting apart from a stall:
pmta show queues gmail.com
pmta show settings gmail.com/mta-news-1
The first shows the number of recipients and recent events: a series of soft bounces among them means the queue is waiting, not stuck. The second shows the hold period in effect for this queue.
◇

What else to read

3 articles

◇A queue is a receiving server together with a sending addressThe engine groups messages by the “recipient domain plus sending address” pair: one domain from two addresses is two independent queues with their own counters, connections and mode.◇A retry ladder of your ownretry-after and backoff-retry-after accept a list of intervals — up to 30 steps, and the last one applies until the bounce.◇Keeping selected domains resolved at all timesA file with a list of domains whose DNS records are refreshed on their own schedule, independently of the queue and regardless of their own time to live.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Tune the pace for a provider · Untangle a stuck queue