Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.94

source-ip-max-data-volume-rate

<domain>

How many bytes per interval are allowed from one outgoing address
in the configuration this is a linesource-ip-max-data-volume-rate unlimitedinside the block <domain>
A limit by volume, not by number of messages

How much data may be transferred to this recipient per interval from a given sending address. It is useful where messages differ in weight: a thousand messages of ten kilobytes and a thousand of a megabyte are completely different loads on the receiver, and a limit on the number of messages does not see that difference.

It counts what was delivered, not attempts. This is the only directive in the family with such a count: the manual says the volume of successful deliveries goes toward the limit. Bounces and retries do not use up the volume — unlike source-ip-max-msg-rate, where an attempt counts on a par with a delivery.

The mask comes first, and each address gets the number. What counts as a sending address is decided by enable-source-ip-limits-on-sending-ip.

The numerator has size suffixes: b — bytes, k — kilobytes, m — megabytes, g — gigabytes, t — terabytes. The denominator has time units and an optional multiplier: 10g/2h is ten gigabytes per two hours.

The main trap — and it is right in the manual. Without a suffix the number reads as bytes. The manual’s example, source-ip-max-data-volume-rate 1.2.3.4 600/m, literally means six hundred bytes a minute — less than one message. It was clearly carried over from the neighboring directive, where 600/m means six hundred messages. Always write the suffix, even when it seems obvious.
What the Hub does. It does not write it. Volume is not limited at all in the Hub’s fleet: the rate is set by the number of messages and connections, and message weight is accounted for on the campaign side. There is even less need to split volume by address — each sending address has exactly one smtp-source-host.

The directive will be useful where the receiver or the channel is limited by bandwidth rather than by the number of messages: mailings with attachments, a narrow uplink, a rented proxy billed by traffic.

Recommended values

Calculate from the average message weight. Take the planned message rate and multiply it by the average size: a thousand messages an hour at 60 KB is about 60 MB an hour, that is, 60m/h. Setting a volume limit without knowing the weight is pointless.

A volume limit is the second line of defense, not the first. Receivers count messages and connections, not bytes; volume is worth limiting when the bottleneck is the channel or traffic billing, not the recipient’s attitude.

The suffix is mandatory. A number without a suffix is bytes, and such a line almost completely stops sending.

The default is unlimited: there is no volume limit.

The calculation order is our recommendation. From the manual here come the syntax with a mask, the size suffixes, counting only successful deliveries and the unlimited default.
Example configuration
# messages have attachments — limit the bandwidth, not the number of messages
<domain comcast.net>
    source-ip-max-data-volume-rate 1.2.3.0/30 2g/h</domain>
Two gigabytes an hour for each of the subnet’s four addresses — eight in total. The g suffix is mandatory: without it the engine will read “two bytes an hour.”
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▶

Writing a number without a size suffix

§ 3.3.10.94

What it costsWithout a suffix the value reads as bytes. 600/m is six hundred bytes a minute, less than one message: sending from the address practically stops. The mistake is all the more likely because that is exactly how the example in the manual itself is written — it was carried over from a directive where the number means messages.
How to spot itThe queue is stalled, connections open and close, and only a handful of messages go out.
How to do it rightAlways write the suffix: 2g/h, 60m/h, 500k/m. Check the line by eye after every edit.

Expecting bounces to use up the limit too

§ 3.3.10.94

What it costsOnly successful deliveries go toward the volume. A queue that gets transient refusals all day long does not use up the volume limit at all, and it does not protect the channel from retries.
How to spot itTraffic on the interface is noticeably higher than the allowed volume.
How to do it rightLimit retries separately — with the message rate and backoff parameters, and keep the volume limit for successful delivery.

Counting the mask rather than the addresses in it

our experience

What it costsEach matching address gets the volume. A /24 with a fully occupied subnet is two hundred and fifty-four times what is written.
How to spot itTraffic consumption is many times higher than calculated.
How to do it rightMultiply by the number of addresses actually up in the mask and check it against the channel capacity.
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
source-ip-max-data-volume-rate CIDR { unlimited | 0 | N [{b|B|k|K|m|M|g|G|t|T}] /[X]{d|day|h|hr|m|min|s|sec} }
Values
a network mask and a volume per interval — for example 1.2.3.4 2g/h; suffixes b k m g t, without a suffix it reads as bytes
Default
unlimited § 3.3.10.94
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The value merges across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file. The line can be repeated with different masks. It is picked up by pmta reload; no restart is needed.
How to check on the node
Check the suffix first of all — that is where mistakes happen most often. The volume that has actually passed through the queue is visible in the summary:
grep -rn source-ip-max-data-volume-rate /etc/pmta/
pmta show queues --maxitems=20
The queue summary has a kilobyte column — it shows how much data is sitting in the queue and how close the limit is. If sending has almost stopped while there are many messages in the queue, first check whether the line has a size suffix. The Hub does not collect volume by address.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Address warm-up · Sending through proxies