Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.52

auto-mx-rollup

Global

Whether to roll up domains with the same set of lowest-priority MX records automatically
in the configuration this is a lineauto-mx-rollup not enabledinside the block Global
Rollup without a list — the node groups by itself

The second way to roll domains up into one queue. The first is the <mx-rollup-list> block, where you list MX records by hand. This one is a single line: the node itself combines domains whose set of lowest-priority MX records matches by name. By name, not by address: two gateways with different names pointing to the same address will be considered different by the node.

The list takes precedence. Automatic rollup is considered only where no match was found in <mx-rollup-list>.

The node makes up the queue name itself — from the set of MX records. Two gateways mx1.foo.com and mx2.foo.com give the queue qn.mx1.foo.com.mx2.arollup. A name longer than about 160 characters is shortened, and when names collide a number is added to qn. The created queue survives a restart.

The main trap is whose settings the queue gets. If no <domain> block other than the asterisk matches the made-up name, and one of the rolled-up domains has settings, the node will take those — and if several match, the first encountered in the file. That is, the rate of the shared queue will be set by one arbitrary domain from the group, chosen by the order of lines in the configuration.
What the Hub does. It does not write it. Made-up queue names break everything the Hub builds around the “receiver + sending address” pair: the name changes when a provider changes its MX, and telemetry for it breaks off. The Hub groups providers on its own side and leaves the queues on the node per-domain.
Recommended values

There is one value. The line either exists with the word by-name or it does not: it has no other kinds of rollup.

Enable it together with a settings block. Right after enabling it, create a <domain> for the expected queue names, otherwise they will get settings from a random domain of the group.

Do not combine it with manual per-domain warm-up. The daily warm-up quota is taken from the rolled-up queue, not from individual domains — a schedule written per domain will stop working.

The advice to create a settings block along with enabling it is ours. From the manual here are the only allowed value, the precedence of the manual list, the queue naming rule and the fact that the queue survives a restart.
Example configuration
# rollup by matching MX names
auto-mx-rollup by-name
# and right away — settings for the made-up names,
# otherwise they will go to the first matching domain of the group
<domain *.arollup>
    max-smtp-out 20
    max-msg-rate 300/h
</domain>
The line is written at the root of the file; it has no block. The *.arollup name catches all automatically created queues at once — the exact names are not known in advance.
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▶

Enabling it without creating a settings block for the new names

§ 3.3.1.52

What it costsThe rolled-up queue’s settings come from the first matching domain of the group — by the order of lines in the configuration. The rate of the shared queue turns out to be random.
How to spot itThe .arollup queue runs at the rate you set for one specific domain.
How to do it rightCreate a <domain> with the *.arollup pattern and set the required limits explicitly.

Expecting rollup to survive a provider's MX change

§ 3.3.1.52

What it costsGrouping is by MX names. The provider changed them — the domain drops out of its rolled-up queue and starts a new one with a new name. The history under the old name breaks off.
How to spot itA new .arollup name has appeared in the list of queues, and the old one is empty.
How to do it rightWhere a stable name is needed, use the manual list or queue-to: they set the name rather than derive it.
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
auto-mx-rollup by-name
Values
the only value is by-name; without the line rollup is off
Default
not enabled § 3.3.1.52
Applying
reload, no restart needed
Queue
also affects what is already in the queue
Where to write it
Global
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
A node-level line: written at the root of the file, not inside a block, and applies to the whole node. Rollup can be canceled for a specific receiver only on its side — with a disable-mx-rollup line in its <domain> block. It is picked up by pmta reload; rolled-up queues already created do not disappear — they survive a restart too.
⇄

Related directives

3 relations

Can be replaced by

mx-connection-limitGlobalThe manual calls rollup a more correct way to achieve the same — a limit at the gateway level, not the domain level. § 3.3.1.60.1

Affects

proxy-include-tlvGlobalRollup is one of the two reasons why a queue’s domain does not match the recipient’s domain. § 3.3.1.49

Applies to

Different domains in one queue, because the gateway is the sameThe mechanism as a whole, together with the manual list. The manual list takes precedence: automatic rollup is considered after it. § 3.3.1.52

Referenced from

How the policy for a receiver is assembledRolling up domains by shared MX changes which queue a receiver belongs to — and therefore which policy applies to it. § 3.3.1.52Warm-up built into the engineWith MX rollup the quota is taken from the rolled-up queue, and per-domain numbers stop applying. § 3.3.10.57queue-to<domain>Automatic combining by matching MX: it does not need a list of domains, but it also comes up with the queue name by itself. § 3.3.10.39max-cold-virtual-mta-msg<domain>With MX rollup the value of the rolled-up queue is used — and less than configured may go through cold addresses. § 3.3.10.57disable-mx-rollup<domain>The automatic combining this line cancels for one recipient. § 3.3.10.103

How to check on the node
Automatically created queues are recognized by name: they end in .arollup, not .rollup:
pmta show queues | grep -i arollup
grep -n auto-mx-rollup /etc/pmta/config
The one-letter difference matters: .rollup is a queue from the manual list, .arollup one made up by the node. The Hub creates neither.
◇

What else to read

3 articles

◇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.◇Reputation monitoring inside the nodeThe engine itself watches the receiving servers’ replies and changes the queue mode on a pattern match — a reaction within the connection, not through telemetry.

In the Hub
Cost of a mistake
disruptive: applying it interrupts the node
Scenarios
Troubleshoot deliverability · Tune the pace for a provider
Neighboring settings of the block Global:aliassmtp-proxy-source-hosthost-namepostmasterdomain-keyAll 108 directives of the block →