Кратко

  • RFC 9991 определяет подробные отчёты DMARC об одном письме с ошибкой или группе сходных сбоев. Они способны поступать быстрее агрегированных и нести существенно более чувствительный исходный материал.
  • Параметры ruf и fo выражают просьбу владельца домена, а не приказ о выдаче. Получатель почты по собственной политике, характеру сбоя, требованиям приватности и безопасности решает, какие отчёты вообще отправлять.
  • Daniel Kade предлагает целевую квитанцию раскрытия: она фиксирует отбор, редактирование, группировку, ограничение частоты, передачу, доступ и удаление, но не хранит текст, адреса, учётные данные или вредоносную нагрузку.

Когда улика пересекает не ту границу

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

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

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

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

RFC 9991 опубликован в мае 2026 года как документ Standards Track. Вместе с новой основной спецификацией DMARC и документом об агрегированных отчётах он заменяет соответствующие части RFC 7489 и обновляет прежние правила отчётности о сбоях аутентификации.

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

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

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

Подробность меняет класс доказательства

Abuse Reporting Format разносит по различным MIME-частям понятное человеку описание, машиночитаемые поля обратной связи и материал исходного сообщения. RFC 9991 добавляет семантику DMARC: Identity-Alignment, относящиеся к DKIM сведения, данные DNS для SPF и тип сбоя аутентификации.

Значение Identity-Alignment намеренно узкое. Поле перечисляет механизмы, не сумевшие аутентифицировать выровненный идентификатор, либо содержит none, если применённые механизмы сработали. Оно не объясняет причину повреждения подписи, не доказывает авторство видимого отправителя, вредоносность письма, правильность дальнейшей обработки или допустимость раскрытия.

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

Внешняя авторизация подтверждает готовность, но не право

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

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

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

Полезная минимизация сохраняет ответ, а не весь материал

RFC 9991 рекомендует ограничивать цель и продолжительность, строго контролировать URI отчётов, редактировать текст и заголовки и применять защищённую передачу. Он также отмечает, что многие крупные провайдеры ограничивают или отключают отчёты о сбоях из-за реальной цены приватности.

Редактирование не равно простому удалению. RFC 6590 описывает устойчивое к коллизиям стабильное преобразование: потребитель может понять, что две скрытые строки раньше совпадали, не видя исходного значения. Это сохраняет диагностическую корреляцию и одновременно — связываемость. Если один секрет и метод действуют долго и для разных целей, псевдоним превращается в постоянный индекс отношений.

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

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

Ограничение частоты делает отсутствие многозначным

Отчёты о сбоях могут стать каналом отказа в обслуживании. Злоумышленник массово отправляет почту от имени домена жертвы и побуждает участвующих получателей направить поток отчётов самой жертве или её подрядчику. Поэтому RFC 9991 требует исходящих лимитов и допускает объединение сходных случаев либо отбрасывание избытка. Цель — показать разные условия сбоя, а не посчитать каждое не прошедшее письмо.

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

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

Сам отчёт остаётся недоверенным содержимым

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

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

Ценная автоматизация часто действует отрицательно: удаляет активный контент, отклоняет неизвестные MIME-структуры, помещает вложения в карантин, ограничивает ресурсы распаковки и разбора, закрывает материал от общего поиска. Успешный парсер не завершает решение, а начинает контролируемое хранение.

Квитанция целевого раскрытия сведений о сбое

Я предлагаю компактную квитанцию для каждой политики раскрытия и каждой исключительной выдачи. Это редакционное предложение по управлению, а не дополнительное требование IETF.

Квитанция начинается с домена политики DMARC, времени и результата DNS-запроса, запрошенных адресов ruf, условия fo, результата внешней авторизации, версии политики получателя, цели и даты её истечения. Затем она называет класс сбоя и одиночный либо групповой характер случая.

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

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

Если позднее возникнет вопрос, почему эти байты пересекли границу, ответом будет не «так попросил DNS», а проверяемая цепочка ограниченных местных решений.

Источники

  1. Lu Heng — Техническая и практическая реальность суверенитета данных
  2. Lu Heng — Зачем существует BTW Media
  3. Lu Heng — The Policy Mirror
  4. IANA — Параметры Messaging Abuse Reporting Format
  5. Информационная страница RFC 9991
  6. RFC 5322 — Формат интернет-сообщений
  7. RFC 5965 — Расширяемый формат отчётов о злоупотреблениях
  8. RFC 6590 — Редактирование чувствительных данных в отчётах
  9. RFC 6591 — Отчётность о сбоях аутентификации через ARF
  10. RFC 6650 — Создание и применение почтовых отчётов обратной связи
  11. RFC 7489 — DMARC
  12. RFC 9989 — DMARC
  13. RFC 9990 — Агрегированные отчёты DMARC
  14. RFC 9991 — Отчёты о сбоях DMARC