Demo
Demo
База знаний PMTA›Механизм§ 9.4

Переменная слияния — верхняя ступень, и живёт она в содержимом

vmta merge variable
Выбор потока, спрятанный в самом письме

Доступна при подаче через API, при пакетной подаче из каталога и по SMTP везде, где включено слияние. Стоит на вершине порядка старшинства — значит, единственный способ выбора, который нельзя перекрыть настройкой узла.

И одновременно самый незаметный из шести. Заголовок видно в письме, вызов API — в логе подачи, правило — в конфигурации. Переменная слияния лежит в данных содержимого, куда при разборе происшествия смотрят последними.

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

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

Собственных значений у механизма нет: значение — имя потока или пула в данных слияния. Со стороны узла настраивается только одно — разрешено ли слияние этому источнику вообще (allow-mailmerge). Промежуточных режимов нет: нельзя разрешить слияние и запретить выбор потока через него.

Из руководства здесь то, что переменная стоит выше всех и работает на трёх путях подачи. Оценка риска для многоклиентского узла — наша.
Пример в конфигурации
# слияние разрешено — вместе с ним отправитель получает верхнюю ступень
<source 10.0.0.0/24>
    allow-mailmerge yes    process-x-virtual-mta yes
    default-virtual-mta mta-hub-pool
</source>
Обе нижние строки этому источнику уже ничего не гарантируют: переменная слияния в содержимом перебьёт и заголовок, и умолчание. Если выбор потока должен оставаться за узлом, слияние такому источнику не выдают.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Разрешают слияние источнику с чужим содержимым

§ 9.4

Чем чреватоВместе со слиянием отправитель получает право выбрать любой поток на узле, включая тот, что прогревается для другого клиента. Конфигурация выглядит правильной и ничего не нарушает.
Как заметитьВ учёте у клиента появляются имена потоков, которых ему не выдавали; суточные объёмы прогрева соседа растут без причины.
Как правильноНе выдавать allow-mailmerge источникам с чужим содержимым. Единственная защита здесь — не включать: ограничить выбор «только этими потоками» MTA не умеет.

Ищут причину в конфигурации

§ 9.4

Чем чреватоРазбор идёт по конфигурации сверху вниз и ничего не находит, потому что причина лежит выше конфигурации — в содержимом письма. Время уходит на проверку правил, которые в этом случае вообще не читались.
Как заметить«В конфигурации всё правильно, а письма уходят не тем адресом» — и так по кругу.
Как правильноНачинать разбор с вопроса «включено ли слияние у этого источника». Если да — конфигурацию можно не смотреть, пока не исключено содержимое.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Наследования у механизма нет: переменная разбирается в каждом письме. Наследуется разрешение — allow-mailmerge записан в <source> и сливается по правилу источников: более узкий блок перекрывает более широкий.
⇄

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

1 связь

Зависит от

Персонализация внутри MTAСуществует только там, где слияние включено, и по той же причине действует на каждого получателя отдельно. § 9.4

Как проверить на узле
Отдельного счётчика нет. Косвенно — по расхождению между тем, что назначено, и полем имени потока в учёте:
pmtaacctfind --output csv[vmta,jobId,rcpt] /var/log/pmta/acct-*.csv
Если поток расходится с назначенным, а заголовок стоял правильный, остаётся ровно одна причина выше по лестнице — переменная слияния в содержимом. Проверять надо у отправителя, на узле следов нет.
◇

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

3 статьи

◇Лицензия на парк, а не на серверЛицензия не привязана к серверу: её ставят на столько машин, сколько разрешает предел экземпляров, а узлы раз в час отправляют вендору статистику объёма.◇Как узел выбирает источник и складывает его настройкиСоединение попадает под все блоки источника, чьи адреса его накрывают, и действуют они слитно — узкий перекрывает широкий; именованные блоки подключаются только по прямой ссылке.◇Списки адресов — именованные и безымянныеСписок адресов, доменов, образцов или хешей; именованный подключается директивами вроде подавления, безымянный живёт внутри процессора входящей почты.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Разделение отправителей