Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.12

smtp-server-tls-allow-sslv3

Globaldeprecated

Whether to accept SSLv3 — the directive no longer has any effect
in the configuration this is a linesmtp-server-tls-allow-sslv3inside the block Global
A line that does nothing

The manual says one thing about this line: it is no longer valid because PowerMTA does not support SSLv3. It has neither a value nor a default.

That is how it should be. SSLv3 was recognized as unfit more than ten years ago; its absence is the normal state, not a limitation.

The same line exists for sending — smtp-tls-allow-sslv3 in the recipient block — and it has no effect either.

The main trap is taking the line for an effective setting. It causes no error and looks like an ordinary permission; a person reading the configuration concludes that the node can do SSLv3.
What the Hub does. It does not write it — and could not: there is no protocol support. The line appears only in configurations migrated from very old versions, and it should simply be deleted.
Recommended values

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

What was found What to do
smtp-server-tls-allow-sslv3 delete, behavior will not change
other smtp-server-tls-allow-* next to it rewrite them all as a pair of bounds

Versions for receiving are set by the pair smtp-server-tls-min-version and smtp-server-tls-max-version.

The fact that the directive is no longer valid is from the manual (§ 3.3.1.12). The advice to delete it when migrating is ours.
Example configuration
# it should not be like this — the line does nothing
smtp-server-tls-allow-sslv3 false
# it is enough to remove it: versions are set with bounds
smtp-server-tls-min-version tlsv1.2
The upper line is found in migrated configurations. It will cause no error and 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.1.12

What it costssmtp-server-tls-allow-sslv3 false 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 smtp-server-tls-min-version: it is the only working way to set the lower bound for receiving.
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-server-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
Global
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 at the root of the file, the Global section, and apply to the whole node; a listener has its own set.
How to check on the node
There is one check — find and remove:
grep -rn "tls-allow-sslv3" /etc/pmta/
All five such lines will be found — for sending, receiving by the node, the listener, the Transmissions API input and the web monitor. All are to be deleted: the node’s behavior will not change.
In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Configuration lifecycle