Demo
Demo

Knowledge base

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

tls-allow-sslv3

<smtp-listener>deprecated

Whether to accept SSLv3 on this input — the directive has no effect
in the configuration this is a linetls-allow-sslv3inside the block <smtp-listener>
The same name 1:<smtp-listener><transmissions-api-listener>— some of them are other settings, some are the same one
The third copy of a line that does nothing

Like its namesakes for receiving and sending, the line is not valid: the protocol is not in the distribution.

A configuration may contain five such lines — for sending to the receiver, for receiving mail by the node, for the listener, for the Transmissions API input and for the web monitor. All five are to be deleted, and the node’s behavior will not change.

The main trap is taking the line for an effective setting. It causes no error and looks like an ordinary permission; in security configuration reports it regularly appears as a “prohibition of an insecure protocol”.
What the Hub does. It does not write it — and could not: there is no protocol support.
Recommended values

There are no values. The only action is to remove it:

What was found What to do
tls-allow-sslv3 for the listener delete
the same lines for sending, receiving, the API input and the monitor delete too
other tls-allow-* next to it rewrite as a pair of bounds
The fact that the directive is no longer valid is from the manual (§ 3.3.17.9). The advice to delete all five copies is ours.
Example configuration
# it should not be like this — the line does nothing
<smtp-listener 0.0.0.0:25>
    tls-allow-sslv3 false</smtp-listener>
Found in migrated configurations. Deleting it will not change behavior: the protocol is not in the distribution.
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 ends1 mistake▶

Considering the line an effective protection

§ 3.3.17.9

What it costsIt looks like a prohibition of an insecure protocol and ends up in security configuration reports. In fact it does nothing.
How to spot itThe line is listed among protective measures in a configuration audit.
How to do it rightRemove it and rely on tls-min-version: it is the only working way to set the listener’s lower bound.
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
tls-allow-sslv3 <boolean>
Values
values are not applied — the directive has no effect
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
There is no inheritance to discuss: the line has no effect at any level. The bounds that replace it are written in the same listener block; the manual does not promise them inheritance from the node level.
⇄

Related directives

1 relation

Replaced by

tls-min-version<smtp-listener>Versions on this input are set by a pair of bounds; separate switches are no longer needed. § 3.3.17.9

How to check on the node
There is one check — find all five copies and remove them:
grep -rn "tls-allow-sslv3" /etc/pmta/
Lines for sending, receiving by the node, the listener, the Transmissions API input and the web monitor will be found. All are to be deleted.
◇

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 <smtp-listener>:tls-certificatetls-min-versionimmediate-tlstls-v1.3-ciphersuitestls-ca-fileAll 18 directives of the block →