<source>set by the Hub
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 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.
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).
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 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>
what people get wrong and how it ends3 mistakes▶
§ 10.1.1
§ 3.3.7.8
§ 3.3.7.10
2 relations
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
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.