Demo
Demo
База знаний PMTA›Блок <source>›Директива§ 3.3.7.14

require-starttls

<source>

Требовать ли шифрование до любых команд при подаче
в конфигурации это строкаrequire-starttls falseвнутри блока <source>
То же имя ещё 1:<domain><source>— часть из них другие настройки, часть та же самая
Никаких команд, пока соединение не зашифровано

Строка требует от подающего клиента выполнить STARTTLS прежде любых команд, кроме перечисленных в руководстве: EHLO, QUIT, NOOP, XACK, RSET и самой STARTTLS. Умолчание — false.

Это самая строгая из двух форм требования. Соседняя require-starttls-before-auth требует шифрования только перед паролем; эта — перед всем.

Работает лишь вместе с разрешением. allow-starttls должен стоять в том же источнике, иначе требовать нечего.

Цена — совместимость. Клиент, который не умеет STARTTLS или настроен на открытую подачу, не сможет подать вовсе.

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

Две формы требования, и они разной строгости:

Строка Что требует Кого теряете
не задавать (умолчание) ничего никого; пароли могут уйти открытым текстом
require-starttls-before-auth шифрование перед паролем тех, кто шлёт пароль в открытую
эта строка шифрование перед всем ещё и тех, кто подаёт без авторизации

Разумный порядок — сначала вторая строка, и только если подача целиком под контролем, третья.

Умолчание false и список разрешённых до шифрования команд — из руководства (§ 3.3.7.14). Сравнение двух форм требования — наше.
Пример в конфигурации
# самая строгая форма — обе строки в источнике, совпавшем по адресу
<source 10.0.0.0/24>
    allow-starttls true
    require-starttls true</source>
Пример руководства, сужённый до подсети подачи. В <source> 0/0 такую строку ставят только тогда, когда все подающие точно умеют шифрование.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Ставят требование без разрешения

§ 3.3.7.14

Чем чреватоТребовать нечего: узел не объявляет STARTTLS вовсе. Клиенты не могут ни зашифроваться, ни подать открытым текстом — подача останавливается полностью.
Как заметитьВсе подающие получают отказ на первой же команде.
Как правильноСтавить allow-starttls в том же источнике. Это одна настройка из двух строк.

Включают самую строгую форму сразу

наш опыт

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

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

1 связь

Без чего не работает

allow-starttls<source>Требовать нечего, пока шифрование не разрешено: обе строки нужны вместе. § 3.3.7.14

Сюда ссылаются

require-starttls<domain>Однофамилец с другой стороны: тот про приём почты узлом, этот — про отправку. § 3.3.7.14

Как проверить на узле
Проверяется попыткой подать команду без шифрования:
printf 'EHLO test\r\nMAIL FROM:<a@b.c>\r\nQUIT\r\n' | openssl s_client -connect localhost:25 -quiet 2>/dev/null | head -5
Отказ на команде MAIL FROM означает, что требование действует. Успешный приём — что строки нет или она в источнике, который не совпал по адресу.
◇

Что ещё почитать

3 статьи

◇Подача по HTTPS на своём приёмнике, по образцу SparkPostОтдельный вход: свой приёмник с сертификатом, свои ключи и зарезервированное имя источника, через которое к такой почте применяются обычные настройки подачи.◇Приёмник объявляет требование шифрования на своём сайтеУзел забирает политику получателя по HTTPS и, если та в режиме принуждения, доставляет только при совпадении MX, шифровании и проверенном сертификате.◇Приёмник объявляет требование шифрования в своей зоне DNSУзел смотрит записи DANE получателя и, если тот требует STARTTLS, отправляет только по зашифрованному каналу с проверенным по отпечатку сертификатом.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Шифрование соединений
Соседние настройки блока <source>:require-starttls-before-authallow-starttlssmtp-serviceretain-x-dkim-keyprocess-x-dkim-keyВсе 74 директив блока →