Summary

  • The official RIPEstat documentation warns that the abuse contact returned by the Abuse Contact Finder is "in many cases incorrect or not available" — the tool's own accuracy caveat, in the registry's words.
  • The lookup works bottom-up: it returns the first abuse-c found in the organisation objects linked from the covering INET(6)NUM, ignoring legacy abuse-mailbox attributes whenever any abuse-c exists.
  • The confidence rating that once told users how likely the returned contact was to be correct — five stars down to one — was retired in 2015, leaving a single unqualified address behind an API-level disclaimer.
  • Documented failure modes include a heuristic-era bug that frequently returned the registry's own placeholder address, and a database design in which roughly 30–150 separate queries per lookup once climbed a hierarchy of non-unique keys.
  • Accuracy has not been publicly measured since the rating's retirement; the RIPE NCC at one point acknowledged there was no procedure to correct a wrong-but-valid contact.

The Abuse Contact Finder exists because of a simple design choice. When the abuse-c attribute was made the canonical abuse contact under RIPE-563, the RIPE NCC committed its lookup tools to returning exactly what the database records — nothing more, nothing less. Per the registry's own description of the implementation, the tools "work from the bottom up looking for abuse-c: references in ORGANISATION objects linked from the INET(6)NUM objects. The first one found is returned"; when any abuse-c reference exists, the legacy abuse-mailbox attributes are not considered at all.

The database hierarchy means the most specific covering object wins, so a query for a specific IP is answered by the abuse-c on the organisation linked to that covering range — the network the IP belongs to, not the abuser, as the RIPE NCC's public guidance puts it. That distinction matters: a victim of a phishing campaign hosted inside a large provider is routed to the provider's abuse desk, correctly by design; but a victim routed to the wrong covering organisation's desk is routed to an operator who has no power over the offending network at all.

What the tool returns is therefore an expression of database state, not of verified correctness. The current endpoint documentation is unusually blunt about this: "The main purpose of this endpoint is to return abuse contact informations for a Internet number resource. Note that this information is in many cases incorrect or not available." The endpoint returns a list of dedicated abuse email addresses and the authoritative RIR for the queried resource — and disclaims the accuracy of the first in the same sentence that describes it.

That disclaimer is the residue of an earlier, more honest interface.

Before 2015, the RIPEstat Abuse Contact Finder scored its own results on a five-star scale, and the scoring logic documented in RIPE Labs is a taxonomy of doubt: five stars meant an abuse-c attribute conforming to RIPE-563 on the queried object, the case the policy deems correct; four stars meant an abuse-mailbox in a related object; three stars meant contact details found only in remarks; two stars meant an abuse-mailbox inherited from a more specific or upstream object that "may not be the correct contact"; one star meant the returned address was "quite unlikely" to be correct.

Since 2015, an editorial note records, "the RIPEstat Abuse Contact Finder does not provide rating heuristics anymore. It only shows the abuse-c e-mail address as specified in RIPE Document 563." The uncertainty the rating surfaced did not disappear; it was moved out of the interface and into a blanket caveat most users never read.

The pre-563 history explains why confidence collapsed into a disclaimer. The heuristic-era Abuse Finder, described in RIPE Labs, could "only give a best effort suggestion of the appropriate abuse contact details", which "proved to be unreliable and contentious".

Its rule chain — resolving the object, chasing IRT references, climbing to ROLE, PERSON and ORGANISATION objects, extracting route and maintainer data, deduplicating, then harvesting abuse-mailboxes and abuse-related remarks — could involve roughly 30 to 150 separate RIPE Database queries per lookup, and two documented bugs showed how that complexity failed in practice: placeholder data caused the tool to "frequently and incorrectly return the registry's own placeholder address", and because primary and indexed keys are not unique across object types, another bug returned results unrelated to the queried resource.

The structural problem the Finder inherits is older than the tool. Policy proposal 2017-02, the basis for today's regular validation, recorded the quantified accuracy problem behind abuse-c: ripe-563 "didn't provide for the validation of abuse-c: contact information", the RIPE NCC received "several hundred reports of invalid contact information each year", and a preliminary random test indicated 10%–25% of the roughly 70,000 distinct abuse-mailbox attributes "might be incorrect or inactive".

The RIPE 80 (2019) presentation later put numbers on the automated regime: of 77,168 distinct abuse-mailbox entries, 71,711 (93%) passed automated validation and 5,457 (7%) failed — and its enumerated failure modes (fake emails from another organization, mailboxes never read, full or bouncing mailboxes, addresses of non-existent employees) are exactly the cases a deliverability check cannot distinguish from a working desk.

Validation, in other words, measures the wrong thing for the lookup layer too. As the RIPE NCC's validation team put it in RIPE Labs: "The nature of our validation is about checking that there is a working email in the RIPE Database and that this corresponds to a working mailserver that can accept emails.

We have no say in what network operators do with any abuse reports they receive." A valid abuse-c is not the correct abuse-c; the validation introduced by 2017-02 itself acknowledges possible false negatives and false positives, and its scope — syntax, domain and mail-server configuration, checked without sending mail — is silent on whether the address even belongs to the right organisation.

The registry's posture on correcting wrong results has also been documented. A RIPE NCC staff reply recorded on the Labs page acknowledged there was "no procedure in place for users respectively the RIPE NCC to correct/validate abuse contacts" supplied by resource holders. Today the NCC offers a reporting path for contacts that are "invalid or missing"; what remains undocumented is a correction procedure for a contact that is wrong but technically valid — the case in which the Finder reliably routes every complaint for a prefix to a mailbox owned by someone who cannot act.

The practical upshot for a complainant is that the Finder's guarantee runs in one direction only. It is authoritative about what the database says, and silent about whether what the database says is right. The registry's own guidance warns against bypassing the tool — querying the RIPE Database directly and "sending abuse complaints to any or all email addresses found" is described as counterproductive, and the Database documentation adds that a complaint "will not be handled any quicker by copying your message to any other e-mail address found in the database".

The complainant is therefore funnelled into a single address whose accuracy is disclaimed upstream and unmeasured downstream.

None of this is a charge of concealment: the registry discloses the caveat in the endpoint's first paragraph, and the retired rating's taxonomy is published. What is missing is measurement. Since 2015 no public figure exists for how often the returned abuse-c is the correct one, and no independent study of routing correctness was located in the public record this report draws on. The Finder answers "where does the database point" with precision, and "does the database point in the right direction" with a shrug. For the communities whose complaints disappear into the gap, the shrug is the finding.