<signals>
Служба получает от узла события доставки, а открытия и переходы — откуда-то ещё. Чтобы связать их в одно письмо, нужен общий идентификатор, и эта строка называет заголовок, из которого его брать. Умолчания нет.
🔴 Работает только при engagement-tracking со значением external. Руководство говорит это прямо: связывание требуется именно там, где события открытий шлёте вы сами.
Длина — до 512 знаков латиницы. У почтовой подстановки свой путь: там вместо заголовка пользуются переменной *custommessageid.
Зачем это на самом деле. Без связывания служба видит два несвязанных потока: «письмо доставлено» и «кто-то что-то открыл». Половина её выводов строится на соединении этих двух, и вендор называет связывание условием полной пользы от аналитики.
🔎 Приём при этом общий и знакомый: свой идентификатор письма, проставленный заголовком, — то же, что мы делаем полем учёта header_ИМЯ, только для чужой стороны.
Строка нужна ровно в одном сочетании:
| Отслеживание | Строка |
|---|---|
| external | нужна: иначе события не свяжутся |
| sparkpost | не нужна: MTA связывает сам |
| no | не нужна |
# события открытий шлёте вы — нужен общий идентификатор <signals> engagement-tracking external custom-message-id-header x-my-msgid</signals>
что делают не так и чем это кончается1 ошибка▶
§ 11.1.6.2.11
1 связь
grep -i "signals" /var/log/pmta/log | tail -20
3 статьи
◇Отдать письмо вебхуку вместо приёмникаОчередь шлёт письмо запросом POST в виде объекта JSON; успехом считается только ответ 2xx.◇Узел умеет сам вставлять пиксели и переписывать ссылкиВ режиме отслеживания вендора MTA разбирает исходящий HTML, переписывает ссылки на домен отслеживания и вставляет пиксели открытия — с выбором того, что делать, если разметка не разбирается.◇Разбор и правка разметкиОтслеживание открытий и переходов в режиме sparkpost правит разметку письма с помощью встроенного разборщика gumbo-parser; письмо, разметку которого разобрать не удалось, по умолчанию отбивается.