Knowledge base

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

smtp-tls-allow-sslv3

<domain>deprecated

Whether to allow SSLv3 — the directive no longer has any effect
in the configuration this is a linesmtp-tls-allow-sslv3inside the block <domain>
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 — only the fact that the protocol was removed from the distribution.

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

The page is needed for exactly one thing: when you come across the line in a migrated configuration, to understand that it does not work, and delete it.

The main trap is taking the line for an effective setting. It causes no error on apply and looks like an ordinary permission. A person reading the configuration concludes that the node can do SSLv3 and possibly uses it — which is wrong.
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 with this line is to remove it:

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

Versions are configured with the pair smtp-tls-min-version and smtp-tls-max-version.

The fact that the directive is no longer valid is from the manual (§ 3.3.10.108.10). The advice to delete it when migrating is ours.
Example configuration
# it should not be like this — the line does nothing
<domain hotmail.com>
    smtp-tls-allow-sslv3 false</domain>

# it is enough to remove it: versions are set with bounds
<domain hotmail.com>
    smtp-tls-min-version tlsv1.2
</domain>
The upper block is what is found in migrated configurations. The line 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.10.108.10

What it costssmtp-tls-allow-sslv3 false looks like a prohibition of an insecure protocol and therefore ends up in security configuration reports. In fact it does nothing — the prohibition is ensured by the lack of support.
How to spot itThe line is listed among protective measures in a configuration audit.
How to do it rightRemove the line and rely on smtp-tls-min-version: it is the only working way to set the 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
smtp-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
<domain>
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 live in <domain> and merge by the usual rule for recipient blocks — the most precise match by receiver name wins.
How to check on the node
There is one check — find and remove:
grep -rn smtp-tls-allow-sslv3 /etc/pmta/
Any line found is to be deleted. The node’s behavior will not change: there is no SSLv3 in the distribution.
In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Configuration lifecycle