Demo
Demo
База знаний PMTA›Механизм§ 11.3

Внешние адреса на одной машине, узлы внутри

критично

outbound proxy deployment
Зачем вообще заводить прокси

Задача, которую решает механизм, одна и очень конкретная: у вас много адресов отправки и много узлов, и распределять первые по вторым больно. Каждый переезд адреса — это правка конфигурации узла, его перезагрузка и разъезд между тем, что настроено, и тем, что на самом деле.

Решение — развести две вещи. Узлы живут на внутренних адресах и занимаются почтой. Все внешние адреса отправки собраны на одной машине — прокси. Узел, доставляя письмо, подключается к прокси и говорит ему пару: «выйди с такого-то адреса на такой-то».

Разрешение имён остаётся у узла. Он сам ищет MX получателя и сам решает, куда идти; прокси только исполняет и ничего о почте не знает.

🔴 Прокси прозрачен для учёта. Полем адреса отправки записан внешний адрес прокси, полем назначения — адрес приёмника. Понять по обычному учёту, что письмо шло через прокси, нельзя — для этого есть отдельные поля dlvProxy*, которые надо добавить в набор явно.

🔎 Раздел руководства устарел. Он кончается обещанием «поддержку протокола для входящего трафика мы добавим в следующих выпусках» — а она уже есть: use-inbound-proxy у слушателя и у входа Transmissions API. Читать этот абзац как описание возможностей не стоит.

Главная ловушка — считать, что узел проверит настройку прокси. Он проверяет только форму записи адреса. Совпадает ли она с тем, что настроено на прокси, узел не знает и знать не может — а расхождение означает письма, уходящие не с того адреса при исправной с виду конфигурации.
Что делает Хаб. Пользуется — прокси-гейт Хаба устроен именно так: MTA идёт по протоколу PROXY второй версии в гейт на самом узле (hubgate), а тот выходит наружу через арендованный прокси — по SOCKS5 или HTTP CONNECT.

Три вывода разбора в нём учтены: первое — список прокси запасной, а не балансирующий, поэтому форма взята строчная (smtp-proxy-source-host, свой адрес отправки на каждый прокси), а трафик раскладывается пулами наборов; второе — домен очереди гейт получает второй версией протокола со строкой proxy-include-tlv domain; третье — соответствие «адрес отправки ↔ прокси» держит сам Хаб: ярлык в строке MTA и таблица гейта /etc/hubgate/upstreams.tsv пишутся вместе, из одного реестра.

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

Собственных значений у механизма нет — его собирают из блока и трёх строк:

Что нужно Чем задаётся
описать прокси блок <proxy> с server и client
назначить его use-proxy у узла или адреса отправки
передать домен очереди proxy-protocol 2 и proxy-include-tlv
увидеть отказы в учёте enable-tq-record-for-proxy-failure плюс вид tq
Постановка задачи, прозрачность прокси в учёте, поля dlvProxy и то, что разрешение имён остаётся за узлом, — из руководства (§ 11.3). Устаревшую оговорку про входящий трафик заметили мы: § 3.3.17.16 её опровергает.
Пример в конфигурации
# узел на внутреннем адресе, внешний адрес живёт на прокси
<proxy mta-proxy-a>    server 10.1.2.3:5000
    client 16.70.55.233:0  client.hostname.com
</proxy>

<virtual-mta vmta>
    smtp-source-host 10.8.9.10 vmta.hostname.com
    use-proxy mta-proxy-a
</virtual-mta>
Адрес отправки узла внутренний — с него узел идёт к прокси. Наружу выходит адрес из строки client, и именно его увидит приёмник.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Ждут увидеть прокси в обычном учёте

§ 11.3

Чем чреватоОн прозрачен: адресом отправки записан внешний адрес прокси, адресом назначения — приёмник. Отличить доставку через прокси от прямой по этим полям нельзя.
Как заметитьВ учёте всё выглядит как обычная доставка.
Как правильноДобавить поля dlvProxy* в record-fields для видов d, b, t и tq.

Читают раздел как описание текущих возможностей

§ 11.3

Чем чреватоОн утверждает, что протокол поддержан только для исходящего трафика. Это устарело: приём заголовка на входе есть и у слушателя, и у входа Transmissions API.
Как заметитьОтказываются от балансировщика перед узлом, считая, что MTA его не поймёт.
Как правильноСмотреть use-inbound-proxy — входящая сторона существует.

Полагаются на то, что узел сверит адрес с прокси

наш опыт

Чем чреватоУзел проверяет только форму записи. Опечатка означает письма с чужого адреса и прогрев, который считается не туда.
Как заметитьВ заголовках писем адрес не тот, что в конфигурации.
Как правильноСверять список адресов на прокси со строками client и проверять письмом на контрольный ящик.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Наследования у механизма нет — наследуются директивы, которыми он включается. Две из них имеют три уровня: блок прокси, адрес отправки и узел, и самый точный побеждает.
⇄

Связанные записи

3 связи

Работают в паре

Узел берёт тот поток, чей адрес совпал с адресом подключенияВыбор адреса отправки по адресу подачи остаётся прежним: прокси на него не влияет. § 9.4.5

На что влияет

Договор о телеметрииПрокси в учёте прозрачен: адресом отправки записан его внешний адрес, и только поля dlvProxy показывают, что он вообще был. § 11.3

Где это видно

Именованный прокси и три уровня его настроекКак это настраивается: именованный блок с адресом прокси и внешним адресом. § 11.3

Как проверить на узле
Главная проверка не на узле, а со стороны получателя: с какого адреса пришло письмо:
dig +short -x 16.70.55.233
Обратная запись внешнего адреса должна совпадать с именем в строке client. Настоящая проверка — письмо на контрольный ящик: в заголовках виден адрес, с которого оно пришло на самом деле.
◇

Что ещё почитать

3 статьи

◇Ограничения облакаОблака ограничивают исходящую почту через порт 25, пока не попросишь снять лимит, а их диапазоны адресов почтовики встречают с подозрением.◇Ключ активации — условие установки, а не шаг после неёБез ключа активации от поддержки SparkPost MTA не ставится и не работает, а уровень лицензии задаёт потолок исходящих соединений: на стандартной всё сверх 200 игнорируется.◇Как перевести план отправки в железоДве постоянные, по которым считается любой узел: около 2 КБ памяти на каждого получателя в очереди и место под спул, пропорциональное суммарному размеру писем.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Планирование мощности · Отправка через прокси
Важность
критично