Demo
Demo
База знаний PMTA›Блок <source>›Директива§ 3.3.7.70

reject-spf-check-permerror

<source>

Отвергать ли письмо, когда запись SPF отправителя нечитаема
в конфигурации это строкаreject-spf-check-permerror trueвнутри блока <source>
Отправитель не запретил, а напутал

Постоянная ошибка проверки — это не «слать нельзя», а «запись не удалось разобрать»: синтаксическая ошибка, недопустимая конструкция, слишком много вложенных запросов. Умолчание — отвергать такое письмо окончательным отказом.

Отвергаете вы за чужую опечатку. Владелец домена ничего не запрещал; он просто ошибся, публикуя запись. Писем от таких доменов больше, чем кажется: сложные записи с вложенными ссылками ломаются часто и незаметно для владельца.

Сюда же приводит превышение предела пустых ответов DNS — им управляет check-spf-inbound-max-void-lookups, и его умолчание невелико.

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

Осмысленнее не отвергать. Результат всё равно попадёт в заголовок, и решение можно принять дальше по цепочке — уже зная содержимое письма.

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

Проверьте предел пустых ответов. Часть этих ошибок приходит не от записи отправителя, а от вашего собственного порога.

Оценка «осмысленнее не отвергать» — наша. Из руководства здесь умолчание, код отказа и пример причины: синтаксическая ошибка в записи.
Пример в конфигурации
# чужую опечатку записываем в заголовок, но письмо принимаем
<source 0/0>
    check-spf-inbound true
    reject-spf-check-fail true
    reject-spf-check-permerror false</source>
Строка выше отвергает то, что домен запретил сам; эта — то, в чём он ошибся. Решения разные, потому что и случаи разные.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Отвергают наравне с прямым запретом

наш опыт

Чем чреватоОтклоняется почта доменов, чьи владельцы просто ошиблись в записи. У большинства получателей их письма проходят, и разбираться в потере будете вы.
Как заметитьВ отказах домены с корявыми, а не поддельными записями.
Как правильноОставить результат в заголовке, а решение принимать дальше.

Не связывают этот исход с пределом пустых ответов

§ 3.3.7.24

Чем чреватоЧасть постоянных ошибок порождает не запись отправителя, а собственный порог узла. Ужесточив порог, вы увеличиваете число отказов, не меняя ни одной строки про них.
Как заметитьДоля таких исходов выросла после правки предела.
Как правильноСмотреть обе строки вместе.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
reject-spf-check-permerror <boolean>
Значения
yes или no; true и false принимаются наравне с ними
Умолчание
true § 3.3.7.70
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<source>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение задаётся в блоке <source> и действует на почту, поданную подходящим источником; при нескольких подходящих блоках выигрывает наиболее точный. Срабатывает только при включённой check-spf-inbound. Подхватывается по pmta reload.
⇄

Связанные директивы

2 связи

Без чего не работает

check-spf-inbound<source>Строка не срабатывает, пока проверка на входе не включена. § 3.3.7.70

На что влияет

Два обработчика входящих отчётов и что с ними делатьОтвергнутое на входе письмо до обработчиков не доходит. § 3.3.7.70

Сюда ссылаются

check-spf-inbound-max-void-lookups<source>Превышение порога даёт постоянную ошибку — а что с ней делать, решает та строка. § 3.3.7.24

Как проверить на узле
Значение задаётся в конфигурации источника; сколько таких исходов приходит, видно по заголовкам принятых писем:
grep -n reject-spf-check-permerror /etc/pmta/config
grep -ci 'permerror' /var/log/pmta/pmta.log
Заметная доля таких исходов обычно означает не поток подделок, а чужие сломанные записи. Хаб этой строки не пишет.
◇

Что ещё почитать

3 статьи

◇Два обработчика входящих отчётов и что с ними делатьОтказы письмом и жалобы разбираются двумя одинаково устроенными блоками; у каждого свой список адресов и своя пара решений о судьбе письма.◇Что делать с принятым письмомЧто узел делает с принятым входящим письмом: пересылает, кладёт в файл, гасит, передаёт программе или разбирает как отказ или жалобу.◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.

В Хабе
Цена ошибки
опасно: последствия переживут откат
Сценарии
Классификация отказов · Приём входящей почты
Соседние настройки блока <source>:reject-spf-check-temperrorreject-spf-check-failcheck-spf-inboundcheck-dkim-inboundprocess-x-dkim-optionsВсе 74 директив блока →