require-auth
<source>Хаб задаёт сам
Умолчание — false. С true MTA требует вход до приёма любого письма по SMTP — и руководство отдельно оговаривает: локального в том числе.
Смысл директивы — сменить основание, по которому решается «можно ли этому клиенту». Без неё основание — адрес: попал в блок, которому разрешена ретрансляция, значит можно. С ней основание — логин.
Строка нужна ещё и второй директиве: предел неудачных попыток входа, по словам руководства, действует только там, где вход требуется, — smtp-max-auth-failure-rate.
Настоящий замок для невошедшего соединения — отсутствие разрешения на ретрансляцию в адресном блоке, под который оно попало. Если разрешение там есть, эта строка в именованном источнике его не отменит: невошедшее соединение до именованного источника не доходит.
Отсюда правило: требование входа ставят в адресный блок, а не только в именованный.
Невошедшее соединение при этом останавливает не эта строка, а то, что в общем блоке 0/0 нет разрешения на ретрансляцию: оно выдано источнику 127.0.0.1, блокам адресов из «Кому разрешена подача» и именованным источникам. У невошедшего соединения с другого адреса будет принято лишь то, что разрешено правилами приёма отчётов, — жалобы, отказы и роль-адреса. В адресных блоках требования входа нет: с адресов из списка подают и без логина.
Порог неудачных входов smtp-max-auth-failure-rate Хаб пишет в 0/0 как раз без этой строки — и порог срабатывает: в журнале узла отказы с пометкой smtp-max-auth-failure-rate reached (проверено 15.09.2026).
Что ставить. Вопрос — на чём держится право сдавать почту:
| Значение | Когда |
|---|---|
| no (умолчание) | право даёт адрес: подача идёт с известной машины из узкого диапазона |
| yes | право даёт логин: адрес подающей стороны меняется или заранее неизвестен |
Второе — почти всегда выбор парка: узлы стоят у разных хостеров, диапазон подачи не удержать. Тогда строка нужна в адресном блоке, а не только в именованных, и вместе с ней — smtp-max-auth-failure-rate.
# требование входа стоит в адресном блоке — там, где решается судьба # ещё не вошедшего соединения <source 0/0> require-auth true smtp-max-auth-failure-rate 5/m </source>
▲
Типичные ошибки и проблемы
что делают не так и чем это кончается3 ошибки▶
Ставят требование только в именованный источник
§ 10.1.1
Требуют вход без предела неудачных попыток
§ 3.3.7.8
Забывают про «локального в том числе»
§ 3.3.7.10
- Синтаксис
- require-auth <boolean>
- Значения
- yes | no | true | false
- Умолчание
- false § 3.3.7.10
- Применение
- reload, перезапуск не нужен
- Очередь
- уже поставленное в очередь не затронет
- Где писать
- <source>
- Сколько раз
- один раз в блоке
Связанные директивы
2 связи
grep -n 'require-auth\|always-allow-relaying' /etc/pmta/config /etc/pmta/virtualhost.txt printf 'HELO test\r\nMAIL FROM:<a@example.com>\r\nRCPT TO:<b@example.net>\r\nQUIT\r\n' | nc <адрес-узла> 2525
Что ещё почитать
3 статьи
◇Как узел выбирает источник и складывает его настройкиСоединение попадает под все блоки источника, чьи адреса его накрывают, и действуют они слитно — узкий перекрывает широкий; именованные блоки подключаются только по прямой ссылке.◇Логины подачи, пароли открытым текстом и настройки на каждогоОтправитель входит одним из трёх способов; каждый логин — блок конфигурации с паролем в открытом виде, и именованный источник этого логина перекрывает то, что дал бы его адрес.◇Лицензия на парк, а не на серверЛицензия не привязана к серверу: её ставят на столько машин, сколько разрешает предел экземпляров, а узлы раз в час отправляют вендору статистику объёма.
- Значение
- Хаб подбирает сам — темп, стадия прогрева, метрики
- Цена ошибки
- обратимо: вредит, пока стоит
- Сценарии
- Безопасность узла · Разделение отправителей