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

check-dkim-inbound

<source>

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

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

Отличие от SPF и обратной проверки принципиальное: отказов здесь нет. У тех есть по три строки reject-*, у этой — ни одной. MTA умеет только проверить и записать; решение, что делать с письмом, остаётся тому, кто читает заголовок дальше по цепочке.

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

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

Включать безопасно. Отказов по результату нет, приём письма не меняется ни при каком исходе.

Полезнее всего на приёме отчётов. Жалобы и отчёты приходят от почтовиков и обычно подписаны; проверка отделяет настоящие от подделанных.

Результат надо кому-то читать. Без обработчика, который смотрит заголовок, включение ничего не даёт.

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

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

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

Ждут, что письма с неверной подписью перестанут приходить

наш опыт

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

Путают отсутствие подписи с её неверностью

наш опыт

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

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

2 связи

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

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

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

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

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

trace-dkim-check<source>Строка не срабатывает, пока проверка подписи не включена. § 3.3.7.20

Как проверить на узле
Значение задаётся в конфигурации источника; результат виден в заголовке принятого письма:
grep -n check-dkim-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 директив блока →