<smtp-user>

Учётная запись для подачи почты
Право сдавать почту, привязанное к имени, а не к адресу

Блок описывает одного пользователя, которому позволено ретранслировать почту через узел — независимо от адреса, с которого он подаёт. Имя блока и есть логин.

Внутри две обязательные по смыслу части: чем подтверждается вход и какие права даются вошедшему.

Подтверждается вход директивой authentication-method — паролем (умолчание), сертификатом, системным логином на Linux или через LDAP. Для парольного нужен password, для сертификатного — tls-certificate и, если проверяется цепочка, tls-ca-file с tls-certificate-san-or-cn.

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

Пароли здесь лежат открытым текстом — так требует MTA, иначе не поддержать все механизмы SASL. Значит файл конфигурации надо защищать как файл ключей.

Пример в конфигурации
# вход по паролю и свой набор прав через именованный источник
<smtp-user shop-example-com>
    password 8xK2-qRt7-vD1s-mZ4w
    source {shop-example-com-auth}
</smtp-user>

# вход по сертификату — пароля не требуется вовсе
<smtp-user partner>
    authentication-method certificate
    tls-certificate /etc/pmta/partner.pem
    source {partner-auth}
</smtp-user>
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Жизненный цикл конфигурации