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