критично
Из коробки внешний релей запрещён. Руководство говорит это прямо: пока источники не разрешены явно, узел принимает подачу только с адреса 127.0.0.1. Вместе с адресом ответственного за узел это одна из двух настроек, без которых MTA не работает.
Дальше начинается место, на котором чаще всего спотыкаются. Словом «релей» руководство называет два разных вопроса, и решаются они разными директивами:
| Вопрос | Чем решается | Когда нужен |
|---|---|---|
| Кто может сдавать нам почту для кого угодно | always-allow-relaying в блоке источника | отправка: узел принимает почту от своих подающих машин |
| На чьи адреса мы принимаем почту от кого угодно | relay-domain и relay-address | приём: узел обслуживает входящую почту |
Руководство подчёркивает: вторая пара полезна только там, где узел занимается входящей почтой. Для чистой отправки её настраивать не нужно вовсе — там работает первая строка.
Отсюда и самая частая путаница: отправитель, которому нужно «разрешить релей», берётся за relay-domain, потому что имя подходит, — и не получает ничего.
Второй край тише и от этого хуже: разрешение по адресу не переживает переезд. Платформа сменила адрес — подача встала; вернули широкую маску «на время» — она осталась навсегда.
Отправка — по адресу из списка или по логину. Разрешение always-allow-relaying yes стоит в трёх местах: в источнике 127.0.0.1 (подача с самой машины), в блоке на каждый адрес из «Кому разрешена подача» и в каждом именованном источнике подачи, куда попадают только вошедшие. В общем блоке 0/0 его нет — значит соединению с адреса не из списка сдать почту без логина нельзя.
Список адресов годится для машин с постоянным адресом. Платформе, которая может переехать к другому хостеру, надёжнее логин: разрешение по адресу пришлось бы править при каждом переезде.
Приём — тремя правилами по образцу. Хаб открывает приём на жалобы (fbl@fbl.<домен>), на асинхронные отказы (bounce@bounce.<домен>) и на роль-адреса — dmarc@, postmaster@, abuse@. Последнее правило появилось не сразу: без него анти-релей отбивал агрегатные отчёты DMARC ответом 550 relaying denied.
# два разных вопроса — две разные строки <source 127.0.0.1> always-allow-relaying yes # кто может слать через нас</source> relay-address /^bounce@bounce\./ # на чьи адреса мы принимаем relay-address /^(dmarc|postmaster|abuse)@/
что делают не так и чем это кончается3 ошибки▶
§ 2.3
наш опыт
§ 2.3
4 связи
always-allow-relayingGlobalДиректива, открывающая подачу источнику; описана в главе 3. § 2.3
relay-domainGlobalВторой вопрос: не кто нам сдаёт, а на чьи адреса мы принимаем. § 2.3
Первоначальная настройкаМеханизм, на котором держится этот шаг. § 2.3total-max-smtp-inGlobalОбе про приём: этот потолок решает, сколько соединений узел выдержит, контроль релея — что им позволено. inferencealiasGlobalЧтобы письмо дошло до раскрытия, узел сначала должен согласиться его принять — это решают правила приёма. inferenceКак узел выбирает источник и складывает его настройкиРазрешение на ретрансляцию — одна из настроек, которую решает это слияние. § 3.3.7Два обработчика входящих отчётов и что с ними делатьПриём этих писем разрешает не обработчик, а правила ретрансляции. inferencerequire-auth<source>Второй способ решить тот же вопрос: право по логину вместо права по адресу. § 3.3.7.10
grep -n 'always-allow-relaying\|relay-address\|relay-domain' /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
3 статьи
◇Заголовки, которыми отправитель управляет доставкойШесть служебных заголовков позволяют подающей стороне выбрать поток, пометить письмо заданием, задать настройки и ключ подписи, идентификатор конверта и расписание; каждый разрешается отдельно и по источникам.◇Заголовок балансировщика на входеУзел читает заголовок PROXY в начале входящего соединения и считает источником адрес из него; работает у обоих видов входа.◇Что нужно обвязке подачиЧто должно быть на стороне подающего, чтобы обвязка заработала: библиотека, права и членство в группе.