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

Засеивание кампаний контрольными адресами

automatic inline seeding
Чужие ящики вместо своих

Задача одна и старая: понять, куда попадает письмо — во «Входящие» или в «Спам». Ответа на неё нет ни в учёте, ни в метриках: приёмник отвечает «принято» одинаково в обоих случаях. Единственный способ — контрольные ящики у самих почтовиков.

Вендор предлагает делать это за вас. Адреса заведены на его стороне, MTA подставляет их в кампанию сам, результат виден в его инструменте.

Механизм независим от выгрузки событий. <signals> и засеивание включаются порознь; но при использовании обоих субсчета должны быть согласованы — вендор оговаривает это отдельно, и добавляет, что отбора по правилам, как у выгрузки, здесь нет вовсе.

Охват задаётся отдельной строкой — enable-inline-seeding, и у неё три уровня: узел, пул, адрес отправки. Правило наследования обычное, пул сильнее узла. Тонкость: значение true без указания субсчёта не наследует субсчёт сверху, а обнуляет его.

Главная ловушка — считать засеивание измерением доставляемости. Оно измеряет попадание в папку у горстки контрольных адресов, а не у ваших получателей. Это индикатор, а не статистика: он ловит направление изменений, а не их величину.
Что делает Хаб. Не пользуется.

🔎 Задача при этом наша. Контрольные ящики — то, чем мы собирались мерить попадание в папку, — упираются в проблему, которую вендор здесь решил за деньги: опрос ящиков с одного адреса кончается их блокировкой, а значит нужен прокси. Пока эта часть отложена, и панель показывает доставляемость по ответам приёмников (250 / 4xx / 5xx), а не по папке.

🔎 Ограничения механизма стоит знать и для своей реализации: письмо должно нести идентификатор задания, быть не больше 20 МБ и иметь заголовок отправителя. Первое у нас есть, остальное — разумные условия для любой такой схемы.

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

Собственных значений у механизма нет — его собирают из блока и строки охвата:

Что Чем Умолчание
доступ к службе api-key в блоке нет, обязателен
охват enable-inline-seeding true на узле, если блок есть
ритм разговора batch-frequency, persist-threshold 15 секунд, 5 писем
кэш решения eligibility-ttl 5 минут
Четыре условия работы, требования к письму, определение кампании, независимость от выгрузки событий и правило наследования охвата — из руководства (§ 11.2, § 11.2.1). Оценка «индикатор, а не статистика» — наша.
Пример в конфигурации
# блок даёт доступ, строка охвата — где именно засеивать
<inline-seeding>
    api-key 0123456789abcdef012345678901234567890123
</inline-seeding>

enable-inline-seeding true,subaccount=555
<virtual-mta v3>
    enable-inline-seeding true
</virtual-mta>
У v3 значение true без субсчёта: субсчёт узла он не унаследует, а обнулит. Это не опечатка вендора, а описанное поведение.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Ждут засеивания от рассылки без идентификатора задания

§ 11.2

Чем чреватоКампания определяется по идентификатору задания, домену и субсчёту. Без идентификатора кампании нет, и засеивать нечего.
Как заметитьЧасть рассылок засеивается, часть нет.
Как правильноПроставлять идентификатор задания всем рассылкам.

Пишут true без субсчёта у адреса отправки

§ 11.2.2.1

Чем чреватоЗначение без субсчёта не наследует его сверху, а обнуляет. Данные засеивания этого потока уйдут без привязки к клиенту.
Как заметитьУ части потоков субсчёт в данных пустой.
Как правильноУказывать субсчёт явно на каждом уровне, где пишется строка охвата.

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

наш опыт

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

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

3 связи

Без чего не работает

Две метки, которые отправитель вешает на письмоИдентификатор задания — обязательное условие: без него кампании не существует, и засеивать нечего. § 11.2

Конфликтует

Ключ подписи, пришедший вместе с письмомКлюч подписи, переданный заголовком, поддержан не полностью: письма-семена могут уйти неподписанными. § 11.2.2.1

Работают в паре

Аналитика вендора — и что уходит с узла ради неёВторой механизм того же вендора: включаются порознь, но субсчета у них должны быть согласованы. § 11.2.1

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

enable-inline-seedingGlobalУстройство механизма целиком: что засеивается, при каких условиях и во что это обходится. § 11.2.2.1api-key<inline-seeding>Механизм, работу которого эта строка и настраивает. § 11.2.2.2.1Спам-ловушкиМеханизм, который здесь и виден. inference

Как проверить на узле
Работу видно по журналу MTA и по инструменту вендора:
grep -i "seed\|inline" /var/log/pmta/log | tail -20
Обращения к службе означают, что механизм работает. Семена в самой рассылке в учёте видны как обычные получатели — по метке srcType их различают только метрики.
◇

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

3 статьи

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

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Разобраться с доставляемостью · Засеивание и контрольные ящики