trace-spf-check

<source>

Класть ли в заголовок письма все запросы, сделанные при проверке
в конфигурации это строкаtrace-spf-check falseвнутри блока <source>
Разбирательство ценой размера письма

Добавляет в заголовок с результатами проверки все запросы к DNS, которые для неё понадобились. Умолчание — не добавлять.

Польза одна и понятная: когда проверка даёт неожиданный результат, по этому следу видно, что именно узел спросил и что ему ответили. Без него остаётся повторять проверку вручную и надеяться, что DNS ответит так же.

След остаётся в письме. Он не пишется в журнал — он добавляется к самому сообщению и доезжает до получателя, обработчика, архива.

Главная ловушка — след уходит вместе с письмом. Сложная запись SPF порождает десяток запросов, и все они окажутся в заголовке принятого письма. Это и заметный размер, и внутренние подробности вашего разрешения имён в чужом ящике.
Что делает Хаб. Не пишет: проверка на входе не включена. И включать этот след стоило бы только на время разбирательства — как и прочие отладочные переключатели.
Рекомендуемые значения

Только на время разбирательства. И с комментарием, когда включили.

Не на потоке. Десяток лишних строк в каждом принятом письме складывается быстро.

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

Совет пользоваться ручной проверкой вместо следа — наш. Из руководства здесь умолчание и состав следа: все запросы к DNS.
Пример в конфигурации
# ВРЕМЕННО: разбираемся с проверкой одного отправителя
<source 198.51.100.0/24>
    check-spf-inbound true
    trace-spf-check true</source>
Источник сужен до одной сети намеренно: след попадёт только в письма оттуда, а не во всю принимаемую почту.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Оставляют включённым после разбирательства

наш опыт

Чем чреватоКаждое принятое письмо несёт десяток строк служебного следа — и до получателя, и в архив. Размер растёт, подробности разрешения имён утекают наружу.
Как заметитьВ заголовках писем видны запросы к DNS.
Как правильноВыключить; на время разбирательства ставить с комментарием.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
trace-spf-check <boolean>
Значения
yes или no; true и false принимаются наравне с ними
Умолчание
false § 3.3.7.21
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<source>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение задаётся в блоке <source> и действует на почту, поданную подходящим источником; при нескольких подходящих блоках выигрывает наиболее точный. Срабатывает только при включённой check-spf-inbound. Подхватывается по pmta reload.
Как проверить на узле
Значение задаётся в конфигурации источника; результат виден в заголовке принятого письма:
grep -n trace-spf-check /etc/pmta/config
grep -i 'Authentication-Results' /var/log/pmta/pmta.log | tail -3
След добавляется к тому же заголовку, что и результат проверки, — и уезжает вместе с письмом. Хаб этой строки не пишет.
В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Приём входящей почты