Demo
Demo

Knowledge base

PMTA knowledge base›Block <source-group>›Directive§ 3.3.9.1

max-smtp-in

<source-group>

A ceiling on simultaneous inbound connections from a group
in the configuration this is a linemax-smtp-in unlimitedinside the block <source-group>
A ceiling for the group, not for an address

The default is unlimited. The line limits the number of simultaneous inbound connections from all sources of the group together.

It is a ceiling, not a guarantee: it says “no more than,” while “no less than” is said by the neighboring line — reserved-smtp-in. Both are needed where several parties share the node: one gets a ceiling so it does not eat everything, the other a reserve so that something is always left for it.

The group ceiling works under the node’s overall ceiling total-max-smtp-in: if the overall one is exhausted, the group one will no longer change anything.

The main trap is that the sum of ceilings does not have to match the overall one. Nothing prevents giving three groups 500 connections each with an overall node ceiling of 1000. The configuration is valid, yet the behavior is not what was intended: two groups together will use up the overall limit, and the third will get nothing, even though its own ceiling is untouched.

Check the arithmetic, not the lines: the engine does not check it.

What the Hub does. It does not write it: there are no source groups in its configuration. The limit on inbound connections is set once per node — total-max-smtp-in 1000 in the base configuration.

For a fleet node this is enough: there is one submitting party, and nothing to divide between parties. Groups would be needed on a node used by several clients.

Recommended values

What to set. The value is calculated from the node’s overall ceiling, not from the group’s needs:

Value When
unlimited (default) there is one submitting party, nothing to divide
a share of the overall ceiling several parties, and none of them should take everything
a small number a party that does not need many connections but can grab them

It is useful to keep the sum of ceilings above the overall one — otherwise part of the node sits idle — but not many times above: otherwise the ceilings stop meaning anything.

The unlimited default and the purpose come from the manual, § 3.3.9.1. Subordination to the node’s overall ceiling comes from the link to it. The advice about the sum of ceilings is ours.
Example configuration
# a ceiling and a reserve work as a pair: one says “no more than,” the other “no less than”
<source-group localSources>
    max-smtp-in 10    reserved-smtp-in 5
</source-group>
The group will not take more than ten connections at once, and five of them are guaranteed to it even when the node is busy with others.
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▶

Handing out ceilings without checking the node's overall limit

our experience

What it costsThe sum of ceilings can exceed the overall limit many times over. Then the ceilings stop dividing the node: whoever took the connections first keeps them, and the rest get what is left.
How to spot itThe group has spare room under its ceiling, but new connections still do not get through.
How to do it rightDo the arithmetic by hand and back the ceilings with a reserve for the groups that need slots guaranteed.

Taking the ceiling for a guarantee

§ 3.3.9.1

What it costsA ceiling says only “no more than.” A group with a ceiling of ten connections may not get a single one if the node is busy with others.
How to spot itA ceiling is set, but the group’s connections still do not get through.
How to do it rightAdd a reserve: only it gives a guarantee.
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
max-smtp-in <integer>
Values
unlimited or an integer number of connections
Default
unlimited § 3.3.9.1
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<source-group>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <source-group> and applies to one group. There is no inheritance between groups: group blocks do not merge the way sources do. But the line works under the node’s overall ceiling — that one is stronger.
⇄

Related directives

2 relations

Depends on

total-max-smtp-inGlobalGroup ceilings work under the node’s overall limit: once the overall one is exhausted, the group one decides nothing. § 3.3.1.3

Works together with

reserved-smtp-in<source-group>One says “no more than,” the other “no less than”; together they divide the node between parties. § 3.3.9.2

Referenced from

source-group<source>The group’s overall connection ceiling; it is set in the group block, not here. § 3.3.9.1

How to check on the node
The written limits are visible in the configuration, the occupied connections on the node:
grep -n -A3 '^<source-group' /etc/pmta/config
pmta show status | grep -i 'inbound\|smtp-in'
It is worth comparing the sum of group ceilings with the node’s overall ceiling: the engine does not check that they are consistent, and a mismatch shows up only under load.
◇

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
Cost of a mistake
reversible: harms only while it is set
Scenarios
Connect a sending platform
Neighboring settings of the block <source-group>:reserved-smtp-inAll 2 directives of the block →