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

process-x-dkim-options

<source>

Читать ли заголовок X-DKIM-Options и править по нему подпись
в конфигурации это строкаprocess-x-dkim-options falseвнутри блока <source>
Настройки подписи, заданные для одного письма

Умолчание — false. С разрешением MTA берёт значения из заголовка X-DKIM-Options и подписывает ими письмо — но только если подпись для этого письма вообще настроена. Заголовок правит подпись, а не включает её.

Синтаксис заголовка похож на теги самой подписи, через точку с запятой. Глава 10 перечисляет, чем можно распорядиться:

Тег Что задаёт Условие
s селектор, тег s= подписи объявленный ключ должен иметь этот селектор
d домен, тег d= подписи ключ должен иметь ровно этот домен, звёздочку или подходящий путь в хранилище
i личность, тег i= подписи без d ключ должен иметь тот же домен или родительский
q способ запроса, тег q= —
key-list из какого списка брать ключ список должен быть объявлен

Смысл — выбрать один ключ из нескольких объявленных. Если у домена два ключа с разными селекторами, заголовок X-DKIM-Options: s=key2 называет второй.

Для второй подписи этот способ не работает: руководство оговаривает это отдельно. Вторая подпись настраивается только директивами.

Без разрешения заголовок игнорируется и, как прямо сказано в разделе, остаётся в письме.

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

Второй край той же ловушки: названный селектор должен существовать. Опечатка в теге s — это не «подписать как получится», а несовпадение с условием, которое руководство ставит явно.

Что делает Хаб. Не пишет, то есть оставляет вендорское умолчание false. Ключи и селекторы Хаб раскладывает по узлам сам и подписывает по конфигурации: у каждой пары «домен плюс адрес отправки» свой ключ, названный в её потоке. Отдавать выбор ключа подающей стороне незачем — она и так подаёт под своим логином, которому соответствует ровно один поток.

Практическое следствие для нас в другом: если платформа подачи всё-таки поставит этот заголовок, MTA его не прочтёт и не снимет — заголовок доедет до получателя.

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

Что ставить. Вопрос ровно один — выбирает ли ключ подающая сторона:

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

Второй случай встречается у посредников, подписывающих за многих клиентов ключами этих клиентов. Там же обычно нужен и process-x-dkim-key.

Умолчание false и оговорка про вторую подпись — из руководства, § 3.3.7.45 и § 10.3.4. Разбор тегов заголовка — § 10.3.3. Разбивка «кому давать» — наша.
Пример в конфигурации
# заголовок правит подпись только там, где подпись уже настроена
<source 10.0.0.0/24>
    process-x-dkim-options true</source>
Письмо из этой подсети с заголовком «X-DKIM-Options: s=key2» подпишется вторым ключом домена. Ключ при этом должен быть объявлен заранее — заголовок только называет его.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Называют селектор, которого нет

§ 10.3.3

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

Ждут, что заголовок настроит вторую подпись

§ 10.3.4

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

Оставляют разрешение выключенным и забывают про заголовок

§ 3.3.7.45

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

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

3 связи

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

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

На что влияет

domain-keyGlobalЗаголовок выбирает среди ключей, объявленных этой директивой, и не может назвать ключ, которого нет. § 3.3.7.45

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

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

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

dkim-sign<domain>Третье значение отдаёт решение о подписи заголовку письма, а его обработку включает эта строка у источника. § 3.3.7.45domain-key<domain-key-list>Список выбирается заголовком письма, а обработку этого заголовка включает та строка у источника. § 3.3.7.45Заголовок письма, которым подающая сторона правит подписьСтрока у источника, без которой заголовок не обрабатывается вовсе. § 10.3.3

Как проверить на узле
Разрешение видно в конфигурации; объявленные ключи — рядом, и без них разрешение бессмысленно:
grep -n 'process-x-dkim-options\|domain-key' /etc/pmta/config /etc/pmta/virtualhost.txt
Если строка разрешения есть, а объявленных ключей нет, заголовок не сделает ничего. Сработал ли выбор — видно по тегу s= в подписи доставленного письма.
◇

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

3 статьи

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

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Подпись и аутентификация писем
Соседние настройки блока <source>:reject-spf-check-temperrorreject-spf-check-permerrorreject-spf-check-failcheck-spf-inboundcheck-dkim-inboundВсе 74 директив блока →