<inline-seeding>
The line sets how often the node contacts the service to reconcile the job counters and receive seed assignments. The default is 15s, the allowed range is from fifteen seconds to five minutes.
The second condition is volume, persist-threshold: reconciliation happens on whichever comes first.
Increasing it is safe for long mailings — so the vendor says. The idea is the same: fewer requests for the same work.
The price of increasing it is timing precision. Seeds are inserted into the mailing as it goes, and infrequent reconciliation means an assignment arrives later than it could.
🔎 The task is close to ours. Seed mailboxes — what we were going to use to measure inbox placement — are solved here by the vendor: addresses are inserted into the mailing automatically, and the results are viewed in its own tool. Our analysis showed that doing it ourselves runs into proxies: polling mailboxes from a single address ends with them being blocked.
The value is chosen by the size and duration of mailings:
| Value | When |
|---|---|
| 15s (default) | mailings are short |
| 1m–5m | jobs run for hours |
<inline-seeding> api-key 0123456789abcdef012345678901234567890123 batch-frequency 5m</inline-seeding>
what people get wrong and how it ends2 mistakes▶
our experience
§ 11.2
1 relation
grep -i "seed" /var/log/pmta/log | tail -20
2 articles
◇Seeding campaigns with control addressesThe engine mixes the vendor’s addresses into a mailing, and the result is viewed in the vendor’s deliverability tool; independent of event export.◇Job headerThe x-job header tags a message with a job; the node reads it only if the source is allowed process-x-job, and then the job is visible in accounting, the monitor and pause commands.