Demo
Demo
База знаний PMTA›Блок <virtual-mta>›Директива§ 3.3.12.11

include-headers-from

<virtual-mta>

Файл заголовков для писем этого адреса отправки
в конфигурации это строкаinclude-headers-fromвнутри блока <virtual-mta>
То же имя ещё 2:Global<virtual-mta><virtual-mta-pool>— часть из них другие настройки, часть та же самая
Свой файл заголовков — в дополнение к общему

Синтаксис тот же. Меняется область — и, в отличие от остальных директив блока, не меняется способ наследования.

Значения складываются. Руководство говорит об этом прямо: если строка задана на уровне узла и здесь, применяются обе. Это единственная директива <virtual-mta>, которая ведёт себя так; у соседей по блоку своё значение перекрывает общее.

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

Главная ловушка. Привычка «своё перекрывает общее» здесь неверна. Файл, написанный сюда «вместо» общего, ничего не отменяет — письмо получит оба набора заголовков, а одноимённые окажутся в нём дважды.
Что делает Хаб. Не пишет ни здесь, ни на уровне узла. Заголовки формирует отправляющая сторона; узел, наоборот, снимает лишнее — remove-header вычищает служебные заголовки платформы, а add-received-header выключен.
Рекомендуемые значения

Значение — путь к файлу, как и на уровне узла. Разница в том, что сюда стоит класть:

Уровень Что туда Помня о сложении
узел одинаковое для всех писем достанется всем адресам отправки
здесь то, что относится к этому адресу добавится к общему, не заменит
<virtual-mta-pool> общее для группы про сложение на этом уровне руководство молчит

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

Правило сложения — из руководства (§ 3.3.1.55.3), прямой формулировкой. Разбивка «что на какой уровень» — наша.
Пример в конфигурации
# у адреса отправки свой файл — он ДОБАВИТСЯ к общему, а не заменит
<virtual-mta shop-example-com>
    smtp-source-host 203.0.113.10 shop.example.com
    include-headers-from /etc/pmta/shop-headers.txt</virtual-mta>
Если на уровне узла тоже задан файл, письмо получит заголовки из обоих. Чтобы применялся только этот, общую строку надо убрать — иначе перекрытия не произойдёт.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Пишут файл сюда, чтобы отменить общий

§ 3.3.1.55.3

Чем чреватоОтмены не происходит: применяются оба файла. Расчёт «здесь свой набор заголовков» превращается в «общий плюс свой», и часть заголовков дублируется.
Как заметитьВ письме заголовки из файла, который для этого адреса не назначали.
Как правильноУбрать общую строку на уровне узла или свести оба файла в один. Перекрыть эту директиву нельзя.

Переносят правило сложения на пул

наш опыт

Чем чреватоРуководство формулирует сложение только для узла и адреса отправки. Что происходит с пуловым значением, не описано, а остальные пуловые директивы участник перекрывает.
Как заметитьПоведение расходится с ожиданием, и проверить его можно только опытом.
Как правильноНе рассчитывать на сложение через пул. Держать файл на одном уровне и проверять результат по письму.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
include-headers-from <see-global>
Значения
путь к файлу с заголовками в формате RFC 2822
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<virtual-mta>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
🔴 Исключение из общего правила блока. Своё значение здесь не перекрывает общее, а складывается с ним — так написано в руководстве. Про уровень <virtual-mta-pool> оно не говорит ничего, и переносить на него правило сложения без проверки нельзя: остальные пуловые директивы перекрываются участником обычным образом.
⇄

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

2 связи

То же имя в других блоках

include-headers-fromGlobalОпределение руководство даёт на уровне узла; здесь — только то, что меняет запись внутри адреса отправки. § 3.3.1.55.3

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

Адрес отправки — из чего он складываетсяОдна из настроек адреса отправки: какие заголовки добавляются в его письма. § 3.3.12.11

Как проверить на узле
Единственная надёжная проверка — по доставленному письму. По конфигурации видно только, что файлов два:
grep -rn include-headers-from /etc/pmta/config
Две строки в выводе означают, что заголовки сложатся. Дальше надо посмотреть исходный код письма: одинаковые имена заголовков в двух файлах дадут дубли.
◇

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

3 статьи

◇Заголовки, которыми отправитель управляет доставкойШесть служебных заголовков позволяют подающей стороне выбрать поток, пометить письмо заданием, задать настройки и ключ подписи, идентификатор конверта и расписание; каждый разрешается отдельно и по источникам.◇Щадящий режим — вторая личность очередиОчередь, которой приёмник начал отказывать, переключается на параллельный набор лимитов, повторов и маршрутов — десять директив, действующих только в этом режиме.◇Прогрев, встроенный в MTAПрогретый адрес отдаёт первые N писем дня каждому получателю своему холодному напарнику; тот отправляет их сам и набирает историю.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Ротация адресов отправки
Соседние настройки блока <virtual-mta>:host-namedomain-keysmtp-source-hostproxy-protocolproxy-include-tlvВсе 15 директив блока →