check-spf-inbound-max-void-lookups

<source>

Сколько пустых ответов DNS терпеть при проверке SPF
в конфигурации это строкаcheck-spf-inbound-max-void-lookups 2внутри блока <source>
Порог, за которым проверка сдаётся

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

Умолчание — два. Руководство объясняет почему: низкий порог мешает превратить вашу проверку в средство нагрузки на чужой резолвер. Обратная сторона названа там же — сложные записи могут не разобраться.

Исход при превышении один: постоянная ошибка. Что с ней делать, решает reject-spf-check-permerror.

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

Оставьте умолчание. Оно уравновешивает две крайности, названные в руководстве.

Повышать — только разобравшись, чьи записи не проходят. Сложная запись у крупного отправителя — повод; десяток неизвестных доменов — нет.

Понижать незачем. Ниже двух остаются только простейшие записи, а нагрузку на резолвер это уменьшает незначительно.

Советы про повышение и понижение — наши. Из руководства здесь умолчание, смысл порога и обе стороны выбора: защита от нагрузки против сложных записей.
Пример в конфигурации
# умолчание оставлено намеренно
<source 0/0>
    check-spf-inbound true
    check-spf-inbound-max-void-lookups 2</source>
Строка полезна как напоминание: именно этот порог порождает часть постоянных ошибок, за которые письма потом отвергаются.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Ужесточают порог при включённом отказе

наш опыт

Чем чреватоРастёт доля постоянных ошибок, и письма начинают отклоняться — по причине, которой в записи отправителя может не быть вовсе. Ни одна строка про отказы при этом не менялась.
Как заметитьОтказы выросли после правки, не связанной с отказами.
Как правильноВернуть умолчание либо выключить отказ по постоянной ошибке.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
check-spf-inbound-max-void-lookups <integer>
Значения
целое число пустых ответов DNS; умолчание 2
Умолчание
2 § 3.3.7.24
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<source>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение задаётся в блоке <source> и действует на почту, поданную подходящим источником; при нескольких подходящих блоках выигрывает наиболее точный. Срабатывает только при включённой check-spf-inbound, а результат превышения обрабатывает reject-spf-check-permerror. Подхватывается по pmta reload.
Как проверить на узле
Значение задаётся в конфигурации источника; сколько проверок упирается в порог, видно по доле постоянных ошибок:
grep -n max-void-lookups /etc/pmta/config
grep -ci 'permerror' /var/log/pmta/pmta.log
Отличить превышение порога от синтаксической ошибки в записи по журналу нельзя — оба дают один исход. Хаб этой строки не пишет.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Приём входящей почты