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

Отправитель называет поток для каждого письма

критично

VirtualMTA selection at submission
Поток называет тот, кто подаёт письмо

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

Это самый прямой и самый невидимый из трёх. В конфигурации узла не остаётся никакого следа о том, что письмо ушло определённым потоком, потому что так сказал отправитель. Читая конфигурацию, нельзя понять, как распределяется трафик.

Для прогрева это единственный подходящий механизм. План, который обязан отправить ровно столько-то писем ровно этим адресом ровно в это время, не может отдавать решение пулу: пул раздаёт по кругу, а не по плану.

Доступен и по SMTP, и через API. По SMTP — заголовком X-Virtual-MTA, через API — вызовом метода. Разница между ними только в granularity при слиянии: заголовок действует на всё задание.

Главная ловушка. Ничто не проверяет, что узел выбор исполнил. Отправитель назвал поток, письмо приняли — и всё; совпало ли имя с настроенным потоком, видно только в учёте, задним числом. Опечатка в имени превращается в отказ на подаче или, при настроенном запасном варианте, в тихую отправку не тем адресом.
Что делает Хаб. Именно так и работает прогрев: планировщик ставит заголовок с именем нужного потока на каждое письмо. Разрешение на заголовок Хаб пишет сам — process-x-virtual-mta yes в источниках подачи. Чего пока нет — сверки: никто не сравнивает, каким потоком письмо ушло на самом деле, с тем, какой назначил план. Данные для сверки есть, поле vmta пишется в учёт по каждому письму.
Рекомендуемые значения

Собственных значений у механизма нет: значение — это имя потока или пула, и его задаёт отправитель. Со стороны узла настраивается лишь разрешение (process-x-virtual-mta) и поведение при неизвестном имени (reject-invalid-virtual-mta и invalid-virtual-mta-fallback).

Из руководства здесь то, что выбор делается на письмо и что имя может быть именем пула. Про сверку с планом — наше наблюдение.
Пример в конфигурации
# письмо само называет поток — как это делает планировщик прогрева
x-virtual-mta: shop-example-com
From: Магазин <news@shop.example.com>
To: recipient@example.net
Subject: Проверка прогрева

Тело письма.
Заголовок узел снимает перед доставкой, получателю он не виден. Чтобы строка сработала, у источника, с которого подано письмо, должно стоять process-x-virtual-mta yes — без этого заголовок не только не выберет поток, но и уедет получателю как есть.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Шлют заголовок источнику, который его не обрабатывает

§ 3.3.7.52

Чем чреватоБеда двойная: выбор не срабатывает — письмо уходит умолчанием, — и сам заголовок остаётся в письме и доезжает до получателя, показывая ему внутренние имена потоков.
Как заметитьВ доставленном письме виден X-Virtual-MTA, а в учёте стоит совсем другое имя потока.
Как правильноПоставить process-x-virtual-mta yes у того источника, с которого идёт подача. Не «где-нибудь», а именно у совпавшего блока <source>.

Батчат прогрев слиянием

§ 9.4

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

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

3 связи

Чем можно заменить

Группа адресов отправки с долями трафикаТем же вызовом можно назвать пул: тогда MTA раздаёт письма его участникам по кругу, а не выбирает адрес сам. inferenceЗаголовки, которыми отправитель управляет доставкойТот же выбор при подаче по SMTP выражается заголовком, а не вызовом метода. inference

Где применяется

Адрес отправки — из чего он складываетсяВыбирается именно поток — набор адреса, имени в приветствии и правил доставки. § 7.4.7

Сюда ссылаются

Шесть способов выбрать поток и порядок между нимиПодача через API называет поток вызовом метода — это вторая ступень лестницы, и переменная слияния её перебивает. § 9.4

Как проверить на узле
Сверить назначенное с отправленным можно только по учёту — узел решение не комментирует:
pmtaacctfind --output csv[vmta,header:x-virtual-mta,rcpt] /var/log/pmta/acct-*.csv
Поле vmta — поток, которым письмо ушло. Если оно расходится с тем, что назначил план, причина одна из двух: заголовок не обрабатывался у этого источника, или его перебила переменная слияния в содержимом.
◇

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

3 статьи

◇Адрес отправки — из чего он складываетсяИменованный набор всего, что является свойством адреса: с какого IP уходит письмо, чем узел представляется, чем подписывает и как быстро шлёт.◇Прогрев, встроенный в MTAПрогретый адрес отдаёт первые N писем дня каждому получателю своему холодному напарнику; тот отправляет их сам и набирает историю.◇Группа адресов отправки с долями трафикаИменованная группа адресов отправки; без долей письма раздаются по кругу, с долями — в заданной пропорции, с шагом в десятую процента.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Ротация адресов отправки · Прогрев адресов · Отправка через прокси
Важность
критично