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

allow-mailmerge

<source>

Можно ли использовать расширения слияния от этого источника
в конфигурации это строкаallow-mailmerge falseвнутри блока <source>
Разрешение подавать одно письмо на многих

Умолчание — false. Строка разрешает источнику пользоваться расширениями слияния — тремя дополнительными командами протокола, которыми письмо передаётся один раз, а получатели и подставляемые значения идут отдельно.

Смысл — объём: вместо тысячи одинаковых передач одна, и разница в нагрузке на канал и на узел заметная.

Строку можно включить косвенно. Руководство говорит: always-allow-api-submission со значением yes на сегодня равносилен этому разрешению. То есть включив разрешение для подачи по API, вы включили и слияние.

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

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

Что делает Хаб. Не пишет — и косвенно тоже не включает: always-allow-api-submission, который по букве руководства сегодня равносилен разрешению слияния, убран из конфигурации 29.08.2026.

Слияние нам и не нужно: прогрев подаёт письма по одному обычным SMTP, а подачей по API Хаб не пользуется.

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

Что ставить. Разрешение стоит выдавать по нужде, а не впрок:

Значение Когда
false (умолчание) подача идёт письмами по одному — наш случай
true подающая платформа умеет слияние и объём того стоит

Проверять при этом надо не только эту строку: разрешение на подачу по API включает слияние само.

Умолчание false — из руководства, § 3.3.7.11. Равносильность разрешению подачи по API — § 3.3.7.72, оттуда же слово «на сегодня».
Пример в конфигурации
# разрешение выдаётся тому источнику, чья платформа умеет слияние
<source 10.0.0.0/24>
    allow-mailmerge true</source>
Ту же настройку включает always-allow-api-submission yes — и включает молча, без этой строки в конфигурации.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Считают, что слияние выключено, раз строки нет

§ 3.3.7.72

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

Ждут от слияния обычной обработки заголовков

§ 3.3.7.1

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

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

2 связи

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

mailmerge-expands-undefined-variablesGlobalРешает, что делать с переменной, для которой значения не передали. § 3.3.1.39

На что влияет

always-allow-api-submission<source>Включает это разрешение заодно — по букве руководства, «на сегодня равносилен». § 3.3.7.72

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

Что подающая система собирает перед отправкойСлияние надо ещё и разрешить в блоке подачи — иначе подающая система его не применит. § 7.1Персонализация внутри MTAРазрешение на узле: без него подающая система слияние не применит. § 7.1Что нужно обвязке подачиДиректива, которой этот механизм и включается. § 7.1Слияние через расширения SMTPДиректива, которой этот механизм и включается. § 11.19.3

Как проверить на узле
Смотреть надо обе строки — вторая включает первую:
grep -n 'allow-mailmerge\|always-allow-api-submission' /etc/pmta/config /etc/pmta/virtualhost.txt
printf 'EHLO test\r\nQUIT\r\n' | nc <адрес-узла> 2525 | grep -i xmrg
Отсутствие первой строки не значит, что слияние выключено: вторая включает его сама. Надёжнее посмотреть приветствие приёмника с адреса подачи.
◇

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

3 статьи

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

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