Demo
Demo
База знаний PMTA›Блок <transmissions-api-listener>›Директива§ 3.3.21.13

use-inbound-proxy

<transmissions-api-listener>

Ожидать ли заголовок балансировщика на входе подачи по HTTP
в конфигурации это строкаuse-inbound-proxy falseвнутри блока <transmissions-api-listener>
То же имя ещё 1:<smtp-listener><transmissions-api-listener>— часть из них другие настройки, часть та же самая
Настоящий адрес клиента из-за балансировщика

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

Версию MTA определяет сам — обе понимает без настройки. Это отличает вход от выхода, где версию задают явно.

🔴 Заголовок обязателен, а не желателен. Со включённой строкой узел закрывает соединение, если заголовка не пришло. То есть клиент, подключившийся напрямую в обход балансировщика, будет отвергнут — и это правильно, иначе адрес можно было бы подделать.

От этого зависит всё, что смотрит на адрес источника: блоки <source>, ограничения, статистика. Ошибка здесь выглядит не как ошибка прокси, а как «списки работают неправильно».

Главная ловушка — включить, когда балансировщика нет. Заголовка никто не пришлёт, и узел закроет каждое соединение. Подача встанет полностью, а причина в журнале не появится, пока не включён log-inbound-proxy.
Что делает Хаб. Не пишет: балансировщика перед узлами у нас нет, подающие подключаются напрямую.

🔎 Появится балансировщик — включать надо одновременно с ним, а не заранее: строка без него останавливает приём целиком.

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

Строка и балансировщик включаются вместе:

Значение Когда
no (умолчание) клиенты подключаются напрямую
yes перед узлом стоит балансировщик и он уже шлёт заголовок

Промежуточного состояния нет: либо заголовок ждут всегда, либо никогда.

Умолчание false, автоопределение версии, извлечение адреса и порта и закрытие соединения без заголовка — из руководства (§ 3.3.21.13). Замечание про подмену адреса — наше.
Пример в конфигурации
# включать одновременно с балансировщиком, не заранее
<transmissions-api-listener 127.0.0.1:4433>
    use-inbound-proxy yes    inbound-proxy-timeout 5s
</transmissions-api-listener>
Со включённой строкой прямое подключение к этому входу будет отвергнуто — заголовка от него не придёт.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Включают приём заголовка до появления балансировщика

§ 3.3.21.13

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

Ищут причину «не того адреса» в списках источников

наш опыт

Чем чреватоСписки работают по адресу, извлечённому из заголовка. Пока не видно, что прислал балансировщик, правки списков ничего не объясняют.
Как заметитьПодающий есть в списке, а узел отвечает отказом.
Как правильноВключить log-inbound-proxy и посмотреть настоящий адрес.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
use-inbound-proxy <boolean>
Значения
yes | no | true | false
Умолчание
false § 3.3.21.13
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<transmissions-api-listener>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Наследования нет: строка живёт внутри своего <transmissions-api-listener> и касается соединений его адреса и порта. Такая же строка есть у второго вида входа — это разные входы, а не уровни одного.
⇄

Связанные директивы

1 связь

То же имя в других блоках

use-inbound-proxy<smtp-listener>Одноимённая строка у слушателя почты; здесь она про отдельный вход, свой у API. § 3.3.21.13

Как проверить на узле
Проверка прямая — подключиться в обход балансировщика:
nc -zv NODE 4433
Соединение должно закрыться: заголовка от nc не придёт. Если оно держится — строка не применилась. Через балансировщик подключение должно проходить.
◇

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

3 статьи

◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.◇Группа, дающая право управлятьЧленство в группе pmta даёт непривилегированному пользователю право звать команды узла и пользоваться подачей.◇Как узел выбирает источник и складывает его настройкиСоединение попадает под все блоки источника, чьи адреса его накрывают, и действуют они слитно — узкий перекрывает широкий; именованные блоки подключаются только по прямой ссылке.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Безопасность узла
Соседние настройки блока <transmissions-api-listener>:log-inbound-proxyinbound-proxy-timeouttls-certificatetls-min-versiontls-ciphersВсе 15 директив блока →