Demo
Demo

Knowledge base

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

bounce-upon-5xx-greeting

<domain>set by the Hub

Whether to bounce all of a receiver's mail at once on a 5xx reply to the greeting
in the configuration this is a linebounce-upon-5xx-greeting trueinside the block <domain>
What to treat as a “go away for good” reply before the very first command

The receiving server replies with a 5xx code in the very first line — the greeting, before the node has even named the sender and the recipient. Formally this is an unambiguous refusal: mail standards prescribe treating such a reply as final and bouncing the mail. The vendor default true does exactly that — and bounces this receiver’s entire queue at once.

The manual is unusually frank here: it calls this behavior prescribed by the standards and immediately says that the network is full of misconfigured servers because of which mail is lost for no reason.

With false the reply is treated as temporary: the node tries other servers from the MX list and keeps retrying until the bounce-after deadline. It is slower, but it does not lose mail because of one faulty server.

The main trap. What bounces is not a message but the receiver’s entire queue at once. One server from the MX list crashed and greets with a 5xx code — and the entire accumulated volume for this domain turns into bounces in a single attempt. This cannot be undone: the bounces have already been sent, the messages removed from the queue.
What the Hub does. In the receiver policy template true is set in all fifteen blocks: for fourteen well-known mailbox providers and in the general <domain *>. For the well-known ones this is justified — for them 5xx on the greeting really does mean a refusal, not a breakdown; the general block extends the same decision to arbitrary domains.
Recommended values

Well-known mailbox providers — keep true. Their servers are configured correctly, and a refusal on the greeting is meaningful for them: most often the sender’s address has landed on the receiving server’s blocklist.

Unfamiliar domains — false. The cost of a mistake is asymmetric: with false you lose time, with true — the receiver’s entire queue.

Parse the reply text. The 5xx code itself does not say why you were rejected. Configure smtp-pattern-list to tell an address block from a receiving server failure — otherwise the decision is made blindly.

The split by familiarity with the receiving server is ours. From the manual here are the true default, the admission that it loses mail on misconfigured servers, and the behavior with false: attempts to other MX servers until the deadline expires.
Example configuration
# a well-known mailbox provider: 5xx on the greeting is a block, not a failure
<domain gmail.com>
    bounce-upon-5xx-greeting true</domain>

# unfamiliar domains: we do not burn the queue because of one faulty server
<domain *>
    bounce-upon-5xx-greeting false    bounce-after 3d
</domain>
In the second block the bounce deadline is set next to it on purpose: with false, it is what decides how long the node will keep trying before giving up.
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▶

Leaving the default for unfamiliar domains

§ 3.3.10.70

What it costsOne misconfigured server in the MX list bounces the receiver’s entire queue. The manual openly admits this case, and yet the default is true.
How to spot itMass bounces for one domain within a single minute, while an hour later mail goes there without a problem.
How to do it rightSet false in the asterisk block, keeping true for well-known mailbox providers.

Making the decision without reading the reply text

our experience

What it costsA 5xx on the greeting is given both by a receiving server that has blocked the address and by a server that has run out of disk space. One value for both cases is always wrong for one of them.
How to spot itRefusals with text about a temporary problem at the receiving server are counted as final.
How to do it rightParse receiving server replies via smtp-pattern-list and decide by the text, not just by the code.
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
bounce-upon-5xx-greeting <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
true § 3.3.10.70
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. It is picked up by pmta reload; for messages already queued it takes effect from the next attempt — enabling it bounces the queue not at the moment of the edit but at the very first greeting with a 5xx code.
⇄

Related directives

1 relation

Works together with

bounce-after<domain>With the line off, the reply is treated as temporary, and the boundary becomes the general deadline: attempts go on until it. § 3.3.10.70

How to check on the node
The queue settings command prints the value; the receiving server’s reply itself is visible in the log if connection logging is enabled:
pmta show settings gmail.com/vmta1 | grep -i bounce-upon-5xx-greeting
grep -i '220\|5[0-9][0-9] ' /var/log/pmta/pmta.log | tail -20
A one-time spike of bounces for one receiver almost always means this line fired. The Hub shows such spikes in telemetry but does not yet link them to this cause.
◇

What else to read

3 articles

◇Four value types the whole config is written inBoolean, domain pattern, regular expression and time interval — defined once in § 3.2 and then used by all directives.◇Two inbound report processors and what to do with themBounces by message and complaints are parsed by two identically structured blocks; each has its own address list and its own pair of decisions about the message’s fate.◇How the policy for a receiver is assembledSettings are assembled from the most general pattern to the most precise; the order of blocks in the file means nothing.

In the Hub
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
reversible: harms only while it is set
Scenarios
Bounce classification · Tune the pace for a provider
Neighboring settings of the block <domain>:smtp-pattern-listsmtp-553-means-invalid-mailboxbounce-category-patternsbounce-upon-no-mxbounce-upon-transfer-failureAll 135 directives of the block →