Global
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.
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.
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.
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 limit is per sending address, not per node mx-connection-limit *.protection.outlook.com 5mx-connection-limit mx.example.net 2
what people get wrong and how it ends3 mistakes▶
§ 3.3.1.60.1
§ 3.3.1.60.1
§ 3.3.1.60.1
3 relations
grep -n 'mx-connection-limit\|ip-connection-limit\|auto-mx-rollup' /etc/pmta/config pmta show queues --connected=yes --maxitems=20
3 articles
◇Four value types the whole config is written inBoolean, domain pattern, regular expression and time interval — defined once in § 3.2 and then used by all directives.◇How the policy for a receiver is assembledSettings are assembled from the most general pattern to the most precise; the order of blocks in the file means nothing.◇Backoff mode — the queue's second personalityA queue that a receiver has started refusing switches to a parallel set of limits, retries and routes — ten directives that act only in this mode.