Кратко

  • Обязательная проверка abuse-mailbox устанавливает достижимость ящика — синтаксис адреса, существование домена, конфигурацию почтового сервера, — а не то, что доставленные сообщения об abuse кто-то обрабатывает.
  • Опубликованная доля отказов прошла путь от предварительной оценки в 10–25 процентов через примерно 21 процент в пробе 2018 года до 7 процентов в завершённом раунде 2019 года и 6–8 процентов при еженедельных проверках в 2021 году; ни один из этих показателей не измерял реакцию на жалобы.
  • Порядок эскалации асимметричен по классам объектов: для organisation-объектов LIR он может закончиться закрытием члена и дерегистрацией ресурсов, тогда как для resource-объектов и End User-объектов реестр ограничивается комментарием в базе о том, что контакт не прошёл проверку.

Что именно проверяет обязательный атрибут

Требование держать выделенный контакт для жалоб на злоупотребления закреплено через обязательный атрибут abuse-c, а политика, окончательно оформленная как ripe-705, обязывает RIPE NCC проверять атрибут abuse-mailbox не реже одного раза в год и вести работу с теми записями, которые признаны некорректными (ripe-705).

Сама проверка техническая. Предложение 2017-02 достигло консенсуса 1 июня 2018 года и было зафиксировано как полностью реализованное 10 октября 2019 года; описанная в нём автоматическая валидация касалась синтаксиса, домена и конфигурации почтового сервера, а не того, отвечает ли человек на письма (предложение 2017-02; разъяснение порядка работы с некорректными контактами). Разграничение здесь не бюрократическое: машинная проверка умеет отличить неработающий ящик от работающего, но не отличает ящик, который читают, от ящика, который существует.

Динамика отказов: от 10–25 процентов к 7

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

Перед реализацией анализ воздействия оценивал, что от 10 до 25 процентов из примерно 70 000 отдельных атрибутов abuse-mailbox могут быть некорректными или неактивными — оценка опиралась на предварительный тест со случайной выборкой (предложение 2017-02). Проба конца 2018 года охватила контакты abuse в 900 organisation-объектах LIR: она дала 187 тикетов, то есть около 21 процента, из которых 106 были закрыты без вмешательства сотрудников, а 81 потребовал ручной работы (разъяснение порядка работы с некорректными контактами).

Первая сплошная валидация всех атрибутов abuse-mailbox насчитала 77 168 отдельных атрибутов: 71 711, или 93 процента, прошли автоматическую проверку, а 5 457, или 7 процентов, её не прошли. Примерно 8 000 атрибутов abuse-mailbox были обновлены в 2019 году, работа потребовала трёх временных сотрудников на полную ставку в течение нескольких месяцев, а 20–25 процентов тикетов нуждались в ручном сопровождении (презентация о ходе реализации 2017-02).

Промежуточный отчёт фиксировал, что около 60 процентов случаев закрывались без вмешательства сотрудников, примерно 9 500 контактов abuse были обновлены из примерно 67 000 проверенных, а около 50 независимых ресурсов изменили статус спонсорства (обновление о ходе валидации abuse-c). Разбивка середины 2019 года по классам объектов показывает, откуда берётся эта нагрузка: завершённая валидация 18 200 адресов organisation-объектов LIR дала 3 500 тикетов, из которых 1 400 обрабатывались вручную; завершённая валидация 3 200 адресов resource-объектов LIR дала 200 тикетов, из которых 40 обрабатывались вручную, и 100 комментариев в базе; продолжавшаяся тогда валидация 13 500 адресов End User дала 1 200 тикетов, из которых 350 обрабатывались вручную (обновление abuse-c, RIPE 78).

К ноябрю 2021 года процесс вышел на устойчивый режим: примерно 2 000 контактов проверялись еженедельно, около 6–8 процентов не проходили проверку, годовой охват составлял примерно 19 600 organisation-объектов LIR, около 58 100 resource-объектов LIR и около 15 400 независимых ресурсов, а некорректный abuse-c на resource-объекте заменялся рабочим контактом abuse ответственного LIR (текущее состояние процесса).

Показательно, что позднейшее обсуждение не пересматривало эти цифры: более позднее предложение повторило ту же сводку — 77 168 атрибутов, 93 процента успешных и 7 процентов неуспешных проверок и примерно 8 000 обновлённых в 2019 году атрибутов (предложение 2019-04; презентация о ходе реализации 2017-02). Иными словами, спор шёл не о точности измерения, а о том, что именно измеряется.

Асимметрия эскалации по классам объектов

Опубликованное описание эскалации прямо разделяет последствия по типам объектов. Для organisation-объектов LIR неотвечаемость или отказ от сотрудничества могут в конечном счёте привести к закрытию члена и дерегистрации ресурсов, причём после запуска процедуры закрытия у LIR остаётся ещё три месяца, чтобы обновить контакт abuse, прежде чем членство будет прекращено. Для resource-объектов LIR и для End User-объектов реестр заявил, что не будет прекращать членство или спонсорство, а вместо этого добавит комментарий в RIPE Database о том, что контакт abuse не прошёл валидацию (разъяснение порядка работы с некорректными контактами).

Для серьёзного неурегулированного нарушения документированная терминальная последовательность выглядит так: письменное уведомление с трёхмесячным сроком, напоминания на 30-й и 60-й день, затем уведомление управляющего директора о том, что соглашение об обслуживании может быть расторгнуто на 90-й день, после чего следуют дерегистрация записей о ресурсах и отзыв сертификатов RPKI (ripe-858). Речь идёт о редком, но необратимом сценарии: дерегистрация и отзыв сертификатов не отменяются одним письмом.

Чего не показывает ни одна из этих цифр

Более позднее предложение сформулировало предел режима открытым текстом: существующая проверка не устанавливает, что ящик для жалоб работает на практике, а сопроводительный текст о воздействии прямо оговаривает, что цель политики — не изучать, как отслеживаются и обрабатываются случаи abuse. Там же приведена проектная оценка объёма: полный повторяющийся раунд мог бы потребовать более 32 000 тикетов, из которых около 19 200 пришлось бы проверять вручную (предложение 2019-04; презентация 2019-04, RIPE 80).

Сложив публичные цифры рядом, видно, что они описывают доступность, а не реакцию. Доля отказов прошла путь от предварительной оценки 10–25 процентов и примерно 21 процента в пробе 2018 года до 7 процентов в завершённом раунде 2019 года и 6–8 процентов при еженедельных проверках в 2021 году (предложение 2017-02; разъяснение порядка работы с некорректными контактами; презентация о ходе реализации 2017-02; текущее состояние процесса). Ни одна из этих величин не отвечает на вопрос о том, что происходит с жалобой, доставленной на адрес, который проверку прошёл.

Практический вывод сдержанный, но не пустой: валидация abuse-c — это контроль достижимости с измеримым положительным эффектом на качество контактных данных, а не контроль реагирования. Организация, которая строит на ней оценку чужой готовности к реагированию, измеряет не то, что думает. Запись в справочнике: RIPE ABUSE.