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

retain-x-dkim-key

<source>критично

Оставлять ли приватный ключ подписи в отправленном письме
в конфигурации это строкаretain-x-dkim-key falseвнутри блока <source>
Строка, которую не включают

Умолчание — false. Смысл директивы — оставить заголовок X-DKIM-Key в письме при отправке на чужой сервер, то есть отправить получателю приватный ключ подписи.

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

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

Главная ловушка — не в самой строке, а в том, что о ней забывают. Её включают на время разбирательства, чтобы увидеть, с каким ключом пришло письмо, — и оставляют. Дальше каждое письмо с этого источника несёт приватный ключ получателю.

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

Что делает Хаб. Не пишет: механизм передачи ключа письмом он не задействует вовсе, поэтому и снимать нечего. Ключи Хаб раскладывает по узлам сам и называет их в конфигурации потоков.
Рекомендуемые значения

Что ставить. Выбора здесь по существу нет:

Значение Когда
no (умолчание) всегда
yes нет такого случая

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

Умолчание false, предупреждение о риске и рекомендация держать false — из руководства, § 3.3.7.47. Оценка «случая для yes нет» наша.
Пример в конфигурации
# значение по умолчанию, и менять его незачем
<source 0/0>
    retain-x-dkim-key false</source>
Строка написана ради явности: она повторяет умолчание. Смысл держать её в конфигурации один — чтобы при следующем разборе никто не включил обратное, не заметив.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Включают на время и оставляют

§ 3.3.7.47

Чем чреватоКаждое письмо с этого источника уносит приватный ключ получателю. Ключ после этого скомпрометирован, и вернуть его нельзя — только выпустить новый и заменить запись в DNS.
Как заметитьВ контрольном ящике видно письмо с X-DKIM-Key.
Как правильноУбрать строку, выпустить новый ключ, сменить селектор в DNS и дождаться, пока у приёмников истечёт кэш прежней записи.

Полагаются на независимость директив

§ 3.3.7.47

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

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

2 связи

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

process-x-dkim-key<source>Первая половина пары: та решает, читать ли ключ, эта — оставлять ли его в письме. § 3.3.7.47

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

Заголовки, которыми отправитель управляет доставкойПоловина «оставить или снять» у самого опасного из шести служебных заголовков. § 3.3.7.47

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

retain-x-dkim-options<source>Такая же настройка у соседнего заголовка, только цена ошибки там несравнимо выше: в письме остаётся приватный ключ. § 3.3.7.60

Как проверить на узле
Проверять стоит не только настройку, но и то, что реально доехало:
grep -rn 'retain-x-dkim-key' /etc/pmta/
Пустой вывод означает вендорское умолчание — оно верное. Найденная строка со значением true требует немедленного разбора: ключи, которыми подписаны уже отправленные письма, придётся считать скомпрометированными.
◇

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

3 статьи

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

В Хабе
Цена ошибки
опасно: последствия переживут откат
Сценарии
Безопасность узла
Важность
критично
Соседние настройки блока <source>:process-x-dkim-keysmtp-servicesmtp-max-auth-failure-rateallowed-sender-listsallow-unencrypted-plain-authВсе 74 директив блока →