<inline-seeding>
Служба решает, подлежит ли задание засеиванию, а узел это решение запоминает — чтобы не спрашивать заново на каждое письмо. Строка задаёт срок хранения. Умолчание — 5m, допустимо от пяти минут до часа.
Увеличивать безопасно там, где настройка редко меняется — так прямо говорит вендор. Цена увеличения — задержка: правка в кабинете вендора дойдёт до узла не раньше, чем истечёт срок.
Это кэш решения, а не кэш данных. Сами назначения семян обновляются по другому расписанию — batch-frequency.
🔎 Задача близка к нашей. Контрольные ящики — то, чем мы собирались мерить попадание в папку, — здесь решены вендором: адреса подставляются в рассылку сами, а результат смотрят в его же инструменте. Наш разбор показал, что своими силами это упирается в прокси: опрос ящиков с одного адреса кончается их блокировкой.
Значение выбирают по размеру и длительности рассылок:
| Значение | Когда |
|---|---|
| 5m (умолчание) | настройку меняют, идёт обкатка |
| 1h | настройка устоялась, меняется редко |
<inline-seeding> api-key 0123456789abcdef012345678901234567890123 eligibility-ttl 1h</inline-seeding>
что делают не так и чем это кончается2 ошибки▶
наш опыт
§ 11.2
1 связь
grep -i "eligib\|seed" /var/log/pmta/log | tail -20
2 статьи
◇Засеивание кампаний контрольными адресамиMTA подмешивает в рассылку адреса вендора, а результат смотрят в его инструменте доставляемости; независимо от выгрузки событий.◇Заголовок заданияЗаголовок x-job метит письмо заданием; узел читает его, только если источнику разрешено process-x-job, и тогда задание видно в учёте, мониторе и командах паузы.