Knowledge base

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

max-msg-per-hour

<domain>deprecated

Message rate to the receiver — a deprecated form with a hard-coded hour
in the configuration this is a linemax-msg-per-hourinside the block <domain>
The interval is built into the name, not the value

The line limited the message rate to the receiver per hour. The manual gave it a one-sentence section — “deprecated, use max-msg-rate” — and gives no syntax or default for it.

The replacement differs in that the interval moved into the value. In max-msg-rate it is written as the denominator: 500/h — the same five hundred messages per hour, 500/d — per day, 100/15m — a hundred per fifteen minutes. The old name gave no such choice: the hour was the only one.

What the replacement counts. Not only delivered messages count, but attempts too: a temporary failure from the receiver uses the limit on a par with an accepted message. A triggered limit is visible in the web monitor as the line message rate limit reached (based on max-msg-rate in configuration) — it immediately shows which of four similar directives held sending back.

The migration is mechanical. max-msg-per-hour N becomes max-msg-rate N/h. The same value, the same behavior — only the notation changes.

The main trap is renaming and forgetting the denominator. The replacement has a strict value grammar: a number, a slash, an optional multiplier and a time unit. A bare max-msg-rate 500 does not match this grammar, and you cannot rely on the engine to infer the hour — the hour was a property of the old name, not of the value. When migrating the line, append /h.
What the Hub does. It never writes the deprecated name. It writes the replacement — max-msg-rate in a <domain> block inside the sending address: 1/h during warm-up, then from the node preset — 2/m, 10/m or 30/m; for the fallback address — the backoff mode rate of the same preset (1/h, 5/h or 20/h).

The line is worth looking for in configurations assembled by hand before the move to the Hub: the engine accepts it, and next to the new form in the same file it reads as a second setting that does not exist.

Recommended values

What to set. Nothing: the line should be replaced.

Value When
do not write always: the rate is set by the replacement
N only in an old configuration that has not been migrated yet

Migration. The number carries over as is, with /h appended. If after migration you want a different window, that is what the denominator is for: a day, a minute, fifteen minutes.

The deprecation mark and the replacement’s name are from the manual, § 3.3.10.42. The value grammar and the fact that attempts count are from the replacement’s section § 3.3.10.40. The migration order is ours.
Example configuration
# this is how it was written before — the hour was the only window
<domain yahoo.com>
    max-msg-per-hour 500</domain>

# this is how it is written now — the window is chosen by the denominator
<domain yahoo.com>
    max-msg-rate 500/h
</domain>
The same value, the same behavior. The denominator will be needed as soon as the window stops being an hour: 500/d or 100/15m cannot be expressed with the old name at all.
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▶

Renaming the line without appending the denominator

§ 3.3.10.40

What it costsThe hour was a property of the old name, not of the value. The replacement’s grammar requires a time unit, and a bare number does not match it — there is no basis for counting on the engine to substitute an hour.
How to spot itAfter the edit the configuration is either not accepted, or the rate behaves differently than before the rename.
How to do it rightWrite max-msg-rate N/h. Check the effective value with the queue settings command, not by reading the file.

Leaving both forms in the same file

§ 3.3.10.42

What it costsThe deprecated line is not rejected during parsing, and the file contains two rate limits with different numbers. Which of them wins, the manual does not specify.
How to spot itThe effective rate matches neither of the two written values, or matches an unexpected one.
How to do it rightRemove the deprecated line right after migration. Search for both forms with one search across the whole configuration directory.

Believing the limit caps delivered messages

§ 3.3.10.40

What it costsAttempts count too: the receiver answered with a temporary failure — the limit is used just as for an accepted message. With a high failure rate, actual delivery ends up noticeably below the written number.
How to spot itNoticeably less is delivered than the set rate, while the monitor shows the limit being triggered.
How to do it rightDeal with the cause of the failures rather than raising the limit. A raised limit will speed up the attempts too.
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-msg-per-hour <rate>
Values
a number of messages per hour; the manual gives no full grammar for this name
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
Inheritance is shared with other receiver settings: merging across matching <domain> blocks from general to specific, the most precise match wins. The replacement has exactly the same — when migrating, the line does not need to be moved anywhere, only the name and the value change.
How to check on the node
The deprecated name is searched for together with the replacement — to see whether both forms are in the file:
grep -rn 'max-msg-per-hour\|max-msg-rate' /etc/pmta/
pmta show settings yahoo.com/mta-news-1
The second command prints the effective value — under the name max-msg-rate. If both forms were found in the configuration, the deprecated one should be removed: the manual does not help figure out which wins.
In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Configuration lifecycle