Кратко

  • RIPE-563 сделала атрибут abuse-c обязательным для объектов inetnum, inet6num и aut-num: связанный role-объект должен содержать один abuse-mailbox, публично доступный через WHOIS и API, способный принимать сообщения и не требующий веб-формы; при вступлении в силу требование не распространялось на legacy-ресурсы.
  • По предложению 2017-02 «Regular abuse-c Validation» реестр проактивно проверяет abuse-mailbox не реже одного раза в год — автоматическими техническими тестами, которые не отправляют писем.
  • Проверка подтверждает наличие атрибута и достижимость ящика; она не оценивает, как обрабатываются обращения после доставки.
  • При провале атрибут помечается недействительным, создаётся тикет и запускается лестница эскалации — вплоть до процедуры закрытия участника и дерегистрации ресурсов.
  • Реестр сообщал, что раннее тестирование инструмента указывало на 10–25% некорректных или неактивных ящиков, а поздний раунд — примерно на 92,5% успешных автоматических проверок; обе цифры не проверялись независимо.

Что именно требует RIPE-563

Политика RIPE-563 «Abuse Contact Management in the RIPE Database» сделала атрибут abuse-c обязательным для трёх типов объектов: inetnum, inet6num и aut-num. Связанный role-объект должен содержать ровно один атрибут abuse-mailbox: адрес обязан быть публично доступен через WHOIS и программные интерфейсы, обязан принимать сообщения, и отправитель не может быть вынужден пользоваться веб-формой (описание требований). Оговорка, о которой легко забыть: на момент вступления требований в силу они не распространялись на устаревшие (legacy) интернет-ресурсы (там же) — часть старейших блоков и сегодня может находиться вне автоматической проверки.

Годовая валидация

Под предложением 2017-02 «Regular abuse-c Validation» RIPE NCC проверяет атрибуты abuse-mailbox проактивно — не реже одного раза в год (RIPE NCC о регулярной валидации abuse-c). Это не проверка по конкретной жалобе: она идёт по расписанию реестра и не зависит от того, поступали ли на адрес обращения.

Как проходит автоматическая проверка

Валидация начинается с автоматических технических тестов, которые не отправляют электронных писем: проверяется форматирование адреса, выполняется проверка DNS, выявляются фиктивные и honeypot-адреса, а также проводится тест на способность ящика принимать почту (описание процесса валидации). Фактически проверка эмулирует доставку, не создавая переписки.

Граница проверки: наличие и достижимость, а не обработка

Процесс оценивает, присутствует ли атрибут и достижим ли ящик; он не оценивает, как обрабатываются инциденты после получения (предложение 2017-02; описание процесса; материалы реестра). Разграничение принципиально: успешная ежегодная проверка удостоверяет контактную точку, а не качество реагирования. Ни один автоматический тест не отличает ящик, где на письма отвечают в течение суток, от ящика, который молча принимает почту.

Что происходит при провале

Если ящик не проходит валидацию, атрибут помечается недействительным и создаётся тикет. Ответственный LIR — а для независимых ресурсов спонсирующий LIR — получает запрос на рассмотрение; на сам ящик отправляется ссылка для верификации, позволяющая подтвердить рабочий адрес, ошибочно не прошедший проверку; если ответа нет, предпринимаются ещё две попытки с интервалом в одну неделю; затем сотрудник реестра пробует связаться по телефону или через альтернативный контакт; в качестве крайней меры RIPE NCC может инициировать процедуру закрытия участника и дерегистрации интернет-ресурсов (описание процедуры).

Цифры реестра и их пределы

Раннее тестирование инструмента валидации указывало, что примерно 10–25% атрибутов abuse-mailbox могут быть некорректными или неактивными; позднее реестр сообщал, что около 92,5% атрибутов прошли автоматическую техническую проверку (сводка результатов). Это заявления реестра, а не независимо подтверждённые измерения, и они относятся к разным раундам и разным методикам: трактовать их как динамику «от 10–25% к 92,5%» некорректно. Кроме того, RIPE NCC заявляла, что анонимизированную статистику о том, как обрабатываются обращения о злоупотреблениях, следует собирать и периодически публиковать (заявление реестра) — то есть измеритель реакции, а не доставляемости, пока остаётся желанием, а не отчётом.

Что это меняет для держателей ресурсов

Для LIR проверка превращает контактную точку в регулярно проверяемое обязательство с эскалационными последствиями: недействительный адрес виден публично, а на кону — вплоть до ресурсов. Но метрика поощряет работоспособный ящик, а не работающую реакцию: очистка базы улучшает процент прохождений, ничего не говоря о том, как обрабатываются сами обращения. Справочная карточка объекта: RIPE abuse в справочнике BTW.