rewrite-list

<virtual-mta>

Список правил переписывания для этого адреса отправки
в конфигурации это строкаrewrite-listвнутри блока <virtual-mta>
То же имя ещё 1:<virtual-mta><virtual-mta-pool>— часть из них другие настройки, часть та же самая
Переписывание, привязанное к адресу отправки

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

Основной путь подключения у руководства другой. § 3.3.18 говорит прямо: чтобы пользоваться списком, его надо назвать в блоке <source> — и свой пример показывает именно так. Подключение здесь привязывает переписывание к адресу отправки, а не к подаче.

Разница практическая. Источник выбирается при приёме письма, адрес отправки — после; значит подключение здесь переписывает адрес позже и зависит от того, каким потоком письмо пойдёт. Для одинакового обратного адреса на весь узел это лишняя зависимость.

🔎 Записи rewrite-list для <source> в каталоге нет — оглавление директив руководства перечисляет её только для <virtual-mta> и <virtual-mta-pool>, хотя раздел § 3.3.18 подключает список именно к источнику. Каталог повторяет оглавление позиция в позицию, поэтому здесь — четвёртый известный пробел вендорского индекса.

Главная ловушка — думать, что это единственное место. Список, подключённый в <source>, работает независимо от этой строки и применяется раньше. Настраивая переписывание «в адресе отправки», легко не заметить, что то же самое уже сделано при приёме — и адрес будет переписан дважды.
Что делает Хаб. Не пишет здесь. Список bounce-rw Хаб собирает, когда в генераторе включено переписывание обратного адреса, и подключает к источникам — там, где руководство и советует: к общему 0/0 в основном файле конфигурации и к каждому источнику подачи с логином в файле адресов. Дублируется подключение намеренно: директивы общего источника на авторизованное соединение не переносятся, и без второй строки обратный адрес остался бы неизменным.
Рекомендуемые значения

Значение — имя объявленного списка. Выбор здесь — где подключать:

Куда Когда применяется Кому подходит
<source> при приёме письма, до выбора потока одинаковый обратный адрес для всей подачи — обычный случай
сюда после выбора адреса отправки когда обратный адрес зависит именно от потока
<virtual-mta-pool> то же для всей группы одинаковые правила у волны адресов

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

Требование подключать список к источнику — из руководства (§ 3.3.18). Разбивка по местам подключения и вывод «в парке первый вариант» — наши.
Пример в конфигурации
# переписывание, привязанное к потоку, а не к подаче
<rewrite-list abc>
    mail-from foo@*  *@bar.com
</rewrite-list>

<virtual-mta mta1>
    rewrite-list abc</virtual-mta>
Пример руководства для этого раздела. Тот же список руководство подключает и к <source> — и именно ту форму показывает в разделе самого списка как обязательную.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Подключают здесь, не заметив подключения в источнике

§ 3.3.18

Чем чреватоСписки применяются независимо: сначала при приёме, потом при выборе адреса отправки. Адрес переписывается дважды, и итог не совпадает ни с одним из двух ожиданий.
Как заметитьВ поле обратного адреса учёта стоит нечто, не описанное ни одним из списков по отдельности.
Как правильноДержать переписывание в одном месте. Для парка это <source>: обратный адрес зависит от домена отправки, а не от потока.

Дописывают список участнику пула, ожидая сложения

§ 3.3.13

Чем чреватоСобственная строка участника заменяет пуловую целиком. Правила пула для этого адреса отправки перестают применяться разом.
Как заметитьОдин адрес группы переписывает конверт иначе, чем остальные.
Как правильноСобрать нужные правила в один список для этого участника — списки при наследовании не складываются.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
rewrite-list <name>
Значения
имя объявленного списка правил переписывания
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<virtual-mta>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Строка наследуется по обычному порядку адресов отправки: записанная в <virtual-mta-pool>, она достаётся каждому участнику, а собственная строка участника пуловую перекрывает целиком — списки не складываются. Подключение в <source> при этом отдельное и независимое: оно применяется раньше и от этой строки не зависит.
Как проверить на узле
Что реально ушло в конверте, видно в учёте — поле обратного адреса:
pmtaacctfind --output csv[orig,vmta,rcpt] /var/log/pmta/acct-*.csv | head -20
Если адрес переписан не так, как ожидалось, ищите второй список — в блоке <source>, под который попадает адрес подачи. Он применяется раньше и об этой строке ничего не знает.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Ротация адресов отправки