Demo
Demo

Knowledge base

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

smtp-max-auth-failure-rate

<source>set by the Hub

How many failed logins per period are allowed from this source
in the configuration this is a linesmtp-max-auth-failure-rate unlimitedinside the block <source>
The only protection against password brute-forcing

The default is unlimited, that is, brute-forcing is not limited by anything. The value 0 means the same. The manual names the purpose directly: protection against password guessing.

The value is a rate: 5/min allows five failed attempts per minute. The syntax is shared with the other rate limits: N/[M]unit, where N is mandatory and non-zero, and M is optional and defaults to 1. The units are d/day, h/hr, m/min, s/sec.

The count starts from the first failure, not the last. The manual walks through an example: with 3/5m, failed attempts at 10:00, 10:01 and 10:02 close logins until 10:05 — five minutes from the first.

The manual also sets a condition: the directive applies only where login is required by the require-auth line. Engine 6.0 applies the threshold without it as well — verified on a Hub node (see below).

The main trap is the default. The directive is not written, and there is no brute-force protection at all. This usually goes unnoticed for a while: failed logins look in the log exactly like someone’s typos, and they can be told apart from guessing only by their rate.

The second half is where the line goes. A failed attempt happens before the sender is identified, which means the named login source has not been chosen yet. The directive can work only in the block matched by address. In a named one it is useless.

What the Hub does. It writes it — into the 0/0 <source> block of both templates, 5/m by default. The threshold is set in the configuration generator, in the “Who may submit mail” section, with the “Brute-force protection” field; the unlimited value leaves a comment instead of the line, and there is no protection.

The place is chosen correctly: a failed login happens before the named login source is selected. The Hub does not write require-auth into 0/0 — the node accepts complaints and bounces, which do not log in, through this same block. The threshold still works: on node 45.134.12.126 the log for Sep 15, 2026 has 13,348 refusals marked <source> smtp-max-auth-failure-rate reached, and there are no more than five failed attempts from one address per minute.

Recommended values

What to set. The threshold is chosen by how many failures your own clients have:

Value When
unlimited (default) the submission port is restricted by range, and an outsider cannot reach it
5/m regular submission: your own platform errs rarely and not in a row
3/5m the port is open to the whole network, there are few logins, and passwords change rarely

A threshold that is too strict is dangerous for your own platform: a restart after which it tries to log in several times in a row will close logins for the whole period. The count starts from the first failure, so the period is exactly the downtime.

The unlimited default, the rate syntax, counting from the first failure and the require-auth requirement come from the manual, § 3.3.7.8. The analysis of where the line goes and the breakdown of thresholds are ours; that the threshold works without require-auth was verified on a node on Sep 15, 2026.
Example configuration
# both lines in the address block: before login the named source has not been chosen
<source 0/0>
    require-auth true
    smtp-max-auth-failure-rate 5/m</source>
After the fifth failed attempt within a minute, the engine refuses further attempts from this source until the end of the minute counted from the first failure.
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▶

Setting a threshold without requiring login

§ 3.3.7.8

What it costsThe manual names the condition directly: without the login requirement the directive has no effect. The line is in the configuration, but there is no protection.
How to spot itThe threshold is set, yet brute-forcing in the log is not limited by anything.
How to do it rightSet the pair: the login requirement and the threshold, in the same block.

Counting from the last failure

§ 3.3.7.8

What it costsThe count starts from the first. With 3/5m, three errors in a row close logins for five minutes from the first of them, not from the third — and your own platform, restarted with a wrong password, will be stuck for exactly that long.
How to spot itSubmission recovered later than expected based on the last failed attempt.
How to do it rightTreat the period as downtime and choose it by looking at how your own platform behaves on restart.

Writing the threshold in the named login source

our experience

What it costsA failed login attempt happens before the sender is identified — at that moment the named source has not been chosen yet. The line does not work and creates a false sense of security.
How to spot itThe threshold is visible in the submission file, yet brute-forcing is not limited by anything.
How to do it rightMove the line to the address block that the submitting side falls under.
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
smtp-max-auth-failure-rate <rate>
Values
unlimited · 0 · N/[M] with a unit d|day|h|hr|m|min|s|sec — for example 5/m or 3/5m
Default
unlimited § 3.3.7.8
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 threshold set in the 0/0 block also goes to your own subnets — there it is usually worth relaxing with a separate line.
⇄

Related directives

2 relations

Does not work without

require-auth<source>The applicability condition named by the manual: without the login requirement the threshold has no effect. § 3.3.7.8

Depends on

allow-auth<source>If the login command is forbidden altogether, there is nothing to limit. § 3.3.7.8

How to check on the node
The configured threshold is visible in the configuration; a triggered one shows up as refusals in the log:
grep -n 'smtp-max-auth-failure-rate\|require-auth' /etc/pmta/config
grep -i 'auth' /var/log/pmta/pmta.log | tail -20
A missing line means unlimited — there is no protection. A series of failed logins from one address in the log without a subsequent refusal means the threshold does not trigger: either it is absent, or login is not required.
◇

What else to read

3 articles

◇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.◇Submission logins, plain-text passwords and per-user settingsA sender logs in with one of three methods; each login is a configuration block with a plain-text password, and that login’s named source overrides what its address would have given.◇A license for a fleet, not for a serverThe license is not bound to a server: it is installed on as many machines as the instance limit allows, and the nodes send volume statistics to the vendor every hour.

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
Neighboring settings of the block <source>:retain-x-dkim-keyprocess-x-dkim-keysmtp-serviceallowed-sender-listsallow-unencrypted-plain-authAll 74 directives of the block →