Demo
Demo

Knowledge base

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

max-smtp-data-volume-rate

<virtual-mta>

How many bytes per interval are allowed from this whole address
in the configuration this is a linemax-smtp-data-volume-rate unlimitedinside the block <virtual-mta>
The same name 1:<virtual-mta><virtual-mta-pool>— some of them are other settings, some are the same one
A ceiling in bytes for the whole sending address

How much data the sending address will transfer per interval — in total, across all receivers at once. The other limits in the family count messages and recipients; this one counts bytes and therefore behaves differently: the same thousand messages will use it up differently if the messages differ in size.

Only what is delivered counts. The manual says so directly: the volume of successful deliveries is counted toward the limit. Bounces, retries and broken transfers bypass the counter, so the actual outgoing traffic from the node can be noticeably higher than what is allowed here.

The volume unit is written right in the value. b — bytes, k — kilobytes, m — megabytes, g — gigabytes, t — terabytes; without a suffix the number is taken as bytes. The denominator is d, h, m, s with an optional multiplier: 6g/10h is six gigabytes per ten hours.

It counts the address as a whole, not a queue. The neighbor in meaning max-data-volume-rate lives in the receiver block and limits one queue: with ten receivers it allows ten times what is written. There is no multiplication here — as much as is specified is what leaves the whole address.

The main trap. The sending plan lives in messages, while this limit lives in bytes, and converting one into the other has to go through the average message size, which changes. A plan of ten thousand messages with an average size of sixty kilobytes is six hundred megabytes; add an image, the average size becomes a hundred and twenty, and the same plan hits the limit halfway. There will be neither a refusal nor a bounce: sending will simply stretch out, and the number of messages will not tell you why it does not fit into the window.
What the Hub does. It does not write it — neither in the address nor in the pool; the vendor’s unlimited remains.

The Hub holds the daily warm-up quota with its scheduler and counts it in messages, not in bytes: the plan knows how many messages to hand over today, can stop on the spam share and swap in an address from the reserve pool. A byte ceiling cannot do that — it will simply hold back the transfer without telling the plan anything. So the quota lives upstairs, and the engine gets the queue rate — max-msg-rate in the <domain> block inside the address.

Recommended values

Set it when the bottleneck is the channel, not the receiver. A byte ceiling fits where the node shares the bandwidth with something else or where the provider meters traffic. For deliverability it is almost useless: receivers look at messages and complaints, not at megabytes.

Recalculate it when templates change. The value is tied to the average message size, and a layout edit changes that size silently. It is wiser to take a margin of one and a half to two times the calculated volume than to fit the number tightly.

Do not confuse it with a daily quota. Bytes per hour do not replace a plan of “so many messages a day”: the limit stretches sending out, but it does not know how many messages are left and will not stop a mailing if the receiver has started complaining.

About 0. The syntax allows it as a separate value, but the manual does not explain what it does. By the grammar it is zero volume, that is, sending from the address stops; check it on a test bench.

The calculation order and the margin advice are ours. From the manual here come the value grammar with units, the unlimited default and the fact that only the volume of successful deliveries counts.
Example configuration
# two ceilings of one address: one in messages, the other in bytes
<virtual-mta mta-news-1>
    smtp-source-host 1.2.3.4 news1.example.com
    max-smtp-msg-rate 3000/h
    max-smtp-data-volume-rate 6g/10h</virtual-mta>
Whichever is reached first applies. With an average message of sixty kilobytes, three thousand messages an hour is about a hundred and eighty megabytes, so sending will hit the upper line. Make the message four times heavier, and the lower one becomes the bottleneck.
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▶

Converting the daily plan into bytes once

§ 3.3.12.3

What it costsThe value stays tied to the average message size on the day of the calculation. The template gets heavier — and the same plan no longer fits into the interval, even though neither the plan nor the configuration changed.
How to spot itSending does not fit into the window, the number of messages is the same, and there are no refusals from receivers.
How to do it rightTake a margin over the calculated volume and recalculate it when the layout changes. Keep the quota in messages where it belongs — in the plan, not in the byte ceiling.

Believing that the limit caps the node's traffic

§ 3.3.12.3

What it costsOnly the volume of successful deliveries counts. Retries, broken transfers and everything that bounced are invisible to the limit — the actual outgoing traffic ends up above the allowed amount, sometimes noticeably.
How to spot itThe provider shows a volume above the set ceiling, and the gap grows with the share of failures.
How to do it rightLimit the channel with the node’s own means, not with this line. It is about what was delivered, not what was transferred.

Setting the ceiling in the pool and treating it as shared

§ 3.3.13

What it costsA pool hands the value to each member rather than dividing it among them. A pool of five addresses at 6g/10h lets out up to thirty gigabytes, and adding a sixth address raises the ceiling to thirty-six, even though no one touched the configuration.
How to spot itThe total volume from the group of addresses is a multiple of the number of members and grows each time the group is expanded.
How to do it rightDivide the intended group volume by the number of addresses, or set the ceiling for each address separately.
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 <rate>
Values
unlimited · 0 · N with a unit b|k|m|g|t and a denominator /[X] and d|h|m|s — for example 6g/10h or 12M/m
Default
unlimited § 3.3.12.3
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<virtual-mta>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The address’s own ceiling overrides the pool one, and the pool one overrides the one set above. A pool hands the value to each member as its own rather than dividing it among them: 6g/10h in a pool of five addresses is thirty gigabytes from the pool. It is picked up by pmta reload, no service restart needed.
⇄

Related directives

4 relations

Same name in other blocks

max-data-volume-rate<domain>The same volume at the queue level — and the value grammar is described there. § 3.3.12.3

Works together with

max-smtp-msg-rate<virtual-mta>The same address ceiling, only in messages. § 3.3.12.2

Applies to

The sending address — what it is made ofOne of the settings that make up a sending address. § 3.3.12.3Four ways to say “slower”The same rate mechanism, but counting bytes rather than messages. § 3.3.12.3

Referenced from

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

How to check on the node
The effective value — already merged with the pool — is printed by the address settings command:
pmta show vmta-settings mta-news-1
The max-smtp-data-volume-rate line appears there next to max-smtp-msg-rate and max-smtp-out — the three ceilings of one address are visible at once. The queue settings (pmta show settings) do not have this line: it belongs to the address, not to the queue.
◇

What else to read

3 articles

◇Four ways to say “slower”Messages, data volume, connection rate and number of connections — each has its own limit, and each has a “per source address” variant and a backoff mode twin.◇A queue is a receiving server together with a sending addressThe engine groups messages by the “recipient domain plus sending address” pair: one domain from two addresses is two independent queues with their own counters, connections and mode.◇Three pool rules the manual states directlyRotation-based distribution, inheritance of settings by members with the member’s own values overriding, and a namespace shared with sending addresses.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Address warm-up · Tune the pace for a provider
Neighboring settings of the block <virtual-mta>:max-smtp-outmax-smtp-msg-ratehost-namedomain-keysmtp-source-hostAll 15 directives of the block →