<source>
Запись SPF может ссылаться на другие домены, те — на следующие. Разбирая её, узел делает запросы к DNS, и часть их возвращается пустыми: имени нет или ответ пустой. Эта строка задаёт, сколько таких ответов стерпеть, прежде чем признать проверку постоянной ошибкой.
Умолчание — два. Руководство объясняет почему: низкий порог мешает превратить вашу проверку в средство нагрузки на чужой резолвер. Обратная сторона названа там же — сложные записи могут не разобраться.
Исход при превышении один: постоянная ошибка. Что с ней делать, решает reject-spf-check-permerror.
Оставьте умолчание. Оно уравновешивает две крайности, названные в руководстве.
Повышать — только разобравшись, чьи записи не проходят. Сложная запись у крупного отправителя — повод; десяток неизвестных доменов — нет.
Понижать незачем. Ниже двух остаются только простейшие записи, а нагрузку на резолвер это уменьшает незначительно.
# умолчание оставлено намеренно <source 0/0> check-spf-inbound true check-spf-inbound-max-void-lookups 2</source>
что делают не так и чем это кончается1 ошибка▶
наш опыт
2 связи
grep -n max-void-lookups /etc/pmta/config grep -ci 'permerror' /var/log/pmta/pmta.log
3 статьи
◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.◇Два обработчика входящих отчётов и что с ними делатьОтказы письмом и жалобы разбираются двумя одинаково устроенными блоками; у каждого свой список адресов и своя пара решений о судьбе письма.◇Списки адресов — именованные и безымянныеСписок адресов, доменов, образцов или хешей; именованный подключается директивами вроде подавления, безымянный живёт внутри процессора входящей почты.