log-tls

<domain>

Записывать ли в журнал ход согласования TLS
в конфигурации это строкаlog-tls falseвнутри блока <domain>
То же имя ещё 2:<domain><source><transmissions-api>— часть из них другие настройки, часть та же самая
Единственный способ узнать, почему шифрование не сложилось

Строка включает подробную запись хода согласования TLS с этим приёмником. Умолчание — false.

Это диагностический переключатель, а не постоянная настройка. Учёт показывает результат — согласованную версию и шифр или пустое поле; журнал показывает почему результата нет: не предложен STARTTLS, не нашлось общего шифра, не сошлась цепочка сертификата.

Включать точечно и на время. Записей много, и на объёме они заметно добавляют журналу.

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

Значение булево, вопрос — когда включать:

Значение Когда
no (умолчание) всегда в обычной работе
yes разбор: в учёте пусто в поле версии протокола, и надо понять почему

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

Умолчание false — из руководства (§ 3.3.10.108.17). Порядок разбора и предупреждение про объём журнала — наши.
Пример в конфигурации
# на время разбора, одному приёмнику
<domain broken.example.com>
    use-starttls yes
    log-tls true</domain>
После разбора строку убирают. В <domain *> её не ставят: подробности согласования со всеми приёмниками сразу — это заметный объём журнала без всякой пользы.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Забывают выключить после разбора

наш опыт

Чем чреватоЖурнал растёт, ротация ускоряется, и записи о других событиях вытесняются раньше срока. Заметно это становится, когда понадобится история за прошлую неделю.
Как заметитьЖурналы за нужный день уже удалены ротацией.
Как правильноУбирать строку сразу после разбора. При правках через Хаб она и так исчезнет при следующем применении конфигурации.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
log-tls <boolean>
Значения
yes | no | true | false
Умолчание
false § 3.3.10.108.17
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Директива живёт в <domain> и сливается по обычному правилу блоков получателей: побеждает самое точное совпадение по имени приёмника. Те же три уровня действуют по адресу отправки — узел, <virtual-mta-pool>, <virtual-mta>.
⇄

Связанные директивы

1 связь

Как проверить на узле
Записи попадают в журнал узла; смотреть их надо по имени приёмника:
grep -i "tls" /var/log/pmta/pmta.log | tail -30
В строках видно, что предложил приёмник, какая версия и шифр согласованы и на каком шаге сорвалось. Пусто при включённой строке — значит до согласования дело не дошло вовсе: соединение не установилось.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Шифрование соединений