Resumen

  • La documentación oficial del endpoint del Abuse Contact Finder advierte que la información de contacto devuelta es "en muchos casos incorrecta o no está disponible": el propio registro documenta la imprecisión de la capa que dirige las denuncias de abuso.
  • La calificación de fiabilidad de cinco estrellas que una vez mostraba la incertidumbre se retiró en 2015; desde entonces la herramienta devuelve una única dirección sin cualificar, acompañada de una advertencia a nivel de API.
  • La búsqueda funciona de abajo hacia arriba y devuelve el primer abuse-c encontrado; los errores documentados de la era heurística incluyen la devolución repetida de la dirección de marcador de posición del propio registro.
  • La validación automatizada comprueba solo que existe un correo funcional; no garantiza que el buzón sea el destino correcto o eficaz para una denuncia.

El número al que se envía una denuncia de abuso no es un detalle menor. Es el punto donde un informe de, por ejemplo, un nodo comprometido o un intento de fraude llega a alguien capaz de actuar o no llega. Cuando la dirección es incorrecta, la denuncia se pierde silenciosamente: nadie la recibe, nadie responde y el remitente no tiene forma de saberlo.

Este informe no examina la validez de los datos en la base de datos del RIPE NCC ni los procedimientos de denuncia: lo examinado aquí es la capa de búsqueda, la máquina que decide qué contacto de abuso devolver cuando se le pregunta por una dirección IP, un prefijo o un número de sistema autónomo.

La advertencia del propio endpoint

La documentación oficial de la API de datos de RIPEstat para el Abuse Contact Finder contiene una advertencia notable para un servicio de producción: la información de contacto de abuso devuelta es, en palabras del propio documento, "en muchos casos incorrecta o no está disponible" (en muchos casos incorrect or not available). No es una crítica externa ni un estudio independiente; es la advertencia que el propio registro escribe sobre su propio servicio en la documentación del endpoint.

El endpoint devuelve dos campos principales para la consulta: abuse_contacts, las direcciones de correo de abuso dedicadas asociadas al recurso consultado, y authoritative_rir, el registro al que pertenece el recurso. Ese es el resultado que las herramientas, los panelistas y los remitentes de denuncias automatizadas consumen. La advertencia significa que el registro no garantiza que la dirección devuelta sea correcta en un porcentaje de casos significativo, y que tampoco garantiza que exista.

La calificación retirada: cómo se perdió la incertidumbre

La historia de la herramienta muestra que este problema no es nuevo y que en su día se intentó hacerlo visible. En su encarnación heurística anterior, el Abuse Contact Finder de RIPEstat mostraba una calificación de fiabilidad de cinco estrellas: cinco estrellas indicaban un abuse-c conforme al documento RIPE 563 en la propia IP consultada; cuatro, un abuse-mailbox en un objeto relacionado; tres, un contacto hallado solo en campos de comentarios; dos, un abuse-mailbox tomado de un objeto más específico o de un operador de tránsito, con la advertencia explícita de que podía no ser el contacto correcto; y una estrella, un contacto "bastante improbable" correcto (RIPE Labs).

Esa escala comunicaba la incertidumbre de cada resultado al usuario. Desde 2015 ya no lo hace: el servicio retiró las heurísticas de calificación y desde entonces muestra únicamente la dirección de abuse-c tal y como está especificada en RIPE 563. El resultado es una única dirección sin cualificar. La incertidumbre no desapareció; dejó de ser visible y hoy solo subsiste en la advertencia de la documentación de la API.

En la misma página de RIPE Labs, una respuesta del personal del RIPE NCC reconocía que "no había ningún procedimiento en marcha para que los usuarios, y respectivamente el RIPE NCC, corrigieran o validaran los contactos de abuso" proporcionados por los titulares de recursos. Las causas documentadas de contactos erróneos incluían erratas, problemas técnicos del lado del destinatario y buzones que no se mantienen ni se leen.

Cómo decide la capa de búsqueda

La mecánica de la búsqueda está documentada. Tras la introducción del atributo abuse-c en RIPE 563, la búsqueda funciona de abajo hacia arriba: busca referencias abuse-c: en los objetos ORGANISATION vinculados desde los objetos INET(6)NUM y devuelve la primera que encuentra. Si se encuentra cualquier referencia abuse-c:, los atributos legacy abuse-mailbox: ni siquiera se consideran (RIPE Labs, actualización sobre la implementación de RIPE 563).

El propio predecesor heurístico fue descrito en la misma fuente como algo que "solo podía dar una sugerencia de mejor esfuerzo" y que "resultó ser poco fiable y controvertido". El RIPE NCC también advirtió en aquella época contra consultar directamente la base de datos y enviar en masa correos a todas las direcciones encontradas, práctica que calificó de contraproducente.

La era heurística dejó errores documentados. Según las notas de actualización de las heurísticas del servicio, un error hizo que la herramienta devolviera con frecuencia e incorrectamente la dirección de abuso genérica del registro, porque los datos de marcador de posición de la base de datos contenían esa dirección; otro error devolvía resultados no relacionados con la entrada, porque las claves primarias e indexadas no son únicas entre los distintos tipos de objeto (RIPE Labs, heurísticas actualizadas). El primer error es particularmente ilustrativo: el destino falso era la propia dirección de abuso del registro, lo que significaba que denuncias legítimas podían acabar en el buzón del registro en lugar del buzón del operador culpable.

Qué cubre el atributo y qué devuelve la base de datos

La documentación de la base de datos del RIPE describe la estructura que la búsqueda recorre: abuse-c: es un atributo en el objeto de organización que hace referencia a un objeto de rol que debe contener un atributo abuse-mailbox:; cualquier inetnum, inet6num o aut-num que haga referencia a esa organización queda cubierto por esa dirección de abuso; y si no se encuentra ningún contacto de abuso en los objetos que abarcan, no se devuelve ningún resultado (documentación de la base de datos). La misma documentación advierte que una denuncia no se tramitará más rápidamente por copiar el mensaje a otras direcciones de correo encontradas en la base de datos.

Los datos de fondo: cuántos contactos fallan la validación

La magnitud del problema de datos subyacente quedó registrada en la propuesta de política 2017-02: ripe-563 no preveía ninguna validación de la información abuse-c:, el RIPE NCC recibía varios cientos de informes de información de contacto no válida cada año, y una prueba aleatoria preliminar indicaba que entre el 10 % y el 25 % de los atributos abuse-mailbox podían ser incorrectos o inactivos; la base de datos contenía en torno a 70.000 atributos abuse-mailbox distintos (propuesta 2017-02). La validación automatizada introducida por esa propuesta comprueba la sintaxis, el dominio y la configuración del servidor de correo, y reconoce la posibilidad de falsos negativos y falsos positivos.

Las cifras más recientes disponibles en este periodo provienen de la RIPE 80 (2019): de 77.168 atributos abuse-mailbox distintos, 71.711 (el 93 %) pasaron la validación automatizada y 5.457 (el 7 %) la fallaron; los modos de fallo incluían correos falsos de otra organización, buzones que nunca se leen, buzones llenos o que rechazan el correo, y empleados inexistentes (presentación de la RIPE 80).

La validación, sin embargo, tiene un límite estructural: comprueba solo que existe un correo funcional y que un servidor de correo puede aceptar mensajes. Como lo expresó el propio registro, "no tenemos nada que decir sobre lo que los operadores de red hacen con las denuncias de abuso que reciben"; una dirección de abuso válida no garantiza el destino correcto o eficaz (RIPE Labs, validación de abuse-c).

La lectura estructural

Ensamblados, estos hechos describen una capa de búsqueda que hereda una elección estructural del registro: devuelve el abuse-c más específico presente en la base de datos, no necesariamente el operador capaz de actuar sobre la denuncia. Su exactitud no se ha medido de forma independiente desde 2015; la calificación que una vez hacía visible la incertidumbre fue retirada y lo que queda es una única dirección sin cualificar acompañada de una advertencia a nivel de API. El riesgo de desvío incorrecto se concentra donde la jerarquía de la base de datos, los datos legacy y los artefactos de marcador de posición se encuentran.

La orientación pública del RIPE NCC es coherente con este cuadro: al introducir una dirección IP en RIPEstat se muestra el contacto de abuso de la red a la que pertenece la IP, "un ISP u otro operador de red, ¡no el abusador!", y se invita a los usuarios a informar de contactos de abuso no válidos o ausentes al RIPE NCC (orientación del RIPE NCC). Es decir: el resultado de la búsqueda es, por diseño, el contacto de la red, y el registro ofrece un canal para corregir el dato cuando es evidentemente erróneo. Lo que queda sin documentar es la corrección de un contacto que es válido pero incorrecto.

Qué significa para los remitentes de denuncias

Para cualquier equipo que automatice el envío de denuncias de abuso, la conclusión práctica es triple. Primero, el contacto devuelto por una API o un panel debe tratarse como el contacto de la red consultada, no como el contacto del responsable del abuso. Segundo, la ausencia de calificación desde 2015 significa que la herramienta ya no comunica cuán incierta es una dirección concreta; esa incertidumbre solo se documenta de forma agregada.

Tercero, la única comprobación que el registro garantiza es la deliverabilidad del correo, no la idoneidad del destinatario: un 93 % de aprobación en la validación de 2019 mide buzones que aceptan correo, no buzones que leen y actúan sobre lo que reciben.