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

log-inbound-proxy

<transmissions-api-listener>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

наш опыт

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

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

§ 3.3.21.15

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

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

2 связи

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

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

Где применяется

log-fileGlobalЗаписи ложатся в тот самый журнал, который задан там. inference

Как проверить на узле
Смотрим журнал во время подключения через балансировщик:
grep -i proxy /var/log/pmta/log | tail -20
В строках будет содержимое заголовка и извлечённый из него адрес. Пусто означает, что заголовок не пришёл вовсе, — и тогда соединение узел закроет, как и предписано.
◇

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

3 статьи

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

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