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

dkim-disallow-adding-headers

<domain>

Какие заголовки должны ломать подпись, если их добавят после неё
в конфигурации это строкаdkim-disallow-adding-headersвнутри блока <domain>
Сделать добавление заголовка заметным

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

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

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

Главная ловушка — забыть её включить. Умолчания у строки нет: без неё письмо с верной подписью можно дополнить вторым From или вторым Subject, и получатель увидит чужой текст под вашей подписью. Это не теория — приём известный, и защита от него состоит ровно в одной строке.
Что делает Хаб. Пока не пишет. Это кандидат на добавление в шаблон политик: строка ничего не стоит, а закрывает известный способ подделать письмо с проходящей проверкой. Набор напрашивается очевидный — отправитель, получатель, тема.
Рекомендуемые значения

Начните с трёх: from, to, subject. Это набор из примера руководства и ровно те заголовки, подмена которых меняет смысл письма для читателя.

Добавьте reply-to, если он у вас есть. Второй Reply-To уводит ответы на чужой адрес, а письмо выглядит подлинным.

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

Набор для начала и совет не перечислять всё — наши. Из руководства здесь назначение (защита от повторного использования подписанного письма), синтаксис и пример.
Пример в конфигурации
# второй From или Subject теперь ломает подпись
<domain *>
    dkim-disallow-adding-headers from,to,subject,reply-to</domain>
Имена попадают в подпись лишний раз — приёмник видит, что заголовков с такими именами должно быть ровно столько, сколько было при подписи.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Не задают её вовсе

наш опыт

Чем чреватоПисьмо с верной подписью можно дополнить вторым From или Subject. Почтовый клиент покажет добавленный, получатель увидит чужой текст под вашей подписью, и проверка при этом пройдёт.
Как заметитьСтроки нет в конфигурации.
Как правильноЗадать хотя бы from,to,subject.

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

§ 3.3.10.29

Чем чреватоКаждое имя попадает в подпись лишний раз, поле h= разрастается. Пользы нет: заголовки, которых читатель не видит, подменять незачем.
Как заметитьВ строке десяток имён, включая служебные.
Как правильноОставить те, что показываются читателю или управляют ответом.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
dkim-disallow-adding-headers <header-list>
Значения
имена заголовков через запятую; умолчания нет — без строки защита не действует
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение сливается по блокам <domain> от общего к частному: побеждает наиболее подходящий блок, а не последний по файлу. Умолчания нет: где строка не задана, защита не действует. Подхватывается по pmta reload; на письма в очереди действует со следующей попытки.
⇄

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

2 связи

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

arc-oversigned-headers<domain>То же самое для подписи пересылки. § 3.3.10.38

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

dkim-headers<domain>Та строка добавляет заголовки к подписи, эта — перечисляет имена ещё раз, чтобы их появление подпись ломало. § 3.3.10.26

Как проверить на узле
Действующее значение печатает команда настроек очереди; результат виден по повторам имён в поле h= подписи:
pmta show settings gmail.com/vmta1 | grep -i disallow-adding
grep -i 'DKIM-Signature' /var/log/pmta/pmta.log | tail -3
Имя, встречающееся в поле h= дважды, и есть защищённое этой строкой. Хаб её пока не пишет — кандидат в шаблон политик.
◇

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

3 статьи

◇Не отправлять то, что не пройдёт проверку у получателяУзел сам проверяет SPF своей почты перед отправкой: не прошло — отбивает, не дожидаясь чужого отказа.◇Как узел подписывает письма и выбирает ключКлюч выбирается по домену отправки из заголовков, перебором объявлений сверху вниз.◇Заголовок письма, которым подающая сторона правит подписьПять параметров в X-DKIM-Options: селектор, домен, имя подписи, способ запроса и список ключей.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Подпись и аутентификация писем
Соседние настройки блока <domain>:dkim-signdkim-identitycheck-spf-outbounddkim-headersdkim-add-body-limitВсе 135 директив блока →