Demo
Demo

Knowledge base

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

replace-smtp-421-service-response

<domain>

Whether to replace the text of a 421 reply with a neutral one
in the configuration this is a linereplace-smtp-421-service-response falseinside the block <domain>
Someone else’s text does not go into the report

The default is false. With the value true the engine replaces the text of the reply after the 421 code and after the enhanced status code with a neutral “service unavailable”.

The reason is named plainly: so that addresses and other things from this reply do not get into bounce reports. Receivers often put a contact address, a link to their page or the recipient’s address into the refusal text — and all of it travels further with the report.

Pattern-based parsing keeps working. The original text is passed to the smtp-pattern-list rules as it was, so backoff mode and other pattern-based actions do not break. What accounting records in the meantime, the manual does not specify.

The main trap is that the replacement hides the text from you too. The bounce report sees a neutral “service unavailable”, and a person investigating the problem from the report will not learn what exactly the receiver replied.

Whether the original text remains in accounting, the manual does not say: it only stipulates that the pattern rules still get it. Before relying on accounting, this is worth checking on your own node.

The second half: the line concerns only the 421 code — a temporary service refusal. The texts of other refusals, including hard 5xx, go out as they were.

What the Hub does. It does not write it — the vendor false stays.

In reports the line would not show up for us: local outcome reports are suppressed in all submission sources and do not go outside at all. The Hub gets receivers’ reply texts as accounting records in telemetry, and whether the replacement reaches accounting, the manual does not say.

There is no reason to enable it without checking: there is nothing to gain, and the texts of temporary refusals could be lost.

Recommended values

What to set. The question is whether reports go outside:

Value When
false (default) reports are suppressed or read only by you
true bounce reports reach senders, and other parties’ texts in them are undesirable

The second does not interfere with the pattern rules: they get the original text. Whether it is kept in accounting, the manual does not say.

The false default, replacement of the text after the code and the enhanced status code, the reason (addresses in reports) and keeping the original text for pattern-based parsing come from the manual, § 3.3.10.68.
Example configuration
# reports reach senders — other parties' texts are not needed in them
<domain *>
    replace-smtp-421-service-response true</domain>
Pattern-based parsing does not break: the rules get the original text. What gets into accounting — the original text or the replaced one — is worth checking on the node.
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▶

Investigating bounces from reports after enabling the replacement

§ 3.3.10.68

What it costsThe report shows a neutral text, and what exactly the receiver replied cannot be learned from it. If the replacement has reached accounting too, the original text cannot be found there either.
How to spot itAll temporary service refusals look the same in reports.
How to do it rightLook at the reply text in accounting records; if it says “service unavailable” there too, turn the line off for the duration of the investigation.

Expecting replacement for other refusal codes

§ 3.3.10.68

What it costsThe line concerns only the 421 code. The texts of hard refusals and other temporary ones go into reports as they were, together with everything the receiver put in them.
How to spot itOther parties’ addresses and links still show up in bounce reports.
How to do it rightSuppress reports entirely or clean them on your side.
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
replace-smtp-421-service-response <boolean>
Values
yes | no | true | false
Default
false § 3.3.10.68
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 directive lives in <domain> and obeys the merging of receiver blocks: a narrower block overrides a wider one. Here the general block is appropriate — the replacement is needed by all receivers equally.
⇄

Related directives

1 relation

Works together with

bounce-category-patterns<domain>Bounce classification goes by the original text: the replacement does not interfere with it. § 3.3.10.68

Referenced from

smtp-421-means-mx-unavailable<domain>About the same code: that line hides the response text in bounces, this one decides whether to switch servers because of it. § 3.3.10.67

How to check on the node
The line is visible in the configuration; what gets into accounting — from the text of 421 replies in the records:
grep -n 'replace-smtp-421\|suppress-local-dsn' /etc/pmta/config /etc/pmta/virtualhost.txt
grep -i 'smtp;421' /var/log/pmta/acct-*.csv 2>/dev/null | tail -10
The second command will show the texts of 421 replies in accounting if transient failure records are written to the file (t in the records line); otherwise 421 gets there only in the final bounce. If you see “service unavailable”, the replacement has reached accounting too. If local reports are suppressed, the line will not show up in reports at all.
◇

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
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-553-means-invalid-mailboxsmtp-pattern-listbounce-category-patternsbounce-upon-no-mxbounce-upon-5xx-greetingAll 135 directives of the block →