Demo
Demo

Knowledge base

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

pix-bug-workaround

<domain>

Whether to send the final dot as a separate packet for the sake of old Cisco PIX firewalls
in the configuration this is a linepix-bug-workaround trueinside the block <domain>
A fault workaround enabled by default

Some versions of the Cisco PIX firewall have a known fault (CSCds90792) in parsing the mail protocol: if the terminating sequence with the dot is split across several network packets, the firewall rejects the message — and it gets duplicated on retry.

The workaround is simple: the node sends the final dot as a separate packet, so that it is sure to arrive whole. This is on by default.

The firewall is recognized by the greeting. If the greeting line has at least ten asterisks in a row — that is how the firewall hides the server’s real greeting — the node assumes a PIX is in front of it. There is no other check.

The main trap is turning it off “as outdated”. The equipment really is old, but the workaround costs nothing where there is no firewall: the sign did not match — the node works as usual. Turning it off speeds nothing up, while at a rare receiver behind such a firewall it brings message duplication back.
What the Hub does. It does not write it — the vendor true stays, and that is the right value. The workaround is free, and the case it saves is rare but unpleasant.
Recommended values

Leave it on. The workaround triggers only when the firewall is detected and does nothing in other cases.

There is no reason to turn it off. There is no gain: the cost is one extra packet per message, and only where the sign matched.

The paired line decides something else. bounce-upon-pix-transfer-failure determines what to do if duplication does happen; this one reduces its likelihood.

The rule “leave it on” is ours. From the manual come the true default, the vendor fault number, the mechanics with a separate packet for the final dot and the detection sign of ten asterisks in the greeting.
Example configuration
# the workaround is on by default; the line is needed only to bring it back
<domain legacy.example.com>
    pix-bug-workaround true    bounce-upon-pix-transfer-failure true
</domain>
The two lines close one risk from different sides: the first reduces the chance of duplication, the second decides what to do after it.
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▶

Turning it off as outdated

our experience

What it costsThe workaround costs nothing where there is no firewall: the sign did not match — behavior is ordinary. Turning it off speeds nothing up, but at a rare receiver behind such a firewall it brings message duplication back.
How to spot itDuplicates at one particular receiver whose greeting contains asterisks.
How to do it rightRestore the default.

Assuming the workaround always applies

§ 3.3.10.97

What it costsIt triggers only when the firewall is detected. Do not expect it to protect against other causes of duplication — a transfer break, a confirmation timeout: those are covered by other lines.
How to spot itDuplicates continue, the workaround is on.
How to do it rightLook at smtp-data-termination-timeout and allow-cancel-during-transfer: most often the cause is there.
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
pix-bug-workaround <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
true § 3.3.10.97
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 is merged 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 the value in the general block is harmless.
⇄

Related directives

1 relation

Often used with

bounce-upon-pix-transfer-failure<domain>A second workaround for the same equipment: this one reduces the chance of duplication, that one decides what to do after it. § 3.3.10.97

How to check on the node
The value is printed by the queue settings command; whether such equipment occurs at all is visible from the greetings in the log:
pmta show settings legacy.example.com/vmta1 | grep -i pix-bug
grep -E '^220 .*[*][*][*]' /var/log/pmta/pmta.log | tail -10
The second command looks for greetings with asterisks; the node itself treats as a firewall a greeting with at least ten of them in a row. The Hub sees mailbox provider greetings only in the proxy check and does not look for asterisks in them.
◇

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>:connect-timeoutauth-usernamecommandallow-cancel-during-transferassume-delivery-upon-data-termination-timeoutAll 135 directives of the block →