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

Заголовки, которыми отправитель управляет доставкой

критично

X- control headers
Решение принимает не конфигурация, а письмо

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

Заголовок Что делает Разрешение Оставить в письме
X-Virtual-MTA выбирает поток отправки process-x-virtual-mta retain-x-virtual-mta
x-job помечает письмо заданием process-x-job retain-x-job
x-envid задаёт идентификатор конверта process-x-envid —
X-DKIM-Options правит настройки подписи process-x-dkim-options retain-x-dkim-options
X-DKIM-Key приносит приватный ключ process-x-dkim-key retain-x-dkim-key
x-schedule задаёт окна отправки process-x-schedule retain-x-schedule

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

Все умолчания — false. То есть управление заголовками выключено, пока его не включили тому источнику, с которого идёт подача. Платформа, рассчитывающая на выбор потока заголовком, против источника без разрешения не получит никакой ошибки — выбор просто не сработает.

Главная ловушка — руководство противоречит само себе в самом опасном месте.

Раздел про обработку ключа подписи говорит: если обработка не включена, MTA не удаляет заголовок, и советует проверить установку, чтобы не утекли приватные ключи. Раздел про сохранение того же заголовка утверждает обратное: при обеих директивах false MTA игнорирует заголовок, но всё равно удаляет его перед доставкой.

Так же расходятся и остальные разделы: три «обработать» — про поток, про идентификатор конверта, про настройки подписи — прямо говорят «оставляя заголовок в письме, если он там был». Обе фразы про удаление стоят в разделах «сохранить» и написаны под копирку.

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

Что делает Хаб. Пользуется одним заголовком из шести — X-Virtual-MTA. Разрешение на него стоит во всех источниках рабочей конфигурации: и в подобранных по адресу, и в именованных источниках подачи с логином. Прогрев ставит этот заголовок на каждое письмо, и это основной способ выбора адреса отправки.

Заголовок задания Хаб запрещает явно — строкой process-x-job false в каждом именованном источнике подачи. Остальные четыре не задаёт вовсе: они остаются в вендорском умолчании false.

Сохранение заголовков Хаб не трогает нигде, то есть полагается на умолчание. Для X-Virtual-MTA это значит, что имя потока снимается перед доставкой и получателю не показывается.

Пример в конфигурации
# разрешения выдаются источнику, а не узлу целиком
<source 10.0.0.0/24>
    process-x-virtual-mta yes    process-x-job false
    always-allow-relaying yes
</source>
Из этой подсети сработает выбор потока заголовком; метку задания MTA читать не будет. Обе строки касаются только этой подсети — соседний блок решает за себя.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

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

§ 3.3.7.44

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

Ставят разрешение не тому источнику

§ 3.3.7

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

Полагаются на MTA в защите приватного ключа

§ 3.3.7.46

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

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

3 связи

На что влияет

domain-keyGlobalЗаголовок с ключом подписи подменяет объявленные ключи на одно письмо. § 3.3.7.46

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

Как узел выбирает источник и складывает его настройкиВсе разрешения задаются у источника и подчиняются его слиянию. § 3.3.7Как узел подписывает письма и выбирает ключГлава 10 описывает, чем именно распоряжаются заголовки подписи. § 3.3.7.45

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

process-x-envid<source>Один из шести служебных заголовков подачи, со своим разрешением у источника. § 3.3.7.44process-x-dkim-options<source>Один из шести служебных заголовков подачи, со своим разрешением у источника. § 3.3.7.45process-x-dkim-key<source>Самый опасный из шести служебных заголовков подачи. § 3.3.7.46retain-x-dkim-key<source>Половина «оставить или снять» у самого опасного из шести служебных заголовков. § 3.3.7.47retain-x-dkim-options<source>Половина «оставить или снять» у одного из шести служебных заголовков. § 3.3.7.60process-x-job<source>Один из шести служебных заголовков подачи, со своим разрешением у источника. § 3.3.7.49

Как проверить на узле
Разрешения видны только в конфигурации — отдельной команды под них у MTA нет:
grep -n 'process-x-\|retain-x-\|jobid-' /etc/pmta/config /etc/pmta/virtualhost.txt
Найденные строки нужно разложить по блокам источника и наложить по правилу слияния: разрешение в широком блоке достаётся и узким. Сработал ли заголовок — видно уже по следствию: имя потока в учёте, метка задания в списке заданий, подпись в доставленном письме.
◇

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

3 статьи

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

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