process-x-job

<source>Хаб задаёт сам

Читать ли заголовок x-job и метить им письмо
в конфигурации это строкаprocess-x-job falseвнутри блока <source>
Разрешение, без которого рассылку потом не отобрать

Умолчание — false. С разрешением MTA берёт значение заголовка x-job и делает его меткой задания письма. Вид заголовка простой:

x-job: abc123

Ограничение на значение жёсткое: печатаемые символы, без пробелов и непечатаемых. Заголовок в письме предполагается один.

При слиянии заголовок не работает. Если письмо собирается слиянием, метку задают переменной *jobid, а не заголовком — руководство говорит это прямо.

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

Главная ловушка — метку нельзя поставить задним числом. Разрешение действует на письма, поданные после него. Момент, когда метка нужна, — это момент, когда одну рассылку из нескольких требуется срочно остановить, а её письма уже в очереди и уже без меток.

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

Что делает Хаб. Пишет — и пишет запрет: строка process-x-job false стоит в каждом именованном источнике подачи рабочей конфигурации.

Отсюда и устройство управления очередями в Хабе: остановка, возобновление и удаление работают по очереди, а не по заданию. Отбирать по заданию нечего — метку не ставит ни прогрев, ни платформа подачи.

На узле с рассылками нескольких отправителей это значит, что остановка задевает всех, кто шлёт в ту же сторону.

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

Что ставить. Ответ зависит от того, кто отвечает за содержимое метки:

Значение Когда
no (умолчание) подача чужая, и позволять ей называть метки задания незачем
yes подача ваша, и вы хотите уметь останавливать рассылки поштучно

Приставка jobid-prefix снимает половину возражений против yes: она добавляет к метке ваше значение, и заданиям разных отправителей уже не столкнуться. Со значением {auth} приставкой становится логин подающего.

Умолчание false, ограничение на символы, оговорка про один заголовок и про слияние — из руководства, § 3.3.7.49. Разбивка «кому давать» наша.
Пример в конфигурации
# разрешение выдаётся источнику, под который попадает подача
<source 10.0.0.0/24>
    process-x-job true    jobid-prefix {auth}
</source>
Письмо со строкой «x-job: sale-08» получит метку, начинающуюся логином подавшего пользователя. Дальше по этой метке работают отбор в очереди и остановка одной рассылки.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Кладут в метку пробелы или человеческое название

§ 3.3.7.49

Чем чреватоРуководство разрешает только печатаемые символы без пробелов. Название рассылки в читаемом виде под это не подходит, и метка либо не ставится, либо ставится не тем, чем задумано.
Как заметитьСписок заданий узла пуст или показывает обрезанные имена.
Как правильноСтавить машинный идентификатор рассылки, а человеческое название держать у себя рядом с ним.

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

§ 3.3.7.49

Чем чреватоДля слияния руководство требует переменную *jobid и прямо говорит не пользоваться заголовком. Метка не встанет, и рассылка окажется неотличимой от прочих.
Как заметитьЗадания видны у обычных рассылок и не видны у собранных слиянием.
Как правильноВ слиянии задавать метку переменной *jobid.

Включают разрешение чужому источнику без приставки

наш опыт

Чем чреватоЧужой отправитель называет метки заданий сам — и может назвать те же, что и вы. Остановка вашей рассылки заденет и его письма, а его — ваши.
Как заметитьВ списке заданий встречаются имена, которых ваша платформа не ставила.
Как правильноДобавить приставку — своим значением или зарезервированным {auth}, который подставляет логин подающего.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
process-x-job <boolean>
Значения
yes | no | true | false
Умолчание
false § 3.3.7.49
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<source>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Директива живёт в <source> и подчиняется слиянию источников: соединение попадает под все адресные блоки, которые его накрывают, и узкий перекрывает широкий. Для подачи под логином действует именованный блок — у нас запрет прописан именно там, в каждом блоке подачи отдельно.
Как проверить на узле
Разрешение видно в конфигурации, результат — в списке заданий узла:
grep -n 'process-x-job\|jobid-' /etc/pmta/config /etc/pmta/virtualhost.txt
pmta show jobs --maxitems=20
Пустой список заданий при непустой очереди означает, что метку не ставит никто: либо разрешения нет, либо подающая сторона заголовок не шлёт. У нас список пуст всегда — разрешение выключено намеренно.
В Хабе
Значение
Хаб подбирает сам — темп, стадия прогрева, метрики
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Подключить платформу отправки