allowed-sender-lists

<source>

По каким спискам проверяется адрес отправителя при подаче
в конфигурации это строкаallowed-sender-listsвнутри блока <source>
Кто чьим именем может подписываться

Директива называет один или несколько списков адресов через запятую. Проверяются два адреса: MAIL FROM из протокола и адрес отправителя из самого письма — из заголовка Sender, а если его нет, то из From.

Не прошедшее проверку письмо отвергается ответом 550 5.7.1 Forbidden Sender Address. Отказ синхронный: отправитель узнаёт о нём сразу, письмо в очередь не попадает.

Без директивы разрешены все отправители — это её умолчание и есть.

Списки объявляются блоками <address-list> и наполняются адресами, локальными частями, доменами и образцами.

Главная ловушка — проверяются два адреса, а думают об одном. Обычно настраивают под MAIL FROM и забывают, что заголовок письма проверяется тоже. Платформа, у которой конверт и видимый отправитель различаются — а различаются они почти всегда, когда настроен обратный адрес для отказов, — упирается во второй адрес.

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

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

Разделение доменов у Хаба держится не на этом, а на выборе адреса отправки: у каждого логина свой именованный источник со своим потоком, и почта уходит с назначенного адреса независимо от того, что написано в письме. Но имя в письме при этом не проверяется ничем.

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

Что ставить. Значение — имена списков; выбирать приходится степень строгости:

Значение Когда
не писать (умолчание) отправители доверенные, а имя в письме контролирует подающая платформа
список доменов узлом пользуются несколько отправителей, и каждый должен подписываться только своим
список адресов подача идёт с фиксированных адресов и меняется редко

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

Проверка двух адресов, порядок Sender→From, код отказа и умолчание «разрешены все» — из руководства, § 3.3.7.43. Разбивка по строгости наша.
Пример в конфигурации
# список объявляется отдельно, источник на него ссылается
<address-list sender1>
    domain shop.example.com
</address-list>

<source {shop-example-com-auth}>
    allowed-sender-lists sender1</source>
Этот логин сможет подать письмо только от имени своего домена. Попытка подписаться чужим получит отказ 550 5.7.1 Forbidden Sender Address прямо на подаче.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Настраивают под конверт, забыв про заголовок письма

§ 3.3.7.43

Чем чреватоПроверяются оба адреса. Платформа, у которой обратный адрес для отказов отличается от видимого отправителя, пройдёт первую проверку и упрётся во вторую.
Как заметитьПисьма отвергаются с 550 5.7.1 Forbidden Sender Address, хотя MAIL FROM в списке есть.
Как правильноВносить в список оба домена — конверта и письма — либо перечислять домены, а не адреса.

Полагаются на выбор потока вместо проверки имени

§ 3.3.7.43

Чем чреватоПоток решает, с какого адреса уйдёт письмо, а не чьим именем оно подписано. Вошедший отправитель может подписаться чужим доменом, и письмо уйдёт с вашего адреса от его имени.
Как заметитьВ доставленных письмах встречаются домены отправителя, которых этому логину не выдавали.
Как правильноДобавить список разрешённых отправителей в именованный источник каждого логина.

Ставят список в широкий блок

наш опыт

Чем чреватоСписок достаётся всем подсетям по правилу слияния, и разные отправители получают один и тот же набор разрешённых имён. Разделение, ради которого всё делалось, пропадает.
Как заметитьОдин список назван в блоке 0/0 и больше нигде.
Как правильноСтавить свой список в именованный источник каждого логина.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
allowed-sender-lists <list>
Значения
имена списков через запятую
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<source>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Директива живёт в <source> и подчиняется слиянию источников: соединение попадает под все адресные блоки, которые его накрывают, и узкий перекрывает широкий. Список, названный в широком блоке, достанется и узким — а поскольку у каждого логина свой набор разрешённых имён, ставить её осмысленно именно в именованные источники.
Как проверить на узле
Ссылку и сам список видно в конфигурации; работу проверяют попыткой подать чужим именем:
grep -n 'allowed-sender-lists' -A3 /etc/pmta/config /etc/pmta/virtualhost.txt
grep -n 'Forbidden Sender' /var/log/pmta/pmta.log | tail -5
Отсутствие строки означает, что разрешены все отправители. Проверять стоит обоими адресами: сначала чужим MAIL FROM, потом чужим From при своём конверте — второй случай ловится реже.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Безопасность узла · Разделение отправителей