Кратко

  • RFC 9990 задаёт агрегированный отчёт получателя о результатах аутентификации, выравнивании DMARC, оценённом disposition, локальных исключениях, источниках и количестве за период.
  • Это не журнал отдельных сообщений. В одном окне могут смешиваться политики, частичные пересечения не всегда разделимы, а сам RFC предупреждает о возможности подделки данных.
  • Daniel Kade предлагает минимальную квитанцию использования агрегата: связать генератора, окно, эпоху политики, дайджест файла, решение по дублям и действие, не сохраняя тела и личные адреса.

Панель знает только тех наблюдателей, которые прислали данные

Агрегированные отчёты дают владельцу домена внешний взгляд. Они показывают неожиданные IP-адреса, результат SPF, подписи DKIM, выравнивание с From и причины, по которым получатель отступил от запрошенной политики. Благодаря им можно найти забытый сервис или ошибку ротации ключа.

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

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

Стандартная форма ограниченного утверждения

RFC 9990 опубликован в мае 2026 года как документ IETF Standards Track. Вместе с новыми спецификациями DMARC он заменяет отчётную часть RFC 7489. Domain Owner указывает адреса, Mail Receiver оценивает сообщения, создаёт XML и пытается доставить его допустимым получателям.

Метаданные называют организацию, Report-ID и окно UTC. policy_published показывает замеченную конфигурацию политики. Строка объединяет исходный IP, число сообщений, оценённое disposition, выравнивание и идентификаторы. Результаты DKIM и SPF разделены. Отклонение от запрошенного действия можно объяснить локальной политикой, списком рассылки, тестовым режимом, доверенным пересыльщиком или иной причиной.

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

Сжатие удаляет событийные связи

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

Резкий рост ошибок может означать неавторизованного отправителя. Но он также появляется из-за нового источника отчётов, поздней доставки, другого правила группировки или пересекающегося окна. Число достаточно для начала расследования, но не для автоматического причинного вердикта.

Объект доказательства — сводка, составленная конкретным получателем. Реальный поток почты шире. Замена первого вторым незаметно расширяет полномочия генератора.

Одно поле политики может закрывать смешанную эпоху

Если запись DMARC меняется в середине периода, получатели замечают это в разное время. RFC 9990 разрешает отдельные отчёты по конфигурациям или единый файл, где смешаны решения по старой и новой политике, хотя элемент policy_published только один.

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

Когда домен в полдень переходит от наблюдения к более строгому действию, суточный файл может показывать финальную конфигурацию и содержать утренние оценки. Без дополнительной привязки честная метка — «смешанная» или «неизвестная» эпоха.

Аутентификация письма с отчётом не удостоверяет каждую строку

Почтовый поток с DMARC-отчётом обязан получить выровненный pass. Рекомендуется защищённый транспорт. Внешний адрес должен подтвердить в DNS готовность принимать отчёты для другого домена; без подтверждения URI игнорируется.

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

RFC 9990 прямо предупреждает: сведения в агрегатах могут быть подделаны и массово отправлены, чтобы влиять на политику или архитектуру. Это не повод отвергать известного получателя, а причина фиксировать основание доверия и предел допустимого действия.

Уникальный Report-ID не делает множества непересекающимися

Report-ID должен быть уникальным среди отчётов одному домену. При повторной отправке сохраняется исходное имя файла, что помогает обнаружить повтор. Это хорошая опора для идемпотентности.

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

Сложение каждого уникального ID — не чисто техническая операция. Это предположение об отсутствии пересечения. Если итог запускает важное действие, правило и ответственный должны остаться в журнале решения.

Разрешение внешнему сервису не заверяет его выводы

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

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

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

Проверяемая цепочка не требует собирать личную переписку

Агрегаты исключают содержимое писем и индивидуальные адреса. Метаданные трафика всё равно могут быть чувствительными, особенно у посредника или при отчётности Public Suffix. Усиление аудита не должно отменять минимизацию.

Для цепочки достаточно дайджеста файла, генератора, домена, окна, эпохи, хеша нормализованных строк и решения. Тела, получатели и размещение в ящике не нужны.

GZIP и XML нужно считать недоверенным вводом. Распаковка и разбор могут истощить ресурсы. Синтаксически успешный файл ещё может оставаться в карантине из-за неясной идентичности, пересечения или политики.

Квитанция использования агрегата

Daniel Kade предлагает создавать небольшую запись в момент, когда агрегат становится основанием решения. RFC 9990 этого не требует.

Сначала связываются Report-ID, исходное имя, дайджест, размер, время приёма, результат транспортной аутентификации и основание идентичности генератора. Затем сохраняются домен политики, границы UTC, версия схемы и состояние окна: полное, позднее или частичное.

Для эпохи указываются policy_published и метка «одна», «смешанная» либо «неизвестная». Связанные отчёты и интервалы получают решение: заменить, объединить, отклонить, принять или изолировать, с правилом и ответственным.

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

Так организация не восстанавливает поток писем, но сохраняет причину, по которой сводка получила власть над действием.

Границы доказательств

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

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

Источники