Demo
Demo

Knowledge base

PMTA knowledge base›Block <smtp-user>›Directive§ 3.3.8.1

password

<smtp-user>set by the Hub

The submission login password
in the configuration this is a linepasswordinside the block <smtp-user>
A secret that has to be stored in the clear

The line sets the login’s password. It applies only with the password login method — authentication-method set to password, which is also the default.

The password is stored in plain text, and this is a requirement, not an oversight. The manual explains: otherwise the full set of SASL mechanisms cannot be supported — CRAM-MD5 computes the challenge response from the password itself, and a hash is not enough for it. And right away it names the only measure: the permissions on the configuration file must be as strict as possible.

So the node’s configuration file is a password store. Anything that can read it reads them too: the configuration page in the web monitor, the file-based login of the HTTP API, a backup, a copy made for troubleshooting.

The engine does have a passwordless method — certificate login; there this problem does not arise at all.

The main trap is one password for several logins. Logins are created to separate senders, but the password is shared — it is easier to hand out and easier to change. After that the separation exists only on paper: knowing one password, a sender logs in under any name and gets the rights of any named source.

Revoking access one at a time then becomes impossible: removing access for one means changing the password for everyone.

What the Hub does. It writes it — in every login block of the working configuration. The value is set by the user in the cabinet (8 to 64 characters, no spaces or quotes); the Hub keeps it in an encrypted field of the working configuration and puts it on the node in plain text: otherwise the engine will not accept it.

🔴 There is one password for all of a node’s logins. Both the pool’s common login and the logins of individual “domain plus address” pairs get the same string. The names differ, the secret is shared — so today the separation of logins is nominal.

Recommended values

What to set. The manual places no requirements on the value itself — they come from the circumstances:

Property Why
unique for each login otherwise logins separate nothing, and revoking one access affects everyone
long and random the submission port is usually open to the network, and there is no login attempt limit by default
no spaces or quotes the configuration parser reads the value as a single word

If the password rotation process is so inconvenient that nobody will ever change them, certificate login is the more honest choice: there it is not a secret that needs changing but a certificate, and it has its own expiration date.

The requirement to store it in plain text, the reason (SASL support) and the advice about file permissions come from the manual, § 10.1.1 and § 3.3.8.1. The requirements for the value are ours.
Example configuration
# each login has its own password — otherwise the names separate nothing
<smtp-user shop-example-com>
    password 8xK2-qRt7-vD1s-mZ4w    source {shop-example-com-auth}
</smtp-user>
The password sits in the file in the clear — the engine requires it. Only one thing protects it: the permissions on the file itself.
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▶

Treating the configuration like an ordinary settings file

§ 10.1.1

What it costsA copy for troubleshooting, an email attachment, a branch in a code repository carry off all of the node’s submission passwords at once. All of them will have to be changed, because they sit side by side.
How to spot itThe configuration file turns up outside the node.
How to do it rightTreat it like a key file and do not take it off the node.

Giving all logins the same password

our experience

What it costsLogins stop separating senders: anyone who knows the single secret logs in under any name. Access cannot be revoked for one without breaking submission for everyone.
How to spot itIn the submission file all user blocks have the same password line.
How to do it rightA password of its own for each login. Then revoking one access does not affect the others.

Setting a password with a different login method

§ 3.3.8.1

What it costsWith certificate or LDAP login the line has no effect at all — and it stays in the file doing nothing, but with the full risk of a leak.
How to spot itThe login block has both a password and a login method other than password.
How to do it rightRemove the line: a secret that unlocks nothing is still a secret in a plain-text file.
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
password <string>
Values
a string
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<smtp-user>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <smtp-user> and applies to one login. It has no inheritance: user blocks do not merge with each other the way sources do — each describes its account in full.
⇄

Related directives

2 relations

Does not work without

authentication-method<smtp-user>The line applies only with the password login method, which is also the default. § 3.3.8.1Lock down permissions on configuration filesThe only protection for the password is the permissions on the file where it is stored in the clear. § 1.6.3

How to check on the node
It is worth checking not the value but the permissions on the file it sits in:
ls -l /etc/pmta/config /etc/pmta/virtualhost.txt
grep -c '^ *password ' /etc/pmta/virtualhost.txt
Only the node process and the administrator should be able to read the file. The second command shows how many passwords it holds; if there are several lines but one value, the logins are not separated.
◇

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 <smtp-user>:authentication-methodsourcetls-ca-filetls-certificatetls-certificate-san-or-cnAll 6 directives of the block →