База знаний PMTA›Блок <smtp-listener>›Директива§ 3.3.17.16

use-inbound-proxy

<smtp-listener>

Ожидать ли заголовок балансировщика на входе почтовой подачи

в конфигурации это строкаuse-inbound-proxy falseвнутри блока <smtp-listener>

То же имя ещё 1:<smtp-listener><transmissions-api-listener>— часть из них другие настройки, часть та же самая

Настоящий адрес клиента из-за балансировщика

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

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

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

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

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

Что делает Хаб. Не пишет: балансировщика перед узлами у нас нет, подающие подключаются напрямую.

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

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

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

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

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

Умолчание false, автоопределение версии, извлечение адреса и порта и закрытие соединения без заголовка — из руководства (§ 3.3.17.16). Замечание про подмену адреса — наше.

Пример в конфигурации

# включать одновременно с балансировщиком, не заранее
<smtp-listener 0/0:2525>
    use-inbound-proxy yes    inbound-proxy-timeout 5s
</smtp-listener>

Со включённой строкой прямое подключение к этому входу будет отвергнуто — заголовка от него не придёт.

жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.

▲

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

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

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

§ 3.3.17.16

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

Как заметитьВсе подключения к этому входу рвутся сразу после установления.

Как правильноВыключить строку либо поставить балансировщик, который шлёт заголовок.

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

наш опыт

Чем чреватоСписки работают по адресу, извлечённому из заголовка. Пока не видно, что прислал балансировщик, правки списков ничего не объясняют.

Как заметитьПодающий есть в списке, а узел отвечает отказом.

Как правильноВключить log-inbound-proxy и посмотреть настоящий адрес.

Совместимость

PowerMTA 6.0

описана в руководстве этой версии · платформа: любая

С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.

Справочные данные

Синтаксис: use-inbound-proxy <boolean>
Значения: yes | no | true | false
Умолчание: false § 3.3.17.16
Применение: reload, перезапуск не нужен
Очередь: уже поставленное в очередь не затронет
Где писать: <smtp-listener>
Сколько раз: один раз в блоке

Всё здесь — из руководства, с разделом.

Наследование

Наследования нет: строка живёт внутри своего <smtp-listener> и касается соединений его адреса и порта. Такая же строка есть у второго вида входа — это разные входы, а не уровни одного.

⇄