log-tls

<transmissions-api>

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

Со значением true MTA пишет, как прошло согласование шифрования с подающим клиентом. По умолчанию выключено.

Переключатель и сами настройки TLS лежат в разных блоках. Шифрование входа настраивается в <transmissions-api-listener>, а этот переключатель — в <transmissions-api>. Разделение сбивает с толку: ищут запись рядом с тем, что она записывает.

Пишет в общий журнал MTA, а не в отдельный, — в отличие от веб-монитора с его собственным журналом.

Строка нужна ровно на время разбора. Успешные рукопожатия однообразны, а на потоке подачи объём заметен.

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

Включают на время разбора и выключают после:

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

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

Умолчание false и назначение — из руководства (§ 3.3.20.4). Что пример в этом разделе показывает не ту директиву — наша находка. Совет выключать после разбора — наш.
Пример в конфигурации
# на время разбора: подающий клиент не согласует шифрование
<transmissions-api>
    api-key 14ac5499cfdd2bb2859e4476d2e5b1d2bad079bf
    log-tls yes</transmissions-api>
Руководство в этом разделе (§ 3.3.20.4) показывает в примере log-data yes — не ту директиву, о которой раздел. Здесь пример исправлен.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Ищут переключатель в блоке входа рядом с настройками TLS

наш опыт

Чем чреватоНастройки шифрования и запись их хода разведены по двум блокам. Пока это не замечено, строку пишут не туда, и записи не появляются.
Как заметитьСтрока стоит в блоке входа, в журнале ничего.
Как правильноПисать в <transmissions-api>, а не в <transmissions-api-listener>.

Оставляют запись включённой после разбора

наш опыт

Чем чреватоКаждое подключение подающего клиента добавляет строки в общий журнал MTA — тот самый, где ищут историю доставки.
Как заметитьЖурнал растёт быстрее обычного, ротация ускоряется.
Как правильноВернуть no сразу после разбора.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
log-tls <boolean>
Значения
yes | no | true | false
Умолчание
false § 3.3.20.4
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<transmissions-api>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Наследования нет: строка пишется в <transmissions-api> и действует на всю подачу по API. Разделения по входам у неё нет — входов может быть несколько, а переключатель один.
Как проверить на узле
Записи попадают в общий журнал MTA:
grep -i "tls" /var/log/pmta/pmta.log | tail -30
В строках видно версию, шифр и шаг, на котором сорвалось. Пусто при включённой строке — значит до согласования дело не дошло: клиент не достучался до входа.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Подключить платформу отправки