Кратко

  • Ревизия 00 предлагает один машинно-читаемый результат для всей цепочки DKIM2, домен исходной подписи и, когда возможно, номер подписи, к которой отнесён сбой.
  • DKIM2 не защищает сам Authentication-Results: он осмыслен только внутри создавшего его ADMD и не должен копироваться следующей организации как доказательство.
  • При результате не pass значение header.d может помогать диагностике, не будучи аутентифицированной личностью; комментарий по узлам — недоверенный текст для человека, а не интерфейс политики.

В журнале остаётся аккуратная строка: цепочка DKIM2 прошла проверку. Через месяц исходные подписи уже не хранятся, контекст SMTP потерян, а строка попала в общую базу нескольких компаний. Теперь она коротка, удобна и почти бесполезна: нельзя установить, кто проверял цепочку, с каким конвертом и имела ли эта организация право доверять записи.

Первый проект формата отчёта, объявленный 5 сентября 2026 года, проводит границу заранее. DKIM2 создаёт криптографически проверяемую цепочку обработки сообщения. Authentication-Results появляется после проверки и сообщает её итог локальным компонентам. Отчёт о доказательстве сам доказательством не становится.

Запись Datatracker API показывает индивидуальный Internet-Draft без официального одобрения IETF. XML-источник фиксирует текст ревизии 00, а объявление I-D — дату, автора и аннотацию. Намерение Standards Track не равно принятому стандарту.

Базовый проект DKIM2 WG, ревизия 06, определяет четыре состояния попытки проверки: PASS, FAIL, PERMERROR, TEMPERROR. Новый текст отображает их в формат RFC 8601 и добавляет none, когда подписи DKIM2 не было и проверка не предпринималась. Метаданные документа WG относятся к основному механизму; их процессуальный статус нельзя переносить на индивидуальное дополнение.

Результат один для всего сообщения. DKIM1 допускает отдельный итог для каждой независимой подписи. Здесь проверяется целостность Chain of Custody. Верификатор идёт от самой новой подписи с наибольшим i= назад и может остановиться на ошибке. Более ранние подписи тогда перечисляются в комментарии как skipped. Это означает «не проверено», а не «неверно».

Поэтому header.d имеет условную доказательную силу. Он берётся из домена исходной подписи i=1 и может печататься рядом с любым результатом для диагностики. Но аутентифицированной идентичностью он является только при общем pass. Если система репутации извлекает домен, но теряет состояние fail или temperror, наблюдаемая строка незаметно превращается в подтверждённую личность.

У header.i другая опасность. В DKIM2 это порядковый номер подписи, которой приписан сбой. В DKIM1 то же имя свойства означает Agent or User Identifier. Схема, где метод аутентификации не хранится вместе со свойством, смешивает числовую позицию и идентичность.

Модель доверия задаёт RFC 8601. Поле Authentication-Results передаёт вывод валидатора механизму оценки внутри одного Administrative Management Domain. Собственной целостности у поля обычно нет. Поэтому пограничный MTA обязан удалить недоверенные входящие экземпляры, которые выдают себя за результат его authserv-id, прежде чем добавить локальный.

authserv-id называет заявленного проверяющего, но не удостоверяет эту заявку. Доверенные имена и внутренние пути определяются локальной конфигурацией. DKIM2 намеренно не подписывает Authentication-Results: поле создаётся после проверки и обычно снимается на границах. Любой обработчик может изменить или удалить его, не нарушив DKIM2-подпись.

Даже подлинный результат не переносится в следующую SMTP-транзакцию. Последняя DKIM2-подпись связывается с MAIL FROM и RCPT TO, которые видел конкретный получатель. Его pass описывает цепочку лишь до этой точки. Пересылка создаёт новый контекст. Пересылающая сторона не должна копировать старый результат для следующей системы; она добавляет свою DKIM2-подпись, после чего новый получатель проверяет всю цепочку и создаёт собственный локальный отчёт.

Так отделяется переносимое доказательство от непереносимого суждения. Подписи можно пересчитать. Скопированный индикатор не раскрывает использованные ключи, DNS-наблюдение, SMTP-конверт, версию программы или последующую модификацию.

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

При этом selector, домены, MAIL FROM и RCPT TO могут зависеть от отправителя или посредника. В синтаксисе комментариев RFC 5322 скобки и обратная косая черта имеют управляющее значение. Их нужно экранировать, длину ограничивать, а вывод отображать как недоверенный текст. Иначе злоумышленник может преждевременно закрыть комментарий и заставить последующий текст выглядеть как ещё один результат внутри доверенного поля.

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

Проект следует подходу ARC: несколько стабильных машинных свойств и подробности экземпляров для человека. DKIM задаёт прежнюю семантику свойств, а Internet Mail Architecture показывает ADMD как операционную границу, а не мирового удостоверяющего субъекта.

Во время проверки реестр IANA не содержал dkim2. Ревизия 00 просит зарегистрировать метод, два свойства и пять результатов. Запрос в проекте — не свершившаяся регистрация.

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

Стандартизировать можно язык отчёта. Нельзя стандартизацией присвоить ему чужое доверие.