<transmissions-api>
Со значением true MTA пишет, как прошло согласование шифрования с подающим клиентом. По умолчанию выключено.
Переключатель и сами настройки TLS лежат в разных блоках. Шифрование входа настраивается в <transmissions-api-listener>, а этот переключатель — в <transmissions-api>. Разделение сбивает с толку: ищут запись рядом с тем, что она записывает.
Пишет в общий журнал MTA, а не в отдельный, — в отличие от веб-монитора с его собственным журналом.
Строка нужна ровно на время разбора. Успешные рукопожатия однообразны, а на потоке подачи объём заметен.
Включают на время разбора и выключают после:
| Значение | Когда |
|---|---|
| no (умолчание) | обычная работа |
| yes | разбираем, почему подающий клиент не согласует шифрование |
Порядок разбора. Сначала убедиться, что клиент вообще доходит до входа, потом включить запись, посмотреть причину, выключить.
# на время разбора: подающий клиент не согласует шифрование <transmissions-api> api-key 14ac5499cfdd2bb2859e4476d2e5b1d2bad079bf log-tls yes</transmissions-api>
что делают не так и чем это кончается2 ошибки▶
наш опыт
наш опыт
2 связи
grep -i "tls" /var/log/pmta/pmta.log | tail -30
3 статьи
◇Как письмо попадает в MTAШесть описанных способов подачи: расширенный SMTP, четыре языковые обвязки и каталог, за которым узел следит на диске.◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.◇Заголовки, которыми отправитель управляет доставкойШесть служебных заголовков позволяют подающей стороне выбрать поток, пометить письмо заданием, задать настройки и ключ подписи, идентификатор конверта и расписание; каждый разрешается отдельно и по источникам.