Summary

  • The Abuse Contact Finder turns a prefix, IP address or ASN into the abuse mailbox a reporter should write to, plus the RIR that is authoritative for the resource; its own documentation warns that the underlying data "is in many cases incorrect or not available".
  • Validation under RIPE policy 2017-02 confirms formatting, DNS entries and — by ping — that a mailbox exists and can accept mail. It sends no email, and the withdrawn 2019-04 proposal said its process "will not check how the abuse cases are processed".
  • Independent measurements of what follows a report — a 480-report experiment and a 2026 inside-provider study — find low human response rates and mitigation that depends on who reports and what the abuse is. They belong beside the registry's 93% pass figure, not instead of it.

From a resource to a mailbox

The endpoint takes one input — a prefix, a single IP address or an autonomous system number — and returns two things a reporter needs: abuse_contacts, the email addresses to write to, and authoritative_rir, which identifies the registry responsible for the resource (Abuse Contact Finder documentation). Its value is orientation: it turns an address seen in a log into a place to send a complaint. The same documentation publishes the caveat that matters later — the information it returns "is in many cases incorrect or not available".

The RIPE community treats the selected address as the preferred channel. RIPE-658, written for CERTs and abuse handlers, lists the RIPE Database and RIPEstat's abuse-contact tools among the ways to find the best matching abuse contact for a resource, and describes abuse-c as "the preferred way to report any form of abuse", following the RIPE policy on abuse contact management in the database (RIPE-658). The RIPEstat widget, which since 2015 shows only the abuse-c address under ripe-563, is explicit about the workflow and even suggests wording a reporter can append to an email noting how the contact was found (RIPE Labs: Finding Abuse Contact Information with RIPEstat).

National incident-response practice assumes the same path. CSIRT.CZ's incident-reporting guidance tells reporters to establish which organisation is responsible for an address through RIR databases, send the report to the registered abuse contact, and escalate to the CSIRT only when no reasonable response arrives within several days (CSIRT.CZ incident-reporting FAQ). The lookup is step one; escalation is the fallback when the mailbox produces nothing.

What validation measures

How far the registry's responsibility extends is stated by the registry itself. RIPE NCC guidance tells users to read the abuse contact for a network in RIPEstat and is direct about the division of labour: the network operator, not the RIPE NCC, handles the abuse report; the NCC's role is to keep contacts valid and up to date; and "There is nothing we can do if a network operator chooses not to reply" (RIPE NCC abuse guidance). The validation method that supports the database follows that boundary. Under policy 2017-02, the NCC checks abuse-mailbox attributes for formatting errors, verifies DNS entries, looks for bogus or honeypot addresses and uses ping to confirm that the mailbox exists and can accept mail. It sends no test email, requires no action when validation passes, and treats legacy resources as outside the policy. The same account records: "We have no say in what network operators do with any abuse reports they receive" (How we will be validating abuse-c).

That method has been applied at scale, and the results are public. The implementation summary for 2017-02 reports 77,168 distinct abuse-mailbox attributes, of which 71,711 — 93% — passed automated validation and 5,457 failed. Consensus was reached on 1 June 2018 and implementation completed on 10 October 2019; about 8,000 attributes were updated during 2019, initial validation required three temporary full-time staff, and 20–25% of tickets needed manual follow-up (RIPE 79 implementation summary). A progress update in May 2019 had reported about 9,500 abuse contacts updated out of about 67,000 checked, a count that explicitly includes duplicates, with roughly 60% of cases resolved without NCC staff intervention and about 50 independent resources changing sponsorship status (RIPE Labs: Abuse-c validation update).

The community then debated how often to repeat the check. Proposal 2019-04 would have revalidated whether an abuse-mailbox is present and able to receive messages at least every six months. Its own text drew the line that matters here: "This validation process will not check how the abuse cases are processed." The NCC's impact analysis estimated that a six-monthly regime over roughly 93,000 distinct attributes would need more than 32,000 tickets per round — 64,000 a year — with about 19,200 manual tickets annually. The proposal was withdrawn on 8 September 2020, and on 26 October 2020 the Working Group Chairs Collective upheld the Anti-Abuse Working Group co-chairs' decision after an appeal (Proposal 2019-04).

By RIPE 87 in 2023 the process had settled into a recurring cycle. The NCC reported annual validation covering about 19,600 contacts in LIR organisation objects, 58,100 in LIR resource objects and 15,400 in independent resource objects, with around 2,000 contacts checked weekly and a persistent 6–8% failure rate. An invalid abuse-c in a resource object is replaced by a working LIR abuse-c; an invalid LIR abuse-c triggers extensive investigation; a member that stays unresponsive for a long time can have its membership terminated; and an ASN cleanup that contacted more than 4,000 ASN holders recovered about 2,150 — 54% (RIPE 87 Anti-Abuse Working Group update).

The half that stays unmeasured

What those figures do not describe is what happens once a complaint lands. Independent experiments have tried to measure that, and the results complicate any simple reading. A randomized controlled experiment that sent 480 abuse reports to hosting providers and website owners received 89 email responses, of which 11 — 12% — were clearly human and 78 — 88% — machine-generated. Many noticed parties did not reply but still remediated, so silence does not equal inaction, and more detailed reports significantly increased cleanup rates (Journal of Cybersecurity: sender reputation in abuse reporting). A 2026 NDSS study working from a hosting provider's internal abuse data found that whether a report leads to client notification or mitigation depends heavily on who is reporting and what the abuse is: CSAM and spam-related reports led to mitigating action, while copyright-infringement and port-scanning reports were often neglected, and ordinary individual reporting was often easily ignored (Tickets to Hide, NDSS 2026).

Both studies concern hosting providers and DNS or web abuse rather than abuse-c mailboxes specifically; they bound the registry's reachability metric from outside rather than measure it directly. That is the point. "Exists and accepts mail" is a precondition for a report being handled, and it is the part of the chain that can be verified cheaply, repeatedly and at scale. A 93% pass rate, or a recurring 6–8% failure, describes routing, not responsiveness.

A reporter who follows CSIRT.CZ-style practice and receives no answer has exhausted the registry's mechanism and moved to escalation — while the registry's records continue to show a working mailbox.

Two questions stay open in the public record. First, it does not show whether the ultimate sanction — membership termination for persistent unresponsiveness — has ever been used against a member. Second, and more consequential, no public measurement that samples abuse-c addresses specifically establishes whether a report produces a human decision, a repair, or neither. The boundary is stated rather than hidden — validation "will not check how the abuse cases are processed" — but it means coverage figures should be read as a statement about mailboxes, not about networks. The subject is tracked in the RIPEstat Abuse Contact Finder directory entry.