Demo
Demo

Knowledge base

PMTA knowledge base›Block <smtp-listener>›Directive§ 3.3.17.1

await-slot

<smtp-listener>

Whether new connections on this listener wait when the ceiling is exhausted
in the configuration this is a lineawait-slot falseinside the block <smtp-listener>
Wait or refuse — per listener

The default is false. The line decides what to do with a new incoming connection when the node has hit the total-max-smtp-in ceiling: wait for a free slot or refuse.

With the default the engine responds with a 421 greeting — service unavailable — and closes the connection.

The difference from the node-wide line smtp-await-slot is in scope: that one sets the behavior for the whole node, this one — for connections on the address of one listener. This way listeners can be split: submission waits, complaint intake refuses — or vice versa.

The main trap is that waiting is not free. A connection waiting for a slot itself occupies a resource: it is open, it has its own timeouts, and the submitting side considers it alive. Under load this turns a refusal that would be visible right away into a delay that the submitting platform will detect by its own timeouts — later and less clearly.

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

What the Hub does. It does not write it — neither here nor as the node-wide line. So the vendor default applies: when the ceiling of 1000 connections is exhausted, the node responds with 421 and closes the connection.

For the fleet this is reasonable: submission comes from the Hub itself, which sees the refusal right away and reschedules the attempt, and it has no reason to wait in an open connection.

Recommended values

What to set. The choice depends on what the listener is used for:

Value When
false (default) submission from your own platform, which can retry later
true an incoming mail listener: a third-party server will not retry soon, and it is better to hold the connection

The second is justified for complaint and report intake: the sender there is a third party, and its retry schedule is beyond your control.

The false default, the binding to the listener address and the link to the incoming ceiling come from the manual, § 3.3.17.1. The 421 response on refusal — § 3.3.1.32. The breakdown of cases is ours.
Example configuration
# submission refuses right away, complaint intake waits for a slot
<smtp-listener 0/0:2525>
    await-slot false
</smtp-listener>

<smtp-listener 0/0:25>
    await-slot true</smtp-listener>
Your own platform will get 421 and retry on its own schedule. A third-party server bringing a complaint will wait for a slot — it would not retry for a long time and might not retry at all.
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 refusal on the submission listener, and waiting on the incoming mail listener, if it is needed there.

Taking the line for a way to raise the ceiling

§ 3.3.17.1

What it costsIt does not change the ceiling: there are still no more connections than the node-wide line allows. Only what the client sees beyond the ceiling 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
await-slot <boolean>
Values
yes | no | true | false
Default
false § 3.3.17.1
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<smtp-listener>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <smtp-listener> and applies to connections on the address of one listener. There is no inheritance between listeners; the node-wide line sets the behavior where a listener has not specified its own.
⇄

Related directives

2 relations

Same name in other blocks

smtp-await-slotGlobalThe same decision for the whole node; the listener line overrides it on its own address. § 3.3.17.1

Applies to

smtp-listenerGlobalThe line applies to connections accepted on this listener’s address. § 3.3.17.1

How to check on the node
The setting is visible in the configuration; it shows itself only at the ceiling:
grep -n 'await-slot\|total-max-smtp-in\|smtp-listener' /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.
◇

What else to read

3 articles

◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇Headers the sender uses to control deliverySix control headers let the submitting side choose a stream, tag a message with a job, set signing options and the key, the envelope identifier and the schedule; each is allowed separately and per source.◇The load balancer header at the entranceThe node reads the PROXY header at the start of an incoming connection and treats the address from it as the source; this works for both kinds of entry point.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security · Connect a sending platform
Neighboring settings of the block <smtp-listener>:sourceuse-inbound-proxytls-certificateinbound-proxy-timeoutimmediate-tlsAll 18 directives of the block →