Knowledge base

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

max-rcpt-per-message

<domain>

A second name of the max-rcpt-per-transaction directive
in the configuration this is a linemax-rcpt-per-message 1000inside the block <domain>
The same name 1:<domain><source>— some of them are other settings, some are the same one
One field, two names — and a third meaning in another block

An alias. The manual gives the name a separate section and says plainly: it is the same as max-rcpt-per-transaction. One field, two ways to name it, the same default of 1000.

You need to know about the alias to read other people’s configurations. A setting set with one name may appear in a file under the other — and look like two different limits that do not actually exist. The field itself is described on the page of the main name: that is also where the price of fine splitting is discussed.

The engine prints exactly this name. The queue settings command outputs the line max-rcpt-per-message — whichever of the two names is in the configuration.

And the same name is taken in the submission block. There <source> carries a setting with this name, and it is about something completely different: how many recipients the node is willing to accept, default 0. The result is a name with three roles — two aliases on sending and a full namesake on reception.

The main trap. Three occurrences of one name are easy to mix up. A line copied from the submission block into a receiver block parses without error and silently changes meaning: instead of a reception ceiling you get transfer splitting. Zero, which in the submission block meant “no limit”, is not described here by the manual at all — and what the engine will do with it cannot be learned from the manual.
What the Hub does. It writes neither this name nor the main one. The vendor thousand stays, and for our sending it does not come into play: messages go out one recipient at a time.
Recommended values

Choose one name for the whole configuration. Which one does not matter; what matters is uniqueness: two names of one field in different files read as two settings. We stick to the main one, max-rcpt-per-transaction: it names the mechanism, not the result.

The values are the same as for the main name. The estimate “body size times the number of chunks” and the advice to lower it only at the receiver’s request are discussed there.

The advice to stick to one name is ours. From the manual come the equivalence of the names and the default of 1000.
Example configuration
# the manual gives its own example for its own name — the limit is the same
<domain yahoo.com>
    max-rcpt-per-message 10</domain>
Ten addresses per transfer is very fine splitting: a list of a thousand people will go out in a hundred transfers, and the receiver will get the message body a hundred times.
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▶

Treating two names as two limits

§ 3.3.10.83

What it costsBoth lines with different numbers appear in the configuration — usually expecting one to limit the transaction and the other the message. There is one field: one value applies, and the second is simply lost.
How to spot itThe effective value does not match the expectation: it equals whichever of the two lines was parsed last.
How to do it rightKeep one name in the configuration. Find diverging lines by searching for both names at once.

Copying the line from the submission block

§ 3.3.7.39

What it costsThe name is the same, the block is different — and the meaning flips: instead of a reception ceiling you get outgoing transfer splitting. The error produces neither a rejection at parsing nor a warning.
How to spot itReception still takes messages with any number of addresses, while sending to this receiver suddenly started being cut into pieces.
How to do it rightKeep in mind which block the line is from. The reception ceiling is set only in <source>, splitting — only here.

Carrying zero over here, expecting “no limit”

§ 3.3.10.83

What it costsIn the submission block zero means no limit, and that is written in the manual. Here the manual speaks only of a positive integer: how the engine will treat zero is unknown, and there is nothing to base a guess on in the receiver block.
How to spot itSending behavior toward the receiver differs from what was expected, and the manual has no description to check it against.
How to do it rightDo not carry zero between blocks. If no limit is needed, do not write the line at all — the vendor thousand is the “default”.
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-rcpt-per-message <integer>
Values
a positive integer
Default
1000 § 3.3.10.83
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 the main name: merging across matching <domain> blocks from general to specific, the most exact match wins. Both names write to one field, so one cannot “override” the other within a single block — whatever was parsed last remains.
How to check on the node
Check not the name in the file but the effective value of the field:
pmta show settings yahoo.com/mta-news-1
grep -rn 'max-rcpt-per-message\|max-rcpt-per-transaction' /etc/pmta/
The first prints the effective value — always under the name max-rcpt-per-message. The second will show whether both names have spread across the files: if both are found, the configuration is worth tidying up.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Troubleshoot deliverability · Tune the pace for a provider