tls-max-version

<transmissions-api-listener>

Верхняя граница версии TLS на входе Transmissions API
в конфигурации это строкаtls-max-version none — действует как tlsv1.3внутри блока <transmissions-api-listener>
То же имя ещё 1:<smtp-listener><transmissions-api-listener>— часть из них другие настройки, часть та же самая
Потолок версии на втором способе подачи

Вторая граница того же диапазона, что и tls-min-version. Умолчания нет — потолок не ограничен, и вход согласует самую новую версию, которую предложит клиент.

Повод поставить потолок один: библиотека в подающей программе объявляет современную версию и на ней срывается. У API это обычный случай — клиент пишут сами, и его HTTP-библиотека может быть старой.

Это обход чужой поломки, а не настройка безопасности.

Главная ловушка — поставить потолок и забыть. Библиотеку обновят, повод исчезнет, а вход останется на старой версии — вместе с ключом подачи, который в нём передаётся.
Что делает Хаб. Не пишет: подача у нас идёт по SMTP, блока входа по API в конфигурации нет.
Рекомендуемые значения

Ставить только по конкретному поводу:

Значение Когда
не задавать (умолчание) всегда
tlsv1.2 библиотека подающего клиента рвёт 1.3

Строку сопровождают комментарием с поводом и датой — иначе она переживёт причину, по которой появилась.

Значения и отсутствие умолчания — из руководства (§ 3.3.21.8). Совет записывать повод и дату — наш.
Пример в конфигурации
# обход поломки в клиенте, а не настройка безопасности
<transmissions-api-listener 1.2.3.4:8585>
    tls-certificate /etc/pmta/transmissions-api-certificate.pem
    tls-max-version tlsv1.2   # библиотека клиента X рвёт 1.3; проверить в 2027</transmissions-api-listener>
Комментарий с поводом и сроком — часть строки. Второй вход можно оставить без потолка: границы у входов независимы.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается2 ошибки▶

Понижают потолок «на всякий случай»

наш опыт

Чем чреватоПотолок ничего не защищает — он только запрещает новое. На входе, через который идёт ключ подачи, это чистая потеря.
Как заметитьВход согласует 1.2 при том, что клиенты умеют 1.3.
Как правильноУбрать строку. Ограничивать снизу — задача tls-min-version.

Ставят потолок вместо разбора поломки клиента

наш опыт

Чем чреватоПричина — библиотека в подающей программе — остаётся, и та же поломка вылезет на любом другом входе, куда эта программа ходит.
Как заметитьКлиент работает с вашим API и не работает больше нигде.
Как правильноСтавить потолок как временную меру и заводить задачу на обновление клиента.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
tls-max-version { tlsv1 | tlsv1.1 | tlsv1.2 | tlsv1.3 }
Значения
tlsv1 | tlsv1.1 | tlsv1.2 | tlsv1.3
Умолчание
none — действует как tlsv1.3 § 3.3.21.8
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<transmissions-api-listener>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Наследования нет: строка действует внутри своего <transmissions-api-listener>. У каждого входа граница своя, и настройки почтового слушателя сюда не достают.
Как проверить на узле
Спрашиваем вход о самой новой версии — она должна согласоваться, если потолок не ставили:
openssl s_client -connect NODE:8585 -tls1_3 -brief </dev/null
Protocol version: TLSv1.3 — потолка нет. alert protocol version вместо этого означает, что потолок стоит и опущен ниже 1.3.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Безопасность узла