Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 10.1.2

Authentication during delivery

outbound SMTP authentication
When the receiver requires a login

Authentication during outbound delivery: the node logs in on the receiver’s side with the CRAM-MD5, LOGIN or PLAIN mechanism, if the receiver supports it. LOGIN and PLAIN — only with use-unencrypted-plain-auth yes.

The login and password are set in the receiver block — auth-username and auth-password; without both, no login is performed.

Needed where the receiver requires a login — for example, corporate mail that accepts messages only from an identified sender. A receiver block inside a sending address limits the login to messages through that address.

The main trap is a plain-text password. LOGIN and PLAIN transmit the password unencrypted if the connection is not protected; that is why the manual requires explicit permission for them with use-unencrypted-plain-auth.
What the Hub does. Not used: our receivers are ordinary mail servers that require no login.
Recommended values

Login directives for delivery:

What Directive
login auth-username
password auth-password
allow LOGIN and PLAIN use-unencrypted-plain-auth yes
The mechanisms, directives and the example with a block inside a sending address come from the manual (§ 10.1.2). The trap analysis is ours.
Example configuration
<virtual-mta auth-mta>
    smtp-source-host 1.2.3.4 vmta.esp.com
    <domain secure.example.org>
        auth-username costanza        auth-password bosco
    </domain>
</virtual-mta>
An example from the manual: login only for messages to secure.example.org through this sending address.
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

2 relations

Depends on

How the policy for a receiver is assembledThe same setting at another level. § 10.1.2

Works together with

The stream is chosen by matching the envelope or a headerA related mechanism: they work together. § 10.1.2

How to check on the node
Check how the login goes:
pmta trace secure.example.org/auth-mta
tail -40 /var/log/pmta/log
In the recorded conversation, after EHLO there must be an AUTH command and the receiver’s reply to it.
◇

What else to read

3 articles

◇How a message gets into the engineSix described submission methods: extended SMTP, four language bindings and a directory the node watches on disk.◇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.◇Headers the sender uses to control deliverySix control headers let the submitting side choose a stream, tag a message with a job, set signing options and the key, the envelope identifier and the schedule; each is allowed separately and per source.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Connect a sending platform