Кратко

  • draft-gondwana-dkim2-debug-header-01 унифицирует формат следа X-DKIM2-Info для ранних испытаний DKIM2, но не вводит новый результат проверки.
  • Поле намеренно исключено из хешей и подписей. Оно может подсказать человеку, где искать доказательства, но не удостоверяет отправителя, действие, снимок или полноту рассказа.

Проблемное письмо выглядит так, будто принесло собственный отчёт о расследовании. Одна строка называет версию проекта DKIM2, репозиторий и программу входного фильтра. Другая утверждает, что ПО списка рассылки создало Message-Instance m=2, перечисляет заголовки в хеше и указывает на прежнюю сохранённую копию. Выходной фильтр сообщает, что отказался подписывать из-за разрыва цепочки.

Инженеру, который сопоставляет две реализации, такая детализация экономит время. Системе, решающей вопрос доставки, карантина или ответственности, она ничего не доказывает. Любую строку можно вставить, изменить, переставить или удалить, а действительно защищённые DKIM2 части сообщения продолжат успешно проверяться.

Такую границу проводит A Diagnostic Header Field for DKIM2 Implementations. Редакция 01 зарегистрирована 30 сентября 2026 года по тихоокеанскому времени, когда в Шанхае и UTC уже наступило 1 октября. Это индивидуальный Internet-Draft с предполагаемым статусом Informational и состоянием I-D Exists. Он не принят рабочей группой DKIM, не является RFC или регистрацией IANA и не служит нормативной зависимостью DKIM2. Сам текст называет его инструментом раннего тестирования и считает публикацию маловероятной.

Общий словарь для сравнения расхождений

DKIM2 пытается сохранить проверяемую цепочку после преобразований сообщения, например в списке рассылки. Поля Message-Instance содержат хеши и Recipes для восстановления прежних состояний; DKIM2-Signature связывает защищённые записи. Когда два прототипа дают разные ответы, итогового «успеха» или «ошибки» недостаточно, чтобы найти первый расходящийся шаг.

X-DKIM2-Info отводит подсказкам повторяемое место. Каждое поле содержит пять обязательных тегов в порядке draft, repo, date, sw, action. Первый обозначает реализованную редакцию DKIM2. Репозиторий и программа различают компонент или ответвление. Дата должна меняться вместе с поведением DKIM2 у этого эмитента. Одно поле описывает одно действие; для нескольких действий нужны несколько полей.

Словарь охватывает проверку, добавление Message-Instance, подпись и отказ от подписи. За verify=pass или verify=fail может следовать свободное объяснение. mi-m=<N> способен указать количество и порядок хешированных заголовков, а также идентификаторы прочитанного и сохранённого снимков. sign сообщает домен и алгоритм. not-signed содержит выбранную реализацией причину, например broken-mi-chain.

Редакция 01 устранила поверхностные расхождения редакции 00: применила точную грамматику расширений DKIM2, потребовала точку с запятой после каждого тега и заменила mi-m<N> на mi-m=<N>. Синтаксическая совместимость стала лучше, но самоописание не превратилось в свидетельство.

Поле подвижно именно потому, что доказательство его не видит

Базовый проект DKIM2 исключает имена заголовков с префиксом X- из хеша заголовков Message-Instance. Диагностический проект также запрещает эмитенту включать X-DKIM2-Info в подписываемые или хешируемые данные. Поэтому пояснение можно поставить рядом с описываемым заголовком, не изменив защищённую Message-Instance и не нарушив DKIM2-подпись.

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

Поэтому материал не повторяет прежнюю статью BTW о DKIM2 в Authentication-Results. Там рассматривалось локальное доверие к authserv-id в пределах административного домена и SMTP-транзакции. X-DKIM2-Info находится ниже даже этого локального вердикта. Оно создано для следующего вопроса расследователя, а не для автоматического ответа.

Соседство строк не удостоверяет причинность

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

Но положение строки не аутентифицировано. Более поздний обработчик может добавить убедительное action=sign, переместить строку к другой Message-Instance или удалить объяснение сбоя. Путь репозитория и имя программы — самодекларация, а не аттестация бинарного файла. Дата поведения — не хеш коммита. Нет идентификатора события, ключа экземпляра, номера последовательности, подтверждения получателя или заявления о полноте.

Молчание тоже неоднозначно. Если верхняя Message-Instance по-прежнему совпадает и эмитент ничего не добавляет, действие вообще не записывается. Отсутствие mi-m=<N> не доказывает, что проверка запускалась, изменений не было или посредник сохранил весь след.

Указатель на снимок не переносит сам снимок

snapf обозначает прежнюю сохранённую копию, использованную для расчёта Recipe; snaps — текущую копию для будущего сравнения. Это наиболее практичные теги, но их смысл, согласно проекту, локален для записавшего их эмитента. Один пример похож на ключ базы данных или путь хранения.

Идентификатор сокращает разговор со службой эксплуатации: по нему можно запросить байты, журналы и сведения о сроке хранения. За пределами системы он не доказывает содержимое, цепочку хранения, доступность или срок сохранности. Без отдельного дайджеста содержимого и квитанции извлечения скопированная строка не становится переносимым доказательством.

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

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

RFC 6648 описывает общий риск имён X-: частные расширения выходят наружу, превращаются в фактические интерфейсы и усложняют миграцию. Здесь префикс — сознательный компромисс, оставляющий диагностику вне смысла и криптографической защиты DKIM2. Чёткая протокольная граница ещё не означает гарантированной операционной изоляции.

От подсказки — к проверяемой квитанции

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

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

X-DKIM2-Info полезно потому, что оставляет читаемые отпечатки рядом с неисправностью. Опасность начинается, когда удобство поддержки повышают до происхождения, политики или вердикта. Правильная автоматизация не действует по подсказке, а использует её для поиска проверяемых доказательств.

Источники