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

check-arc-inbound

<source>

Проверять ли заверение пересылки у писем, которые подают нам
в конфигурации это строкаcheck-arc-inbound falseвнутри блока <source>
Чему верить, когда обычная подпись сломана пересылкой

Включает проверку заголовков ARC у входящих писем. Если письмо их несёт, узел проверяет цепочку заверений и записывает результат в общий заголовок проверок.

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

Отказов, как и у проверки подписи, нет. Только наблюдение.

Главная ловушка — доверие к цепочке упирается в доверие к пересыльщику. Заверение подтверждает лишь, что пересыльщик сказал вот это. Если он не заслуживает доверия, цепочка формально верна и бесполезна. Проверять надо не только её целостность, но и кто в ней участвовал.
Что делает Хаб. Не пишет: узлы принимают почту только от самого Хаба. Строка понадобится вместе с check-dkim-inbound, если узел начнёт принимать почту извне.
Рекомендуемые значения

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

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

Отказов нет. Как и у проверки подписи, MTA только записывает результат.

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

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

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

Доверяют цепочке, не глядя на её участников

наш опыт

Чем чреватоЗаверение подтверждает лишь, что пересыльщик сказал вот это. Цепочка от неизвестного узла формально верна и не значит ничего.
Как заметитьОбработчик принимает любую целую цепочку за подтверждение.
Как правильноУчитывать, кто именно заверял, а не только сходится ли цепочка.

Включают без проверки обычной подписи

наш опыт

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

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

2 связи

Работают в паре

Два обработчика входящих отчётов и что с ними делатьРезультат проверки достаётся обработчику вместе с письмом — отвергнуть письмо MTA здесь не умеет. § 3.3.7.18

Обычно вместе с

check-spf-inbound<source>Соседняя проверка входящей почты: результат ложится в тот же заголовок. § 3.3.7.18

Как проверить на узле
Значение задаётся в конфигурации источника; результат виден в заголовке принятого письма:
grep -n check-arc-inbound /etc/pmta/config
grep -i 'Authentication-Results' /var/log/pmta/pmta.log | tail -3
У писем без заголовков заверения проверка не выполняется — их большинство: цепочку ставят только пересыльщики. Хаб этой строки не пишет.
◇

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

3 статьи

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

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Приём входящей почты · Безопасность узла
Соседние настройки блока <source>:reject-spf-check-permerrorcheck-spf-inboundreject-spf-check-failreject-spf-check-temperrorprocess-x-dkim-optionsВсе 74 директив блока →