Demo
Demo

Knowledge base

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

ignore-8bitmime

<domain>

Do not tell the receiver that the message body is eight-bit
in the configuration this is a lineignore-8bitmime falseinside the block <domain>
Keep quiet about eight-bit content for the sake of gateways that cannot digest it

The receiver announces the 8BITMIME extension, and the node makes use of it: if the submitting application said the body is eight-bit, the node passes this on — as a parameter of the MAIL FROM command. The line cancels passing it on.

It does not change the message itself. The body encoding stays the same; the only thing that changes is whether the receiver is told about it or not. The line has nothing to do with what is declared in the message headers.

Why keep quiet. The manual describes a specific failure: the recipient’s external gateway announces 8BITMIME and accepts such a message, while the internal server behind it does not understand eight-bit bodies — and the message is bounced already inside someone else’s network. By keeping quiet, you make the external gateway do without this extension.

The main trap is mistaking it for re-encoding. The line re-encodes nothing. An eight-bit body will stay eight-bit; the receiver simply will not know about it in advance. If the problem is the encoding itself, it must be fixed on the message submission side, not here.
What the Hub does. It does not write it — the vendor false stays. The case is narrow: it is about corporate gateways with an old server inside, not about the large mailbox providers the Hub works with by default.
Recommended values

Only pointwise, for a specific recipient. In the asterisk block the line strips the extension from all receivers at once, including those for whom it works fine.

The sign to enable it by. Bounces come not from the external gateway but from inside someone else’s network, mentioning the encoding or body conversion.

Check after enabling. If the bounces did not go away, the problem was not the extension announcement.

The sign for enabling and the requirement of pointwise use are ours. From the manual come the default, the description of the gateway failure itself and the direct caveat that the line does not change the message encoding.
Example configuration
# the corporate gateway accepts eight-bit, but the server behind it does not
<domain corp.example.com>
    ignore-8bitmime true</domain>
The line is set for one recipient on purpose: for the others the extension is useful, and there is no reason to cancel it for everyone.
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▶

Expecting the message to be re-encoded

§ 3.3.10.77

What it costsThe line does not touch the body encoding. An eight-bit message will stay eight-bit — the only change is whether the receiver learns about it in advance.
How to spot itBounces mentioning the encoding continue.
How to do it rightRe-encode the message at submission; here only the extension announcement is decided.

Enabling it in the wildcard block

our experience

What it costsThe extension is cancelled for all receivers. Those who handle it correctly lose the regular path for transferring eight-bit bodies — with no benefit at all.
How to spot itThe line sits in the general block, while the failure was at one recipient.
How to do it rightKeep it in the block of the recipient that has the problem.
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
ignore-8bitmime <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.10.77
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 does not affect open connections.
⇄

Related directives

1 relation

Often used with

ignore-chunking<domain>The same switch for another extension — but this one has its own reason: gateway incompatibility, not debugging. § 3.3.10.77

How to check on the node
The value is printed by the queue settings command; whether the receiver announces the extension at all is visible in the conversation log:
pmta show settings corp.example.com/vmta1 | grep -i ignore-8bitmime
grep -i '8BITMIME' /var/log/pmta/pmta.log | tail -10
If the extension is not in the receiver’s replies, the line will never take effect — there is nothing to cancel. The Hub does not collect receivers’ extensions.
◇

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