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

Как узел подписывает письма и выбирает ключ

критично

DKIM key selection
Ключ выбирается письмом, а не настройкой

Подпись включается строкой dkim-sign у получателя, а ключ выбирается по самому письму. Узел смотрит на домен отправки — берёт его из заголовка Sender, а если того нет, из From, — и ищет подходящий ключ среди объявлений domain-key.

Перебор идёт сверху вниз, побеждает первое подходящее. Подходит объявление, чей домен совпал с доменом отправки или является для него родительским: ключ для example.com подпишет письма с mail.example.com, обратное неверно.

Ключи потока сильнее общих. Если подходящие объявления есть и на уровне узла, и внутри VirtualMTA, выигрывают те, что внутри.

Не нашлось ни одного — письмо уходит без подписи. Молча: ни ошибки, ни записи в журнале.

Главная ловушка — звёздочка выше конкретных объявлений. Объявление с доменом * подходит любому письму, а перебор идёт сверху вниз — значит оно перехватит и те письма, для которых ниже лежит точный ключ. Руководство прямо советует держать звёздочку последней.
Что делает Хаб. Ведёт ключи на карточке домена в разделе «DNS → Домены и зоны», публикует записи и раскладывает объявления по узлам. Порядок объявлений Хаб выстраивает сам — точные домены выше, звёздочка ниже, — так что перехвата не случается.
Пример в конфигурации
# точные домены выше, звёздочка последней — иначе она перехватит всё
domain-key m, mail.port25.com, /etc/pmta/m.pem
domain-key k1, example.org, /etc/pmta/k1.example.org.pem
domain-key base, *, /etc/pmta/base.pem
<domain *>
    dkim-sign yes
</domain>
Поменяйте строки местами — и подсвеченная подпишет всё своим ключом, а два точных объявления не отработают ни разу.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Ставят объявление со звёздочкой первым

§ 3.3.1.55.1

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

Заводят ключ на поддомен и ждут, что он подпишет родительский

§ 3.3.1.55.1

Чем чреватоСовпадение идёт в одну сторону: объявление для example.com подходит письмам с mail.example.com, но не наоборот. Письма с родительского домена остаются без ключа.
Как заметитьЧасть писем не подписана, ключ при этом есть.
Как правильноРегистрировать ключ на домене подписи или на его родителе.

Считают, что домен подписи — это домен получателя

наш опыт

Чем чреватоКлюч ищется по домену отправки из заголовков письма, а dkim-sign задаётся у получателя. Настроив ключ по получателю, вы не найдёте совпадения ни для одного письма.
Как заметитьПодпись включена у всех получателей, писем с подписью нет.
Как правильноКлюч — на домен из Sender или From, включение — у получателя.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
⇄

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

3 связи

Чем можно заменить

Секреты во внешнем хранилищеКлюч может быть путём к файлу, а может — ссылкой в хранилище секретов; на подпись это не влияет. § 10.3.2

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

Сменить ключ подписи, не прерывая отправкуСмена ключа — это новый селектор, поэтому селектор и входит в объявление отдельным значением. § 10.3.2

Где это видно

Как включить подпись DKIM с нуляТо же самое по шагам: от выбора домена до первого подписанного письма. § 10.3.2

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

domain-keyGlobalПравило выбора ключа целиком — вместе с приоритетом потоков и поведением при отсутствии совпадения. § 3.3.1.55.1Заголовки, которыми отправитель управляет доставкойГлава 10 описывает, чем именно распоряжаются заголовки подписи. § 3.3.7.45Заголовок письма, которым подающая сторона правит подписьПерекрывает автоматический выбор ключа — но в пределах уже объявленных. § 10.3.3Вторая подпись на том же письмеТот же механизм второй раз, со своими настройками. § 10.3.4Ключ подписи, пришедший вместе с письмомКлюч приходит с письмом вместо того, чтобы лежать в конфигурации. § 10.3.5Подпись, которая сохраняет чужую проверку при пересылкеТе же объявления ключей и то же правило выбора, только набор строк подписи другой. § 10.4.2

Как проверить на узле
Какой ключ достался письму, видно по заголовку подписи в нём — селектор и домен стоят там прямо:
dig +short TXT k1._domainkey.example.org
grep -i 'DKIM-Signature' /var/log/pmta/pmta.log | tail -5
В заголовке подписи селектор стоит в поле s=, домен — в d=: по ним и сверяют, то ли объявление выиграло. Хаб порядок объявлений выстраивает сам.
◇

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

3 статьи

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

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