Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.60.1

mx-connection-limit

Global

A limit on simultaneous connections to one matching MX
in the configuration this is a linemx-connection-limitinside the block Global
A line the vendor advises against using

The manual opens the section with a bold warning: rolling queues up by MX is a better way to manage at the MX level than this directive.

What it does: it limits the number of simultaneous connections to an MX matching a pattern. The pattern is written by the same rules as names in recipient blocks — an asterisk works too.

Then come three caveats, each of which changes the meaning:

The limit is counted for each sending address separately — not for the node and not for the stream. Ten sending addresses with a limit of five give fifty connections to one MX.

With an asterisk pattern the limit applies to each matching MX, not to all of them together.

The match is against the MX, not the recipient domain. That is the point of the line: a receiver serves hundreds of domains through a few MX hosts, and it is them that need limiting.

The line is repeated — one line per rule.

The main trap is that the limit is not what it seems. The number in the line is connections from one sending address. A node with twenty addresses and a limit of five opens up to a hundred connections to one MX, and the receiver sees exactly a hundred.

Hence the vendor’s advice: rolling queues up by MX works differently — it merges domains into one queue, and the queue limits apply to everything that ends up in it rather than being multiplied by the number of addresses.

The other half: with an asterisk the limit multiplies across each matching MX. The rule *.example.com with a limit of five and ten matching MX hosts is fifty connections, not five.

What the Hub does. It does not write it — and rightly so: it sets connection limits where the receiver counts them — in recipient rules and on sending addresses, through max-smtp-out.

The MX rollup of queues that the vendor recommends instead of this line is not enabled by the Hub either: auto-mx-rollup stays at its default.

Recommended values

What to set. Before the value, decide whether the line is needed at all:

Value When
do not write it the usual case: limits are set on recipients and sending addresses
a number with an exact MX name a known receiver complains about the number of connections, and you do not want to enable queue rollup
a number with a pattern the same case, but the receiver has several MX hosts — keeping in mind that the limit will multiply

Count it multiplied by the number of sending addresses: that is exactly how many connections the receiver will see.

The advice to prefer queue rollup, counting for each sending address separately, the multiplication of the limit across matching MX hosts and matching against the MX rather than the recipient domain come from the manual, § 3.3.1.60.1. The breakdown of cases is ours.
Example configuration
# the limit is per sending address, not per node
mx-connection-limit *.protection.outlook.com 5mx-connection-limit mx.example.net 2
With an asterisk the limit applies to each matching MX separately. Multiply by the number of sending addresses — that is how many connections the receiver will see.
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 limit as a node-wide total

§ 3.3.1.60.1

What it costsThe number in the line is connections from one sending address. A node with twenty addresses opens twenty times more connections to one MX than written, and the receiver sees exactly that number.
How to spot itThe receiver complains about the number of connections, even though the limit looks modest.
How to do it rightDivide the desired number by the number of sending addresses — or switch to rolling queues up by MX.

Writing a pattern and expecting a shared limit

§ 3.3.1.60.1

What it costsWith an asterisk the limit applies to each matching MX separately, not to all of them together. Ten matching MX hosts give ten times the connections.
How to spot itThere are many times more connections to the receiver than the written limit.
How to do it rightCount the matching MX hosts or list them by exact names.

Writing the recipient domain in the pattern

§ 3.3.1.60.1

What it costsThe match is against the MX name, not the recipient domain. The rule does not fire, and the limit does not apply — silently.
How to spot itThe line is there, the number of connections does not change.
How to do it rightLook up which MX hosts the domain actually has, and write the pattern from them.
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
mx-connection-limit MX-NAME N
Values
an MX name pattern and an integer number of connections; the line can be repeated
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
Global
How many times
may be repeated
Everything here comes from the manual, with the section.
Inheritance
The directive is written at the root of the configuration file and applies to the whole node, but it is counted for each sending address separately. This is not inheritance but multiplication: one line gives as many limits as the node has sending addresses.
How to check on the node
The rules are visible in the configuration, the actual connections in the queue state:
grep -n 'mx-connection-limit\|ip-connection-limit\|auto-mx-rollup' /etc/pmta/config
pmta show queues --connected=yes --maxitems=20
It is worth comparing the number of connections in the queues with the limit multiplied by the number of sending addresses. If it matches a single limit, the rule did not match the MX name.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Tune the pace for a provider