Кратко

  • Согласно собственной процедуре RIPE NCC, сообщения о спаме, фишинге и другом сетевом злоупотреблении, исходящие извне сети RIPE NCC, не входят в обязанности реестра и не рассматриваются как предмет расследования.
  • Заявителя направляют через Abuse Contact Finder (RIPEstat) к адресу abuse-c сети, к которой относится проблемный IP-адрес; обязанность ответить лежит на операторе, и реестр прямо заявляет, что не может действовать, если оператор не отвечает.
  • Политика RIPE-705 сделала атрибут abuse-c обязательным в объектах inetnum, inet6num и aut-num и требует ежегодной проверки почтового ящика; за пять лет было расследовано более 1 000 внешних сообщений о некорректных abuse-mailbox без запуска процедуры закрытия.
  • Правка RIPE-858, опубликованная 7 мая 2026 года, удалила почтовые напоминания из процедуры уведомлений членов, сузив канал официального уведомления до электронной почты; реестр называет почту неэффективной и дорогостоящей, а электронную почту — юридически обязывающей.
  • Регистровый механизм защиты — закрытие члена и дерегистрация ресурсов с трёхмесячным сроком на исправление — документирован, но, по имеющимся данным, публично не запускался через жалобу на злоупотребление.
  • Независимых источников, не связанных с реестром, которые подтверждали бы исходы жалоб, в этой записи нет; этот пробел указан прямо.

Контур обработки сетевых злоупотреблений в регионе RIPE устроен так, что его первый рубеж находится не в реестре, а у оператора сети. На странице процедуры подачи сообщений RIPE NCC формулирует это без оговорок: сообщения о спаме, фишинге и другом сетевом злоупотреблении, исходящие вне сети RIPE NCC, «не относятся к обязанностям RIPE NCC как реестра» и не будут рассматриваться для расследования. Это утверждение принадлежит самой организации и здесь приводится как её позиция.

Для заявителя это означает конкретный маршрут. Руководство реестра для конечных пользователей предписывает использовать Abuse Contact Finder в RIPEstat, чтобы получить адрес злоупотреблений (abuse contact) сети, к которой относится данный IP-адрес, и направить туда письмо с деталями — IP-адресом и временем инцидента. Роль реестра при этом описывается ограниченно: обеспечивать действительность и актуальность адресов abuse-c, но не добиваться ответа. Если оператор сети решает не отвечать, реестр заявляет, что действовать не может.

Инфраструктура проверки этого контакта выросла из политики RIPE-705 («Управление контактами злоупотреблений в базе данных RIPE», на основе предложения 2017-02). Она сделала атрибут abuse-c обязательным в объектах inetnum, inet6num и aut-num, требует, чтобы связанный объект role содержал единственный атрибут abuse-mailbox, и предписывает проверять этот ящик не реже раза в год с последующими мерами при обнаружении ошибки.

На странице предложения 2017-02 реестр отмечает, что закрытие и дерегистрация рассматриваются как крайняя мера: за пять лет было расследовано и решено более 1 000 внешних сообщений о некорректных атрибутах abuse-mailbox без запуска процедуры закрытия и дерегистрации; если процедура всё же запускается, у держателя ресурсов есть ещё три месяца на исправление.

Материалы RIPE Labs описывают саму лестницу последующих мер. Проверка идёт по порядку: сначала объекты организаций LIR, затем объекты ресурсов LIR, затем объекты конечных пользователей; направляются два дополнительных напоминания с недельными интервалами, а через неделю после последнего напоминания к работе подключаются сотрудники. Для объектов организаций LIR неответ может вести к закрытию члена с дополнительными тремя месяцами; для объектов ресурсов LIR и конечных пользователей завершения работы не предусмотрено — только комментарий в базе данных RIPE о том, что контакт злоупотреблений не прошёл проверку.

Вторая статья RIPE Labs описывает процесс как двухэтапный: автоматические письма дают LIR около трёх недель, затем начинается ручной контакт через адреса из LIR Portal. Те же материалы приводят объёмы проверок: 2 320 расследований и 86 959 проверенных адресов в 2025 году по ранее цитировавшимся данным годового отчёта.

7 мая 2026 года вступила в силу публикация RIPE-858 «Закрытие членов, дерегистрация интернет-ресурсов и Legacy-интернет-ресурсы»: раздел A описывает прекращение соглашения о сервисном обслуживании с последующим закрытием члена, раздел B — дерегистрацию номерных ресурсов, раздел C — прекращение Legacy Services Agreement.

В тот же день юридический советник RIPE NCC Теодорос Филаридис (Theodoros Fyllaridis) объявил в списке рассылки ncc-services-wg поправку: из раздела 1.2.1.1 (процедура) удалены слова «и напоминание почтовым отправлением» и «email и»; из раздела 1.2.2.c (непредставление действующей выписки из торгового реестра) удалены «и уведомление почтой» и «и почтового». Обоснование реестра: почта неэффективна, часто недоставляема и дорога, тогда как электронная почта юридически обязывает, а члены по-прежнему отвечают за актуальность контактных данных по соглашению SSA; содержательные результаты эскалации, по утверждению реестра, не меняются.

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

Здесь нужна честная граница доказательств. Все процедурные утверждения в этой статье — заявления RIPE NCC: страниц процедуры, документов политики, объявлений в списке рассылки и статей RIPE Labs. Независимых источников, не связанных с реестром, которые подтверждали бы исходы конкретных жалоб, работоспособность прежних почтовых напоминаний или кейсы запуска процедуры закрытия, в доступной записи нет.

Источники

  1. Abuse-c validation update on progress and some numbers — RIPE Labs
  2. How we will be following up with invalid abuse contacts — RIPE Labs
  3. Объявление о поправке RIPE-858 в списке рассылки ncc-services-wg
  4. Reporting procedure — RIPE NCC
  5. Policy proposal 2017-02 — RIPE NCC
  6. Abuse — RIPE NCC
  7. RIPE-705 — RIPE NCC
  8. RIPE-858 — RIPE NCC