Demo
Demo

Knowledge base

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

max-smtp-data-volume-rate

<virtual-mta-pool>

A byte ceiling that each pool address gets
in the configuration this is a linemax-smtp-data-volume-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 per group — but not shared by the group

The same byte ceiling as for a single address, written in a pool. The meaning of the setting is fully described on the max-smtp-data-volume-rate page of the <virtual-mta> block — the manual itself refers there, repeating only the value grammar and the example.

There is one difference between the blocks, and it is in the arithmetic. A pool does not divide the value among its members but passes it to each: the section on pools says of its directives that they “are inherited by the member addresses.” The line 6g/10h in a pool of five addresses means six gigabytes for each, that is, up to thirty from the pool.

Why a pool, then. For the sake of a single point of change: it is easier to change the quota of a group of twenty addresses with one line than with twenty. A value written in the address itself overrides the pool one — an exception for one member is made there.

The manual gives no default for the pool form. Without the line, whatever is inherited or set in the address itself applies; for an address it is unlimited.

The main trap. The ceiling looks group-wide but works per address — and changes by itself when the pool’s membership changes. Add a sixth address to five, and the group’s allowed volume grows by a fifth, even though no one touched the configuration. This line gives no real group boundary: there is no such boundary in the pool block at all.
What the Hub does. It does not write it. In the pool the Hub keeps only the member list — it puts neither limits nor signing keys there: the warm-up quota is calculated by the scheduler, and by its nature it is per address.

This is deliberate. A pool line would hand one number to all members at once, while warm-up leads each address along its own schedule: one is on its third day, another on its second month.

Recommended values

Set it when the group’s addresses have the same role. One quota for all is justified while the addresses are interchangeable. As soon as one of them gets its own schedule, the pool line starts getting in the way: it has to be overridden in the address itself, and the setting spreads across two places.

Count from the member, not from the group. Each one gets the written number. The intended group volume is divided by the number of addresses — keeping in mind that it will have to be divided again when the pool grows.

Not suitable for warm-up. Different addresses in a pool are almost always at different stages, and the line cannot tell them apart.

The interchangeability advice is ours. From the manual here come the value grammar, the reference to the address form and the rule of the pools section: directives are inherited by member addresses.
Example configuration
# each gets 6g/10h — from the pool that is up to 12g over the same ten hours
<virtual-mta mta1>
</virtual-mta>
<virtual-mta mta2>
</virtual-mta>
<virtual-mta-pool pool>
    max-smtp-data-volume-rate 6g/10h    virtual-mta mta1
    virtual-mta mta2
</virtual-mta-pool>
The example from the manual, with its own numbers. Twelve gigabytes from the pool, not six: each member gets the value as its own.
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▶

Dividing the group quota, treating the line as shared

§ 3.3.13

What it costsThe pool value goes to each member. The pool quota was written in full — and the actual ceiling turned out as many times larger as there are addresses in the pool.
How to spot itThe group’s total volume is a multiple of the number of members and never matches the intended one on any day.
How to do it rightDivide the intended volume by the number of addresses and keep in mind that the divisor changes when the pool grows.

Expecting the pool to even out its members

§ 3.3.13.8

What it costsThe pool sets the same ceiling for them, not a shared one. A fast address will use up its share and stop, a slow one will not use up its own — nothing flows between them.
How to spot itSome addresses in the group hit the ceiling, others sit idle, and the total volume is below the allowed one.
How to do it rightEven out the load by distributing messages across addresses, not with a ceiling. The line sets a boundary for each, it does not share out among them.

Setting the line both in the pool and in the address, expecting a sum

§ 3.3.13

What it costsThe address value overrides the pool one entirely rather than adding to it. The pool line stays in the file and reads as effective, even though it does not work for this member.
How to spot itOne of the addresses has a number other than the one written in the pool, and it cannot be found in the pool block.
How to do it rightCheck the effective value on the member itself with the address settings command. Leave exceptions only where they are needed, and mark them with a comment.
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-data-volume-rate <see-reference>
Values
unlimited · 0 · N with a unit b|k|m|g|t and a denominator /[X] and d|h|m|s — the grammar is shared with the address form
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
Members get the pool value as their own; a value set in the address itself overrides the pool one. Below are the receiver blocks inside the address, but there the directive has a different name (max-data-volume-rate) and limits a queue, not an address. It is picked up by pmta reload.
⇄

Related directives

3 relations

Depends on

Three pool rules the manual states directlyWhat the pool does with the directive — the arithmetic of the number depends on it. § 3.3.13

Same name in other blocks

max-smtp-data-volume-rate<virtual-mta>The same setting in the address itself, where its mechanism is explained. § 3.3.12.3

Applies to

A group of sending addresses with traffic sharesOne of the settings a pool carries for its members. § 3.3.13.8

How to check on the node
A pool has no command of its own — the effective value is checked on a member, which also confirms that it reached the member:
pmta show vmta-settings mta1
pmta show vmta-settings mta2
Both print max-smtp-data-volume-rate — and both will show the same number if it came from the pool. A mismatch means one of the addresses has its own line overriding the pool one.
◇

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-msg-ratemax-smtp-outsuppression-listsAll 9 directives of the block →