authentication-method

<smtp-user>

Чем подтверждается логин подачи
в конфигурации это строкаauthentication-method passwordвнутри блока <smtp-user>
Пять способов доказать, что подаёт свой

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

Пять значений, и три из них требуют шифрования соединения:

password — пароль. system — только Linux: пароль проверяется по учётным записям системы. certificate — клиент предъявляет тот самый файл сертификата, названный в tls-certificate. ca-file — клиент предъявляет любой сертификат, сходящийся к цепочке из tls-ca-file; при желании ещё и с проверкой имени (tls-certificate-san-or-cn). {vault}:ldap — пароль проверяется в LDAP через хранилище секретов, и пароль в конфигурации тогда не пишется вовсе.

Два способа с сертификатами требуют TLS-соединения — так прямо сказано в руководстве. Подающая программа должна уметь либо STARTTLS, либо SMTPS.

У LDAP есть ограничение по механизму: CRAM-MD5 с ним не работает, только LOGIN и PLAIN. То есть подача через некоторые API PowerMTA с этим способом невозможна.

Главная ловушка — выбрать LDAP и не заметить ограничения по механизму. CRAM-MD5 отпадает; остаются LOGIN и PLAIN, оба передают пароль почти открыто — а значит соединение обязано быть зашифровано, причём обязательно, а не по возможности.
Что делает Хаб. Не пишет — оставляет умолчание: подача идёт по логину и паролю, которые Хаб генерирует сам. Способы с сертификатами понадобятся, если появится платформа с взаимной проверкой; LDAP — если логины подачи начнут заводиться в общем каталоге организации.
Рекомендуемые значения

Пять значений и что каждое требует:

Значение Что нужно рядом Требует TLS
password (умолчание) password нет, но стоит требовать
system учётная запись в Linux нет, но стоит требовать
certificate tls-certificate с файлом да
ca-file tls-ca-file, при желании имя да
{vault}:ldap блок <vault>; пароль не пишется да, и только LOGIN или PLAIN

Для всех пяти разумно требовать шифрование перед авторизацией — require-starttls-before-auth.

Пять значений, умолчание password, требование TLS у сертификатных способов и ограничение LDAP по механизму — из руководства (§ 3.3.8.2). Совет про требование шифрования — наш.
Пример в конфигурации
# два логина, два разных способа проверки
<smtp-user foo>
    password barbaz
</smtp-user>

<smtp-user bar>
    authentication-method {vault}:ldap</smtp-user>
Пример руководства. У второго логина пароля в конфигурации нет вовсе — он проверяется в LDAP через хранилище. Но подойдут только механизмы LOGIN и PLAIN, а значит соединение обязано быть зашифровано.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Выбирают LDAP для подачи по CRAM-MD5

§ 3.3.8.2

Чем чреватоМеханизм CRAM-MD5 с этим способом несовместим. Подающая программа, настроенная на него, не сможет авторизоваться вовсе — и причина в отказе будет невнятной.
Как заметитьАвторизация не проходит только у одной платформы, у остальных работает.
Как правильноПеревести платформу на LOGIN или PLAIN — и обязательно требовать шифрование, оба механизма передают пароль почти открыто.

Включают сертификатную проверку без шифрования

§ 3.3.8.2

Чем чреватоСпособы certificate и ca-file требуют TLS-соединения. Без него авторизация невозможна, и подача останавливается.
Как заметитьЛогин с сертификатным способом не подключается ни разу.
Как правильноРазрешить STARTTLS в источнике, совпавшем по адресу (allow-starttls), или завести отдельный слушатель SMTPS.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
authentication-method <enumeration>
Значения
password | system | ca-file | certificate | vault-ldap (пишется как ссылка на хранилище)
Умолчание
password § 3.3.8.2
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<smtp-user>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Директива живёт в <smtp-user> и относится к одному логину; наследования у неё нет — каждый логин настраивается сам. Требование шифрования при этом задаётся в другом месте — в <source>, — и действует на соединение целиком, до того как логин назван.
Как проверить на узле
Проверяется попыткой авторизоваться выбранным способом:
printf 'EHLO test\r\nAUTH LOGIN\r\n' | openssl s_client -starttls smtp -connect localhost:25 -quiet 2>/dev/null | head -5
Приглашение ввести логин означает, что способ с паролем доступен. При способах с сертификатами узел ждёт его в ходе согласования TLS — и без него отказывает раньше, чем дело дойдёт до AUTH.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Безопасность узла · Разделение отправителей