Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.57.3

dummy-smtp-await-slot

Global

What to do when there are no slots for a new fake connection
in the configuration this is a linedummy-smtp-await-slot falseinside the block Global
Refuse at once or wait

A fake receiver, like a real one, has a finite number of connection slots. This line decides what to do with a new connection when all slots are taken.

The false default — refuse at once. The receiver replies 421 in the greeting — “service not available” — and closes the connection.

true — wait for a slot to free up. The connection hangs until a slot appears.

The choice changes what you measure. With refusal you see the node’s ceiling as refusals: so many connections per second beyond what is possible. With waiting — as growing latency: connections are established, but ever more slowly.

The main trap is that 421 changes the behavior of the sending itself. This code is handled by the sending side, and if it has smtp-421-means-mx-unavailable enabled, it will drop the connection and move to the next MX record. In a load run this means part of the flow bypasses the fake receiver, and the figure comes out understated.
What the Hub does. It does not write it: the mechanism is not brought up on the nodes. For measuring the ceiling, waiting is the right choice: it gives a latency curve rather than a cutoff — and does not touch 421 handling on the sending side.
Recommended values

For measuring the ceiling — waiting. A latency curve says more about the headroom than a number of refusals.

For testing behavior under overload — refusal. The default reproduces a receiver that closes up under load: that is how you check how your side behaves.

Remember 421 on your side. With refusal the sending behavior depends on smtp-421-means-mx-unavailable, and so does the result of the run.

The split “measuring the ceiling versus testing overload” is ours. From the manual come the false default and the exact behavior with it: a 421 reply in the greeting and closing the connection.
Example configuration
# measuring the ceiling: let connections wait rather than drop
dummy-smtp-ip 127.0.0.1
dummy-smtp-port 2525
dummy-smtp-await-slot true
With the default, instead of growing latency you would get a stream of 421 replies — and part of the sending would go looking for another server instead of hitting 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▶

Measuring the ceiling with the default

our experience

What it costsThe receiver replies 421, the sending side may move to another MX record, and part of the flow bypasses the measurement. The figure comes out understated, and the run looks successful.
How to spot itThe run log has many 421 replies, and the measured ceiling is lower than expected.
How to do it rightEnable waiting — the ceiling will show up as growing latency.

Considering waiting safe by definition

our experience

What it costsConnections pile up instead of dropping. In a long run this hits no longer the fake receiver but the machine’s own limits on the number of open sockets.
How to spot itThe run hits system-level errors rather than the node’s behavior.
How to do it rightLimit the load on the sending side rather than rely on the receiver accepting it.
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
dummy-smtp-await-slot <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.1.57.3
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
A node-level line: it is written at the root of the file, not inside a block. It has no inheritance. It is picked up by pmta reload; it does not affect connections already established.
⇄

Related directives

1 relation

Applies to

A fake receiver inside the node itselfOne of the eight lines configuring the fake receiver: this one is responsible for behavior when slots run out. § 3.3.1.57.3

Referenced from

smtp-await-slotGlobalThe same decision for the dummy listener used in testing. § 3.3.1.57.3

How to check on the node
Which behavior applies is visible from the receiver’s replies themselves under load:
grep -n dummy-smtp-await-slot /etc/pmta/config
grep -c '421' /var/log/pmta/pmta.log
A stream of 421 replies in the log during a load run means the default applies. The Hub does not use this mechanism.
◇

What else to read

3 articles

◇The activation key is a prerequisite for installation, not a step after itWithout an activation key from SparkPost support the engine neither installs nor runs, and the license tier sets the outbound connection ceiling: on Standard everything above 200 is ignored.◇Cloud restrictionsClouds restrict outbound mail on port 25 until you ask them to lift the limit, and mailbox providers treat their address ranges with suspicion.◇How to turn a sending plan into hardwareTwo constants for sizing any node: about 2 KB of memory per queued recipient and spool space proportional to the total size of the messages.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Capacity planning
Neighboring settings of the block Global:log-filelog-auto-rotationlog-rotatedummy-smtp-ipdummy-smtp-latencyAll 108 directives of the block →