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

process-x-dkim-key

<source>критично

Читать ли приватный ключ подписи из заголовка письма
в конфигурации это строкаprocess-x-dkim-key falseвнутри блока <source>
Разрешение, от которого зависит, утечёт ли ключ

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

Один разрешением не обойтись. Нужен селектор — он передаётся отдельным заголовком X-DKIM-Options, а значит нужно и разрешение на него: process-x-dkim-options. Двух строк меньше не бывает.

Дальше начинается место, ради которого эту страницу стоит дочитать. Руководство пишет прямо: если разрешение не выставлено, MTA заголовок не удаляет, — и советует проверить свою установку, чтобы не утекли приватные ключи. То есть отсутствие разрешения не защищает: оно ровно наоборот, оставляет ключ в письме.

Соседний раздел про сохранение того же заголовка говорит обратное: при обеих директивах false заголовок якобы всё равно снимается. Верить нужно совету самого руководства — проверить.

Главная ловушка — «не включили» здесь не значит «безопасно». Разрешение выключено по умолчанию, и на этом обычно останавливаются. Но по § 3.3.7.46 именно выключенное разрешение оставляет заголовок в письме — вместе с приватным ключом внутри.

Опаснее всего сочетание, до которого легко дойти без злого умысла: подающая платформа умеет передавать ключ письмом, кто-то включил это на её стороне, а на узле разрешение не выставлено. Ключ проходит весь путь и уезжает получателю.

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

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

Проверять, не приходит ли такой заголовок со стороны платформ подачи, всё равно стоит: без разрешения MTA его, по букве § 3.3.7.46, не снимет.

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

Что ставить. Обе стороны выбора неприятны, и это нормально для такой директивы:

Значение Когда
no (умолчание) ключи объявлены в конфигурации — обычный случай, наш в том числе
yes посредник подписывает за многих клиентов их же ключами, и держать все ключи на узле нельзя

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

Что бы вы ни выбрали, retain-x-dkim-key должен остаться false.

Умолчание false, требование селектора и предупреждение про неудаляемый заголовок — из руководства, § 3.3.7.46. Разбивка случаев наша.
Пример в конфигурации
# без второй строки ключ бесполезен: селектор приходит отдельным заголовком
<source 10.0.0.0/24>
    process-x-dkim-key true    process-x-dkim-options true
</source>
Письмо должно нести оба заголовка: один с ключом в формате PEM, второй с селектором. Разрешения тоже нужны оба — порознь ни одно не работает.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Считают выключенное разрешение защитой

§ 3.3.7.46

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

Включают разрешение без разрешения на настройки подписи

§ 3.3.7.46

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

Выдают разрешение широкому блоку

наш опыт

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

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

3 связи

Без чего не работает

process-x-dkim-options<source>Селектор приходит соседним заголовком, поэтому без разрешения на него ключ подписать письмо не может. § 3.3.7.46

Конфликтует

retain-x-dkim-key<source>Вторая половина пары, и единственная, у которой руководство пишет предупреждение жирным. § 3.3.7.47

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

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

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

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

3 статьи

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

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