Обычно всё о подписи решает конфигурация узла. Этот механизм отдаёт часть решений письму: подающая сторона ставит заголовок X-DKIM-Options, и он перекрывает настройки для одного этого сообщения.
Параметров пять, записываются через точку с запятой, как теги в самой подписи: s — селектор, d — домен, i — имя подписи, q — способ запроса ключа, key-list — имя списка, из которого брать ключ.
Перекрытие не безграничное. Заголовок выбирает среди объявленных ключей, а не приносит свой: указанный селектор или домен должен найтись в конфигурации, иначе письмо не подписывается. И сам механизм работает, только если у источника включена обработка этого заголовка.
# два ключа на один домен — письмо выбирает второй domain-key key1, example.com, /etc/pmta/key1.example.com.pem domain-key key2, example.com, /etc/pmta/key2.example.com.pem # и в самом письме: X-DKIM-Options: s=key2
что делают не так и чем это кончается2 ошибки▶
наш опыт
§ 10.3.3
2 связи
grep -n process-x-dkim-options /etc/pmta/config grep -i 'DKIM-Signature' /var/log/pmta/pmta.log | tail -3
3 статьи
◇Не отправлять то, что не пройдёт проверку у получателяУзел сам проверяет SPF своей почты перед отправкой: не прошло — отбивает, не дожидаясь чужого отказа.◇Как узел подписывает письма и выбирает ключКлюч выбирается по домену отправки из заголовков, перебором объявлений сверху вниз.◇Вторая подпись на том же письмеДвенадцать строк с приставкой second-: письмо подписывается дважды, разными ключами и от разных имён.