Demo
Demo

Knowledge base

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

require-starttls-before-auth

<source>

Whether to require encryption before the password is entered
in the configuration this is a linerequire-starttls-before-auth falseinside the block <source>
The password must not travel in plain text

The line requires the client to perform STARTTLS before any authentication command. The default is false, that is, by default the password can be sent over an unencrypted connection.

This is a softer form of requirement than require-starttls: that one requires encryption before everything, this one only before the password. Submission without authentication keeps working as before.

A related line is allow-unencrypted-plain-auth: it is about whether the PLAIN mechanism may be used on an unencrypted connection. The two settings close the same hole from different sides, and they are best understood together.

The main trap is considering the matter closed with one line. There is a second path: the PLAIN mechanism on an open connection, which is allowed separately. If allow-unencrypted-plain-auth is true, the password can still travel in the clear — just in a different way.
What the Hub does. It does not write it, and this is worth reconsidering. The base configuration allows encryption and allows PLAIN on an open connection — that is, the submission password can travel unencrypted if the platform is configured that way. The line closes this without breaking anything for those who already encrypt; it should be enabled together with a check that all submitting platforms support STARTTLS.
Recommended values

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

What is set Can the password travel in the clear
both lines at the default yes, in two ways
only this line true no — authentication without encryption is forbidden
only allow-unencrypted-plain-auth false no for PLAIN, yes for other mechanisms
this one true and PLAIN forbidden no, with margin to spare

The practical minimum for a submission node is this line. It costs less than the strictest form and closes the main gap.

The false default comes from the manual (§ 3.3.7.15). The comparison with the PLAIN mechanism and the conclusion about the minimum are ours.
Example configuration
# the minimum for a submission node: the password only over an encrypted connection
<source 0/0>
    allow-starttls true
    require-starttls-before-auth true</source>
Submission without authentication will keep working; the only change is that the password cannot be sent in plain text. Check allow-unencrypted-plain-auth while you are at it: it is the second path to the same hole.
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▶

Protecting the password with this line alone

our experience

What it costsA second path remains: the PLAIN mechanism on an unencrypted connection is allowed by a separate line. The hole is only half closed.
How to spot itThe line is set, while allow-unencrypted-plain-auth is true.
How to do it rightLook at both lines together. For a submission node it is sensible to require encryption before the password and not to allow PLAIN in the clear.

Setting the requirement without allowing encryption

§ 3.3.7.15

What it costsThe node does not advertise STARTTLS but requires it before the password. Authenticating becomes impossible altogether.
How to spot itSubmission with authentication stops working entirely.
How to do it rightSet allow-starttls in the same source.
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
require-starttls-before-auth <boolean>
Values
yes | no | true | false
Default
false § 3.3.7.15
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 chosen by the submitter’s address, before authentication — so the line does not take part in login-based sources.
⇄

Related directives

2 relations

Conflicts with

allow-unencrypted-plain-auth<source>The other side of the same hole: one line requires encryption before the password, the other forbids the PLAIN mechanism without encryption. § 3.3.7.15

Works together with

require-auth<source>Requiring encryption makes sense where authentication is needed at all. § 3.3.7.10

How to check on the node
It is checked by trying to authenticate without encryption:
printf 'EHLO test\r\nAUTH LOGIN\r\nQUIT\r\n' | openssl s_client -connect localhost:25 -quiet 2>/dev/null | head -5
A refusal at the AUTH command means the requirement is in effect. A response inviting you to enter a login means the password can currently travel in plain text.
◇

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
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security
Neighboring settings of the block <source>:allow-starttlsrequire-starttlssmtp-serviceretain-x-dkim-keyprocess-x-dkim-keyAll 74 directives of the block →