Demo
Demo

Knowledge base

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

use-unencrypted-plain-auth

<domain>

Whether to allow PLAIN and LOGIN on an unencrypted connection
in the configuration this is a lineuse-unencrypted-plain-auth falseinside the block <domain>
A password over the network in plain text — or not sending at all

Of the three authentication mechanisms the node understands, two — PLAIN and LOGIN — transmit the password in the conversation itself. If the connection is not encrypted (STARTTLS is not used), the password goes over the network in plain text.

This line decides whether that is acceptable. The third mechanism, CRAM-MD5, does not transmit the password over the network and is not subject to the restriction.

The line applies to outbound authentication — the one where the node identifies itself to someone else’s relay (auth-username, auth-password). Mail acceptance has its own mirror line: allow-unencrypted-plain-auth in the <source> block.

The main trap is confusing it with the mirror line. The names almost match, but the sides differ: this one is about how we identify ourselves to someone else’s relay, that one about how submitters identify themselves to us. An edit on the wrong side looks applied and does nothing.
What the Hub does. It does not write it: it has no outbound authentication, the nodes send directly to recipients. If a relay scenario appears, the value must be prohibiting and the connection encrypted.
Recommended values

Do not allow it. A password to someone else’s relay that goes over the network in the clear is compromised entirely and unnoticed.

The right answer is to encrypt the connection. If the relay cannot do STARTTLS, the question is not about this line but about the relay itself.

CRAM-MD5 is a workaround. It does not transmit the password over the network; if the relay supports it, the restriction stops getting in the way.

The order “encryption first, then this line” is ours. From the manual here comes the exact scope: the PLAIN and LOGIN mechanisms on an unencrypted connection.
Example configuration
# no password over the network in the clear; the relay must support STARTTLS
<domain relay.example.com>
    auth-username relay-user
    auth-password s3cr3t
    use-unencrypted-plain-auth false</domain>
With the ban in place and a relay without encryption, authentication simply will not happen — and that is the right behavior: better not to send than to hand the password to the network.
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▶

Allowing it “to make it work”

our experience

What it costsThe password to someone else’s relay goes over the network in the clear on every attempt. The compromise happens unnoticed and leaves no traces in any log.
How to spot itThe line allows it, and there is no STARTTLS with this relay in the log.
How to do it rightEnable encryption on the relay or switch to CRAM-MD5.

Editing it on the wrong side

our experience

What it costsA line with almost the same name exists in the <source> block and applies to mail acceptance. An edit there does not affect outbound authentication, and vice versa.
How to spot itThe value was changed, the behavior is the same.
How to do it rightCheck the block: <domain> is the outbound side, <source> the inbound one.
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
use-unencrypted-plain-auth <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.10.65
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. The line is about the outbound side; the mirror one for mail acceptance lives in the <source> block. It is picked up by pmta reload.
⇄

Related directives

1 relation

Same name in other blocks

allow-unencrypted-plain-auth<source>The mirror line for mail acceptance: that one is about those who submit to us, this one about us identifying ourselves to someone else’s relay. § 3.3.10.65

How to check on the node
The value is printed by the queue settings command; whether the connection to this relay is encrypted is visible from STARTTLS use in the log:
pmta show settings relay.example.com/vmta1 | grep -i use-unencrypted-plain-auth
grep -i 'STARTTLS' /var/log/pmta/pmta.log | tail -10
If STARTTLS is not used with this relay while the line allows it, the password goes over the network in the clear on every attempt. The Hub does not set outbound authentication.
◇

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>:auth-passworddisable-acct-recordsbounce-afterretry-afterdkim-signAll 135 directives of the block →