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

process-x-envid

<source>

Читать ли заголовок x-envid и задавать по нему идентификатор конверта
в конфигурации это строкаprocess-x-envid falseвнутри блока <source>
Обходной путь для тех, кто не может сказать это по протоколу

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

Штатный способ задать идентификатор конверта другой: параметр ENVID команды MAIL в самом протоколе. Руководство прямо называет случай, ради которого сделан заголовок, — подающее приложение не позволяет управлять этим параметром. Тогда то же значение передают заголовком письма.

Без разрешения заголовок игнорируется и, как прямо сказано в разделе, остаётся в письме.

Идентификатор конверта — вторая из двух меток подачи. В отличие от метки задания, он опознаёт одно письмо, а не группу, и служит отбором –envId в перечислении, удалении и смене приоритета.

Главная ловушка — заголовок проигрывает протоколу молча. Если подающая библиотека всё-таки умеет передавать параметр в команде MAIL и передаёт его, письмо получит идентификатор оттуда. Разбираться, какая из двух дорог сработала, придётся по учёту, а не по конфигурации.

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

Что делает Хаб. Не пишет: идентификатор конверта Хаб не задаёт ни заголовком, ни параметром протокола.

Поле envid при этом входит в звёздочку record-fields, которую Хаб ставит всем видам записей, — значит оно приезжает в телеметрию с каждой записью и всегда пусто. События с отправками Хаб связывает по адресу получателя и адресу отправки, а не по идентификатору письма.

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

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

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

Второе — именно обходной путь, а не равноценная замена: параметр протокола не путешествует в теле письма и не может уехать получателю.

Умолчание false, снятие заголовка при чтении и назначение «когда приложение не даёт управлять параметром» — из руководства, § 3.3.7.44. Оценка «обходной путь, а не замена» наша.
Пример в конфигурации
# заголовок нужен там, где приложение подачи не умеет параметр ENVID
<source 10.0.0.0/24>
    process-x-envid true</source>
Письмо со строкой «x-envid: order-40213» получит этот идентификатор конверта, а сам заголовок будет снят перед доставкой. Без строки разрешения тот же заголовок уедет получателю.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Ставят заголовок, не выдав разрешения

§ 3.3.7.44

Чем чреватоИдентификатор не появится, отбор по нему ничего не найдёт, а сам заголовок останется в письме и уедет получателю — вместе с вашим внутренним номером заказа или письма.
Как заметитьВ доставленном письме виден x-envid.
Как правильноВыдать разрешение блоку источника, под который попадает подача, либо снять заголовок на подающей стороне.

Пользуются заголовком, имея параметр протокола

§ 3.3.7.44

Чем чреватоЗначение путешествует в теле письма вместо служебного канала. Если разрешение при этом выключено, оно доезжает получателю — чего с параметром команды MAIL не случается никогда.
Как заметитьБиблиотека подачи умеет ENVID, а конфигурация всё равно полагается на заголовок.
Как правильноПередавать параметром команды MAIL, а заголовок оставить для приложений, которые этого не умеют.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
process-x-envid <boolean>
Значения
yes | no | true | false
Умолчание
false § 3.3.7.44
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<source>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Директива живёт в <source> и подчиняется слиянию источников: соединение попадает под все адресные блоки, которые его накрывают, и узкий перекрывает широкий. Для подачи под логином действует именованный блок, и строку в нём приходится повторять — наследования из адресных блоков в именованный мы на своей установке не увидели.
⇄

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

1 связь

Где применяется

Заголовки, которыми отправитель управляет доставкойОдин из шести служебных заголовков подачи, со своим разрешением у источника. § 3.3.7.44

Как проверить на узле
Разрешение видно в конфигурации, результат — в очереди:
grep -n 'process-x-envid' /etc/pmta/config /etc/pmta/virtualhost.txt
pmta list --envId=order-40213 --maxitems=20
Если письмо по идентификатору не находится, значит MTA его не поставил: либо разрешения нет, либо заголовок пришёл не в том виде. Хаб идентификатор конверта не задаёт — ни прогревом, ни шаблонами конфигурации, — так что у писем прогрева поле envId в телеметрии пустое.
◇

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

3 статьи

◇Как письмо попадает в MTAШесть описанных способов подачи: расширенный SMTP, четыре языковые обвязки и каталог, за которым узел следит на диске.◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.◇Заголовки, которыми отправитель управляет доставкойШесть служебных заголовков позволяют подающей стороне выбрать поток, пометить письмо заданием, задать настройки и ключ подписи, идентификатор конверта и расписание; каждый разрешается отдельно и по источникам.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Подключить платформу отправки
Соседние настройки блока <source>:process-x-jobjobid-prefixallow-mailmergeadd-message-id-headeradd-received-headerВсе 74 директив блока →