Именованный прокси и три уровня его настроек

критично

<proxy>

Один блок — один выходной адрес

Блок описывает один прокси, и обязательных строк в нём две: server — куда узлу подключаться, client — с какого адреса прокси обязан выйти наружу. Порт и имя во второй необязательны; имя по умолчанию берётся у адреса отправки.

Три необязательные строки настраивают протокол, и у двух из них по три уровня: сам блок, потом proxy-protocol и proxy-include-tlv у адреса отправки, потом те же строки уровня узла. Побеждает самое точное. Третья, retry-attempts, уровней не имеет.

Это одна из двух форм записи прокси, и руководство подаёт их как два способа сделать одно и то же. Вторая — smtp-proxy-source-host, строка вместо блока. Разница в том, где живёт связь: строка несёт локальный адрес, прокси, внешний адрес и имя одной записью и перебирается по кругу; блок именуется, и на него ссылаются адреса отправки.

Отсюда практическое правило выбора. Один арендованный адрес на каждый поток — удобнее строкой. Два-три прокси, общих для многих потоков, — удобнее блоками.

Главная ловушка — умолчание имени. Не задав имя в client, вы получаете имя адреса отправки. Пока оно верно для арендованного адреса, всё хорошо; как только адрес переезжает или арендуется у другого поставщика, поток здоровается одним именем, а выходит с адреса, чья обратная запись говорит другое, — и приёмники это видят.

Что делает Хаб. Не пишет: из двух форм гейт Хаба взял другую — строку smtp-proxy-source-host в каждом адресе отправки, её вендор и рекомендует. Блоков <proxy> и строк use-proxy в конфигурации нет.

🔎 Блочная форма остаётся в запасе — для второго гейта, если он понадобится: список use-proxy запасной, а не балансирующий.

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

Собственных значений у механизма нет — их задают пять строк:

Строка	Обязательна	Уровней
server	да	один
client	да	один
protocol-version	нет	три
include-tlv	нет	три
retry-attempts	нет	один

Обязательность двух строк, умолчание имени по адресу отправки, цепочка из трёх уровней и подача двух форм как равноправных — из руководства (§ 3.3.22). Правило выбора между формами — наше.

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

# блок именуется, адреса отправки на него ссылаются
<proxy mta-proxy-a>    server 10.1.2.3:5000
    client 16.70.55.233:0  client.hostname.com
    protocol-version 2
    include-tlv domain
</proxy>

<virtual-mta vmta>
    smtp-source-host 10.8.9.10 vmta.hostname.com
    use-proxy mta-proxy-a
</virtual-mta>

Имя в строке client задано явно. Без него взялось бы vmta.hostname.com — имя адреса отправки, а не выходного адреса прокси.

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

▲

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

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

Полагаются на умолчание имени

§ 3.3.22.2

Чем чреватоИмя берётся у адреса отправки. Для выходного адреса прокси оно может быть неверным, и поток будет здороваться не тем именем, с которого выходит.

Как заметитьОбратная запись внешнего адреса не совпадает с именем в приветствии.

Как правильноЗадавать имя в client явно.

Смешивают две формы записи прокси

§ 3.3.22

Чем чреватоБлок и smtp-proxy-source-host — два способа настроить одно и то же, и use-proxy с ним несовместим. Конфигурация, где есть оба, не пройдёт проверку.

Как заметитьСогласование конфигурации ругается на несовместимость.

Как правильноВыбрать одну форму: блоки — когда прокси общий для многих потоков, строку — когда адрес свой у каждого.

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

PowerMTA 6.0

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

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

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

Наследования у самого блока нет: он именованный и подключается ссылкой. Зато две его строки участвуют в цепочке из трёх уровней — блок, адрес отправки, узел, — и заданное здесь перекрывает оба верхних.

⇄