Кратко

  • RFC 9990 устанавливает XML-отчёт, в котором Mail Receiver передаёт Domain Owner агрегированные наблюдения: замеченную политику, строки IP-источников, количества и результаты аутентификации за период отчёта.
  • DNS-подтверждение внешнего получателя rua означает готовность Report Consumer принять данную отчётную связь; оно не доказывает полноту или истинность данных и не передаёт полномочие применять санкции.

Есть соблазн прочитать поле disposition как окончательное суждение. В строке находятся источник, число сообщений, результат аутентификации и применённая принимающей системой политика. Но RFC 9990 формулирует предмет заметно уже. policy_published — это конфигурация, наблюдавшаяся принимающей системой. Каждый record говорит, что указанные IP были замечены при доставке сообщений от имени Author Domain в эту принимающую систему.

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

SPF и DKIM присутствуют в auth_results, но RFC характеризует их как неинтерпретированные по отношению к DMARC. Причина переопределения политики тоже объясняет локальный выбор получателя, а не устанавливает виновность домена или поставщика. Если внутренний дашборд называет такую строку «подтверждённым мошенничеством», он создаёт новую интерпретацию. У этой интерпретации должны быть владелец, правила сопоставления, дополнительные факты и возможность оспорить результат.

Период отчёта не является полной хронологией почты

Структура включает метаданные генератора, policy_published и хотя бы один record. Метаданные задают Report-ID и границы времени UTC. Начало и конец обозначают период отчёта, а не первую и последнюю сообщения, реально замеченные получателем. Обычно это сутки UTC, а периоды не должны пересекаться.

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

Оригинальное вложение, его хеш, извлечённые поля и вычисленная панелью оценка должны быть разными объектами. Фраза «критический риск» не пришла из RFC. Это решение организации, которое должно быть воспроизводимым и обратимым.

Разрешение получить отчёт не есть разрешение распорядиться им

Domain Owner указывает желаемую точку доставки через rua. Если она находится за пределами его Organizational Domain, Mail Receiver обязан выполнить проверку внешнего назначения: запросить предусмотренную DNS-запись и при отсутствии положительного подтверждения проигнорировать URI. Это защищает от отражения, при котором злоумышленник укажет адрес жертвы и заставит множество получателей отправлять туда нежелательные отчёты.

Положительное подтверждение отвечает на узкий вопрос: согласен ли Report Consumer принимать отчёты для этой связи? Оно не определяет круг аналитиков, срок хранения, последующую передачу, объединение с другими данными или действие против источника. RFC 9990 отмечает, что политика конфиденциальности или условия использования Mail Receiver могут ограничивать передачу третьей стороне. В отчёте нет содержимого сообщений, индивидуальных почтовых адресов и индивидуальных IP, но получатель всё же может провести анализ доменного трафика.

Нужен отдельный операционный реестр: для каждого внешнего consumer — допустимые домены, цель, ответственный, доступ, допустимые преобразования, субподрядчики, удержание, удаление, дальнейшая передача и контакт на случай инцидента. DNS подтверждает путь. Он не заменяет этот режим обращения с данными.

Аутентифицированная доставка, синтаксис XML и истинность — не один контроль

Агрегат передаётся как XML-вложение в почте, обычно в GZIP. RFC требует, чтобы поток писем с feedback сам соответствовал DMARC и получал aligned pass, что уменьшает риск обработки мошеннических отчётов. Идентификаторы и имена файлов помогают с повторной доставкой.

Однако данные могут быть подделаны. RFC прямо предупреждает о массовой подаче ложных агрегатов для влияния на решения по политике или архитектуре платформы. Неверный отчёт может истощить распаковщик или XML-парсер через zip bomb либо XML bomb. Файл может прийти на подтверждённый адрес и оставаться опасным или ложным.

Поэтому сначала ограничивают вход: размер до и после распаковки, глубину и сложность XML, время обработки, ожидаемую схему и доступ к сырому артефакту. Если формат вызывает сомнение, оценщик вправе отбросить отчёт или отложить его для согласования с генератором. Успешный парсинг не означает достоверность. Достоверность наблюдения не означает оправданность необратимой меры.

RFC 9989 подчёркивает временную сторону: в зависимости от частоты почты Domain Owner может месяцами потреблять агрегированные отчёты, прежде чем убедится в корректной аутентификации всей почты; выбор p зависит от его потребностей. Отчёт копит материал для локального решения, а не решает вместо оператора.

Редакционная интерпретация: ограниченный общий слой

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