Кратко

  • Успешный DKIM подтверждает подпись выбранного канонизированного материала ключом селектора s= в подписывающем домене d=. Он сам по себе не уполномочивает видимый домен From и не устанавливает личность автора.
  • DMARC по действующему RFC 9989 отдельно проверяет согласование с доменом автора. Даже согласованная проверка не доказывает правдивость, безопасность, актуальность или разрешение на деловое действие.

Корректная подпись, присвоенная чужому имени

Верификатор не ошибся. Он получил открытый ключ из пространства DNS злоумышленника, пересчитал хеши и подтвердил подпись. Ошибка возникла позже: система увидела слово pass, отбросила домен, к которому относился результат, и связала его с наиболее заметным адресом банка.

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

Что именно входит в криптографический объект

В DKIM-Signature параметр d= задаёт Signing Domain Identifier, s= выбирает пространство ключа, а h= перечисляет подписанные поля заголовка. bh= хранит хеш охваченной канонизированной части тела. b= — подпись канонизированных заголовков, включая само поле DKIM, где значение b= при вычислении считается пустым.

Поэтому проверка — это не один неразличимый зелёный сигнал. Получатель применяет указанную канонизацию, вычисляет хеш тела и сравнивает его с bh=, извлекает ключ s= под d=, формирует вход заголовков и проверяет b=. Если хеш тела не совпал, вся подпись недействительна, даже когда отдельная операция над заголовками могла бы завершиться успешно.

Поле From обязательно должно присутствовать в h=. Это защищает точный подписанный текст From от последующего изменения. Но такая защита не доказывает, что домен d= управляет доменом, написанным в From. Подписант может честно зафиксировать ложное утверждение о другой организации.

Канонизация нормализует байты, а не смысл

Для заголовков и тела DKIM предлагает режимы simple и relaxed. Relaxed допускает определённые изменения пробелов и регистра имени поля, обычные при пересылке; simple строже. Ни один режим не решает, равнозначны ли сообщения по смыслу.

Невинное форматирование может сломать одну форму подписи, а вредоносное требование — остаться побайтно неизменным и пройти проверку. В журнале нужны выбранная пара канонизации и точный хешируемый объект; фраза «письмо не изменилось» слишком широка.

Необязательный параметр l= ещё резче очерчивает границу. Он ограничивает покрытие тела числом канонизированных октетов. Дописанный после этого префикса текст остаётся вне хеша. Возможность создавалась, в частности, для посредников с нижними колонтитулами, но RFC 6376 предупреждает о несанкционированных добавлениях. При l=0 тело вообще не подписано.

Интерфейс, который помещает всё видимое тело под один знак «подписано», искажает область действия криптографии. Если l= не достигает конца, неподписанный суффикс надо явно отделять либо не представлять подпись как защиту всего показанного текста.

Согласование отвечает на вопрос о домене автора

RFC 9989 — нынешний стандарт DMARC, сменивший RFC 7489. Он объясняет, почему голого DKIM pass недостаточно для отображаемого автора: любой домен, включая домен злоумышленника, может создать действительную DKIM-подпись.

DMARC берёт Author Domain из RFC5322.From и проверяет его согласование с аутентифицированным d= DKIM либо идентификатором SPF. В строгом режиме домены должны совпадать. В ослабленном режиме достаточно общей Organizational Domain по установленным правилам определения.

В исходном письме DKIM проходит для receipt-alert.example, но согласование с bank.example не проходит. Эти два факта должны одновременно остаться в трассировке. Запись только dkim=pass скрывает именно тот отказ, который важен для заявленного автора.

Даже успешный DMARC ограничен. Он подтверждает разрешённое использование Author Domain, но не оценивает ценность сообщения и не гарантирует безопасную доставку. Взломанная учётная запись или официальная массовая платформа может отправить вредоносное, но согласованное письмо.

Пять идентичностей нельзя сворачивать в одну

Необязательный i= Authenticated User Identifier способен указать более узкую идентичность внутри подписывающего домена. RFC 6376 не требует его совпадения с идентичностью из заголовка и предостерегает от широкой привязки к конечному пользователю.

SMTP-конверт, SPF-идентификатор, DKIM-домен, адрес RFC5322.From и аутентифицированная SMTP-учётная запись — разные записи. В одном письме допустимы несколько DKIM-подписей разных доменов. Каждая проверяется отдельно; DMARC ищет хотя бы один аутентифицированный и согласованный идентификатор.

Поле Authentication-Results передаёт результаты фильтрам и пользовательским приложениям. Но полномочие поля исходит от доверенного создателя, а не от написанного имени. На входной границе внешние копии следует удалять или изолировать и признавать только результаты авторизованных валидаторов принимающего административного домена.

Изменение письма на непрямом пути

Списки рассылки и шлюзы добавляют футеры, переписывают тему, меняют кодировку тела или конверт. Это может разрушить ранее действительную DKIM-подпись и согласование DMARC. Отказ после посредника не доказывает отсутствия аутентификации прежней формы, но и не даёт права принимать любое повреждённое письмо.

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

Срок подписи не защищает от повтора

Параметр t= может указать момент создания, а x= — срок истечения. RFC 6376 прямо говорит, что истечение не является защитой от replay. Перехваченное действительное письмо можно снова разослать или повторно обработать, пока подпись сохраняется.

Поэтому аутентификация почты и идемпотентность деловой операции должны жить в разных реестрах. Подлинная инструкция об оплате может оказаться старой, повторной или выходить за нынешние полномочия отправителя. Решение принимают идентификаторы транзакции, состояние процесса, контроль счёта и подтверждение человеком.

Негативные испытания с точными субъектами

Подпишите атакующее письмо собственным доменом, показав во From чужой домен. В одной трассировке должны появиться dkim=pass и отказ согласования DMARC. Затем подпишите вредоносный текст авторизованным согласованным доменом: аутентификация должна пройти, а политика контента и риска учётной записи — вынести независимый вердикт.

Отдельно измените подписанный и неподписанный заголовки. Добавьте видимую инструкцию за границей l=. Меняйте пробелы при simple и relaxed. Вызовите несовпадение bh=, сохранив путь вычисления подписи заголовка. Повторите неизменённое письмо и предъявите несколько подписей с разными результатами проверки и согласования.

Наконец, внедрите поддельный Authentication-Results, смените селектор в разных состояниях DNS-кеша и проведите письмо через посредника, добавляющего футер. Цель — не получить pass в каждом опыте, а заставить систему назвать объект, домен, охват, производителя результата и политику решения.