Кратко

  • RFC 8601 унифицирует передачу результатов аутентификации, но поле обычно не защищает собственную целостность и не удостоверяет автора. Его ограниченные полномочия создаёт локальная связь между проверяющим процессом, разрешённым authserv-id, путём, очисткой границы и потребителем.
  • Воспроизводимое решение хранит исходные байты, удалённую подделку, добавленное локальное поле, версии процессов, проверенные свойства, при необходимости ARC-цепочку и итоговое действие. Отдельное pass — переносимый текст, а не переносимое доверие.

Одинаковый текст может прийти с разных сторон границы

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

RFC 8601 прямо предупреждает: злоумышленник способен использовать домен принимающего ADMD как authserv-id. Без фильтрации MUA или следующий фильтр поверит формально правильному ложному утверждению.

Поэтому объект управления — канал утверждений от процесса, который измерил конкретное состояние сообщения, до правила, которое превратило оценку в показ, балл, карантин или доставку. Контроль каждого звена входит в доказательство.

Общий словарь не назначает общего судью

Payload содержит идентификатор сервиса, необязательную версию и пары метод=результат со свойствами. В одном поле может быть несколько проверок, в сообщении — несколько полей. Реестр IANA обеспечивает единое толкование токенов.

RFC 8601 не предписывает пропускать письмо после dkim=pass, отклонять после spf=fail или уменьшать проверку контента после dmarc=pass. Это местная политика. Регистрация слова доказывает его значение, но не то, что конкретный процесс выполнил тест и честно описал результат.

Тонкий общий слой нужен для совместимости. Если он начинает выдавать универсальное разрешение, координационный формат превращается в скрытую власть.

ADMD определяется управлением, а не стойкой

Обычная модель связывает производителя и потребителя внутри одной Administrative Management Domain. Потребитель доверяет утверждению лишь через управляемые отношения с процессом и путём. Способ построения доверия остаётся локальным.

Проверяющий сервис у подрядчика может быть внутри границы, если договор, ключи, изменение и аудит контролируются. Соседний relay может быть снаружи. Карта должна перечислять MX, резервные и региональные пути, submission, фильтры, хранилище и MUA. Один прямоугольник «защитный шлюз» не показывает обход.

RFC 5598 разделяет ADMD именно потому, что у них независимая операционная политика и решения о доверии.

Удаление на входе создаёт происхождение

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

Canary должен охватывать текущие и недавно выведенные IDs, регистр и folding, дубликаты, положение относительно Received, вложенные сообщения. Каждый публичный MX и failover обязан показать одинаковое удаление и замену.

Закрытое хранилище может сохранить исходные байты и факт удаления для расследования. Сообщение для внутренних потребителей содержит только допустимые поля. Уничтожить всё — потерять атрибуцию; передать всё как доверенное — потерять защиту.

authserv-id требует реестра ролей и эпох

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

Переименование создаёт ограниченное перекрытие из-за задержанных сообщений. У старого ID должны быть владелец, конечная дата и отрицательные тесты. Бессрочное перекрытие отменяет отзыв. Шлюз, который вправе сообщать SPF и DKIM, не получает автоматически право говорить за SMTP AUTH, отдельную DMARC-policy или поздний ARC.

Позиция — след, но не подпись

RFC 8601 рассматривает поле как trace field и добавляет его сверху после проверки. RFC 5322 сильнее сохраняет порядок trace-блоков. Положение помогает восстановить последовательность.

Однако отправитель тоже может написать строку сверху, а шлюз — добавить верный результат над не удалённой подделкой. Правило «первая» или «последняя» заменяет происхождение догадкой. Сначала определяются доверенный trace-блок и производитель, затем разбираются метод и свойства.

У каждого pass свой предмет

SPF проверяет разрешение SMTP-клиента для ограниченной SMTP-идентичности, не тело и все видимые адреса. DKIM проверяет подпись и покрытые части, но не человека и безопасность содержимого. DMARC по RFC 9989 оценивает alignment с Author Domain, а не разрешает платёж, восстановление аккаунта или запуск вложения.

Сведение всего к authenticated=true создаёт полномочия из ничего. Действие связывают с методом, результатом, свойством, производителем, временем, состоянием сообщения и версией правила. Свободный reason полезен диагностике, но не является удалённой командой.

ARC подписывает свидетельство, а не его истинность

После выхода из ADMD и возврата сохранённый текст не наследует доверие. Новая проверка видит текущий объект, но не всегда состояние до изменений списка рассылки или пересылки.

ARC переносит оценки в упорядоченных подписанных наборах. RFC 8617 сравнивает оценку со свидетельством проверяемой стороны, а не с независимо повторяемым твёрдым доказательством. Валидность chain не зависит от точности и даже синтаксиса вложенной оценки.

Валидная цепочка связывает утверждения и порядок с sealers. Получатель отдельно решает, доверять ли им. ARC удостоверяет хранителей, а не качество их суждения и безопасность сообщения.

Реальный путь завершает проверку

Postfix Milter передаёт фильтрам SMTP-события, заголовки и тело; SpamAssassin AuthRes потребляет результаты. Наличие компонентов не доказывает безопасную связку во всех входах.

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

Конфигурация показывает намерение. Доставленные байты и поведение показывают принятую реальность. Общая семантика остаётся тонкой, доверие — локальным, а граница доказывается running canaries.

Источники