<source>
Добавляет в заголовок с результатами проверки все запросы к DNS, которые для неё понадобились. Умолчание — не добавлять.
Польза одна и понятная: когда проверка даёт неожиданный результат, по этому следу видно, что именно узел спросил и что ему ответили. Без него остаётся повторять проверку вручную и надеяться, что DNS ответит так же.
След остаётся в письме. Он не пишется в журнал — он добавляется к самому сообщению и доезжает до получателя, обработчика, архива.
Только на время разбирательства. И с комментарием, когда включили.
Не на потоке. Десяток лишних строк в каждом принятом письме складывается быстро.
Вручную часто достаточно. Команда проверки на узле показывает то же самое, ничего не добавляя к письмам.
# ВРЕМЕННО: разбираемся с проверкой одного отправителя <source 198.51.100.0/24> check-spf-inbound true trace-spf-check true</source>
что делают не так и чем это кончается1 ошибка▶
наш опыт
1 связь
grep -n trace-spf-check /etc/pmta/config grep -i 'Authentication-Results' /var/log/pmta/pmta.log | tail -3
3 статьи
◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.◇Два обработчика входящих отчётов и что с ними делатьОтказы письмом и жалобы разбираются двумя одинаково устроенными блоками; у каждого свой список адресов и своя пара решений о судьбе письма.◇Списки адресов — именованные и безымянныеСписок адресов, доменов, образцов или хешей; именованный подключается директивами вроде подавления, безымянный живёт внутри процессора входящей почты.