Demo
Demo

Knowledge base

PMTA knowledge base›Block <virtual-mta-pool>›Directive§ 3.3.13.5

max-smtp-msg-rate

<virtual-mta-pool>

The sending rate each address in the pool gets
in the configuration this is a linemax-smtp-msg-rateinside the block <virtual-mta-pool>
The same name 1:<virtual-mta><virtual-mta-pool>— some of them are other settings, some are the same one
One line for the group — but each gets the full value

What the directive does is described on its main page: it is a ceiling on attempts per interval for the whole sending address. Here is only what changes when it is written in a pool.

The pool hands the value out rather than dividing it. The manual lists the directives a pool passes down and calls this inheritance: members get the value as their own. 100/m in a pool of five addresses means a hundred for each, that is, up to five hundred a minute from the pool. There is no “common group budget” here.

Why write it here, then. For one line instead of five identical ones, and so that an address added to the pool immediately gets the same policy instead of being left without a limit. This is a convenience of notation, not a separate level of limitation.

What overrides what. A value written in the address itself cancels the pool one — entirely, not partially. So the pool sets the rule for those members that have no value of their own, and says nothing about the rest.

The main trap. The group’s total rate changes with its membership, even though the configuration stays the same. Add a sixth address to the pool and a sixth more messages come out of the pool, without a single line being edited. If you need a limit for the group as such, this directive does not provide one: divide the intended rate by the number of members yourself and recalculate on every membership change.
What the Hub does. In a pool it writes nothing but the member list — neither this directive nor its neighbors. The reason is the same one for which it does not write it for an address either: during warm-up the daily volume is kept by its own scheduler, which can stop on the spam rate and swap in an address from the reserve pool. A line common to the whole group would only get in the way: in the fleet an address under warm-up and an established one stand side by side, and the same rate does not suit both.
Recommended values

First divide by the number of members. The group’s intended rate is divided by the number of addresses in the pool — and only the result goes here. A pool of four addresses, fifteen hundred messages an hour from the group: 375/h, not 1500/h.

A pool of different addresses is a bad place for this line. If an address under warm-up and an established one stand side by side, a common value will either choke the second or overload the first. Then it is more honest to set the limit for each separately and leave the pool for traffic distribution.

The pool entry has no default. The manual does not name one: without the line in the pool, members live with their own values, and those without their own have no limit.

The division rule and the caveat about a mixed pool are our recommendation. From the manual here come the fact that pool directives are inherited by members, and the value grammar.
Example configuration
# one line instead of two identical ones — but each gets the full value
<virtual-mta mta1>
</virtual-mta>

<virtual-mta mta2>
</virtual-mta>

<virtual-mta-pool pool>
    max-smtp-msg-rate 100/m    virtual-mta mta1
    virtual-mta mta2
</virtual-mta-pool>
The manual’s example, our comment. Both addresses will get 100 messages a minute each — two hundred from the pool, not one hundred.
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▶

Reading the line as a budget for the whole group

§ 3.3.13

What it costsThe pool does not divide the value but hands it out: 100/m in a pool of five addresses means five hundred messages a minute, not a hundred. The calculation diverges from reality by exactly as many times as there are addresses in the pool.
How to spot itThe actual rate from the group is a multiple of the number of members and changes when an address is added, even though nobody touched the configuration.
How to do it rightDivide the group’s intended rate by the number of addresses and write the result. Recalculate on every membership change — otherwise the line quietly stops meaning what was intended.

Setting a common rate for a mixed pool

§ 3.3.13

What it costsAn address under warm-up and an established one sit in the same pool. A value safe for the second is an overload for the first; a value suitable for the first chokes the second. A common line picks which one to spoil.
How to spot itThe young address’s bounce rate grows while the mature one’s queue builds up — at the same time and from the same line in the configuration.
How to do it rightSet the limit for each address separately and leave the pool for traffic distribution. A pool line is good where the members are uniform.

Editing the pool while the value does not change

our experience

What it costsThe address has its own value, and it overrides the pool one entirely. The edit in the pool goes through without errors, the configuration looks applied, but the behavior stays the same.
How to spot itpmta show vmta-settings prints something other than what is written in the pool for the member.
How to do it rightCheck the effective value on the member instead of reading the configuration. Remove the line from the address if you want to manage it from the pool.
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-msg-rate <see-reference>
Values
as in the definition: unlimited · 0 · N/[M] with a unit d|day|h|hr|m|min|s|sec
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<virtual-mta-pool>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The pool passes the value to each member as its own; a value written in the <virtual-mta> block cancels the pool one. Above the pool there is nothing to inherit from: the directive is not described at the node level. It is picked up by pmta reload; a service restart is not needed.
⇄

Related directives

2 relations

Same name in other blocks

max-smtp-msg-rate<virtual-mta>The directive’s definition: what it does and how it is counted is there. Here is only what writing it at the group level changes. § 3.3.12.2

Applies to

A group of sending addresses with traffic sharesOne of the settings a pool passes to its members. § 3.3.13.5

How to check on the node
Look not at the pool but at a member: the command prints the value already after merging, and it immediately shows whether the address got it from the pool or has its own.
pmta show vmta-settings mta1
pmta show vmta-settings mta2
If both commands show the same value, it came from the pool, and the group’s total rate is twice what is printed. If they differ, the address has its own, and the pool value did not reach it. The Hub does not collect pool settings: monitoring shows the per-address summary, but not the effective limits.
◇

What else to read

3 articles

◇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.◇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.◇Warm-up built into the engineA warmed-up address hands the first N messages of the day for each receiver to its cold partner; the partner sends them itself and builds history.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Sending address rotation
Neighboring settings of the block <virtual-mta-pool>:virtual-mtadomain-keymax-smtp-outsuppression-listsinclude-headers-fromAll 9 directives of the block →