Кратко

  • Политика ripe-705 требует атрибут abuse-c на всех объектах aut-num и напрямую выделенных inetnum/inet6num — проверка охватывает доступность, но не обработку.
  • RIPE NCC прямо указывает на собственных страницах, что сообщения о злоупотреблениях из-за пределов его сети входят в ответственность сетевых операторов, и что он ничего не может сделать, если оператор не отвечает.
  • Все публично доступные показатели (объёмы проверок, еженедельная частота, доля ошибок, ручная доработка) — метрики транспортного уровня; метрики процесса и управления в опубликованных материалах отсутствуют.
  • Предложение 2019-04 требовало, чтобы почтовый ящик Abuse действительно получал сообщения, и предлагало анонимизированную статистику эскалации — этот механизм остался на уровне предложения.

Четырёхуровневая процедура

Абьюс-контакт может отказать на четырёх отдельных уровнях. Уровень (а), транспорт: ящик существует, письмо доставлено. Уровень (b), содержание: ответ относится к конкретному делу, а не к шаблону. Уровень (c), процесс: дело документированно закрыто с прослеживаемым устранением. Уровень (d), управление: есть документированный путь эскалации с именованными ролями и порогами на случай отказа уровня (c).

Политика ripe-705 (действует с 2018 года) мандатирует первый уровень: она требует атрибут abuse-c на всех объектах aut-num и напрямую выделенных inetnum/inet6num, ссылается на объект role с единственным атрибутом abuse-mailbox, доступным без ограничений через whois и API, и обязывает RIPE NCC проверять abuse-mailbox не реже одного раза в год (ripe-705). Исходное предложение 2017-02 прямо провело границу: проверка охватывает техническую корректность abuse-mailbox — синтаксис, домен, конфигурацию почтового сервера. Ситуации, когда ящик работает, но сообщения не обрабатываются так, как ожидает заявитель, явно вне области действия, поскольку у RIPE NCC нет мандата вмешиваться во внутренние процедуры обработки злоупотреблений владельцев ресурсов (предложение 2017-02).

Что проверяет валидация

Данные служб NCC с RIPE 87 (ноябрь 2023) описывают инструмент валидации: он проверяет формат, DNS и существование ящика, не отправляя электронную почту; около 2 000 контактов проверяются еженедельно с долей ошибок 6–8 процентов; недействительный abuse-c в ресурсных объектах заменяется на рабочий abuse-c LIR (RIPE 87 NCC Services). Инструмент проверяет обещание работающего почтового ящика — но даже не то, что этот ящик действительно получает сообщения.

Именно этот разрыв пыталось закрыть предложение 2019-04: оно требовало, чтобы abuse-mailbox действительно получала сообщения и не заставляла заявителя пользоваться веб-формой, и предлагало RIPE NCC собирать анонимизированную статистику эскалации и периодически её публиковать. Анализ воздействия NCC отметил, что инструмент валидации не отправлял электронную почту и что на тот момент 92,5 процента адресов проходили автоматическую проверку (предложение 2019-04). Механизм статистики остался на уровне предложения; публиковались ли когда-либо анонимизированные данные об эскалации, в публично доступных источниках этого исследования не установлено.

Признание реестра

Собственные страницы RIPE NCC разъясняют: сообщения о спаме, фишинге и другом сетевом злоупотреблении из-за пределов его сети не входили в его обязанности как реестра; обработка таких сообщений — задача сетевого оператора; и нет ничего, что NCC мог бы сделать, если оператор решает не отвечать (процедура подачи сообщений; страница Abuse). Тем самым уровень (c) по собственному признанию находится вне мандата.

Существует механизм качества регистрации, а не качества ответа: ripe-858 определяет ступенчатую лестницу прекращения для неотвечающих членов — тех, кто не реагирует на конкретный запрос RIPE NCC о некорректной или неоднозначной регистрации: первое уведомление, напоминания через 30 и 60 дней, уведомление управляющего директора о прекращении через 90 дней (ripe-858). Эта лестница запускается запросом NCC, а не неотвеченной жалобой третьей стороны. Дополнительно ripe-658 допускает обоснованные исключения из обязательной публикации отдельных атрибутов базы данных (ripe-658); документация об абьюс-контактах описывает структуру атрибутов и то, что abuse-c на ресурсном объекте переопределяет значение организации (документация абьюс-контактов; информация об abuse-c); FAQ по abuse-c повторяют эту структуру (FAQ abuse-c); ripe-563 документировала прежний мандат, который заменила ripe-705 (ripe-563).

Массив показателей

Опубликованные цифры реестра неизменно лежат на уровне (a). Кампании валидации проверили, по более ранним публикациям, 77 168 почтовых ящиков (2019), 84 868 (2023), 83 509 (2024) и 86 959 (2025), с растущим хвостом ручной доработки: 649 (2023), 851 (2024), 899 (2025) (предыдущее освещение BTW). Это входные метрики качества контактов, а не результаты устранения. Реестровые обзоры RIPE 90 (май 2025) сообщают за 2024 год: 2 445 завершённых Assisted Registry Checks с примерно 5 500 корректирующими действиями, включая соответствие политике abuse-c, рост обращений в Member Services на 19,4 процента до 32 514, и намерение расширить верификацию на организационные и реестровые контакты (реестровые обзоры RIPE 90). Снова: качество регистрации, а не качество ответа.

Замечание о гигиене источников: ripe-686 — это Charging Scheme 2018, а не политика абьюс-контактов (ripe-686). Здесь он документируется лишь ради исправления — мандат по злоупотреблениям лежит на ripe-705, заменившей ripe-563.

Источники и ограничения

Все упомянутые выше документы — основа этого отчёта. Измеренных данных о фактических показателях недоставки, содержании автоответов, решениях о закрытии обращений или использовании путей эскалации для почтовых ящиков Abuse в регионе RIPE не существует; этот отчёт представляет процедуру оценки и атрибутированные утверждения, а не измеренную работу канала. Данные RIPE 87 и RIPE 90 — точечные, предоставленные поставщиком цифры из презентаций, которые не были полностью открыты. Источник 13 — предыдущее освещение самой BTW Media и служит только контекстом предыдущего освещения, а не независимым подтверждением заявлений RIPE.