Demo
Demo
База знаний PMTA›Механизм§ 7.4.19

Персонализация внутри MTA

mailmerge variables and parts
Одно письмо, много писем — подстановка на стороне узла

Единственная возможность, которую руководство прямо называет преимуществом обвязок над обычным SMTP.

Как устроено. У каждого получателя свой набор именованных переменных. Тело письма добавляется двумя разными действиями: как дословные данные или как данные слияния — и во втором случае переменные подставляются при доставке, MTA, а не подающей системой.

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

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

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

Нумерованные части существуют для многочастных слияний: первая подразумевается, каждый номер используется один раз.

Главная ловушка — подставить туда, где подставлять нельзя. Данные слияния разворачиваются целиком, включая то, что в них случайно похоже на переменную. Кусок письма, добавленный слиянием «за компанию» — юридический текст, ссылка отписки, чужая вёрстка, — может быть изменён неожиданно. Разделение на дословные данные и данные слияния существует ровно для этого, и обходить его «чтобы проще» — верный способ получить испорченное письмо у части получателей.
Что делает Хаб. Не использует — прогрев отправляет письма по одному получателю, и разворачивать нечего.

Персонализацию у нас делает площадка до подачи: письмо приходит на узел уже собранным. Это осознанно — так содержимое видно в предпросмотре и в журнале до отправки, а не появляется на последнем шаге внутри MTA.

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

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

Что чем добавлять:

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

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

Слияние надо ещё и разрешить в блоке подачи (allow-mailmerge): без этого подающая система его не применит.

Таблица и совет проверять переносы на живом письме наши. Из руководства здесь разделение дословных данных и данных слияния, подстановка при доставке, нумерованные части и оговорка о записи переносов строк.
Пример в конфигурации
# у получателя свои переменные, письмо собирается одно
#   rcpt.defineVariable("name", "Мария")
#   msg.addMergeData("Здравствуйте, [name]!")
#   msg.addData("С уважением, отдел продаж")# первая строка тела подставится, вторая уйдёт как есть
Выделенная строка — дословные данные: их MTA не трогает. Строка выше добавлена слиянием, и в ней переменная будет заменена при доставке, отдельно для каждого получателя.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Добавляют слиянием всё подряд

§ 7.4.19

Чем чреватоДанные слияния разворачиваются целиком. Юридический текст, ссылка отписки или чужая вёрстка, попавшие в них, могут быть изменены там, где случайно похожи на переменную.
Как заметитьУ части получателей письмо приходит с испорченным куском — обычно там, где в тексте были квадратные скобки.
Как правильноДобавлять дословными данными всё, что не персонализируется. Разделение двух действий для этого и сделано.

Пишут перенос строки дословной косой

§ 7.4.19

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

Подают слияние, не разрешив его на узле

§ 3.3.7

Чем чреватоБлок подачи решает, применять ли слияние. Без разрешения подающая система его не применит, и письмо уйдёт с текстом шаблона вместо подставленных значений.
Как заметитьПолучатели видят имена переменных вместо своих данных.
Как правильноДобавить разрешение в блок подачи и проверить его до рассылки, а не после.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Наследования у механизма нет: переменные принадлежат получателю, данные — письму, и оба живут только в рамках одной подачи. Со стороны узла есть лишь разрешение: блок подачи решает, применять ли слияние вообще, и это разрешение сливается по обычному правилу источников.
⇄

Связанные записи

3 связи

Без чего не работает

allow-mailmerge<source>Разрешение на узле: без него подающая система слияние не применит. § 7.1Занятые имена переменных слиянияИмена, занятые MTA: свои переменные так называть нельзя. § 11.19.4.2Нумерованные части слиянияНумерованные части того же механизма — для многочастных слияний. § 11.19.4.3

Сюда ссылаются

mailmerge-expands-undefined-variablesGlobalПравило касается только писем, собираемых слиянием; для обычных подстановок нет. § 3.3.1.39Кодировки при подачеСмежный механизм: они работают вместе. § 7.4.14Подача по HTTPS на своём приёмнике, по образцу SparkPostТело письма собирается подстановками по тому же образцу. § 8.1Подача письма по HTTPМеханизм, который здесь и виден. § 8.1.4Шесть способов выбрать поток и порядок между нимиСлияние решает, действует выбор на всё задание разом или на каждого получателя отдельно. § 9.4Переменная слияния — верхняя ступень, и живёт она в содержимомСуществует только там, где слияние включено, и по той же причине действует на каждого получателя отдельно. § 9.4

Как проверить на узле
Проверять надо не конфигурацию, а результат — отправкой себе:
grep -n 'allow-mailmerge' /etc/pmta/config
pmta show jobs
Первая покажет, разрешено ли слияние в блоке подачи: без разрешения оно просто не применится. Сама подстановка проверяется только доставленным письмом — переносы строк и спецсимволы в переменных иначе не увидеть.
◇

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

3 статьи

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

В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Прогрев адресов · Подключить платформу отправки