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

require-starttls-before-auth

<source>

Требовать ли шифрование перед вводом пароля
в конфигурации это строкаrequire-starttls-before-auth falseвнутри блока <source>
Пароль не должен уходить открытым текстом

Строка требует от клиента выполнить STARTTLS до любой команды авторизации. Умолчание — false, то есть по умолчанию пароль может быть отправлен по незашифрованному соединению.

Это более мягкая форма требования, чем require-starttls: та требует шифрования перед всем, эта — только перед паролем. Подача без авторизации при этом продолжает работать как раньше.

Родственная строка — allow-unencrypted-plain-auth: она про то, можно ли пользоваться механизмом PLAIN на незашифрованном соединении. Две настройки закрывают одну и ту же дыру с разных сторон, и понимать их лучше вместе.

Главная ловушка — считать вопрос закрытым одной строкой. Есть второй путь: механизм PLAIN на открытом соединении, который разрешается отдельно. Если allow-unencrypted-plain-auth стоит true, пароль всё равно может уйти в открытую — просто другим способом.
Что делает Хаб. Не пишет, и это стоит пересмотреть. В базовой конфигурации разрешено шифрование и разрешён PLAIN на открытом соединении — то есть пароль подачи может уйти незашифрованным, если платформа настроена так. Строка закрывает это, ничего не ломая у тех, кто уже шифрует; включать её надо вместе с проверкой, что все подающие платформы умеют STARTTLS.
Рекомендуемые значения

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

Что стоит Может ли пароль уйти открытым
обе строки умолчанием да, двумя способами
только эта строка true нет — авторизация без шифрования запрещена
только allow-unencrypted-plain-auth false нет для PLAIN, да для других механизмов
эта true и PLAIN запрещён нет, с запасом

Практический минимум для узла подачи — эта строка. Она стоит дешевле самой строгой формы и закрывает главное.

Умолчание false — из руководства (§ 3.3.7.15). Сравнение с механизмом PLAIN и вывод про минимум — наши.
Пример в конфигурации
# минимум для узла подачи: пароль только по шифрованному соединению
<source 0/0>
    allow-starttls true
    require-starttls-before-auth true</source>
Подача без авторизации продолжит работать; изменится только то, что пароль нельзя будет отправить открытым текстом. Проверьте заодно allow-unencrypted-plain-auth: это второй путь к той же дыре.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Закрывают пароль только этой строкой

наш опыт

Чем чреватоОстаётся второй путь: механизм PLAIN на незашифрованном соединении разрешается отдельной строкой. Дыра закрыта наполовину.
Как заметитьСтрока стоит, а allow-unencrypted-plain-auth — true.
Как правильноСмотреть обе строки вместе. Для узла подачи разумно требовать шифрование перед паролем и не разрешать PLAIN в открытую.

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

§ 3.3.7.15

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

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

2 связи

Конфликтует

allow-unencrypted-plain-auth<source>Вторая сторона той же дыры: одна строка требует шифрования перед паролем, другая запрещает механизм PLAIN без шифрования. § 3.3.7.15

Работают в паре

require-auth<source>Требование шифрования имеет смысл там, где авторизация вообще нужна. § 3.3.7.10

Как проверить на узле
Проверяется попыткой авторизоваться без шифрования:
printf 'EHLO test\r\nAUTH LOGIN\r\nQUIT\r\n' | openssl s_client -connect localhost:25 -quiet 2>/dev/null | head -5
Отказ на команде AUTH означает, что требование действует. Ответ с приглашением ввести логин — что пароль сейчас может уйти открытым текстом.
◇

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

3 статьи

◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.◇Группа, дающая право управлятьЧленство в группе pmta даёт непривилегированному пользователю право звать команды узла и пользоваться подачей.◇Как узел выбирает источник и складывает его настройкиСоединение попадает под все блоки источника, чьи адреса его накрывают, и действуют они слитно — узкий перекрывает широкий; именованные блоки подключаются только по прямой ссылке.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Безопасность узла
Соседние настройки блока <source>:allow-starttlsrequire-starttlssmtp-serviceretain-x-dkim-keyprocess-x-dkim-keyВсе 74 директив блока →