Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 10.1.1

Submission logins, plain-text passwords and per-user settings

inbound SMTP authentication
Identity moves from the network to the account

There are three login methods — LOGIN, PLAIN and CRAM-MD5. The last is always available when the AUTH command itself is enabled, and it does not send the password over the network: it is a response to a challenge, not a transfer of the secret.

Each name needs its own <smtp-user> block. Besides a password, login can be by system account (Linux only), via LDAP and by certificate.

Passwords are stored in the configuration in plain text. The manual names the reason directly: otherwise the full set of SASL mechanisms cannot be supported. And right away the only measure: the permissions on the configuration file must be as strict as possible. That is, the node’s configuration file is a password store, and anything that can read it reads them too: the configuration page in the web monitor, the file-based login of the HTTP API from chapter 8, a backup.

The advantage of CRAM-MD5 is half eaten away by this: the password does not travel over the network, but it sits on disk in the clear.

The second half of the mechanism is more interesting. A login is bound to a named source with the source directive, and that source’s settings override what the connection would have gotten by its address. Logins without their own source get the reserved {auth}.

This way rights and identity are assigned to a user, not to a place in the network. For a node used by several senders, this is the only working way to separate their rights.

The main trap is that the configuration file becomes a password store but is protected like a settings file. It is copied for troubleshooting, put into version control, handed to support, picked up by backups. Every such action carries away all of the node’s submission passwords.

A separate edge case is the web monitor: its configuration page shows the whole file. Whoever reaches the monitor has read the passwords, and no separate permission is needed for that.

What the Hub does. Password login is its main submission method. In the working configuration the Hub writes a <smtp-user> block for each “domain plus sending address” pair plus the pool’s common login, gives each its own named source and requires authentication.

The user sets the password in the cabinet; the Hub keeps it in an encrypted field of the working configuration and writes it to the node in plain text — otherwise the engine will not accept it.

🔴 All logins share one password. The names differ — pmtauser and one per pair — but the secret is shared across the node. So today the separation of logins is nominal: knowing one password, you can submit under any other login and choose any sending address on this node.

Example configuration
# a login, its source and the rights in it — three blocks working together
<smtp-user shop-example-com>
    password s3cret-not-shared    source {shop-example-com-auth}
</smtp-user>

<source {shop-example-com-auth}>
    smtp-service yes
    always-allow-relaying yes
    require-auth true
    default-virtual-mta shop-example-com
</source>
The named source’s settings apply after login and override what the connection would have gotten by its address. A login without the source line would get the reserved {auth} source.
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▶

Protecting the configuration file like a settings file

§ 10.1.1

What it costsA copy for troubleshooting, a branch in version control, an attachment in a support conversation — each such action carries away all of the node’s submission passwords at once. Changing one password does not help: they sit side by side.
How to spot itThe configuration file turns up where it does not belong — in a code repository, in email, in a shared folder.
How to do it rightTreat it like a key file: strict permissions, a separate copying procedure, no copies outside the node.

Considering CRAM-MD5 the solution to the password question

§ 10.1.1

What it costsIt really does not send the password over the network — but it requires the password to be stored on disk in the clear, otherwise there is nothing to compute the challenge response with. The network risk is closed, the file risk is open.
How to spot itA mechanism that does not transmit the password was chosen, while the configuration file permissions stayed ordinary.
How to do it rightTreat the questions separately: the mechanism covers the network, file permissions cover the disk. Both are needed.

Giving all logins the same password

our experience

What it costsLogins stop separating anything: knowing one password, you can submit under any name and choose any sending address on the node. Access cannot be revoked for one sender — only by changing the password for everyone at once.
How to spot itIn the submission file all user blocks have the same password line.
How to do it rightA password per login, not per node. Then revoking one access does not affect the others.
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.
⇄

Related entries

3 relations

Conflicts with

ConfigurationThe configuration page shows the whole file — including the submission passwords. inference

Overrides

How the node selects a source and combines its settingsThe named source of a logged-in user overrides what the connection’s address would have given. § 10.1.1

Affects

The node's main configuration fileThe configuration file turns out to be a password store and has to be protected accordingly. § 10.1.1

Referenced from

broken-auth-clients<source>The login mechanism the directive belonged to. § 3.3.7.16

How to check on the node
The logins and their sources are visible in the working file; its permissions are right next to it:
grep -n '^<smtp-user\|^ *source \|^ *require-auth' /etc/pmta/virtualhost.txt
ls -l /etc/pmta/config /etc/pmta/virtualhost.txt
The permissions must be such that only the node process and the administrator can read the file. Everything else — the web monitor, backups, the file-based HTTP API login — reads the passwords along with the settings.
◇

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.◇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.◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security · Sender isolation