process-x-sp-subaccount-id

<inline-seeding>

Читать ли заголовок с номером субсчёта
в конфигурации это строкаprocess-x-sp-subaccount-idвнутри блока <inline-seeding>
То же имя ещё 1:<inline-seeding><signals>— часть из них другие настройки, часть та же самая
Кто решает, чей это трафик

Строка разрешает узлу читать заголовок x-sp-subaccount-id и брать из него номер субсчёта для данных засеивания. Умолчание — false, и тогда заголовок игнорируется, а в письме остаётся.

🔴 Заголовок сильнее конфигурации. Если он есть и разрешён, номер субсчёта из конфигурации игнорируется. То есть подающая сторона получает право решать, к какому счёту отнести трафик, — и это надо понимать до включения.

У почтовой подстановки свой путь: там вместо заголовка пользуются переменной *subaccountid, и она тоже перебивает конфигурацию.

Строка общая на два механизма. Вендор оговаривает прямо: включённая хоть в <inline-seeding>, хоть в <signals>, она действует для обоих.

Главная ловушка — включить, не подумав, кто ставит заголовок. Подающая платформа сможет приписать свой трафик любому субсчёту, и разделение по клиентам перестанет быть вашим решением.
Что делает Хаб. Не пишет: засеиванием вендора мы не пользуемся. Разделение клиентов у нас идёт своими потоками, а не субсчетами чужой службы.
Рекомендуемые значения

Решение зависит от доверия к подающей стороне:

Значение Когда
false (умолчание) субсчёт задаётся конфигурацией
true подающая сторона доверенная и сама знает клиента
Умолчание false, приоритет заголовка над конфигурацией, оговорка про переменную почтовой подстановки и общность строки с блоком выгрузки событий — из руководства (§ 11.2.2.2.5).
Пример в конфигурации
<inline-seeding>
    api-key 0123456789abcdef012345678901234567890123
    process-x-sp-subaccount-id true</inline-seeding>
Со включённой строкой номер из заголовка перебивает любой, заданный конфигурацией.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Включают, не проверив, кто ставит заголовок

наш опыт

Чем чреватоНомер из заголовка перебивает конфигурацию. Подающая платформа сможет отнести свой трафик к любому субсчёту.
Как заметитьДанные засеивания появляются под чужим субсчётом.
Как правильноОставить false там, где подающая сторона не полностью доверенная.

Настраивают строку отдельно в двух блоках

§ 11.2.2.2.5

Чем чреватоСтрока общая: включённая хоть в засеивании, хоть в выгрузке событий, она действует для обоих. Разные значения в двух блоках не дадут разного поведения.
Как заметитьВ одном блоке true, в другом false, а ведут себя одинаково.
Как правильноСчитать её одной настройкой на два механизма.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
process-x-sp-subaccount-id { yes | no }
Значения
yes | no | true | false
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<inline-seeding>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Наследования нет: строка живёт внутри <inline-seeding>, а такой блок на узле один. Но действие у неё общее с <signals>: включённая в любом из двух, она работает для обоих.
Как проверить на узле
Проверять надо по отправленному письму — заголовок либо есть, либо нет:
grep -i "x-sp-subaccount-id" /var/log/pmta/log | tail -10
Надёжнее посмотреть заголовки письма, дошедшего до контрольного ящика: там видно, ушёл заголовок получателю или был снят.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Разделение отправителей