Demo
Demo

Knowledge base

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

broken-auth-clients

<source>deprecated

Obsolete, without a description and without a named replacement
in the configuration this is a linebroken-auth-clientsinside the block <source>
A name without content

Section § 3.3.7.16 consists of one word: “Deprecated”. No description, no syntax, no default, no name of a replacement — the manual does not even say what the directive did while it was alive.

There are two such cases in the catalog: pickup-retry-interval is marked the same way, with a single word. For most other deprecated directives a replacement is named: smtp-ip points to smtp-listener, max-msg-per-hour to max-msg-rate. Here there is no pointer, and the card shows no “Replaced by” badge not because we failed to fill it in, but because there is nothing to put there.

What is known for certain. The directive belonged to the <source> block, that is, to accepting mail, and it sits right after the group of login and encryption settings (§ 3.3.7.7–3.3.7.15): from allow-auth and require-auth to require-starttls-before-auth. The directive index of chapter 15 knows the name and links to the same empty section.

What the name suggests — and what it does not prove. “Clients with broken login” reads as a relaxation for programs that implemented the AUTH command incorrectly. That is a reading of the name, not a fact from the manual: what exactly the line relaxed, and in which direction, the vendor did not write. A setting must not be built on such a guess — but it does help to recognize the name in an old file.

The main trap is taking the empty section for a vendor oversight and making up the behavior. The directive is called deprecated, and that is all that is known about it; a guess about the meaning of the name remains a guess no matter how often it is repeated. A line in an inherited configuration should not be interpreted but removed — and if some client then stops logging in, deal with it through the login log rather than putting the line back.
What the Hub does. It does not write it — and could not: it is unknown what the line sets.

The Hub’s login settings are only documented ones: a login for each sending pair and a shared pool login — in sources with require-auth; plain-password login is allowed (allow-unencrypted-plain-auth), STARTTLS is offered but not required. There are no relaxations for non-standard clients there. Mail is submitted by sending platforms and the Hub’s warm-up; if someone’s client cannot log in, it will have to be sorted out through the login log, not with this line.

Recommended values

What to set. Nothing. The line should be removed from the configuration — this is the only recommendation that can be given without inventing anything.

Value When
do not write always
anything never: what the line controls is unknown

If the line turns up in an inherited file — remove it and check the login of the clients that submit mail to this node. Reverse replacement will not be needed: by the sense of the name, the line could only allow non-standard behavior, not forbid it, and removing it tightens the check rather than loosening it.

The deprecation mark and membership in the submission block are from the manual, § 3.3.7.16. The reading of the name and what to do with an inherited line are ours; the manual describes the directive’s behavior nowhere.
Example configuration
# the manual gives no example — this is how the line looks
# in an inherited configuration, and it has to be removed
<source 0/0>
    broken-auth-clients yes    require-auth true
</source>
The form of the value is derived from the directive type, not taken from the manual: it has no example. The upper line is removed, the lower one stays — it is the real login setting.
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▶

Looking for a description in another section of the manual

§ 3.3.7.16

What it costsThere is none anywhere: neither in the chapter on login nor in the directive index — the index links to the same empty section. Time goes into searching for what the vendor did not write.
How to spot itA search by name finds the table of contents, the section itself and the index — and all of it leads to the “deprecated” mark.
How to do it rightAccept it as it is: there is no content. Remove the line, and configure login behavior with directives that are documented.

Keeping the line “just in case”

§ 3.3.7.16

What it costsA deprecated directive without a description is a line nobody on the team can say what it does. Whenever a login problem is being investigated, it will distract attention every time.
How to spot itThe configuration contains a setting that no team member can explain.
How to do it rightRemove it. If a client’s login breaks after that, the cause will be found in the log and is fixed with documented directives.

Treating the name as documentation

§ 3.3.7.16

What it costs“Clients with broken login” is a plausible reading, but not a description. A setting built on a guess about someone else’s code behaves unpredictably, and there is nothing to check the guess against.
How to spot itIn a discussion of the configuration you hear “this line seems to be for clients that…”.
How to do it rightSeparate what is known from what is assumed. Here only the name, the block and the word “deprecated” are known.
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
broken-auth-clients <boolean>
Values
not documented — the manual section consists of the deprecation mark
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
By entry type — merging across matching <source> blocks, the narrow entry overriding the broad one, as with other submission settings. This cannot be checked against behavior: what the directive controls is unknown, and there is nothing to observe the result of merging by.
⇄

Related directives

2 relations

Applies to

allow-auth<source>A neighbor by section and by meaning: the real login switch. § 3.3.7.16Submission logins, plain-text passwords and per-user settingsThe login mechanism the directive belonged to. § 3.3.7.16

How to check on the node
It is looked for only in order to remove it:
grep -rn 'broken-auth-clients' /etc/pmta/
pmta test config
The second command checks that after the line is removed the configuration still parses. Whether the removal broke anything can only be confirmed through the login log: client logins after the configuration reload should go as before.
◇

What else to read

3 articles

◇Accept, route, deliverA message’s path inside the node: accept, decide where, deliver — and all the settings live between these three steps.◇Four value types the whole config is written inBoolean, domain pattern, regular expression and time interval — defined once in § 3.2 and then used by all directives.◇Reloading settings versus restarting the serviceThe configuration is read at startup, and after that edits are picked up by the reload command — except for the directives the manual marks as requiring a restart.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Configuration lifecycle
Neighboring settings of the block <source>:smtp-serviceretain-x-dkim-keyprocess-x-dkim-keyallowed-sender-listsrequire-authAll 74 directives of the block →