Demo
Demo

Knowledge base

PMTA knowledge base›Block <smtp-listener>›Directive§ 3.3.17.2

immediate-tls

<smtp-listener>

Encrypt the connection from the first byte — SMTPS
in the configuration this is a lineimmediate-tls falseinside the block <smtp-listener>
Encryption before the greeting, not after

There are two different ways to encrypt submission. STARTTLS: the connection opens as plain, the client sees the greeting, sends STARTTLS, and only then does encryption begin. SMTPS — what this line enables: encryption begins from the first byte, before the greeting.

The default is false. The line is bound to a listener: it applies to connections that arrived at its address and port.

Historically SMTPS lives on port 465, while STARTTLS is on 25 and 587. That is why it is enabled on a separate listener rather than the main one: a client expecting a plain greeting will simply hang on an encrypted port.

What does not change — the certificate, versions and ciphers come from the same place as for STARTTLS: the listener or the node.

The main trap is enabling it on an existing listener. All clients connecting to that address and port expect a text greeting and get an encrypted stream. Submission stops entirely and at once, and the error message on the client side will be unclear — usually a timeout.
What the Hub does. It does not write it: submission goes over STARTTLS on the regular port, and that is enough. SMTPS will be needed if a platform appears that can do only SMTPS — then a separate listener is created on 465 and the line is enabled there, without touching the main one.
Recommended values

The value is boolean, but the decision is about a separate listener:

What How
regular submission STARTTLS on 25 or 587, this line is not needed
the platform can do only SMTPS a separate listener on 465, the line set to true
enabling it on an existing listener do not: submission will stop entirely

The port is not part of this line but part of the listener’s name. The line only changes how encryption begins.

The false default and the fact that the line implements SMTPS come from the manual (§ 3.3.17.2). The binding to port 465 and the advice to create a separate listener are ours.
Example configuration
# a separate listener for SMTPS — the main one is left untouched
smtp-listener 0.0.0.0:25

<smtp-listener 0.0.0.0:465>
    immediate-tls true</smtp-listener>
The main listener keeps accepting regular submission with STARTTLS; the new one encrypts from the first byte. Both take the certificate from the node if the listener has none of its own.
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 ends2 mistakes▶

Enabling it on the main listener

our experience

What it costsAll submitters expect a text greeting and get an encrypted stream. Submission stops entirely, and for clients it looks like a connection timeout — the cause is looked for anywhere but in this line.
How to spot itRight after the configuration is applied, all submission stops working with timeouts.
How to do it rightCreate a separate listener for SMTPS and leave the existing one alone.

Expecting the line to open port 465 by itself

§ 3.3.17.2

What it costsThe port is set by the listener’s name, not by this line. Without a listener declared on 465, there will be nowhere to connect.
How to spot itThe line is there, the port is closed.
How to do it rightDeclare <smtp-listener> on the needed address and port, and write the line inside it.
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
immediate-tls <boolean>
Values
yes | no | true | false
Default
false § 3.3.17.2
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<smtp-listener>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <smtp-listener> and applies to connections on its address and port; it has no levels — each listener is configured on its own. The certificate is inherited from the node if the listener does not set its own; the manual does not say this about the other encryption parameters.
⇄

Related directives

2 relations

Can be replaced by

allow-starttls<source>Another way to encrypt submission: there encryption begins at the client’s command, here from the first byte. § 3.3.17.2

Applies to

smtp-listenerGlobalThe line applies to this listener’s connections — on its address and port. § 3.3.17.2

How to check on the node
It is checked by connecting without waiting for the greeting — with encryption right away:
openssl s_client -connect localhost:465 -quiet
The node’s greeting appears after encryption is negotiated — that is SMTPS. If STARTTLS runs on the same port, the command will hang: the client waits for encryption, and the node for a text command.
◇

What else to read

3 articles

◇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.◇The load balancer header at the entranceThe node reads the PROXY header at the start of an incoming connection and treats the address from it as the source; this works for both kinds of entry point.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security · Connect a sending platform
Neighboring settings of the block <smtp-listener>:tls-certificatetls-min-versiontls-v1.3-ciphersuitestls-ca-filetls-ciphersAll 18 directives of the block →