Кратко

  • Документированная крайняя мера — закрытие члена реестра и дерегистрация ресурсов за неработающий abuse-контакт — не применялась ни разу в публичной истории.
  • Независимые академические исследования 2016 и 2017 годов зафиксировали, что 85,9–92,8% адресов abuse-контактов не получают ответа, даже когда доставляемы.
  • Единственное предложение ужесточить контроль (2019-04) было отозвано 8 сентября 2020 года после того, как операторы сочли издержки выше предполагаемой пользы.
  • В 2025 году RIPE NCC провёл 2320 расследований проверки abuse-c и валидировал 86 959 адресов, но задокументированные закрытия членов касались преимущественно неоплаты.
  • Автоматическая проверка не отправляет письма и не проверяет, читает ли человек сообщения: подтверждается лишь техническая доставляемость.

Разговор о том, кто должен отвечать за сообщения о сетевых злоупотреблениях, обычно начинается с адреса. В системе, описываемой RIPE NCC, этот адрес — значение атрибута abuse-mailbox в объекте роли abuse-c. Именно туда перенаправляются жалобы посторонних людей, столкнувшихся с вредоносной активностью из сетей участников. Формально всё выглядит завершённым: политика требует контакта, секретариат проверяет адрес, есть процедура наказания за отказ сотрудничать. Фактическая история складывается иначе.

Как появился контакт и как появился контроль

Политика RIPE-563, принятая в 2012 году, ввела обязательный атрибут abuse-c и требование, чтобы объекты ролей содержали единственный атрибут abuse-mailbox. Примечательно, что документация самой политики указывает: проверка сведений abuse-c изначально не предусматривалась вовсе. Контакт стал обязательным полем, но никто не проверял, работает ли он.

Устранить этот пробел попытались позже, через процедуру открытия для предложения 2017-02. Предложение было принято 1 июня 2018 года и реализовано 10 октября 2019 года как RIPE-705: теперь RIPE NCC обязан валидировать атрибут abuse-mailbox не реже раза в год. Но важно понять, что именно проверяет эта валидация. По описанию процедуры, она полностью автоматизирована и техническая по своей природе: проверяется синтаксис, разрешение имени, конфигурация почтового сервера. Она не отправляет писем и не требует никаких действий от abuse-контакта. Иными словами, контроль подтверждает, что сервер примет сообщение, — но не то, что человек его прочитает.

Масштаб проблемы, ожидавшийся на старте, был оценён в анализе воздействия предложения 2017-02: 10–25% из примерно 70 000 различных атрибутов abuse-mailbox в базе RIPE могли быть некорректными или неактивными. За пять лет до введения проверки RIPE NCC исследовал и разрешил более 1000 внешних отчётов о неверных адресах, и ни разу не дошло до закрытия или дерегистрации — эта мера описана как крайнее средство с трёхмесячным сроком на исправление.

Что показала фактическая проверка

Документированное внедрение на RIPE Labs даёт конкретные цифры: около 9500 abuse-контактов были обновлены из примерно 67 000 проверенных — примерно 14%. Около 60% случаев были разрешены автоматизированным процессом, примерно 50 независимых ресурсов сменили статус спонсорства. За период внедрения ни один член не был закрыт за несовместимость с процессом, а текущая проверка генерирует порядка десяти новых обращений в день. На встрече RIPE 79 секретариат отчитался о 93% прохождения автоматической проверки abuse-c.

Эти цифры описывают упражнение по контролю, а не его функциональный результат. Для последнего следует обратиться к независимым источникам, не связанным с реестром. Исследование USENIX Security 2016 года (ICIR, Li и соавторы) о рассылке уведомлений об уязвимостях и исследование WEIS 2017 года (Cetin и соавторы) независимо зафиксировали: 85,9–92,8% abuse-контактов в реестрах и WHOIS не получают ответа, даже когда адреса доставляемы. Это ключевая развилка: формально валидный адрес может годами молчать, и никакая автоматическая проверка этого не обнаружит.

Попытка ужесточить — и почему она не прошла

Логика развития подсказывала следующий шаг: требовать не доставляемости, а фактического получения сообщений. Предложение политики 2019-04 предполагало, что abuse-mailbox должен действительно принимать сообщения (автоматические или от людей), и запрещало заставлять отправителей проходить через веб-формы. Предложение было отозвано 8 сентября 2020 года после того, как не достигло консенсуса; апелляция автора была удовлетворена 26 октября 2020 года.

Опубликованная дискуссия показывает аргументацию противников. По данным из открытой переписки анти-абузной рабочей группы, 92,5% адресов прошли существующую автоматическую проверку, а RIPE NCC оценил дополнительную нагрузку при новом требовании примерно в десять раз выше текущей. Операторы Nick Hilliard и Erik Bais отмечали, что усилия и издержки перевешивают предполагаемую пользу; в фазе рассмотрения не поступило ни одного сообщения поддержки. Решение о выборе дешёвой формальной соответствия вместо проверки функции было коллективным решением сообщества — и оно задокументировано.

Кто говорит жалобу и что отвечает реестр

Позиция самой организации зафиксирована в её собственных материалах. На странице поддержки по abuse RIPE NCC прямо указывает, что не может принудить оператора отвечать на отчёты о злоупотреблениях; жалобщики направляются к abuse-c почтовому ящику оператора, а обязанность отвечать лежит на операторе. Таким образом, человек, чья сеть, вероятно, используется для вредоносной активности, направляется к почтовому адресу, который независимые измерения показывают молчащим в 86–93% случаев, и никаких дальнейших механизмов защиты у него нет.

Крайняя мера — закрытие члена и дерегистрация ресурсов — описана в процедуре RIPE-858, пересмотренной 7 мая 2026 года: уведомления об обеспечении исполнения переведены на электронную почту, почтовые напоминания удалены. Это важное сужение канала эскалации: единственный документированный путь к санкции теперь проходит через тот самый класс электронных коммуникаций, отказ которых и составляет проблему.

Что касается практики применения санкций, годовой отчёт RIPE NCC за 2025 год показывает 2320 расследований проверки abuse-c и 86 959 валидированных адресов электронной почты; задокументированные закрытия членов за этот период связаны преимущественно с неоплатой (172 случая), ни одного — за неверный abuse-c. Валидация работает; санкция за её предмет не срабатывает никогда.