Knowledge base

reserved-smtp-in

<source-group>

How many inbound connections are guaranteed to this group
in the configuration this is a linereserved-smtp-in unlimitedinside the block <source-group>
A guarantee, not a ceiling

The line reserves a certain number of inbound connections for a source group. This is “no fewer than” — unlike the neighboring max-smtp-in, which says “no more than.”

The reserve is subtracted from the node’s overall limit total-max-smtp-in: slots given to the group cease to exist for everyone else — even while the group is not using them.

The point is not to let the busy side crowd out the rare but important one. The classic case: receiving complaints and reports, of which there is little but which must not be missed, next to submission, of which there is a lot.

The default in the manual looks like a typo. For a directive that reserves a number of slots, it says unlimited — the same value as the neighboring ceiling. You cannot reserve “unlimited,” so it should be read as “no reserve,” not as “an infinite reserve.” It looks like a line copied from the neighboring section.

The second half of the trap is real: the reserve is taken away from everyone else at once. A sum of reserves close to the node’s overall limit leaves almost nothing to the sides without a reserve — and the node starts refusing connections even though half the slots are idle.

What the Hub does. It does not write it: there are no source groups in its configuration, and there is nothing to reserve — the inbound limit is set once for the node.

Meanwhile we do have a case for a reserve: a node simultaneously accepts submission and inbound mail — complaints, asynchronous bounces and role addresses. There is little of the latter, but losing it is worse than delaying submission.

Recommended values

What to set. The reserve is calculated from how many connections the group needs at the worst moment, not on average:

Value When
do not write it there is no one to divide the node between
5–10 receiving complaints and reports: few connections, but they must not be lost
a noticeable share of the total the side the node was set up for

Keep the sum of reserves well below the node’s overall limit: everything reserved does not exist for the others, even while idle.

The purpose comes from the manual, § 3.3.9.2. The default is given there as unlimited, which makes no sense for a reserve; we read it as “no reserve” — that reading is ours. The breakdown of values is ours.
Example configuration
# five slots from the node's overall limit always go to the group
<source-group localSources>
    max-smtp-in 10
    reserved-smtp-in 5</source-group>
The group will not take more than ten connections at once, but it will get five under any node load. These five do not exist for the others, even when the group is idle.
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▶

Reserving almost the entire overall limit

our experience

What it costsThe sides without a reserve are left with a handful of slots, and the node starts refusing connections while half of the reserved ones are idle.
How to spot itConnection refusals at a low actual load.
How to do it rightKeep the sum of reserves well below the overall limit and reserve only for those who must not be crowded out.

Reading the default literally

§ 3.3.9.2

What it costsThe unlimited given in the manual makes no sense for a reserve: you cannot reserve an unlimited number of slots. Read literally, it suggests that a reserve already exists — whereas there is none.
How to spot itThere is no reserve line, yet a slot guarantee is being counted on.
How to do it rightAssume that without the line there is no reserve, and set the number explicitly.

Reserving for a group with no members

§ 3.3.7.55

What it costsThe slots are subtracted from the node’s overall limit and go to no one: the group is declared, but no source has named it as its own. The node loses part of its capacity for nothing.
How to spot itThe overall limit seems to have shrunk, while the group is not used.
How to do it rightCheck that the group’s members name it with the group line in their source blocks.
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
reserved-smtp-in <integer>
Values
an integer number of connections
Default
unlimited § 3.3.9.2
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. But the reserve is subtracted from the node’s overall limit — that is, it affects not only its own group but all the others at once.
How to check on the node
Reserves are visible in the configuration; you will have to check their consistency with the overall limit yourself:
grep -n -A3 '^<source-group' /etc/pmta/config
grep -n 'total-max-smtp-in' /etc/pmta/config
The sum of reserves must be noticeably less than the overall limit: the remainder is all that the sides without a reserve will get. The engine does not check this.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Connect a sending platform · Sender isolation