Resumo

  • A política RIPE-563 (2012) introduziu o atributo obrigatório abuse-c sem qualquer validação; a RIPE-705 (implementada em 10 de outubro de 2019) obriga validação anual automatizada — que testa sintaxe, DNS e configuração do servidor de e-mail, envia mensagens e não exige ação do contato de abuso.
  • Estudos acadêmicos independentes (USENIX Security 2016, ICIR; WEIS 2017, Cetin et al.) constataram que 85,9%–92,8% dos contatos de abuso registrados não receberam resposta, mesmo quando os endereços eram entregáveis.
  • A proposta 2019-04, que teria exigido que a caixa de abuso realmente recebesse mensagens, foi retirada em 8 de setembro de 2020 após oposição baseada em custo; o apelo do proponente foi acolhido em 26 de outubro de 2020.
  • Em 2025, o registro conduziu 2.320 investigações de validação e validou 86.959 endereços de e-mail, mas os encerramentos documentados de membros foram quase todos por não pagamento (172) — nenhum por abuse-c inválido.

O atributo abuse-c existe na região RIPE desde 2012, quando a política RIPE-563 passou a exigir que objetos de função (role objects) declarassem uma única caixa de e-mail de abuso (https://www.ripe.net/publications/docs/ripe-563/). Na origem, porém, a política não previa qualquer validação dessas informações: o endereço podia estar incorreto, inativo ou apontar para uma caixa que ninguém monitorava, e o registro não tinha como saber.

A lacuna só recebeu uma resposta institucional em 2018, quando a proposta 2017-02 foi aceita e, em 10 de outubro de 2019, implementada como RIPE-705: o RIPE NCC passou a validar o atributo abuse-mailbox pelo menos uma vez ao ano (https://www.ripe.net/publications/docs/ripe-705/). A validação é automatizada e técnica — verifica sintaxe, resolução de DNS e configuração do servidor de e-mail. Ela não envia e-mails e não exige nenhuma ação do contato de abuso (https://www.ripe.net/community/policies/proposals/2017-02/). Em outras palavras, o controle testa se a caixa existe e aceita mensagens, não se alguém a lê.

A análise de impacto da própria proposta estimava que 10%–25% dos cerca de 70.000 atributos abuse-mailbox distintos no banco de dados RIPE estavam incorretos ou inativos, e que o RIPE NCC havia investigado e resolvido mais de 1.000 relatórios externos de abuse-mailbox incorretos ao longo de cinco anos, sem nunca acionar a sanção de encerramento/desregistro — prevista apenas como último recurso, com três meses adicionais para correção (https://www.ripe.net/community/policies/proposals/2017-02/).

Na implementação documentada no RIPE Labs, cerca de 9.500 contatos de abuso foram atualizados entre cerca de 67.000 verificados (~14%), com cerca de 60% dos casos resolvidos pelo processo automatizado; cerca de 50 recursos independentes mudaram de patrocinador, nenhum membro foi encerrado por falta de cooperação e a validação contínua gera cerca de dez novos casos por dia (https://labs.ripe.net/author/angela_dallara/abuse-c-validation-update-on-progress-and-some-numbers/). No RIPE 79, o próprio registro reportou 93% de aprovação na validação automatizada durante a fase de implantação (https://ripe79.ripe.net/presentations/102-2017-02-Implementation-Summary_final.pdf).

A evidência independente mais forte sobre o que esses números não medem vem de fora do sistema. O estudo da ICIR apresentado no USENIX Security 2016 e o estudo de Cetin et al. no WEIS 2017 constataram que 85,9%–92,8% dos contatos de abuso de registros e WHOIS não receberam resposta alguma — mesmo quando os endereços eram entregáveis (https://www.icir.org/vern/papers/sec16-vuln-notifications.pdf, https://mkorczynski.com/WEIS2017Cetin.pdf). A orientação publicada do próprio RIPE NCC admite que ele não pode obrigar um operador a responder a relatórios de abuso: os reclamantes são roteados para a caixa abuse-c do operador, e a obrigação de responder é do operador (https://www.ripe.net/about-us/support/abuse/, https://www.ripe.net/about-us/support/abuse/).

A única proposta que teria fechado parte dessa lacuna funcional foi a 2019-04, que exigia que a caixa de abuso realmente recebesse mensagens (automáticas ou manuais) e proibia forçar remetentes a passar por formulários web. Ela foi retirada em 8 de setembro de 2020 por não alcançar consenso (https://www.ripe.net/community/policies/archived-policy-proposals/); o apelo do proponente foi acolhido em 26 de outubro de 2020 (https://www.ripe.net/community/policies/proposals/2019-04/). Na fase de revisão, os comentários de Nick Hilliard e Erik Bais argumentaram que o esforço e o custo superavam os benefícios alegados, e nenhuma mensagem de apoio foi recebida (https://www.ripe.net/community/policies/proposals/2019-04/). Dos endereços testados, 92,5% passaram na verificação automatizada existente, e o RIPE NCC estimou que a nova exigência representaria cerca de dez vezes a carga de trabalho atual (https://www.ripe.net/community/policies/proposals/2019-04/).

O registro anual de 2025 do RIPE NCC documenta 2.320 investigações de validação de abuse-c e 86.959 endereços de e-mail validados no período, enquanto os encerramentos documentados de membros foram majoritariamente por não pagamento (172 casos) — nenhum por abuse-c inválido (https://www.ripe.net/manage-ips-and-asns/resource-management/abuse-c-information/, https://www.ripe.net/about-us/press-centre/annual-reports, https://www.ripe.net/media/documents/ripe-855.pdf). A RIPE-858, o procedimento de encerramento e desregistro de membros, foi revisada em 7 de maio de 2026, movendo as notificações de aplicação para e-mail e eliminando lembretes postais (https://www.ripe.net/publications/docs/ripe-858/).

O registro resultante desenha um controle que funciona dentro do que se propôs a medir — a entrega — e que nunca exerceu sua sanção de último recurso pela função que motivou sua criação. A lacuna entre exercício do controle (validação anual) e resultado funcional (ausência de resposta humana) não é um acidente: é o produto de uma escolha coletiva documentada, a retirada da 2019-04 em razão do custo.