Demo
Demo

Knowledge base

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

source

<smtp-user>set by the Hub

Which named source applies to this login
in the configuration this is a linesourceinside the block <smtp-user>
The same name 1:<smtp-listener><smtp-user>— some of them are other settings, some are the same one
Rights are granted to a login, not to a place in the network

The line names the <source> block that will apply to this login. Named blocks are not matched by address — this directive is one of the only two references that bring them into play at all (the second is the source= parameter of smtp-listener).

The manual describes the result in one word: the named block’s settings override what the connection would have gotten by its address. A login without this line gets the reserved {auth} source, if it is declared.

What it is for: this way rights and identity are assigned to an account. One login gets the right to choose a stream and hand over mail, another only to hand over mail, a third its own message size limit. For a node used by several senders, there is no other way to separate their rights.

The main trap is inheritance that may not be there. The manual says “overrides,” from which one reads that anything not mentioned will come from the address block. That is not what happened for us: return address rewriting set in the common 0/0 block did not carry over to the authenticated connection, and the address remained unchanged until the same line was repeated in the named block.

The practical conclusion is one: write out the whole set in the named block, not only the differences. And verify by behavior, not by reading the configuration.

What the Hub does. It writes it — in every login block of the working configuration. It builds the names of named sources from the login name: the pool’s common login goes to {pmta-auth}, a “domain plus address” pair login — to {<pair-name>-auth}.

In each such block the Hub writes out the full set — the submission service, relaying permission, the login requirement, stream selection, the selection list, suppression of local reports, header handling. Not out of caution: we did not see inheritance reach the authenticated connection.

The names are wrapped in curly braces — the format is shared with Protosender. The manual declares this name space reserved and names two of its own in it ({pickup} and {auth}); ours do not resemble them and work, but the space is still the vendor’s.

Recommended values

What to set. The value is a source block name; what you have to choose is the granularity:

Value When
a block of its own per login the senders differ, and their rights must differ
one block for all the senders have equal rights, and logins exist only for accounting
do not write it the reserved {auth}, declared once per node, is suitable

The first is the usual choice for a node used by several senders; the third is for a node where there is essentially one sender, with several logins for technical reasons.

The purpose and the word “overrides” come from the manual, § 3.3.8.6 and § 10.1.1. The caveat about the reserved source for logins without their own comes from there too. The observation about the lack of inheritance is ours.
Example configuration
# the login, its block and the full set of rights in it
<smtp-user shop-example-com>
    password 8xK2-qRt7-vD1s-mZ4w
    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 set in the named block is written out in full, not as differences: inheritance from address blocks into a named one was not confirmed on our installation.
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▶

Writing only differences in the named block

our experience

What it costsSettings left in the address block may not reach the authenticated connection. For us, return address rewriting disappeared this way — silently, without an error, and it was noticed only because the address in messages did not change.
How to spot itA setting works for submission without a login and does not work for the same submission with a login.
How to do it rightWrite out the whole set in the named block and verify by behavior.

Referring to an undeclared block

§ 3.3.8.6

What it costsThere will be no error: the login will log in and get the settings matched by the connection’s address. That is, the rights will not be the intended ones, and it will have to be sorted out by behavior.
How to spot itThe login works but behaves like an anonymous connection from the same address.
How to do it rightCompare the names: each login must have a declared block with exactly the same name.

Creating logins without separating their rights

§ 10.1.1

What it costsAll logins point to one block, and no separation arises: anyone who logs in gets the same rights, including choosing any sending stream.
How to spot itAll user blocks have the same source line.
How to do it rightA block of its own per login — with the set of rights this sender really needs.
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
source <name>
Values
a source block name
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 is not inherited itself. What is inherited is what it points to: the named source block takes effect after login and overrides what was matched by address. We do not advise relying on anything not mentioned in it coming from the address block.
⇄

Related directives

2 relations

Can be replaced by

smtp-listenerGlobalThe second reference to a named block: there the listener chooses it, here the account does. § 3.3.1.27

Applies to

How the node selects a source and combines its settingsNamed blocks come into play only through a direct reference, and this directive is one of the two such references. § 3.3.7

How to check on the node
The link between a login and its block is visible in the configuration; whether it works can only be seen from behavior:
grep -n '^<smtp-user\|^ *source ' /etc/pmta/virtualhost.txt
grep -n '^<source {' /etc/pmta/virtualhost.txt
Each login must have a declared block with the same name. A reference to an undeclared block silently gives nothing: the login will log in and get the settings matched by address.
◇

What else to read

3 articles

◇The source default is the bottom rung, tied to whoever connectsA source block matching the sender’s address can name a default stream; it applies when no choice was made higher up the ladder.◇How a message gets into the engineSix described submission methods: extended SMTP, four language bindings and a directory the node watches on disk.◇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
Connect a sending platform · Sender isolation
Neighboring settings of the block <smtp-user>:authentication-methodpasswordtls-ca-filetls-certificatetls-certificate-san-or-cnAll 6 directives of the block →