<source>
Добавляет к заголовку с результатами проверок все запросы к DNS, сделанные при проверке подписи, — то есть поиск открытого ключа. Умолчание — не добавлять.
Польза одна: когда проверка подписи даёт неожиданный результат, по следу видно, какой именно ключ узел искал и что получил в ответ. Без следа приходится повторять запрос вручную и надеяться, что DNS ответит так же.
След уезжает вместе с письмом — как и у прочих строк этого рода.
Только на время разбирательства. И с комментарием.
Сузьте источник. След попадёт лишь в письма из указанной сети.
Часто хватает ручного запроса. Открытый ключ смотрится одной командой по селектору и домену из подписи.
# ВРЕМЕННО: разбираемся, почему не проходит проверка подписи <source 198.51.100.0/24> check-dkim-inbound true trace-dkim-check true</source>
что делают не так и чем это кончается1 ошибка▶
наш опыт
1 связь
grep -n trace-dkim-check /etc/pmta/config dig +short TXT k1._domainkey.example.org
3 статьи
◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.◇Два обработчика входящих отчётов и что с ними делатьОтказы письмом и жалобы разбираются двумя одинаково устроенными блоками; у каждого свой список адресов и своя пара решений о судьбе письма.◇Списки адресов — именованные и безымянныеСписок адресов, доменов, образцов или хешей; именованный подключается директивами вроде подавления, безымянный живёт внутри процессора входящей почты.