Demo
Demo

Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.108.7

smtp-tls-allow-tlsv1.1

<domain>deprecated

Whether to allow TLS 1.1 — a deprecated switch
in the configuration this is a linesmtp-tls-allow-tlsv1.1 trueinside the block <domain>
The old way to choose protocol versions

The line allows or forbids the node to negotiate TLS 1.1 when sending. Deprecated since PowerMTA 5.5: instead of five switches the vendor offers two bounds — smtp-tls-min-version and smtp-tls-max-version.

It matches the current default of the lower bound: tlsv1.1 is what the node does not go below even without any switches.

Why the page is needed. Such lines live for years in configurations migrated from earlier versions. When you come across them, you need to understand not how to configure them but what to replace them with.

The main trap is mixing the two methods in one configuration. Switches and bounds describe the same thing, and the manual does not explain which setting wins. A configuration with both methods reads ambiguously — and there will be no warning on apply.
What the Hub does. It does not write it: it uses a pair of bounds, or rather their defaults. It is worth recognizing the line on sight when analyzing someone else’s configuration: it means the TLS settings were migrated from a version older than 5.5 and it is time to rewrite them.
Recommended values

Do not translate the value — migrate it. The set of five switches is expressed with a pair of bounds like this:

What it was What it became
tlsv1.2 and tlsv1.3 allowed smtp-tls-min-version tlsv1.2
all from tlsv1 allowed smtp-tls-min-version tlsv1
tlsv1.3 forbidden smtp-tls-max-version tlsv1.2
everything by default neither line is needed

Check after migration in accounting: the negotiated version is visible in the protocol field.

Deprecation as of version 5.5 and the default true are from the manual (§ 3.3.10.108). The migration table is ours.
Example configuration
# this is how it was before
<domain hotmail.com>
    smtp-tls-allow-tlsv1.1 true</domain>

# this is how it is written now
<domain hotmail.com>
    smtp-tls-min-version tlsv1.2
</domain>
The lower block replaces the upper one. A pair of bounds describes the whole range at once and is easier to read than five separate switches.
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▶

Leaving switches next to bounds

§ 3.3.10.108

What it costsThe two methods describe the same thing, and the manual does not name the precedence between them. The configuration reads ambiguously and is applied without warnings.
How to spot itThe negotiated version matches neither what the switches allow nor what the bounds set.
How to do it rightRemove the switches entirely and keep only the bounds. Check the replacement in accounting.

Migrating a configuration without touching deprecated lines

our experience

What it costsThe lines still work today, so the problem is not noticeable — until the next upgrade, when support may be removed. Then the version settings will silently revert to defaults.
How to spot itAfter a PowerMTA upgrade the negotiated protocol version changes.
How to do it rightRewrite them as bounds when migrating the configuration, not afterwards.
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
smtp-tls-allow-tlsv1.1 <boolean>
Values
yes | no | true | false
Default
true § 3.3.10.108.7
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <domain> and merges by the usual rule for recipient blocks: the most precise match by receiver name wins. The same three levels apply by sending address — node, <virtual-mta-pool>, <virtual-mta>. The bounds that replace it are inherited in exactly the same way.
⇄

Related directives

1 relation

Replaced by

smtp-tls-min-version<domain>Replaced the whole set of five switches: the version range is set by a pair of bounds, not by five separate lines. § 3.3.10.108.7

How to check on the node
Finding such lines in the configuration is the first step of migration:
grep -rn smtp-tls-allow /etc/pmta/
Each line found means a setting migrated from a version older than 5.5. They should be replaced with a pair of bounds, and the result checked by the protocol field in accounting.
◇

What else to read

3 articles

◇Submission over HTTPS on its own listener, modeled on SparkPostA separate entry point: its own listener with a certificate, its own keys and a reserved source name through which the usual submission settings apply to such mail.◇The receiver declares an encryption requirement on its websiteThe node fetches the recipient domain’s policy over HTTPS and, if it is in enforce mode, delivers only when the MX matches, the connection is encrypted and the certificate is verified.◇The receiver declares an encryption requirement in its DNS zoneThe node looks at the recipient domain’s DANE records and, if STARTTLS is required, sends only over an encrypted channel with a certificate verified by fingerprint.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Connection encryption
Neighboring settings of the block <domain>:use-mta-stssmtp-tls-min-versionuse-starttlsuse-danerequire-starttlsAll 135 directives of the block →