always-allow-relaying

GlobalкритичноХаб задаёт сам

Разрешить источнику сдавать почту для любых получателей
в конфигурации это строкаalways-allow-relaying falseвнутри блока Global
Кому разрешено слать через этот узел куда угодно

Умолчание — false. Строка разрешает названному источнику отправлять почту любому получателю — то есть не только на домены, которые узел объявил своими.

Совет руководства прямой: включать её в блоках источника внутренних машин, которые подают почту на узел по SMTP.

Это и есть то, ради чего почтовый узел существует как отправитель, — и то, что превращает его в открытый релей, если источник указан неверно.

Из коробки релей запрещён. Пока источники не разрешены явно, узел принимает подачу только с адреса 127.0.0.1.

Главная ловушка — маска подсети. Источник задаётся адресом или сетью, и 0/0 означает «кто угодно». Между «работает» и «катастрофа» здесь один символ.

Вторая половина тише: право по адресу не переживает переезд. Платформа сменила хостера — подача встала, и лечат это обычно расширением маски. Расширенная маска остаётся навсегда.

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

Что делает Хаб. Пишет — и по адресу, и по логину.

Разрешение стоит в трёх местах: в источнике 127.0.0.1 (подача с самой машины), в блоке на каждый адрес из «Кому разрешена подача» и в каждом именованном источнике подачи, куда попадают только вошедшие по логину. В общем блоке 0/0 его нет.

Значит соединение с адреса не из списка сдать почту без логина не может. Подающей стороне, которая входит по логину, переезд ничего не ломает — логин остаётся тем же; адрес из списка при переезде приходится править.

Рекомендуемые значения

Что ставить. Вопрос не в значении, а в том, какому блоку его давать:

Где Что получится
именованный источник логина право следует за учётной записью: переезд не ломает подачу, отзыв возможен
узкая подсеть своей платформы работает, пока адрес не сменился
0/0 открытый релей — не бывает правильным вариантом

Первое — единственная раскладка, которая не разваливается от переезда и позволяет отозвать доступ одному отправителю.

Умолчание false, совет включать во внутренних источниках и запрет внешнего релея из коробки — из руководства, § 3.3.1.54.1 и § 2.3. Разбивка «какому блоку давать» наша.
Пример в конфигурации
# право следует за логином, а не за адресом подающей машины
<source {pmta-auth}>
    require-auth true
    always-allow-relaying yes</source>
В этот блок попадают только вошедшие: он выбирается по логину, а не по адресу. Переезд подающей платформы такую раскладку не ломает.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Открывают релей широкой маской, чтобы заработало

наш опыт

Чем чреватоУзел становится открытым релеем. Через несколько часов через него идёт чужой спам, адреса попадают в чёрные списки, и репутация домена восстанавливается неделями — если восстанавливается.
Как заметитьРезкий рост исходящего объёма без запуска рассылки; в очередях домены, которых у вас нет.
Как правильноУбрать широкую маску немедленно и выдать разрешение именованному источнику логина.

Ставят разрешение в широкий блок, а запрет в узкий

§ 3.3.1.54.1

Чем чреватоСлияние идёт по узости, а не по порядку строк: разрешение из блока 0/0 достаётся каждой подсети, которая сама не сказала обратного. Ограничение, задуманное как строгое, не действует.
Как заметитьСдавать почту может кто угодно, хотя узкий блок выглядит ограничивающим.
Как правильноЗапрет — в широкий блок, разрешение — в узкий.

Привязывают право к адресу подающей платформы

наш опыт

Чем чреватоПереезд платформы к другому хостеру останавливает подачу. Лечат это расширением маски, и расширенная маска остаётся навсегда.
Как заметитьВ конфигурации маски шире нужного, и происхождение их никто не помнит.
Как правильноВыдавать разрешение именованному источнику логина: право следует за учётной записью.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
always-allow-relaying <boolean>
Значения
yes | no | true | false
Умолчание
false § 3.3.1.54.1
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
Global, <source>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Директива живёт в <source> и подчиняется слиянию источников: соединение попадает под все адресные блоки, которые его накрывают, и узкий перекрывает широкий. Отсюда правило: запрет ставится в широкий блок, разрешение — в узкий. Наоборот не работает.
Как проверить на узле
Проверять надо не строку, а поведение — и обязательно с чужой машины:
grep -n -B3 'always-allow-relaying' /etc/pmta/config /etc/pmta/virtualhost.txt
printf 'HELO test\r\nMAIL FROM:<a@example.com>\r\nRCPT TO:<b@gmail.com>\r\nQUIT\r\n' | nc <адрес-узла> 25
Ответ 250 на строке RCPT с постороннего адреса означает открытый релей. Первая команда показывает, в каких блоках выдано разрешение: смотреть надо именно на блок, а не на факт наличия строки.
В Хабе
Управляется
Инфраструктура → Адреса отправки
Значение
Хаб подбирает сам — темп, стадия прогрева, метрики
Цена ошибки
опасно: последствия переживут откат
Сценарии
Безопасность узла · Подключить платформу отправки
Важность
критично