Demo
Demo

Knowledge base

PMTA knowledge base›Block <source>›Directive§ 3.3.7.40

too-many-rcpts-fails-message

<source>

Whether exceeding the number of recipients fails the whole message
in the configuration this is a linetoo-many-rcpts-fails-message falseinside the block <source>
Refuse the extra ones or refuse everyone

The default is false. The line decides how exactly the engine applies the max-rcpt-per-message limit.

With the default the extra recipients are rejected one by one, at the RCPT command: the message goes to the rest. With true the engine rejects the whole message, at the DATA command — it goes to no one.

The difference is in what counts as the right outcome. Partial delivery is simpler for the node, but the submitting side may not find out about it: refusals for individual recipients are easy to miss in the stream of responses. A refusal of the message is noticed at once.

The main trap is silent partial delivery. With the default, a message with more recipients than the limit still goes out — to part of the addresses. A submitting platform that does not parse the response to each RCPT line will consider the mailing successful, while part of the audience will not receive it.

This is discovered by a mismatch in numbers: this many sent, fewer delivered, and no bounces.

What the Hub does. It writes neither this line nor the max-rcpt-per-message limit itself — both stay at the vendor default.

For our submission this does not matter: warm-up sends messages to one recipient each, and there is nothing to hit the limit with. The line would become important on a node that receives batches.

Recommended values

What to set. The question is what the submitting side should see:

Value When
false (default) partial delivery is acceptable, and the platform reads refusals for each recipient
true it is better to send to no one than to send to part and not notice it

The second is stricter and usually more honest for a mailing: a “more sent than delivered” gap without a single bounce takes a long time to sort out.

The false default and the “refusal at RCPT versus refusal at DATA” explanation come from the manual, § 3.3.7.40. The breakdown of cases is ours.
Example configuration
# the limit and the way it is applied — two lines working together
<source 0/0>
    max-rcpt-per-message 100
    too-many-rcpts-fails-message true</source>
A message with a hundred and one recipients will be rejected entirely at the DATA command. Without the second line a hundred recipients would have received it, and the hundred and first would not.
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 ends2 mistakes▶

Setting the line without setting the limit

§ 3.3.7.40

What it costsThere is nothing to apply: without a limit the number of recipients is unrestricted, and there is nothing to reject the message for. The line looks like a working setting.
How to spot itThe line is there, and the behavior does not change for any number of recipients.
How to do it rightSet the limit in the same source block.

Keeping the default with a platform that does not read refusals

our experience

What it costsThe message silently goes to part of the recipients. In the platform’s reports the mailing is successful, and the gap with the number of deliveries is explained by who knows what.
How to spot itThere are consistently fewer deliveries than sends, with no bounces.
How to do it rightEnable refusal of the whole message — then the platform will see the problem at once.
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
too-many-rcpts-fails-message <boolean>
Values
yes | no | true | false
Default
false § 3.3.7.40
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<source>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <source> and follows source merging: a connection falls under all address blocks that cover it, and a narrow one overrides a broad one. It becomes meaningful only where the recipient number limit itself is also set in the same merged set.
⇄

Related directives

1 relation

Does not work without

max-rcpt-per-message<source>The limit itself; this line only decides how the engine applies it. § 3.3.7.40

How to check on the node
Both lines are checked together — on its own this one decides nothing:
grep -n 'max-rcpt-per-message\|too-many-rcpts-fails-message' /etc/pmta/config /etc/pmta/virtualhost.txt
If no limit is set, the line will show up in no way. The behavior itself is checked by submitting a message with more recipients than the limit.
◇

What else to read

3 articles

◇How a message gets into the engineSix described submission methods: extended SMTP, four language bindings and a directory the node watches on disk.◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇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.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Connect a sending platform
Neighboring settings of the block <source>:allow-smtputf8disconnect-on-transient-errorallow-authaccept-invalid-recipientsalways-allow-api-submissionAll 74 directives of the block →