Knowledge base

require-auth

<source>set by the Hub

Whether to require login before accepting any mail from this source
in the configuration this is a linerequire-auth falseinside the block <source>
The right to hand over mail moves from the address to the login

The default is false. With true the engine requires login before accepting any message over SMTP — and the manual stipulates separately: local ones included.

The point of the directive is to change the basis on which “is this client allowed” is decided. Without it the basis is the address: if it falls into a block allowed to relay, it is allowed. With it the basis is the login.

The line is also needed by a second directive: according to the manual, the limit on failed login attempts applies only where login is required — smtp-max-auth-failure-rate.

The main trap is where the line is written. In a named login source it does almost nothing: to get there, the sender has already logged in. The manual’s own example (§ 10.1.1) writes it exactly there — as a prop, not as a lock.

The real lock for a connection that has not logged in is the absence of relaying permission in the address block it falls under. If the permission is there, this line in a named source will not cancel it: a connection that has not logged in never reaches the named source.

Hence the rule: the login requirement goes in the address block, not only in the named one.

What the Hub does. It writes true — in every named submission source of the working configuration, following the manual’s example.

A connection that has not logged in is stopped not by this line but by the fact that the general 0/0 block has no relaying permission: it is granted to the 127.0.0.1 source, to the address blocks from “Who may submit mail” and to the named sources. A connection from another address that has not logged in gets accepted only what the report reception rules allow — complaints, bounces and role addresses. The address blocks have no login requirement: the listed addresses submit without a login.

The Hub writes the failed login threshold smtp-max-auth-failure-rate into 0/0 precisely without this line — and the threshold works: the node’s log has refusals marked smtp-max-auth-failure-rate reached (verified on Sep 15, 2026).

Recommended values

What to set. The question is what the right to hand over mail rests on:

Value When
no (default) the address grants the right: submission comes from a known machine in a narrow range
yes the login grants the right: the submitting side’s address changes or is not known in advance

The second is almost always the fleet’s choice: nodes sit at different hosting providers, and the submission range cannot be pinned down. Then the line is needed in the address block, not only in the named ones, and together with it — smtp-max-auth-failure-rate.

The false default and the “local ones included” caveat come from the manual, § 3.3.7.10. The requirement for the failed attempts limit comes from § 3.3.7.8. The analysis of where the line goes is ours.
Example configuration
# the login requirement goes in the address block — where the fate
# of a connection that has not logged in yet is decided
<source 0/0>
    require-auth true    smtp-max-auth-failure-rate 5/m
</source>
Per the manual, the failed attempts limit applies only together with the first line; engine 6.0 applies it without it as well. Putting it into 0/0 is possible only if this block does not accept mail without a login: complaints and bounces on port 25 will not pass it.
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 ends3 mistakes▶

Putting the requirement only in the named source

§ 10.1.1

What it costsThe line ends up where only connections that have already logged in arrive. A connection that has not logged in is handled by the address block, and if relaying is allowed there, the login requirement will not stop it.
How to spot itThe login requirement is in the configuration, yet submission without a password from another machine goes through.
How to do it rightPut the requirement in the address block that submission falls under — in the named one it is only a prop.

Requiring login without a limit on failed attempts

§ 3.3.7.8

What it costsThe submission port is open, there is one password, and attempts are unlimited. Password brute-forcing is not limited by anything, and in the logs it looks like an ordinary series of failed logins.
How to spot itrequire-auth true is there, smtp-max-auth-failure-rate is not.
How to do it rightPut both lines as a pair and in the same block.

Forgetting about “local ones included”

§ 3.3.7.10

What it costsThe requirement also applies to submission from the machine itself. A local script used to handing over mail without a password stops working right after the configuration is reread.
How to spot itAfter the requirement was enabled, submission from the server itself stopped.
How to do it rightEither create a login for the local sender too, or keep a separate block without the requirement for the 127.0.0.1 address.
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-auth <boolean>
Values
yes | no | true | false
Default
false § 3.3.7.10
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 obeys source merging: a connection falls under all the address blocks that cover it, and the narrow one overrides the wide one. A requirement set in the 0/0 block goes to all subnets that have not said otherwise — here that is exactly what is needed.
How to check on the node
Check not the line but the behavior — and from outside the node:
grep -n 'require-auth\|always-allow-relaying' /etc/pmta/config /etc/pmta/virtualhost.txt
printf 'HELO test\r\nMAIL FROM:<a@example.com>\r\nRCPT TO:<b@example.net>\r\nQUIT\r\n' | nc <node-address> 2525
The second command is run from another machine and must get a refusal at RCPT. A 250 response means the node relays without login — and the requirement line is not where it should be.
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 · Sender isolation