Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.32

smtp-await-slot

Global

Wait for a slot or refuse an inbound connection above the ceiling
in the configuration this is a linesmtp-await-slot falseinside the block Global
What the client sees when the node is busy

The default is false. The line decides what to do with a new inbound connection when no free slots are left — that is, when the total-max-smtp-in ceiling is reached.

With the default the engine answers with a 421 greeting — service unavailable — and closes the connection. With true the connection waits until a slot frees up.

The line sets the behavior for the whole node. An individual listener has its own await-slot, the same in meaning — it overrides this decision on its address, and that way submission and inbound mail acceptance can be separated.

The main trap is that waiting also takes up resources. A waiting connection is open, it has its own timeouts running, and the submitting side considers it alive. Under load this turns an instant and clear refusal into a delay the client learns about through its own timeouts — later and with no reason in the text.

A 421 refusal is more honest: it says “busy, come back later,” and the sending server knows what to do.

The other half: waiting does not raise the ceiling. There are still no more connections than allowed — only what whoever arrives above the limit sees changes.

What the Hub does. It does not write it — neither this line nor its listener form. The vendor default applies: when the ceiling of 1000 connections is exhausted, the node answers 421 and closes the connection.

For submission this is reasonable: the Hub submits itself, it sees the refusal right away and reschedules the attempt. For accepting complaints and reports the choice is less obvious — someone else’s server will retry on its own schedule, or may not retry at all.

Recommended values

What to set. The choice depends on who is arriving:

Value When
false (default) submission from your own platform, which can retry later
true the node accepts other people’s mail, and the senders’ retry schedule is beyond your control

On a node where both roles are combined, it is more honest to separate them by listeners: with a line on each, not with this general one.

The false default and the 421 response with the connection closed come from the manual, § 3.3.1.32. The listener form is from § 3.3.17.1. The breakdown of cases is ours.
Example configuration
# the node's overall decision; a listener can override it with its own line
total-max-smtp-in 1000
smtp-await-slot false
The lines are read together: the first sets the ceiling, the second what whoever arrives above it will see. Waiting does not raise the ceiling.
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 waiting on the submission listener

our experience

What it costsInstead of a clear refusal, your own platform gets a hanging connection and discovers the problem by its own timeouts — later and without a cause in the text.
How to spot itSubmission hangs without refusal messages, while the node’s logs show the connection ceiling exhausted.
How to do it rightKeep the refusal for submission and waiting where other people’s mail arrives, and set it with the listener’s line.

Taking the line for a way to raise the ceiling

§ 3.3.1.32

What it costsIt does not change the ceiling: there are still no more connections than allowed. Only what whoever arrives above the limit sees changes.
How to spot itThe line is enabled, but the number of simultaneous connections has not grown.
How to do it rightRaise the ceiling itself, and choose this line by who submits.
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
smtp-await-slot <boolean>
Values
yes | no | true | false
Default
false § 3.3.1.32
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
The directive is written at the root of the configuration file and sets the behavior of the whole node. It can be overridden at the level of an individual listener — with a line of the same meaning inside its block.
How to check on the node
The line is read together with the ceiling; it shows up only at the ceiling:
grep -n 'smtp-await-slot\|total-max-smtp-in\|await-slot' /etc/pmta/config
pmta show status | grep -i 'smtp-in\|inbound'
While the number of incoming connections is far from the ceiling, there is no difference between the values at all. Checking the behavior makes sense only under load close to the limit.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Connect a sending platform