Summary

  • Abuse-contact accountability in the RIPE region rests on a maintenance chain — resource holder, sponsoring LIR, and the RIPE NCC as fallback setter — that was designed in 2011–2013 and has never been re-examined as a chain.
  • The registry itself created thousands of placeholder abuse contacts, first from member-list email addresses (from December 2013) and then from sponsoring LIR contacts (from November 2014), while simultaneously stating that the policy is "difficult to enforce" because abuse-c is not a mandatory attribute in the database schema.
  • Customer role objects in reseller chains may reference no person objects at all, are publicly queryable without limits, and are treated as business data — meaning the named custodian of complaints can be a bare administrative artefact.
  • Quantified validation outcomes are the registry's own figures: around 90,000 distinct abuse-c contacts with roughly 2,000 weekly verification emails and a 6–8% failure rate (RIPE 87, 2024), against a first complete round in 2019 in which 5,457 of 77,168 distinct abuse-mailbox attributes (7%) failed automated validation.
  • The public record documents who fixed invalid mailboxes in aggregate, but not who answered for any individual complaint that died in a placeholder mailbox.

The attribute that carries the complaint

When a person reports spam, phishing or a botnet node whose address space sits inside the RIPE NCC service region, the routing of that report is decided by an attribute in a registry database. The policy that built this system, accepted as proposal 2011-06 and implemented through ripe-563 and its current revision ripe-705, requires every autonomous system number and every directly allocated or assigned IP prefix to reference an abuse contact. The reference points to a role object containing an abuse-mailbox: attribute, and that mailbox address is protected: while any resource object references the role, the abuse-mailbox attribute cannot simply be removed https://www.ripe.net/community/policies/proposals/2011-06/.

The design intent was straightforward: put a named, reachable complaint destination on every routed resource, make it publicly queryable, and make the responsible party maintain it. What the primary documents show, when read as a chain rather than as individual rules, is that the maintenance obligation was distributed across three parties with different incentives and different visibility — and that the registry itself, in the years when holders did not act, quietly became the largest initial creator of the very placeholders the system was meant to prevent.

Who the policy says is responsible

The current policy document, ripe-705, assigns the duty clearly: members must maintain correct contact information, including abuse contacts, and the RIPE NCC validates the abuse-mailbox attribute at least annually, following up where it is deemed incorrect https://www.ripe.net/publications/docs/ripe-705/. For provider-independent resources and customer assignments, the duty runs through the sponsoring LIR. The RIPE NCC's own FAQ for setting an abuse contact on an assignment states that in most cases the LIR maintains the assignment objects for its customers and must add the organisation reference itself; if the customer has no role object, a new one is created https://www.ripe.net/manage-ips-and-asns/resource-management/faqs-for-abuse-c/how-do-i-set-abuse-c-for-an-assignment-pa-created-out-of-my-allocation/.

That FAQ also contains the detail that matters most for accountability. A customer's abuse role object "does not need to reference any person objects", is public with no query limits, and all information it contains is assumed to be business data rather than personal data https://www.ripe.net/manage-ips-and-asns/resource-management/faqs-for-abuse-c/how-do-i-set-abuse-c-for-an-assignment-pa-created-out-of-my-allocation/. In other words, the registry's data model explicitly permits a complaint destination that is attached to no human being at all — an artefact that exists to satisfy a policy check rather than to receive and process a report. This is not a malfunction of the system. It is the system working as specified.

The registry as placeholder creator

The history of implementation shows how widespread such artefacts became. According to the RIPE NCC's implementation notes and its RIPE Labs write-up, Phase 1 of the abuse-c rollout completed in December 2013: for allocated resources whose LIRs had not set their own abuse contact, the NCC automatically inserted the LIR's publicly listed email address from the membership list as the abuse contact. In Phase 2, completed in November 2014, the NCC added the sponsoring LIR's abuse contact to organisation objects of sponsored resources that maintainers had not updated https://www.ripe.net/publications/docs/ripe-563/ https://labs.ripe.net/author/kranjbar/ripe-563-improving-abuse-contact-information-in-the-ripe-database/.

These were placeholders by design, and their problems were foreseeable. In a January 2016 anti-abuse working group thread, RIPE NCC staff laid them out: end users had little incentive to maintain a contact that pointed at their sponsor's mailbox; LIRs were, in the NCC's own characterisation, "unpleasantly surprised" to find their email listed as the abuse contact for organisations they sponsored; and stale sponsor references were not being cleaned up. The same thread contains the sentence that should anchor any audit of this regime: "In practice it has proven difficult to enforce this, since abuse-c is not a mandatory attribute in the RIPE DB schema" the January 2016 anti-abuse working group thread.

That admission identifies a structural gap between the policy and the enforcement instrument. The policy documents describe the abuse-c as mandatory for aut-numbers and direct allocations; the database schema does not enforce it, and new organisations without any abuse contact continued to appear after the phases completed. The NCC's remedy was procedural rather than structural: since 1 March 2016, a new LIR activation automatically creates an abuse contact that the LIR may modify but not remove the January 2016 anti-abuse working group thread.

What validation measures, and what it found

The community recognised the placeholder problem in quantified terms. Policy proposal 2017-02 recorded that ripe-563 had provided no validation mechanism at all, that abuse-c information "can often be out of date or inaccurate", that the NCC received several hundred reports of invalid contact information each year, and that a preliminary random-batch test suggested 10–25% of the roughly 70,000 distinct abuse-mailbox attributes then in the database might be incorrect or inactive. The proposal was accepted in June 2018 and created the annual validation regime https://www.ripe.net/community/policies/proposals/2017-02/.

The first complete validation round reported its results at RIPE 80 in 2019: of 77,168 distinct abuse-mailbox attributes, 71,711 — 93% — passed automated validation, and 5,457 — 7% — failed. Around 8,000 attributes were updated that year. Crucially, the same presentation stated the boundary of the exercise in plain terms: the policy does not provide sufficient validation of the actual availability of the abuse-mailbox, and the policy intent is not to look into how the mailbox is monitored or how cases are handled https://ripe80.ripe.net/wp-content/uploads/presentations/41-ripe80-2019-04v3.pdf.

By RIPE 87 in 2024, the registry's Registration Services described a larger estate: around 90,000 distinct abuse-c contacts, split roughly into 20,000 in LIR organisation objects, 58,000 in resource objects and 15,000 in independent resource objects. Annual verification divides into roughly 2,000 emails per week, of which "around 6 to 8%" fail — with the caveat, given in the same transcript, that a failing test does not necessarily mean the contact is broken; some failures are timeouts that resolve on the next automated run https://ripe87.ripe.net/archives/steno/29/.

The mechanics of the check have not changed in kind since 2019. An external verification tool checks the address format, verifies DNS entries, and tests that the mailbox exists and accepts mail; no email is sent when verification succeeds. On failure, a verification link goes to the abuse-c address, a ticket is opened at the NCC, and the responsible or sponsoring LIR is contacted — first automatically, then by staff https://ripe87.ripe.net/wp-content/uploads/presentations/72-RIPE87-AAWG-final.pdf. For resource and independent-resource contacts where the responsible person cannot be reached, the NCC's documented practice is to replace the email with the working abuse contact of the LIR or sponsoring LIR https://ripe87.ripe.net/archives/steno/29/.

The accountability question the numbers do not answer

Read together, these figures describe a system that successfully tests whether a mailbox exists. They do not describe, and were not designed to describe, whether anyone reads what arrives. The RIPE 80 presentation says so explicitly; the RIPE 87 transcript presents the status quo as a starting point for community discussion rather than an evaluation of it. What the public record documents, in aggregate, is who corrected invalid mailboxes once validation flagged them.

What it does not document is who answered — in any individual case — for a complaint that was correctly delivered to a placeholder mailbox that existed precisely because no holder had ever claimed it.

The maintenance chain resolves responsibility upward but not outward. A complaint reaching a bare customer role object is the customer's responsibility by policy and the LIR's responsibility by maintenance practice; if both are silent, the NCC's remedy is to repoint the contact to a working mailbox, not to establish that any complaint sent to the dead one was ever processed.

The 2019 proposal 2019-04, which would have tested the actual functioning of abuse contacts, was withdrawn after community discussion of its cost — a decision already examined in prior reporting and consistent with the pattern documented here: the regime measures what is cheap to measure and stops where enforcement would require judging human response.

What a durable fix would have to prove

The structural finding is not that the RIPE NCC neglected abuse contacts. It is that the accountability model was built around a placeholder-creating registry, a schema that does not enforce its own policy, and a validation regime that by stated intent excludes the question complainants actually ask.

Any repair that deserves the name would have to make three things provable from the outside: that every abuse-c role object references a party who has accepted complaint-handling responsibility; that response, not deliverability, is the tested property; and that the history of repointed and replaced contacts is itself public, so that the destinations of dead complaints can be reconstructed by the people who sent them.

Sources

The primary documents reconstructed above are: proposal 2011-06, ripe-563, ripe-705, the RIPE NCC abuse-c implementation page, the RIPE Labs implementation write-up, the RIPE Labs validation post, the January 2016 anti-abuse working group thread, the anti-abuse working group thread on placeholder replacement, proposal 2017-02, proposal 2019-04, the RIPE 80 validation presentation, the RIPE 87 transcript, the RIPE 87 AAWG presentation, the RIPE NCC abuse-c FAQ, the FAQ on setting abuse-c for an assignment, ripe-658, the RIPE Database object-organisation guide, the secondary object descriptions, the WHEREIS study abstract, the WHEREIS study PDF and the NANOG discussion of abuse-contact failures.