Demo
Demo

Knowledge base

PMTA knowledge base›Block <source>›Directive§ 3.3.7.12

allow-unencrypted-plain-auth

<source>set by the Hub

Whether to allow the PLAIN mechanism on an unencrypted connection
in the configuration this is a lineallow-unencrypted-plain-auth falseinside the block <source>
The second way a password goes out in the clear

The PLAIN authentication mechanism transmits the login and password in an encoding, not a cipher: reading them from intercepted traffic takes one command. The line decides whether it can be used on an unencrypted connection.

The default is false, that is, not allowed by default. This is the right default, and it is usually turned on for compatibility with a platform that otherwise does not connect.

The other side of the same hole is require-starttls-before-auth. One line forbids a specific mechanism without encryption, the other requires encryption before any authentication. They should be looked at together.

The main trap is turning it on to “just make it work” and forgetting. The line most often appears while debugging submission: the platform does not connect, the permission helps, the question is closed. After that the password travels over the network in readable form on every connection — and there is nothing to notice it with.
What the Hub does. It writes yes in the base configuration — in the general source, for compatibility with submission platforms. Along with this, require-starttls-before-auth is not set, which means the submission password may go out unencrypted. This is worth revisiting: enable the requirement for encryption before authentication and check that the submitting platforms can handle it.
Recommended values

The value is boolean, and it has to be read together with its neighbor:

This line require-starttls-before-auth Password in the clear
no (default) not set no for PLAIN, possible for other mechanisms
yes not set yes
yes true no: authentication only over an encrypted connection
no true no, with a margin

If you had to turn it on — turn it on together with the requirement for encryption before authentication. Then the permission applies to connections that are encrypted anyway.

The false default comes from the manual (§ 3.3.7.12). The analysis of the pair with the encryption requirement and the assessment of our base configuration are ours.
Example configuration
# compatibility plus protection: the permission works only inside encryption
<source 0/0>
    allow-starttls true
    require-starttls-before-auth true
    allow-unencrypted-plain-auth yes</source>
In this combination the permission is safe: authentication without encryption is forbidden anyway, and PLAIN is used only inside an already established TLS. Right now the Hub’s base configuration does not have the middle line.
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 ends1 mistake▶

Turning it on while debugging and leaving it forever

our experience

What it costsThe submission password travels over the network in readable form on every connection. Nothing breaks, no messages — which is why the line lives on for years.
How to spot itThe base configuration has yes, and there is no requirement for encryption before authentication.
How to do it rightAdd require-starttls-before-auth. Then the permission applies only to connections that are already encrypted.
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
allow-unencrypted-plain-auth <boolean>
Values
yes | no | true | false
Default
false § 3.3.7.12
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<source>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <source> and merges by the source rule: a narrower block overrides a wider one. The source is selected by the submitter’s address, before authentication.
⇄

Related directives

2 relations

Conflicts with

require-starttls-before-auth<source>The other side of the same hole: that line requires encryption before the password, this one allows or forbids PLAIN without encryption. § 3.3.7.15

Works together with

allow-starttls<source>The encryption permission is what makes this setting meaningful: without it there are simply no encrypted connections. § 3.3.7.13

Referenced from

use-unencrypted-plain-auth<domain>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
Checked the same way as the requirement — by trying to authenticate without encryption:
printf 'EHLO test\r\nQUIT\r\n' | nc localhost 25 | grep -i "AUTH"
If the extension list on an unencrypted connection has AUTH PLAIN, the mechanism is allowed in the clear. With the requirement for encryption before authentication enabled, there should be no AUTH line there.
◇

What else to read

3 articles

◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇The group that grants management rightsMembership in the pmta group gives an unprivileged user the right to call the node’s commands and use submission.◇How the node selects a source and combines its settingsA connection falls under all source blocks whose addresses cover it, and they act merged — the narrow one overrides the wide one; named blocks are attached only by direct reference.

In the Hub
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security
Neighboring settings of the block <source>:smtp-serviceretain-x-dkim-keyprocess-x-dkim-keyrequire-authallowed-sender-listsAll 74 directives of the block →