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

Вторая подпись на том же письме

second DKIM signature

Одно письмо, две подписи

Письмо можно подписать дважды, разными ключами и от разных имён. Для этого у каждой строки подписи есть двойник с приставкой second-: second-dkim-sign, second-dkim-identity, second-dkim-headers и так далее — двенадцать штук, полный набор.

Ради чего. Отправка за клиента: первая подпись ставится ключом клиента, по домену из его From; вторая — вашим, от вашего имени. Получатель видит обе и может доверять любой: клиент подтверждает, что письмо от него, вы — что оно ушло через вас.

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

Главная ловушка — вторых строк нет в оглавлении руководства. Двенадцать директив описаны единственным абзацем в главе 10 и в перечень директив не попали. Их нет и в этом каталоге: он повторяет вендорский перечень позиция в позицию. Искать их надо по § 10.3.4, а не по указателю.

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

Пример в конфигурации

# клиентская подпись по его домену и наша — по нашему
<virtual-mta 12345>
    domain-key 2017k1, esp.com, /etc/pmta/esp.esp.com.pem
    domain-key 2017-01, customer.com, /etc/pmta/2017-01.customer.com.pem
    <domain *>
        dkim-sign yes
        second-dkim-sign yes        second-dkim-identity @esp.com    </domain>
</virtual-mta>

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

жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.

▲

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

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

Ищут вторые строки в оглавлении директив

§ 10.3.4

Чем чреватоИх там нет: двенадцать директив описаны абзацем в главе 10 и в перечень не попали. Отсутствие в указателе принимают за отсутствие возможности.

Как заметитьПоиск по имени second-dkim-sign ничего не находит.

Как правильноЧитать § 10.3.4 — там перечислены все двенадцать.

Включают вторую подпись, не объявив второй ключ

наш опыт

Чем чреватоКлюч ищется по тем же правилам, и не найдя подходящего, узел просто не ставит вторую подпись. Молча: письмо уходит с одной.

Как заметитьВ письме один заголовок подписи вместо двух.

Как правильноОбъявить ключ на домен, заданный вторым именем подписи.

Совместимость

PowerMTA 6.0

описана в руководстве этой версии · платформа: любая

С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.

⇄

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

1 связь

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

Как узел подписывает письма и выбирает ключТот же механизм второй раз, со своими настройками. § 10.3.4

Как проверить на узле

Две подписи видны в письме двумя заголовками; различаются они полями d= и s=:

grep -n 'second-dkim' /etc/pmta/config
grep -c 'DKIM-Signature' /var/log/pmta/pmta.log

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

◇

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

3 статьи

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

В Хабе

Цена ошибки: обратимо: вредит, пока стоит
Сценарии: Подпись и аутентификация писем