Логины подачи, пароли открытым текстом и настройки на каждого

inbound SMTP authentication
Личность переезжает из сети в учётную запись

Способов входа три — LOGIN, PLAIN и CRAM-MD5. Последний доступен всегда, когда включена сама команда AUTH, и пароль по сети не передаёт: это ответ на вызов, а не пересылка секрета.

На каждое имя нужен свой блок <smtp-user>. Кроме пароля, вход бывает по системному логину (только Linux), через LDAP и по сертификату.

Пароли лежат в конфигурации открытым текстом. Причину руководство называет прямо: иначе не поддержать весь набор механизмов SASL. И тут же — единственную меру: права на файл конфигурации должны быть настолько строгими, насколько возможно. То есть файл конфигурации узла — это хранилище паролей, и всё, что умеет его прочитать, читает и их: страница конфигурации в веб-мониторе, файловый вход HTTP API главы 8, резервная копия.

Достоинство CRAM-MD5 этим наполовину съедено: пароль не ходит по сети, зато лежит открытым на диске.

Вторая половина механизма интереснее. Логин привязывается к именованному источнику директивой source, и настройки этого источника перекрывают то, что соединение получило бы по своему адресу. Логинам без своего источника достаётся зарезервированный {auth}.

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

Главная ловушка — файл конфигурации становится хранилищем паролей, а защищается как файл настроек. Его копируют для разбора, кладут в систему контроля версий, отдают в поддержку, забирают резервным копированием. Каждое такое действие уносит с собой все пароли подачи узла.

Отдельный край — веб-монитор: его страница конфигурации показывает файл целиком. Кто дошёл до монитора, тот прочитал пароли, и никакого отдельного права на это не нужно.

Что делает Хаб. Вход по паролю — его основной способ подачи. В рабочей конфигурации Хаб выписывает блок <smtp-user> на каждую пару «домен плюс адрес отправки» плюс общий логин пула, каждому даёт свой именованный источник и требует авторизации.

Пароль пользователь задаёт сам в кабинете; Хаб держит его в зашифрованном поле рабочей конфигурации и пишет на узел открытым текстом — иначе MTA его не примет.

🔴 Пароль у всех логинов один. Имена разные — pmtauser и по имени каждой пары, — а секрет общий на узел. Значит разделение логинов сегодня номинальное: зная пароль одного, можно подать под любым другим и выбрать любой адрес отправки этого узла.

Пример в конфигурации
# логин, его источник и права в нём — три блока, работающие вместе
<smtp-user shop-example-com>
    password s3cret-not-shared    source {shop-example-com-auth}
</smtp-user>

<source {shop-example-com-auth}>
    smtp-service yes
    always-allow-relaying yes
    require-auth true
    default-virtual-mta shop-example-com
</source>
Настройки именованного источника действуют после входа и перекрывают то, что соединение получило бы по своему адресу. Логину без строки source достался бы зарезервированный источник {auth}.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Защищают файл конфигурации как файл настроек

§ 10.1.1

Чем чреватоКопия для разбора, ветка в системе контроля версий, вложение в переписку с поддержкой — каждое такое действие уносит все пароли подачи узла разом. Смена одного пароля при этом не помогает: они лежат рядом.
Как заметитьФайл конфигурации встречается там, где ему не место, — в хранилище кода, в почте, в общей папке.
Как правильноОбращаться с ним как с файлом ключей: строгие права, отдельный порядок копирования, никаких копий вне узла.

Считают CRAM-MD5 решением вопроса паролей

§ 10.1.1

Чем чреватоОн действительно не передаёт пароль по сети — но требует, чтобы пароль лежал на диске открытым, иначе ответ на вызов посчитать нечем. Сетевой риск закрыт, файловый открыт.
Как заметитьВыбран механизм без передачи пароля, а права на файл конфигурации остались обычными.
Как правильноСчитать вопросы раздельно: механизм закрывает сеть, права на файл — диск. Нужны оба.

Дают всем логинам один пароль

наш опыт

Чем чреватоЛогины перестают что-либо разделять: зная один пароль, можно подать под любым именем и выбрать любой адрес отправки узла. Отозвать доступ одному отправителю нельзя — только сменить пароль всем сразу.
Как заметитьВ файле подачи у всех блоков пользователя одинаковая строка пароля.
Как правильноПароль на логин, а не на узел. Тогда отзыв одного доступа не задевает остальных.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Как проверить на узле
Логины и их источники видны в рабочем файле; права на него — рядом:
grep -n '^<smtp-user\|^ *source \|^ *require-auth' /etc/pmta/virtualhost.txt
ls -l /etc/pmta/config /etc/pmta/virtualhost.txt
Права должны быть такими, чтобы файл читал только процесс узла и администратор. Всё остальное — веб-монитор, резервные копии, файловый вход HTTP API — читает вместе с настройками и пароли.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Безопасность узла · Разделение отправителей