Кратко

  • Авторская статья, опубликованная 17 сентября в блоге LACNIC, говорит о семи минимально необходимых полях XARF v4. Действующая спецификация XARF перечисляет восемь обязательных полей верхнего уровня.
  • В сокращённом перечне отсутствует sender. XARF отделяет его от reporter, чтобы CERT, технический сервис или иной посредник мог передать жалобу, не становясь её автором.
  • Расхождение не доказывает потерю сообщения и не означает, что LACNIC требует XARF. Оно показывает, почему результат проверки надо связывать с точной версией схемы, набором правил, картой ролей, доставкой и состоянием разбора.

Восьмое поле отвечает не за синтаксис, а за происхождение

Представим входной фильтр с семью ячейками. Версия схемы, ID, время, заявитель, источник, категория и тип заполнены. Фильтр принимает JSON. Но сообщение отправил национальный CERT от имени участника, а отдельного места для этой организации в модели нет.

Такой пример не доказывает реальный сбой. Он лишь показывает, как короткое описание способно незаметно определить архитектуру приёма.

Поводом стала статья Гильермо Перейры «How to Keep an Abuse Report from Getting Lost in Your Mailbox», появившаяся в блоге LACNIC 17 сентября. Автор описывает XARF v4 как поддерживаемый сообществом формат JSON для 32 типов инцидентов в семи категориях.

Далее названы семь минимальных полей: версия схемы, уникальный идентификатор, время инцидента, reporter, источник злоупотребления, категория и тип. Однако текущая техническая спецификация XARF v4 содержит восемь обязательных полей верхнего уровня: xarf_version, report_id, timestamp, reporter, sender, поле идентификатора источника, category и type.

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

Сам материал в блоге дальше правильно объясняет sender и включает его в пример. На странице есть оговорка, что мнение автора не обязательно совпадает с позицией LACNIC. Следовательно, источники не позволяют утверждать, что LACNIC развернул семиполевой валидатор, XARF сломался или конкретная жалоба была потеряна.

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

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

Схемная корректность всё равно остаётся только первой ступенью. XARF называет source_port, evidence, evidence_source и confidence рекомендуемыми общими полями. Категории добавляют собственные обязательные элементы. Стандартный режим требует обязательный набор, строгий — ещё и рекомендуемый.

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

Автор блога сохраняет это различие. Доказательства формально рекомендованы, но на практике часто делают отчёт пригодным для действия. Обычный текст тоже допустим, если в нём есть затронутый ресурс, время UTC, вид злоупотребления, доказательство и отвечающий контакт. Хорошее письмо полезнее плохого JSON.

Региональный контекст задаёт раздел 12 Руководства по политике LACNIC. Контакт по злоупотреблениям должен активно обслуживаться; ручные и автоматические сообщения допускаются; обязательная форма не требуется. Эта норма обеспечивает канал, но не предписывает XARF и не подтверждает факты жалобы.

Транспорт также не решает содержание. В статье упомянут ARF и RFC 5965. RFC определяет расширяемый формат сообщений, но прямо выносит за рамки адрес назначения, проверку содержания и установление доверия. RFC 6650 позже описывает применимость. Стандартизованная оболочка не является приговором.

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

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

Если документацию исправят, оператор увидит, какие сообщения прошли по прежнему правилу, и повторно проверит ограниченный набор. Без квитанции метка «валидный XARF» меняет значение вместе с веб-страницей или локальной версией программы.

Источники