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

allow-unencrypted-plain-auth

<source>Хаб задаёт сам

Разрешать ли механизм PLAIN на незашифрованном соединении
в конфигурации это строкаallow-unencrypted-plain-auth falseвнутри блока <source>
Второй путь, которым пароль уходит в открытую

Механизм авторизации PLAIN передаёт логин и пароль в кодировке, а не в шифре: прочитать их из перехваченного трафика — дело одной команды. Строка решает, можно ли им пользоваться на незашифрованном соединении.

Умолчание — false, то есть по умолчанию нельзя. Это верное умолчание, и включают его обычно ради совместимости с платформой, которая иначе не подключается.

Вторая сторона той же дыры — require-starttls-before-auth. Одна строка запрещает конкретный механизм без шифрования, другая требует шифрования перед любой авторизацией. Смотреть их надо вместе.

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

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

Эта строка require-starttls-before-auth Пароль в открытую
no (умолчание) не задан нет для PLAIN, возможно для других механизмов
yes не задан да
yes true нет: авторизация только по шифрованному соединению
no true нет, с запасом

Если включать пришлось — включать вместе с требованием шифрования перед авторизацией. Тогда разрешение относится к соединениям, которые и так зашифрованы.

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

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

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

Включают при отладке и оставляют навсегда

наш опыт

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

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

2 связи

Конфликтует

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

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

allow-starttls<source>Разрешение шифрования — то, что делает эту настройку осмысленной: без него шифрованных соединений просто нет. § 3.3.7.13

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

use-unencrypted-plain-auth<domain>Зеркальная строка для приёма писем: та про подающих нам, эта про нас, представляющихся чужому релею. § 3.3.10.65

Как проверить на узле
Проверяется тем же способом, что и требование, — попыткой авторизоваться без шифрования:
printf 'EHLO test\r\nQUIT\r\n' | nc localhost 25 | grep -i "AUTH"
Если в списке расширений на незашифрованном соединении есть AUTH PLAIN, механизм разрешён в открытую. При включённом требовании шифрования перед авторизацией строки AUTH там быть не должно.
◇

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

3 статьи

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

В Хабе
Значение
Хаб подбирает сам — темп, стадия прогрева, метрики
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Безопасность узла
Соседние настройки блока <source>:smtp-serviceretain-x-dkim-keyprocess-x-dkim-keyrequire-authallowed-sender-listsВсе 74 директив блока →