Demo
Demo

Knowledge base

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

max-message-size

<source>set by the Hub

The largest message size accepted over SMTP from this source
in the configuration this is a linemax-message-size unlimitedinside the block <source>
The same name 1:<source><transmissions-api>— some of them are other settings, some are the same one
The largest accepted message size

A message larger than the specified size is not accepted from this source — the refusal comes at the submission stage, before the message is queued.

The default is no limit. A source without the line will accept a message of any size. The ceiling is set deliberately, and necessarily in the general <source 0/0> block too: narrow blocks override only what they name, and everything else stays with the vendor’s “as much as you like.”

A refusal at submission is better than a refusal at delivery. A message accepted into the queue and rejected by the recipient for its size has already used spool space and delivery attempts and ended up in the bounce statistics. A refusal at submission returns the problem to where it can be fixed — to the sender.

The namesake from another block does not count the same thing. max-message-size inside <transmissions-api> limits the size of an HTTP submission request and has its own default — one hundred megabytes. It has nothing to do with mail submission.

The main trap. It is the size of the message after encoding that counts, not the size of the attachment. Base64 adds about a third, so a 7-megabyte attachment makes a message of about 10. A limit set “for a twenty-megabyte file” will reject that very file.
What the Hub does. It writes max-message-size 30M in the sources selected by address: for submission from the machine itself (<source 127.0.0.1>) and for the addresses in the “Who may submit mail” list. In the named login-based submission sources there is no line at all, and the vendor’s “no limit” applies there. Thirty megabytes were chosen with a margin and are not calculated from anything.
Recommended values

Count from the receiver, not from the sender. Major mail services stop at around 25 megabytes per whole message; anything larger the node will accept, carry and get a refusal. Setting your ceiling above theirs means paying with spool and attempts for messages that will be refused anyway.

Allow a third for encoding. The limit counts the message as it arrived over SMTP. To accept a 15-megabyte attachment, you need a ceiling of about 20.

Write it in the general block. A ceiling only for platforms leaves everything else open, and that is exactly where the unexpected comes from — for example, a message assembled by a script with a database dump attached.

The unlimited default and the entry format are the vendor’s. The “about 25 megabytes at major receivers” estimate is our guideline, not a line from the manual.
Example configuration
# the general block — a ceiling for everyone not named separately
<source 0/0>
    max-message-size 20M</source>

# a platform that sends catalogs gets its own
<source 10.0.0.5>
    max-message-size 40M
</source>
Twenty megabytes go to all submitters except 10.0.0.5: the narrow block overrides the general one.
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 ends4 mistakes▶

Setting the ceiling only for submitting platforms

§ 3.3.7.37

What it costsThe default is no limit, and all sources except the named ones remain with it. The ones protected are exactly those that are predictable anyway.
How to spot itThe spool suddenly grows from a single message that came not from a platform but from a script or someone else’s host.
How to do it rightWrite the ceiling in the general block and raise it selectively for those who really need more.

Calculating the limit from the attachment size

our experience

What it costsEncoding adds about a third to the attachment, and the message arrives larger than the file. The user sees a refusal where, by their calculation, there was a margin.
How to spot itA file that is “definitely below the limit” is rejected at submission.
How to do it rightSet the ceiling about a third above the largest attachment that should get through.

Setting the ceiling above what the recipient accepts

§ 3.3.7.37

What it costsSpool space, delivery attempts and a bounce record are spent on a message that could not be delivered in principle. And the refusal goes not to the sender but to the node’s statistics.
How to spot itLarge messages go into the queue and come back with a size refusal from the receiver instead of being rejected at submission.
How to do it rightKeep your ceiling no higher than what the strictest of the mail services you need accepts.

Confusing it with the same-named line of the HTTP submission block

§ 3.3.20.5

What it costsmax-message-size inside <transmissions-api> is a different setting with a different default (one hundred megabytes). Same name, different blocks.
How to spot itThe edit affects nothing: mail submission accepts what it did before, and HTTP submission requests were never limited.
How to do it rightLook at the block, not the name: mail submission is limited by the line in <source>.
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-message-size <size>
Values
N with a suffix b, k, m, g or t — for example 20M; or 0, or unlimited; the vendor has declared a bare number in bytes an obsolete form
Default
unlimited § 3.3.7.37
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
<source> blocks merge the same way as recipient blocks: from general to specific, the narrowest match wins. A value from <source 0/0> goes to everyone not named separately. It is picked up by pmta reload.
⇄

Related directives

2 relations

Depends on

How to turn a sending plan into hardwareSpool needs are the message size multiplied by the queue depth. § 1.7.1.2

Works together with

min-free-space<spool>The per-message limit and the free space threshold are two sides of one calculation: how much space accepted mail can take up. § 3.3.2.4

Referenced from

max-message-size<transmissions-api>The same-named line of the source block limits a message arriving over SMTP; this one a request arriving over HTTP. § 3.3.20.5

How to check on the node
The engine has no command that prints source settings — it has to be checked with a live connection from the receiving side:
printf 'EHLO test\r\nQUIT\r\n' | nc -w5 node 2525
If the response to EHLO has a 250-SIZE line, the number in it is the effective ceiling for this connection. If there is no such line, the remaining check is by submission: send a message slightly above the limit and see the refusal before queuing.
◇

What else to read

3 articles

◇The activation key is a prerequisite for installation, not a step after itWithout an activation key from SparkPost support the engine neither installs nor runs, and the license tier sets the outbound connection ceiling: on Standard everything above 200 is ignored.◇Cloud restrictionsClouds restrict outbound mail on port 25 until you ask them to lift the limit, and mailbox providers treat their address ranges with suspicion.◇How to turn a sending plan into hardwareTwo constants for sizing any node: about 2 KB of memory per queued recipient and spool space proportional to the total size of the messages.

In the Hub
Managed at
Configurations → Delivery limits
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
reversible: harms only while it is set
Scenarios
Capacity planning
Neighboring settings of the block <source>:allow-smtputf8disconnect-on-transient-errorallow-authaccept-invalid-recipientsalways-allow-api-submissionAll 74 directives of the block →