Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.3

total-max-smtp-in

Globalset by the Hub

The ceiling on inbound SMTP connections
in the configuration this is a linetotal-max-smtp-in 100inside the block Global
The ceiling on inbound connections

How many inbound SMTP connections the node serves at once — in total across all listeners and all sources.

What happens at the limit. A new connection either waits for a slot to free up or gets 421 and is closed — the choice is set by smtp-await-slot. Waiting looks to the submitter like a slow node, a refusal like an unavailable one.

The vendor advises against raising it. The default is a hundred connections, and the manual directly asks not to set more “in practice,” pointing to the limits of the machine and the operating system. The engine does not check an upper bound, though: any number can be written, and it will show up later, when there really are many connections.

The main trap. Submission from platforms and accepting bounces and complaints share one and the same ceiling. A submission spike can crowd out report acceptance, and telemetry will sag where nobody was looking. This is what slot reservation (reserved-smtp-in) per source group is for.
What the Hub does. It sets 1000 — ten times what the vendor recommends, and there is no calculation behind the number: the value is written into the configuration template as is, it was not derived either from the number of submitting platforms or from the machine’s capabilities. The Hub does not reserve slots for report acceptance at all — there is no reserved-smtp-in line in any configuration in the fleet.
Recommended values

Calculate from the submitters, not from the volume. The value depends on how many parallel sessions the platforms submitting mail to the node keep open, plus a margin for retries. Message volume has nothing to do with it: one connection carries hundreds of them.

Report acceptance shares the same margin. On a node that accepts bounces and complaints, inbound connections come not only from your own platforms. A submission spike can crowd out report acceptance — and what sags is exactly what nobody is guarding.

Ours is set to 1000. That is ten times the vendor recommendation and justified by nothing but a margin; the file descriptor count on the nodes was not calculated.

The 100 default and the advice not to exceed it are the vendor’s. The 1000 value is ours, and it was not calculated.
Example configuration
# the node ceiling — outside any blocks
total-max-smtp-in 1000smtp-listener 0/0:2525    # campaign submission
smtp-listener 0/0:25      # accepting complaints and bounces
Both listeners share the same ceiling — it counts connections for the node as a whole, not per smtp-listener line.
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▶

Treating the ceiling as per listener rather than per node

§ 3.3.1.3

What it costsThere can be several smtp-listener lines, but there is one ceiling for all. Campaign submission can take up the slots meant for accepting complaints and bounces.
How to spot itThe second listener starts answering with refusals although almost nothing is submitted to it — while the first is working at full capacity.
How to do it rightReserve slots for a source group rather than spreading the load across listeners: that does not affect the ceiling.

Raising the number without checking the machine's capabilities

§ 3.3.1.3

What it costsThe engine does not check an upper bound, and everything comes down to file descriptors and memory. A written thousand does not mean a thousand connections will be served.
How to spot itConnections stop being accepted with the ceiling not reached, and the log has operating system level errors.
How to do it rightCalculate from the number of submitting sessions and check it against the process file descriptor limit on the node.

Leaving no margin for accepting bounces and complaints

our experience

What it costsReports arrive at the same node and into the same ceiling. Connections crowded out by them are not retried forever: some bounces and complaints are lost for good, and with them the grounds for the blocklist.
How to spot itThe reports show a dip in bounces and complaints exactly during the hours of large mailings, while delivery during those hours is normal.
How to do it rightReserve slots for the source group through which reports arrive, and look at the top column, not only active.
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
total-max-smtp-in <number>
Values
a positive integer, the number of simultaneous connections; the default is 100, and the vendor advises not to exceed it
Default
100 § 3.3.1.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
There is no inheritance: it is a property of the instance as a whole. Below it are the source group limit (max-smtp-in in the <source-group> block) and its reserve (reserved-smtp-in); HTTP submission is counted separately, with its own ceiling (total-max-transmissions-api). It is picked up by pmta reload.
⇄

Related directives

2 relations

Works together with

smtp-await-slotGlobalThe ceiling at which it is decided whether a connection waits for a slot or gets a refusal. § 3.3.1.32

Often used with

Who is allowed to submit mail and for whom to accept itBoth are about acceptance: this ceiling decides how many connections the node can handle, relay control what they are allowed to do. inference

Referenced from

total-max-transmissions-apiGlobalThe same node-level ceiling for the second submission method — mail. § 3.3.1smtp-listenerGlobalThe ceiling on incoming connections that this listener accepts. inferencemax-smtp-in<source-group>Group ceilings work under the node’s overall limit: once the overall one is exhausted, the group one decides nothing. § 3.3.1.3reserved-smtp-in<source-group>The reserve is subtracted from the node’s overall limit and reduces what is left for everyone else. § 3.3.1.3

How to check on the node
The effective value and how close connections have come to it are printed by the node status:
pmta show status
The Connections section, the Inbound line: maximum is the ceiling, active how many are occupied now, top the record since the counters were last reset. The last column is what tells whether the margin was real. § 6.3.17
◇

What else to read

3 articles

◇How a message gets into the engineSix described submission methods: extended SMTP, four language bindings and a directory the node watches on disk.◇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.

In the Hub
Managed at
Configurations → Delivery limits
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
reversible: harms only while it is set
Scenarios
Connect a sending platform
Neighboring settings of the block Global:always-allow-relayingsmtp-listenerrelay-addresspickuprelay-debugAll 108 directives of the block →