log-inbound-proxy

<smtp-listener>

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

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

Работает только вместе с use-inbound-proxy. Без него заголовок не ожидается и записывать нечего.

Разбирает она один класс неисправностей: «не тот адрес». Списки источников, ограничения по адресу и статистика опираются на то, что узел считает адресом клиента. Если балансировщик шлёт заголовок с неожиданным содержимым, всё это начинает работать не по тем адресам, и увидеть причину можно только здесь.

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

Главная ловушка — искать причину «не того адреса» в списке источников. Список работает правильно; неверен адрес, который узел извлёк из заголовка. Пока заголовок не виден в журнале, разбор идёт не с того конца.
Что делает Хаб. Не пишет: балансировщик перед узлами мы не ставим — подающие платформы подключаются напрямую.

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

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

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

Значение Когда
no (умолчание) балансировщика нет или он давно обкатан
yes подключаем балансировщик либо разбираем «не тот адрес»

Без use-inbound-proxy строка не делает ничего.

Умолчание и то, что строка применима только при включённом приёме заголовка, — из руководства (§ 3.3.17.18). Разбор класса «не тот адрес» — наш.
Пример в конфигурации
# обкатка балансировщика: смотрим, что он присылает на самом деле
<smtp-listener 0/0:2525>
    use-inbound-proxy yes
    log-inbound-proxy yes</smtp-listener>
Первая строка обязательна: без неё заголовок не ожидается и писать нечего.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Разбирают «не тот адрес» со стороны списка источников

наш опыт

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

Включают запись, не включив приём заголовка

§ 3.3.17.18

Чем чреватоБез use-inbound-proxy заголовок не ожидается, и записывать нечего. Строка молча не делает ничего.
Как заметитьСтрока включена, в журнале ни одной записи о заголовке.
Как правильноДобавить use-inbound-proxy в тот же блок.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
log-inbound-proxy <boolean>
Значения
yes | no | true | false
Умолчание
false § 3.3.17.18
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<smtp-listener>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Наследования нет: строка живёт внутри своего <smtp-listener> и касается соединений его адреса и порта. Такая же строка есть у второго вида входа — это разные входы, а не уровни одного.
Как проверить на узле
Смотрим журнал во время подключения через балансировщик:
grep -i proxy /var/log/pmta/log | tail -20
В строках будет содержимое заголовка и извлечённый из него адрес. Пусто означает, что заголовок не пришёл вовсе, — и тогда соединение узел закроет, как и предписано.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Безопасность узла · Подключить платформу отправки