Шесть способов выбрать поток и порядок между ними

критично

VirtualMTA selection precedence
Кто решает, с какого адреса уйдёт письмо

Каждый из шести способов встречается в руководстве отдельно и выглядит равноправной альтернативой. Глава 9 собирает их в одном месте и говорит главное: они упорядочены. Список — не набор вариантов, а правило разрешения.

Лестница сверху вниз. Переменная слияния *vmta в самом письме; выбор при подаче — вызов API или заголовок X-Virtual-MTA; правило по образцу из <pattern-list>; поток, привязанный к слушателю; умолчание источника default-virtual-mta. Что стоит выше — побеждает; что ниже — применяется только тогда, когда наверху никто не высказался.

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

Пул выбирается ровно теми же способами. Разница только в имени: вместо имени потока пишется имя пула. Поэтому имена потоков и пулов живут в одном пространстве, и совпадение MTA не разрешает, а отвергает.

Главная ловушка. Ни в одном отчёте не написано, какой именно из шести способов выбрал поток для конкретного письма. В учёте есть поле vmta — то есть результат, — а причины нет нигде. Когда письмо ушло не с того адреса, у вопроса шесть возможных ответов и ни одного диагностического ответа. Проверять приходится перебором сверху вниз.
Что делает Хаб. Пользуется четырьмя ступенями из шести и знает об этом. В основном файле рабочей конфигурации общий источник 0/0 получает default-virtual-mta со значением by-smtp-source-ip — поток определяется адресом, на который платформа подключилась, — и список выбора по домену отправителя (mail-from в <pattern-list>). В файле адресов источник общего логина получает тот же список и умолчание на пул подачи. Заголовок разрешён: process-x-virtual-mta стоит yes во всех источниках рабочей конфигурации. В базовой, которая ставится до появления пар, нет ни списка, ни умолчания.

Из этого набора важно помнить одно: заголовок стоит выше и списка выбора, и умолчания. Платформа, которая шлёт X-Virtual-MTA, обходит все наши правила маршрутизации — и это разрешено намеренно, чтобы прогрев мог называть адрес письмом.

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

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

Отправитель Чем выбирать Почему
наш, шлёт заголовки X-Virtual-MTA самый прямой и точный: поток на письмо
чужой, заголовки не умеет mail-from по обратному адресу ничего не требует от отправителя
чужой, адрес подачи свой by-smtp-source-ip не растёт с числом адресов
всё остальное default-virtual-mta запасной вариант, а не назначение

Смешивать способы можно и часто нужно; важно лишь понимать, что при совпадении победит верхний.

Таблица — наша, из практики Хаба. Из руководства здесь сам порядок ступеней и правило «выше побеждает».
Пример в конфигурации
# четыре ступени в одной конфигурации — сверху вниз по старшинству
<pattern-list mta-hub-senders>
    mail-from /@shop\.example\.com$/ virtual-mta=shop-example-com
    mail-from /@news\.example\.com$/ virtual-mta=news-example-com
</pattern-list>

<source {pmta-auth}>
    process-x-virtual-mta yes           # 2-я ступень: заголовок разрешён
    pattern-list mta-hub-senders        # 3-я ступень: правило по образцу
    default-virtual-mta mta-hub-pool    # 5-я ступень: запасной вариант</source>
Письмо с заголовком X-Virtual-MTA: news-example-com уйдёт этим потоком, даже если обратный адрес принадлежит магазину: заголовок стоит выше списка. Письмо без заголовка и с чужим обратным адресом достанется пулу — это последняя ступень.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Считают умолчание источника назначением

§ 9.4

Чем чреватоПлатформе выдан «свой» поток строкой default-virtual-mta, и это работает ровно до дня, когда платформа начинает ставить X-Virtual-MTA — например, после обновления. Письма уходят другим адресом, конфигурация при этом не менялась ни строки.
Как заметитьВ учёте у одного отправителя внезапно появляется чужое имя потока; конфигурация не трогалась, а разбор упирается в «всё правильно».
Как правильноЛибо не разрешать заголовок для этого источника (process-x-virtual-mta no), либо перестать считать умолчание назначением и выбирать поток на той же ступени, на которой это делает отправитель.

Ждут, что настройка узла перекроет заголовок

§ 9.4

Чем чреватоКонфигурация стоит ниже заголовка на лестнице. Правило по образцу, добавленное «чтобы наверняка увести отправителя на нужный адрес», не срабатывает вовсе, если тот шлёт заголовок.
Как заметитьНовое правило в <pattern-list> видно в конфигурации, поток прежний, и кажется, что список не читается.
Как правильноПроверить, приходит ли X-Virtual-MTA. Если да — снять разрешение на заголовок у этого источника или договориться с отправителем, а не усложнять список.

Называют пул именем существующего потока

§ 9.3

Чем чреватоMTA отвергает определение пула целиком: выбор идёт одними и теми же заголовками и директивами, и совпадение имён неразрешимо. На применении это не предупреждение, а неудачная перезагрузка.
Как заметитьКонфигурация не применяется, и причина указывает на пул, а не на ту строку, которую правили последней.
Как правильноДержать имена потоков и пулов в одном списке и проверять уникальность до записи файла — генератору это стоит одной проверки.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Наследования у самой лестницы нет: она разрешается заново для каждого письма. Наследуются директивы на ступенях — default-virtual-mta, process-x-virtual-mta и pattern-list записаны в <source> и сливаются по обычному правилу источников: более узкий блок перекрывает более широкий.
⇄

Связанные записи

3 связи

Как проверить на узле
Готового ответа «каким способом выбран поток» нет — есть результат. Смотреть в учёт, в поле имени потока:
pmtaacctfind --output csv[vmta,orig,rcpt] /var/log/pmta/acct-*.csv | head
Если поток не тот, которого ждали, проверять сверху вниз: есть ли в письме X-Virtual-MTA; попадает ли обратный адрес под правило списка; на какой адрес узла пришло подключение; что стоит умолчанием в источнике. Первый же ответ «да» и есть причина — ниже уже не смотрят.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Ротация адресов отправки · Прогрев адресов · Разделение отправителей
Важность
критично