smtp-proxy-source-host

Globalкритично

Исходящие соединения через прокси, со своей идентичностью
в конфигурации это строкаsmtp-proxy-source-hostвнутри блока Global
То же имя ещё 1:Global<virtual-mta>— часть из них другие настройки, часть та же самая
Отправка через прокси, по-вендорски

Четыре слова там, где у smtp-source-host два: локальный адрес или диапазон; прокси с портом; адрес, который прокси предъявит получателю (можно с портом); имя для приветствия.

Повторять можно — строки складываются в набор с перебором по кругу, как у обычной формы. В набор попадают только локальные адреса той же версии IP, что у прокси: несовпадение версий даёт пустой или неполный набор молча.

Внутри адреса отправки перекрывает общую настройку и исключает две другие: ни smtp-source-host, ни use-proxy в том же адресе отправки использовать нельзя.

Почему вендор рекомендует именно её, а не use-proxy. Две причины, и вторая важнее: строки перебираются по кругу; и вся машинерия отключения провинившихся адресов работает по адресу клиента прокси — тому, который увидел получатель, — а не по локальному. То есть disabled-source-ip-notify, reenable-source-ip-after и отключение адреса правилом считают то, что имеет смысл.

Главная ловушка. Узел проверяет только синтаксис адреса клиента: настроен ли он на самом прокси, он проверить не может. Опечатка здесь не ошибка конфигурации, а соединения, уходящие с непредсказуемого адреса — или не уходящие вовсе, с диагностикой на стороне прокси.
Что делает Хаб. На уровне узла не пишет: строку Хаб ставит в каждый адрес отправки через прокси — блоки proxy-<ярлык> в /etc/pmta/proxy.txt, по одному на прокси. Форма та же, что у smtp-source-host, и отключение провинившихся адресов MTA считает по адресу клиента прокси — логика здоровья адресов переносится на прокси без переделки.
Рекомендуемые значения

Порядок слов и что в них класть:

Слово Что это На что смотреть
первое локальный адрес или диапазон CIDR только адреса той же версии IP, что у прокси
второе прокси и порт имя или адрес; порт обязателен
третье адрес клиента, который увидит получатель можно с портом; узел его не проверяет
четвёртое имя для приветствия сходится с обратной записью адреса клиента, не локального

Про обратную запись — не оговорка, а суть. Получатель видит адрес клиента прокси; имя в приветствии должно сходиться с его обратной записью. Проверять dig -x надо по адресу прокси, а не по локальному.

Порядок слов, ограничение по версии IP, несовместимости и отсчёт по адресу клиента — всё из руководства. Совет про dig — наш.
Пример в конфигурации
# локальный адрес → прокси → адрес, который увидит получатель → имя
<virtual-mta shop-via-proxy>
    smtp-proxy-source-host 10.0.0.5 proxy.example.net:5000 198.51.100.7 shop.example.com    proxy-protocol 2
</virtual-mta>
Получатель увидит соединение с 198.51.100.7 и приветствие shop.example.com — сходиться с обратной записью должен именно этот адрес. Ни smtp-source-host, ни use-proxy в этом блоке уже нельзя.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Оставляют smtp-source-host рядом

§ 3.3.1.23

Чем чреватоКомбинация запрещена: если прокси-форма применяется к адресу отправки, обычная в нём недопустима. Ошибка вылезет при применении конфигурации, а не при правке файла.
Как заметитьПерезагрузка конфигурации не проходит, узел остаётся на прежней версии.
Как правильноВ адресе отправки оставить что-то одно. И помнить, что прокси-форма может быть унаследована от узла — тогда обычную нельзя, даже если рядом её не видно.

Смешивают версии IP локального адреса и прокси

§ 3.3.1.23

Чем чреватоВ набор попадают только адреса версии прокси. При полном несовпадении набор оказывается пустым — молча, без предупреждения.
Как заметитьСоединения не устанавливаются вовсе или уходят не с тех адресов, при том что конфигурация применилась без ошибок.
Как правильноДержать локальный диапазон и прокси одной версии IP. Для двух версий — две отдельные строки.

Сверяют обратную запись по локальному адресу

§ 11.3

Чем чреватоПолучатель видит адрес клиента прокси, а не локальный. Имя в приветствии, сошедшееся с локальной обратной записью, для получателя не сходится ни с чем.
Как заметитьПроверки на стороне получателя ругаются на несовпадение имени и обратной записи, хотя dig -x на узле показывает совпадение.
Как правильноПроверять dig -x по третьему слову строки — адресу клиента прокси.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
smtp-proxy-source-host CIDR PROXY-SERVER:PORT PROXY-CLIENT-IP[:PORT] HOSTNAME
smtp-proxy-source-host LOCAL-IP PROXY-SERVER:PORT PROXY-CLIENT-IP[:PORT] HOSTNAME
Значения
локальный адрес или CIDR, прокси с портом, адрес клиента (можно с портом), полное доменное имя
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
Global, <virtual-mta>
Сколько раз
можно повторять
Всё здесь — из руководства, с разделом.
Наследование
Директива пишется в корне файла, раздел Global, и задаёт набор для всего узла. Записанная внутри <virtual-mta>, она этот набор заменяет для писем этого адреса отправки. И действует запрет-спутник: если директива применяется к адресу отправки — заданная в нём самом или унаследованная от узла, — то smtp-source-host и use-proxy в этом адресе отправки недопустимы.
⇄

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

4 связи

Как проверить на узле
Проверять надо не локальный адрес, а тот, который увидит получатель. Что настроено — в конфигурации:
grep -rn 'smtp-proxy-source-host' /etc/pmta/
Сверьте адрес клиента прокси из строки с обратной записью: dig -x 198.51.100.7 +short обязано вернуть имя из той же строки. Что адрес клиента действительно поднят на прокси, узел не проверяет — это смотрят на самом прокси.
В Хабе
Цена ошибки
с перерывом: применение прерывает работу узла
Сценарии
Разобраться с доставляемостью · Ротация адресов отправки · Отправка через прокси
Важность
критично