Кратко

  • В RFC 6376 l= задаёт число октетов канонизированного тела, включённых в хеш. Всё после границы не проверяется этой DKIM-подписью, даже если её результат успешен.
  • Для заголовков действует отдельный периметр: h= хранит упорядоченный список полей. При дубликатах важно, какой именно экземпляр From, Subject или MIME-поля выбрал алгоритм.
  • Воспроизводимый чек сохраняет исходное письмо, выбранную подпись, канонизацию, карту заголовков, длины и хеши префикса и хвоста, наблюдавшийся DNS-ключ, верификатор и доверенную границу Authentication-Results.

Зелёный результат закончился раньше текста

Пусть после канонизации тело содержит 19 750 октетов, а в подписи записано l=15 000. Верификатор хеширует первые 15 тысяч и получает совпадение. Оставшиеся 4 750 октетов не опровергли подпись — они в неё не входили.

Это может быть обычный footer списка рассылки, служебная отметка архива, неожиданное продолжение MIME или намеренная вставка. Один pass не определяет происхождение хвоста. Он также не передаёт ему целостность префикса.

RFC 6376 формулирует правило прямо. Без l= охватывается всё канонизированное тело. С параметром берётся заданное число октетов от его начала. Данные за пределом не валидируются DKIM. При l=0 тело полностью остаётся без подписи.

Локальная политика может считать частичный охват неприемлемым. Поэтому в журнале нужны два результата: криптографическая проверка объявленного scope и последующее решение. Их слияние превращает математический успех в одобрение содержания или маскирует смену policy под ошибку подписи.

Роль Murray Kucherawy здесь задают документы. RFC 6376 совместно называет Dave Crocker, Tony Hansen и Murray S. Kucherawy; это не свидетельство единоличного изобретения. RFC 8601 указывает Kucherawy автором. В официальном профиле IETF при фиксации 2 сентября 2026 года таблица показывала 34 RFC, а автобиографический текст — 33. Даже официальный источник следует цитировать с полем и временем.

Сначала канонизация, затем арифметика

l= — не позиция в сыром файле .eml. DKIM сначала применяет канонизацию тела из c=. Режимы simple и relaxed по-разному обрабатывают пробелы, окончания строк и пустые строки в конце. Вычитание l= из размера файла часто даёт неверную длину хвоста.

Воспроизведение идёт по шагам: сохранить raw message; выбрать конкретный экземпляр DKIM-Signature; извлечь a=, c=, d=, s=, h=, l= и bh=; канонизировать тело; измерить результат; при наличии l= взять точный префикс; сравнить body hash; затем проверить подпись заголовков наблюдавшимся ключом.

Чек хранит длину и хеш полного канонизированного тела, подписанного префикса и неподписанного суффикса. Положительная длина суффикса доказывает только разрыв scope. Если l= отсутствует, фиксируется полный охват, а не выдуманное значение.

У ключа есть время наблюдения. d= задаёт signing domain, s= — DNS selector. После ротации или отзыва lookup вернёт другое. Для старого решения нужны фактически использованный ответ, время, resolver и ошибки; DNSSEC отмечается лишь при реальном измерении.

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

Практическая причина l= — списки рассылки. Они добавляют инструкции отписки или служебный footer. Подпись всего тела сломалась бы, тогда как подпись префикса позволяет распознать исходную часть и отдельно решить судьбу добавления.

Но криптографическая граница не узнаёт намерение посредника. Раздел безопасности RFC 6376 предупреждает, что злоумышленник может добавить выгодный ему контент. Изменение структуры MIME, терпимое HTML-parsing или обход поиска дубликатов способны сделать хвост главной частью пользовательского представления.

Нельзя объявлять каждый footer атакой. Нельзя и считать его подлинным из-за подписи префикса. Анализ называет посредника, сверяет преобразование с его заявленной функцией, строит MIME-дерево и фиксирует выбранную клиентом часть.

Принцип running code у Heng Lu оставляет стандарту и реализации разные роли. RFC задаёт операции над байтами. Захваченное письмо, версия verifier и след renderer показывают, какие байты вычисляла машина и что увидел человек.

h= требует карты экземпляров

Полный body не означает полный набор headers. h= — последовательность имён. Если поле повторяется, DKIM сопоставляет экземпляры снизу вверх. Множество имён не скажет, какой именно Subject или From оказался внутри.

From должен подписываться. RFC 6376 настоятельно рекомендует Date, Subject, Reply-To, Sender и MIME-поля, влияющие на отображение или обработку. При l= особенно важен Content-Type: неподписанная замена способна заставить клиента иначе показать тот же префикс.

Coverage map перечисляет заголовки в исходном порядке, помечает выбранные экземпляры и показывает значимые поля вне scope. Oversigning отсутствующих имён тоже фиксируется, поскольку может защитить от последующей вставки. Каждая подпись — исходного домена, списка или gateway — получает собственную карту.

Подпись домена не подтверждает весь смысл письма

Pass означает, что выбранная подпись проверилась ключом, опубликованным под доменом и selector, для выбранного материала. Он не доказывает человеческого автора, разрешённого использования ключа, истинности текста, безопасности вложения или доставки.

RFC 5585 ограничивает вывод неизменностью подписанного сообщения или его части. RFC 5863 требует считать аутентичным только содержимое внутри scope и прямо приводит l=. RFC 8301 обновляет алгоритмы и размеры ключей. Сильный ключ необходим, но не удлиняет короткий префикс.

DMARC решает задачу alignment с видимым доменом From и передаёт policy signal. Он не расширяет h= или l=. Валидность, alignment, репутация, безопасность, disposition и отображение остаются разными столбцами.

Authentication-Results ценен только с доверенным источником

Последующие фильтры часто не повторяют DKIM, а читают Authentication-Results. RFC 8601 определяет такую передачу внутри административной trust boundary. Само поле обычно не обладает самостоятельной защитой целостности.

Consumer принимает настроенные authserv-id. На входе внешние поля, выдающие себя за внутренние результаты, удаляются или обезвреживаются до добавления локального. Любой отправитель способен написать dkim=pass; измерением строка становится благодаря архитектуре получателя.

Нужно хранить raw field, позицию, producer, правило доверия и точную подпись. Сведение нескольких подписей к безымянному pass уничтожает связь с d=, s=, h= и l=. Результат метода и локальная обработка также записываются отдельно.

Минимальный ledger области действия

Основа — хешированное исходное письмо и все DKIM-Signature в исходном порядке с d=, s=, необязательным i=, a=, c=, h=, l=, bh=, значением подписи и временными полями.

Далее идут наблюдавшийся DNS-ключ и время, воспроизводимая канонизация, выбранные экземпляры заголовков, длины и хеши трёх областей, программа verifier, результат и причина. Отдельно документируются producer Authentication-Results и административная граница.

Последний блок описывает MIME-дерево, выбранные части, версию renderer и использование байтов после l= в основном представлении. Идентификаторы частей и render hash могут сохранить связь без бессрочного хранения частного экрана пользователя.

Принцип agency разделяет полномочия: авторы стандарта задают синтаксис; хранитель ключа выбирает scope; посредник меняет сообщение; verifier считает; административный домен отвечает за канал результата; клиент отображает. Никто не может гарантировать действия остальных.

Точный вывод звучит так: эта подпись этим наблюдавшимся ключом покрыла такие упорядоченные экземпляры заголовков и первые N октетов канонизированного тела; этот хвост остался снаружи; доверенный verifier записал результат; клиент показал такие части. Авторство, безопасность и намерение требуют отдельных доказательств.

Источники