Demo
Demo

Knowledge base

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

smtp-553-means-invalid-mailbox

<domain>set by the Hub

Whether to treat a bare 553 response as a sign of a nonexistent mailbox
in the configuration this is a linesmtp-553-means-invalid-mailbox yesinside the block <domain>
A guess on behalf of a receiver that did not finish its sentence

The receiver responds to the RCPT command with code 553 and gives no enhanced code — the kind that looks like 5.1.1. The code alone is not enough: in mail rules 553 means “this mailbox name is not accepted,” and behind this wording hide a nonexistent address, a banned sender, and simply the receiver’s internal policy.

This line decides what to record in that case. The vendor default yes treats a bare 553 as 5.1.1 — the mailbox does not exist. With no the response stays unparsed and falls into the general category.

The line works only when there is no enhanced code. If the receiver responded with 553 5.7.1, no guess is needed: the enhanced code said everything itself, and the value of this line has no effect.

The main trap. The bounce category depends on the guess, and whether the address ends up on the blocklist depends on the category. “No such mailbox” is a permanent refusal, and the address is removed for good. “Sender not accepted” is a refusal about us, not about the recipient, and there is no reason to strike out their address. With a receiver that answers sender policy issues with a bare 553, this line wipes out your list with your own hands.
What the Hub does. In the receiver policy template yes is set in all fifteen blocks: for fourteen well-known mailbox providers — for them a bare 553 really does mean a missing mailbox — and in the general <domain *>. This is exactly where it is decided whether a bounce is hard or soft, and the Hub removes an address only on hard bounces — so the cost of a wrong guess falls directly on the list.
Recommended values

For well-known mailbox providers — yes. Their responses are predictable, and a bare 553 from them is about the address, not the sender.

For unfamiliar receivers — more carefully. Old and homemade mail servers return 553 for any reason and give no enhanced codes at all. On such a receiver the guess is wrong more often than right.

Parse the response text alongside. What exactly the receiver meant is often written in words after the code. Parsing via bounce-category-patterns is more precise than any guess based on the number.

The split by familiarity with the receiver and the advice to parse the text are ours. From the manual here come the yes default and the main condition: the guess is made only when the response has no enhanced code.
Example configuration
# a well-known mailbox provider: a bare 553 there is about the address
<domain gmail.com>
    smtp-553-means-invalid-mailbox true</domain>

# unfamiliar receivers: we do not declare an address nonexistent based on a guess
<domain *>
    smtp-553-means-invalid-mailbox false    bounce-category-patterns careful
</domain>
In the second block response parsing is set right next to it on purpose: having given up the guess, the category has to come from somewhere else.
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 receivers

§ 3.3.10.66

What it costsA refusal due to sender policy is recorded as a nonexistent mailbox. The recipient’s address leaves the list for good, even though it is alive and the objection was not about it.
How to spot itHard bounces include domains where mail used to get through, and accounting shows a noticeable share of bare 553 responses.
How to do it rightFor unfamiliar receivers set false, and get the category by parsing the response text.

Assuming the line always applies

our experience

What it costsWhen there is an enhanced code, no guess is made at all. The edit is made, a change in statistics is expected and never comes, because the receiver already responds with a full code.
How to spot itThe value was changed, but the category distribution did not change.
How to do it rightFirst check whether 553 responses without an enhanced code arrive at all.
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
smtp-553-means-invalid-mailbox <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
yes § 3.3.10.66
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; bounces already recorded are not recalculated — the edit applies only to future receiver responses.
⇄

Related directives

1 relation

Affects

Two inbound report processors and what to do with themThe guess made here becomes the bounce category — and inbound reports are then parsed based on it. § 3.3.10.66

How to check on the node
The value is printed by the queue settings command; whether many bare 553 responses arrive at all is visible in accounting:
pmta show settings gmail.com/vmta1 | grep -i smtp-553
grep -c '553 ' /var/log/pmta/acct-*.csv
If there are no bare 553 responses in accounting, the value of the line has no effect. The Hub does not yet count the share of such responses per receiver.
◇

What else to read

3 articles

◇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.◇Backoff mode — the queue's second personalityA queue that a receiver has started refusing switches to a parallel set of limits, retries and routes — ten directives that act only in this mode.◇Reputation monitoring inside the nodeThe engine itself watches the receiving servers’ replies and changes the queue mode on a pattern match — a reaction within the connection, not through telemetry.

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
Troubleshoot deliverability · Tune the pace for a provider
Neighboring settings of the block <domain>:smtp-pattern-listbounce-category-patternsbounce-upon-no-mxbounce-upon-5xx-greetingbounce-upon-transfer-failureAll 135 directives of the block →