reject-spf-check-fail

<source>

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

Из трёх исходов проверки этот самый определённый: запись SPF домена есть, она читается, и в ней сказано, что с этого адреса почту слать не разрешено. Владелец домена объявил это сам.

Строка решает, отвергать ли такое письмо на команде отправителя — окончательным отказом. Умолчание — отвергать.

Из трёх это единственная, чьё умолчание бесспорно. Двум другим исходам — ошибке в записи и временному сбою — отправитель ничего не объявлял; здесь он объявил прямо.

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

Оставлять отказ можно. Это единственный исход, где отправитель высказался прямо.

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

Отказ окончательный. Отправитель повторять не будет — в отличие от временной ошибки.

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

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

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

Отвергают на источнике, через который идёт пересылка

наш опыт

Чем чреватоПересланное письмо приходит с адреса пересыльщика при чужом обратном адресе — проверка не проходит всегда. Отвергается вся пересланная почта, и выглядит это как избирательная потеря писем.
Как заметитьНе доходят письма из списков рассылки и от почтовых шлюзов.
Как правильноДля таких источников выключить отказ, оставив проверку и заголовок с результатом.

Включают вместе с двумя другими не глядя

наш опыт

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