Demo
Demo

Knowledge base

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

bounce-upon-pix-transfer-failure

<domain>

The same decision, but only when Cisco PIX is detected on the receiver's side
in the configuration this is a linebounce-upon-pix-transfer-failure falseinside the block <domain>
The same choice, narrowed down to one kind of equipment

A full copy of bounce-upon-transfer-failure with one difference: the message is bounced only if a Cisco PIX firewall is detected on the receiver’s side. In all other cases a transfer drop is handled as usual.

The detection sign is embarrassingly simple: the node looks at the receiver’s greeting line and considers it a PIX if it has at least ten asterisks in a row. That is how the firewall hides the real mail server greeting. There is no other check.

The line exists because some versions of this firewall have a known fault in parsing the mail protocol, which makes messages get duplicated more often than usual. The same firewall is handled by pix-bug-workaround — which, unlike this line, is enabled by default.

The main trap. Detection works by ten asterisks in the greeting — and nothing else. Any receiver that hides its greeting the same way will be identified as a PIX, even though there is no PIX behind it. The line is rare and old; enabling it makes sense only if you really see such greetings in the log.
What the Hub does. It does not write it — the vendor false stays. Cisco PIX has been discontinued, and such greetings have not been seen in the fleet the Hub works with.
Recommended values

Leave it off for almost everyone. The equipment was discontinued long ago, and the chance of meeting it today is small.

Look at the log first. If there are no greetings with asterisks, the line will never fire, whatever its value.

If there is a PIX after all, enable both lines of the family. pix-bug-workaround reduces the likelihood of duplication, this one decides what to do when duplication has still happened.

The advice to check the log before enabling is ours. From the manual come the false default, the detection sign of ten asterisks in the greeting and the fact that in everything else the line repeats the general one.
Example configuration
# a transfer drop is bounced only behind the firewall that duplicates messages
<domain legacy.example.com>
    bounce-upon-pix-transfer-failure true    pix-bug-workaround yes
</domain>
The second line is not superfluous here: it reduces the very likelihood of duplication, and the first decides what to do if it still happens.
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▶

Enabling it instead of the general line

§ 3.3.10.71

What it costsTransfer drops at ordinary receivers keep being handled by default. The setting is considered effective, yet it stays silent until there are ten asterisks in the greeting.
How to spot itDuplicates at recipients continue while the line is on.
How to do it rightFor the general case set bounce-upon-transfer-failure, and leave this one to the narrow case.

Enabling it blindly, “just in case”

our experience

What it costsA receiver that hides its greeting behind asterisks without any PIX will be identified as a PIX. Its messages will start bouncing at the first transfer drop instead of being retried.
How to spot itBounces on transfer drops at one particular receiver that was not among the bounces before.
How to do it rightBefore enabling, make sure from the log that such greetings occur 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
bounce-upon-pix-transfer-failure <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.10.71
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. It acts only when the firewall is detected, so enabling it in the general block is safer than with the general line — but also useless where there is no such equipment.
⇄

Related directives

2 relations

Same name in other blocks

bounce-upon-transfer-failure<domain>The general form of the same decision: this line narrows it down to one kind of equipment. § 3.3.10.71

Often used with

pix-bug-workaround<domain>The second line of the same workaround: that one reduces the likelihood of duplication, this one decides what to do after it. § 3.3.10.71

How to check on the node
The value is printed by the queue settings command; whether the firewall is detected at all is visible from the greetings in the log:
pmta show settings legacy.example.com/vmta1 | grep -i pix
grep -E '^220 .*[*][*][*]' /var/log/pmta/pmta.log | tail -10
The second command looks for greetings with asterisks; PowerMTA itself considers a greeting a firewall if it has at least ten of them in a row. An empty answer means the line will never fire. The Hub does not parse receivers’ greetings.
◇

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
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-5xx-greetingAll 135 directives of the block →