Кратко

  • Опубликованные показатели RIPE NCC за 2025 год демонстрируют конвейер валидации, работающий в промышленных масштабах: 86 959 подтверждённых адресов электронной почты abuse-c против 83 509 в 2024 году и 2 320 расследований валидации abuse-c по аккаунтам LIR, ресурсам LIR и конечным пользователям. Ни один из этих показателей не измеряет, привела ли хотя бы одна жалоба к устранению злоупотребления.
  • Политика, создавшая ежегодную валидацию abuse-c, — предложение 2017-02 (ныне RIPE-705) — прямо гласит, что RIPE NCC "не имеет мандата вмешиваться во внутренние процедуры обработки злоупотреблений у держателей ресурсов". В ней также зафиксировано, что за пять лет до предложения NCC расследовал более 1 000 внешних сообщений о некорректных атрибутах abuse-mailbox, ни разу не запустив закрытие или дерегистрацию.
  • Правообладатели представили Рабочей группе по безопасности на RIPE 89 документированное, названное по именам свидетельство пробела в устранении: повторное пиратство с одних и тех же IPv4-адресов RIPE-региона и трудности с получением ответов от операторов.
  • В просмотренном публичном архиве не обнаружено ни одного опубликованного арбитражного дела или дела о закрытии, инициированного жалобой третьей стороны на злоупотребление. Это картина отсутствия в просмотренном архиве, а не доказанная универсальность, но она согласуется с текстом политики и со статистикой самого реестра.
  • Спустя два года после переименования рабочей группы протоколы Рабочей группы по безопасности на RIPE 90 и RIPE 91 не фиксируют ни одной политики по устранению злоупотреблений на обсуждении.

Конвейер, который измеряет свои входные данные

Начнём с того, что реестр действительно измеряет, потому что цифры велики и актуальны. Годовой отчёт RIPE NCC за 2025 год (RIPE-855) сообщает о 2 825 Assisted Registry Checks — с превышением цели в 2 400; о 2 320 расследованиях валидации abuse-c, распределённых между 801 аккаунтом LIR, 764 ресурсами LIR и 755 конечными пользователями; о 77 086 созданных или обновлённых объектах роли abuse-c; и о 86 959 подтверждённых адресах электронной почты abuse-c, из которых 85 696 были подтверждены автоматически, а 899 потребовали ручного вмешательства. В отчёте утверждается, что NCC "успешно подтвердил все адреса abuse-c на соответствие RIPE-705". Отчёт за 2024 год (RIPE-840) показывает тот же механизм годом ранее: 2 445 Assisted Registry Checks, повлёкших около 5 500 корректирующих действий, 2 366 расследований валидации abuse-c и падение числа созданных или обновлённых объектов роли abuse-c со 149 228 в 2023 году до 102 939 в 2024-м.

При внимательном чтении каждый из этих показателей — входной метрика. Они считают проверенные ящики, исправленные контактные записи, расследования того, ведёт ли атрибут куда-то реальное. Ни один из них не считает судьбу жалоб, которые эти ящики получают: сколько жалоб подано против ресурсов RIPE-региона, сколько подтверждено, сколько привело оператора к прекращению злоупотребления, сколько проигнорировано. Реестр не публикует подобной серии исходов.

Читатель, сравнивающий отчёты за разные годы, может наблюдать, как конвейер валидации становится эффективнее — 83 509 подтверждённых адресов в 2024 году, 86 959 в 2025-м — и при этом полностью не способен узнать из тех же документов, прекратилось ли хоть одно заявленное злоупотребление.

Это не скрытый факт. Это спроектированная граница системы. Текст политики — предложение 2017-02 — говорит об этом в пассаже, который стоит процитировать, поскольку он выполняет ту интерпретационную работу, за которую этой статье иначе пришлось бы спорить: "Также вне области действия этой валидации находятся сценарии, где атрибут abuse-mailbox настроен корректно, но сообщения не обрабатываются так, как хотел бы отправитель. RIPE NCC не имеет мандата вмешиваться во внутренние процедуры обработки злоупотреблений у держателей ресурсов."

Мандат, записанный на бумаге

Эта фраза — шарнир всего вопроса об устранении. Собственный текст политики реестра проводит линию между исправностью ящика — который NCC ежегодно подтверждает согласно RIPE-705 — и судьбой жалоб внутри него, которая принадлежит исключительно держателю ресурса. То же предложение фиксирует последствие в исторических терминах: за пять лет, предшествовавших предложению, NCC расследовал и разрешил более 1 000 внешних сообщений о некорректных атрибутах abuse-mailbox, не запустив закрытие или дерегистрацию ни в одном из них.

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

Институт вправе определять свой мандат узко. Аналитически значимым его делает асимметрия, задокументированная в других местах архива того же института. Предыдущие публикации BTW реконструировали механизм эскалации над ящиком — арбитражную коллегию, двенадцатинедельный срок вынесения решения, публичный архив решений и лестницу прекращения 30/60/90 дней — и установили, что он явно срабатывает при фальсифицированных регистрационных данных, проваленных аудиторских проверках и спорных передачах.

Что не документировано ни в одном опубликованном источнике, так это хотя бы одна из этих эскалаций, вызванная тем, что оператор игнорирует жалобы третьих сторон. Механизм работает — и работает везде, кроме жалоб, которые люди на самом деле подают.

Собственный учебный материал реестра подкрепляет это разделение труда. Слайды Академии RIPE NCC от января 2025 года (учебные материалы по обработке злоупотреблений), адресованные операторам, создающим abuse-дески, описывают обработку злоупотреблений как входящую обработку, разбор и устранение или смягчение; они подчёркивают скорость как ключевой фактор и предлагают измерять успех статистикой вроде числа заявленных проблем, контактированных конечных пользователей и решённых проблем. Все эти метрики успеха лежат на стороне оператора. Слайды ссылаются на RIPE-705 только применительно к ежегодной валидации адреса abuse-mailbox — единственному элементу, который контролирует NCC.

Названное подтверждение с принимающей стороны

Самое сильное доказательство не от оператора в просмотренном архиве приходит от правообладателей, вынесших свой опыт в зал RIPE. Протоколы Рабочей группы по безопасности за RIPE 89 (Прага, октябрь 2024 года) фиксируют презентацию Ли Кента (BeIN) и Эндрю Уиллата (Premier League), описывавших пиратство в реальном времени через IPv4-адреса RIPE-региона: повторные нарушения с одних и тех же адресов и трудности с получением ответов от соответствующих сетевых операторов. Их требования были конкретны — чтобы RIPE NCC улучшил прозрачность и коммуникацию и работал с организациями над политиками в отношении повторных нарушителей. Протокол фиксирует, что Ханс Петтер Холлен из RIPE NCC ответил деталями и статистикой об abuse-c и точности реестра.

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

Где стоит общественная дискуссия

Внутри самой рабочей группы пробел признан в поразительных формулировках. Пост в списке рассылки Рабочей группы по безопасности от 4 августа 2026 года утверждает, что некоторые организации игнорируют жалобы на злоупотребления, потому что это дешевле и за это нет наказания, различая "оппортунистическое" несоблюдение и организации, чья бизнес-модель зависит от злоупотреблений, и предполагая, что в RIPE-регионе отсутствует какой-либо механизм, делающий игнорирование жалоб третьих сторон затратным, указывая на подход в стиле LACNIC как на возможную модель. Другая дискуссия того же периода обсуждала прогрессивные санкции — например, блокировку обновлений объектов базы данных — за устойчивое неразрешение случаев злоупотребления; ничего в просмотренном архиве не указывает на принятие. Это индивидуальные мнения из списка рассылки, а не политика RIPE, и они несут вес аргумента, а не решения. Но их предпосылка — что игнорирование жалобы сейчас ничего не стоит оператору на уровне реестра — в точности совпадает с предпосылкой, которую подтверждают текст политики и статистика.

Институциональный канал для изменения этого молчал. Рабочая группа Anti-Abuse была переименована и перерегистрирована как Рабочая группа по безопасности — изменение, одобренное на RIPE 89, — а её устав называет "противодействие злоупотреблениям интернет-инфраструктурой и ресурсами" ключевой целью, одновременно заявляя, что группа не является местом для подачи жалоб на злоупотребления или спам. Протоколы RIPE 90 от 13 мая 2025 года и RIPE 91 от 21 октября 2025 года не фиксируют ни одной политики на обсуждении; соруководители — Брайан Нисбет, Тобиас Кнехт и Маркус де Брюн — заявили, что будут помогать и направлять соответствующие политические предложения по надлежащему адресу. Исходная страница группы (страница Anti-Abuse) и её архив (архив Anti-Abuse) сохранены как справочные материалы; более раннее обсуждение того же пробела зафиксировано в архиве списка anti-abuse-wg.

Что подтверждает архив и чего он показать не может

Границы доказательств следует изложить прямо. Показатели реестра — самостоятельные и не подвергнутые аудиту, а драйвер роста подтверждённых адресов с 2024 по 2025 год не задокументирован. В публичном архиве нет набора данных об исходах по каждой жалобе, поэтому объём игнорируемых жалоб можно характеризовать лишь качественно — через названные свидетельства вроде презентации правообладателей на RIPE 89 и дискуссии в списке рассылки. Операторы, обвинённые в неответах в этой презентации, на просмотренном архиве публично не ответили на обвинения.

А отсутствие дел о принуждении публикуется здесь как картина отсутствия в просмотренном архиве — негативное утверждение, всегда более слабое, чем позитивное, хотя здесь оно подтверждается текстом политики, который его предсказывает.

Что архив действительно устанавливает, так это структурный факт. Реестр массово подтверждает входные данные и по собственному признанию делает это успешно. Администрируемая им политика явно выводит обработку жалоб за пределы его мандата. Его опубликованная статистика не содержит исходов устранения. Его механизм принуждения задокументирован, работает и — на просмотренном архиве — ни разу не был задействован по жалобе третьей стороны. Собственная дискуссия сообщества называет отсутствующее наказание и обсуждала механизмы его создания, не приняв ни одного.

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

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