Demo
Demo

Knowledge base

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

allow-auth

<source>

Whether the AUTH command is allowed for this source
in the configuration this is a lineallow-auth trueinside the block <source>
A switch that is turned off rarely and deliberately

The default is true: the AUTH command is allowed. With false the engine neither offers nor accepts it — so no login works on this source.

The pair with require-auth reads like this: this directive says whether you can log in, that one — whether you must. The combination “cannot log in, but must” makes the source non-working: nobody will be able to hand over mail through it.

It is turned off to narrow the attack surface — where logins on this source are not intended at all and login attempts from it can only be someone else’s.

The main trap is the combination with a login requirement. Both lines live in the same block and follow the same merging, and set together they produce a source through which mail cannot be handed over at all: without logging in you are not let in, and there is no way to log in.

The mistake is easy to make: false is written in a broad block to narrow the surface, and the login requirement in a narrow one, and the narrow one gets both.

What the Hub does. It does not write it: the vendor default stays, that is, login is allowed everywhere. It could not be otherwise — login is the main way of submission in the Hub.

The directive would be useful on a source from which submission is not intended at all — for example, the one that accepts complaints and bounces on the mail port. Today the Hub does not make that separation.

Recommended values

What to set. It is turned off rarely and for one reason:

Value When
yes (default) submission under a login is intended — the usual case
no there must be no logins on this source, and any login attempt is someone else’s

The second makes sense where the source accepts only incoming mail — complaints, bounces, reports — and submission through it is not expected.

The true default comes from the manual, § 3.3.7.7. The analysis of the combination with a login requirement and of the “receive-only source” case is ours.
Example configuration
# logins are not needed on the receiving source — a login attempt is someone else's
<source 0/0>
    allow-auth false</source>
Such a block is suitable only where nothing is submitted through it. Together with a login requirement it would make the source non-working: entry without logging in is not allowed, and there is no way to log in.
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▶

Disallowing login in a broad block to narrow the surface

our experience

What it costsBy the merge rule, the ban goes to all subnets that did not say otherwise themselves — including the one submission comes from. Together with a login requirement, the source becomes non-working.
How to spot itThe submission platform reports that the server does not offer authentication.
How to do it rightPut the ban only in the block where submission is not intended, and check with the receiver’s greeting from the right address.

Taking the command ban for submission protection

§ 3.3.7.7

What it costsThe ban closes login, not relaying. If an address block is allowed to relay, mail will go through it without any login.
How to spot itallow-auth false is set, yet the node still relays someone else’s mail.
How to do it rightLook at the relaying permission: it is what decides whether to let a message through.
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-auth <boolean>
Values
yes | no | true | false
Default
true § 3.3.7.7
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 follows source merging: a connection falls under all address blocks that cover it, and a narrow one overrides a broad one. A ban set in the 0/0 block also goes to the submission subnets — and together with a login requirement makes them non-working.
⇄

Related directives

2 relations

Works together with

require-auth<source>A neighboring question: this line says whether you can log in, that one — whether you must. § 3.3.7.10

Applies to

An account for submitting mailBanning the command makes all declared logins worthless at once: there is no way to use them. § 3.3.8

Referenced from

smtp-max-auth-failure-rate<source>If the login command is forbidden altogether, there is nothing to limit. § 3.3.7.8broken-auth-clients<source>A neighbor by section and by meaning: the real login switch. § 3.3.7.16

How to check on the node
Whether the command is allowed is visible right in the receiver’s greeting:
printf 'EHLO test\r\nQUIT\r\n' | nc <node-address> 2525 | grep -i auth
A 250-AUTH line in the response means login is offered. Its absence means the command is disallowed or, with mandatory encryption, advertised only after STARTTLS.
◇

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>:always-allow-api-submissiondisconnect-on-transient-errorallow-smtputf8accept-invalid-recipientsmax-message-sizeAll 74 directives of the block →