Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 10.7

Authentication directive index

authentication directive index
A list of login settings

A list of directives related to mail authenticity and login, in one place: the manual collects them from the <source>, <domain> and <smtp-user> blocks, listeners and the Transmissions API.

Useful precisely as a summary: login and verification settings live in different blocks, and same-name ones — for example tls-ca-file — in several at once.

The main trap is looking for a directive in the wrong block. The list names the block for each line: check-spf-inbound lives in <source>, use-mta-sts in <domain>, and the same line in another block enables nothing.
What the Hub does. From the list the Hub writes require-auth, allow-unencrypted-plain-auth, smtp-max-auth-failure-rate, dkim-sign and domain-key; the summary is handy when analyzing its configuration.
Recommended values

The list by task:

Task Directives
login at submission require-auth, allow-auth, allow-unencrypted-plain-auth, smtp-max-auth-failure-rate
login at delivery auth-username, auth-password, use-unencrypted-plain-auth
message signing dkim-sign, domain-key, arc-sign
inbound verification check-spf-inbound, check-dkim-inbound, check-arc-inbound
delivery channel protection use-dane, use-mta-sts
The list and the directives’ blocks come from the manual (§ 10.7). The grouping by task is ours.
Example configuration
# find lines from the list in the node configuration
grep -nE 'require-auth|allow-auth|smtp-max-auth-failure-rate|auth-username|dkim-sign|domain-key' /etc/pmta/config /etc/pmta/*.txt
On Hub nodes some lines are in included files, so those are checked too.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
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

1 relation

Works together with

How the node signs messages and chooses a keyA related mechanism: they work together. § 10.7

How to check on the node
Compare the effective login and signing values for a pair:
pmta show settings gmail.com/vmta1 | grep -E 'auth|dkim'
The command’s response matters more than the file: it shows what is in effect after block merging.
◇

What else to read

3 articles

◇Do not send what will fail the check at the receiverThe node checks the SPF of its own mail before sending: if it fails, it bounces the message without waiting for someone else’s refusal.◇How the node signs messages and chooses a keyThe key is chosen by the sending domain from the headers, going through the declarations from top to bottom.◇A message header with which the submitting side adjusts the signatureFive parameters in X-DKIM-Options: selector, domain, signing identity, query method and key list.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Message signing and authentication