Demo
Demo

Knowledge base

PMTA knowledge base›Block <transmissions-api-listener>›Directive§ 3.3.21.6

tls-allow-sslv3

<transmissions-api-listener>deprecated

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

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

A configuration may contain five such lines, and all five are to be deleted — the node’s behavior will not change.

On the API input it is especially pointless. Here, as everywhere, the version is set by a pair of bounds, not by switches.

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

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

What was found What to do
tls-allow-sslv3 in the API input block delete
the same lines for sending, receiving, the listener 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.21.6). The advice to delete all five copies is ours.
Example configuration
# it should not be like this — the line does nothing
<transmissions-api-listener 0/0:443>
    tls-allow-sslv3 false</transmissions-api-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 of the API input

§ 3.3.21.6

What it costsIt looks like a prohibition of an insecure protocol and ends up in security reports. In fact it does nothing, and the real lower bound stays as it was.
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 lower bound for this input.
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
<transmissions-api-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. The lower bound that replaces it is written in the same input block and does not extend to other inputs.
⇄

Related directives

1 relation

Replaced by

tls-min-version<transmissions-api-listener>It sets the lower bound on this input; separate switches are no longer needed. § 3.3.21.6

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 <transmissions-api-listener>:tls-certificatetls-min-versiontls-max-versiontls-cipher-server-preferencetls-ciphersAll 15 directives of the block →