Demo
Demo
База знаний PMTA›Блок <signals>›Директива§ 11.1.6.2.12

process-x-sp-subaccount-id

<signals>

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

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

Номер — целое положительное число, ноль и отрицательные не годятся.

Строка общая на два блока. Руководство говорит это прямо: выставленная хоть здесь, хоть в блоке засеивания <inline-seeding>, она действует для обоих. То есть отдельного решения «для выгрузки событий» и «для засеивания» не бывает — решение одно, а мест записи два.

При слиянии заголовок не работает — там номер задают переменной *subaccountid.

И главное: заголовок (как и переменная слияния) отменяет субсчёт, заданный конфигурацией. Приоритет у подающей стороны.

Главная ловушка — вы разрешаете, а решает отправитель. Субсчёт задуман как разделение трафика между клиентами, и, включив чтение заголовка, вы отдаёте это разделение тому, кто подаёт письмо: он может приписать свой трафик любому номеру, включая чужой. Строка в конфигурации при этом перестаёт действовать — заголовок её отменяет.

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

Что делает Хаб. Не пишет: службой Signals он не пользуется — события собирает своей телеметрией через вебхук учёта.

Разделение клиентов у нас держится на своих потоках отправки и логинах подачи, а не на субсчетах чужой службы.

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

Что ставить. Вопрос — кому вы доверяете разделение трафика:

Значение Когда
false (умолчание) субсчёт назначает конфигурация: подающая сторона его не выбирает
true подача идёт от вас же, и номер удобнее ставить в письме, чем плодить блоки

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

Умолчание false, требование к номеру, приоритет заголовка над конфигурацией, оговорка про переменную слияния и общность строки с блоком засеивания — из руководства, § 11.1.6.2.12. Разбивка случаев наша.
Пример в конфигурации
# строка действует и здесь, и в блоке засеивания — она одна на два блока
<signals>
    api-key 0123456789012345678901234567890123456789
    process-x-sp-subaccount-id true</signals>
Письмо с заголовком x-sp-subaccount-id: 123 отнесёт свои события к субсчёту 123 — и отменит номер, заданный конфигурацией.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Включают чтение для чужой подающей платформы

§ 11.1.6.2.12

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

Считают строку настройкой только этого блока

§ 11.1.6.2.12

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

Ставят заголовок в письме, собранном слиянием

§ 11.1.6.2.12

Чем чреватоДля слияния руководство требует переменную *subaccountid и заголовок не читает. Номер не встанет, а события уйдут к субсчёту из конфигурации либо без него.
Как заметитьСубсчёт проставляется у обычных писем и не проставляется у собранных слиянием.
Как правильноЗадавать номер переменной слияния.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
process-x-sp-subaccount-id { yes | no }
Значения
yes | no | true | false
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<signals>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Директива живёт в <signals>, но наследования в обычном смысле у неё нет: она общая с блоком засеивания, и выставленная в любом из двух действует для обоих. Перекрыть её на уровне блока нельзя — перекрывает её только сам заголовок письма.
⇄

Связанные директивы

1 связь

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

Шесть способов выбрать поток и порядок между нимиТот же порядок старшинства, что и у выбора потока: заголовок письма сильнее конфигурации. inference

Как проверить на узле
Строку видно в конфигурации; смотреть надо оба блока сразу:
grep -n -A3 '^<signals>\|^<inline-seeding>' /etc/pmta/config
Строка в любом из двух блоков включает чтение заголовка для обоих. Сработал ли заголовок — видно по субсчёту в событиях службы: он будет тот, что в письме, а не тот, что в конфигурации.
◇

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

3 статьи

◇Лицензия на парк, а не на серверЛицензия не привязана к серверу: её ставят на столько машин, сколько разрешает предел экземпляров, а узлы раз в час отправляют вендору статистику объёма.◇Как узел выбирает источник и складывает его настройкиСоединение попадает под все блоки источника, чьи адреса его накрывают, и действуют они слитно — узкий перекрывает широкий; именованные блоки подключаются только по прямой ссылке.◇Списки адресов — именованные и безымянныеСписок адресов, доменов, образцов или хешей; именованный подключается директивами вроде подавления, безымянный живёт внутри процессора входящей почты.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Разделение отправителей
Соседние настройки блока <signals>:privacy-policyhtml-edit-error-modecustom-message-id-headerretain-x-sp-subaccount-idengagement-trackingВсе 16 директив блока →