Summary

  • External reports of spam, phishing and other network abuse are, by the RIPE NCC's own published procedure, outside its remit as a registry and are not investigated by it; complainants are routed to the network operator's abuse-contact mailbox instead. https://www.ripe.net/about-us/support/contact/reporting-procedure/
  • The Abuse Contact Finder on RIPEstat points a complainant at the abuse-c mailbox of the network an IP belongs to, and the RIPE NCC states plainly that if that operator does not reply, "there is nothing we can do." https://www.ripe.net/languages/en/abuse/
  • On 7 May 2026, the RIPE NCC revised its closure procedure (RIPE-858) to remove postal-mail reminders from the enforcement path, leaving email as the sole notification channel. The institution attributes the change to cost, undeliverability and the legal sufficiency of email. https://www.ripe.net/publications/docs/ripe-858/
  • The documented remedy at registry level — closure of a member and deregistration of resources, with a three-month cure window — has never been publicly triggered through abuse-reporting: over five years, more than 1,000 external reports on incorrect abuse-mailbox attributes were resolved without activating it. https://www.ripe.net/community/policies/proposals/2017-02/
  • No independent, non-operator evidence in the public record corroborates complaint outcomes at the mailbox level; the accountability chain ends where the report is delivered.

The instinct of anyone harmed by abuse originating in a network is to report it to someone with power. In the RIPE service region — Europe, the Middle East and parts of Central Asia — that instinct runs into a routing rule that surprises most complainants: the regional internet registry that publishes the abuse contact will not take the report.

The RIPE NCC's reporting procedure is explicit. "Reports of spam, phishing and other types of network abuse from outside the RIPE NCC network do not fall under the RIPE NCC's responsibilities as a Registry and as such will not be considered for investigation," the institution's own page states. What the NCC does process are complaints about Internet number resource registrations; disputes between members or with the NCC itself are directed to the Arbiters Panel under the Conflict Arbitration Procedure. https://www.ripe.net/about-us/support/contact/reporting-procedure/

Where, then, does a complainant go? To the same institution's guidance for end users, which supplies the second half of the routing rule. The Abuse Contact Finder, built on RIPEstat, returns the abuse contact of the network an IP address belongs to — that is, the operator, not the abuser. The complainant is instructed to email that contact with details including the IP address and the time of the abuse. The RIPE NCC describes its own role in terms that leave no ambiguity: "Our role is to ensure that all abuse contacts are valid and up-to-date in the RIPE Database. From there, it is the responsibility of the network operator to handle your abuse report. There is nothing we can do if a network operator chooses not to reply." https://www.ripe.net/languages/en/abuse/

This is the boundary this report examines: a report that never reaches the registry, a duty to respond that sits entirely with the reported party, and a validation regime that measures whether the mailbox exists — not whether anyone reads it.

The object model that makes the routing possible

The routing rule depends on a database convention created in policy. RIPE-705, the outcome of policy proposal 2017-02, introduced the mandatory abuse-c attribute into inetnum, inet6num and aut-num objects. The abuse-c references a role object that must contain a single abuse-mailbox attribute, "intended for receiving automatic and manual reports about abusive behavior originating in the resource holders' networks." The same policy mandates that the RIPE NCC validate that mailbox at least annually and follow up where it is incorrect. https://www.ripe.net/publications/docs/ripe-705/ https://www.ripe.net/community/policies/proposals/2017-02/

Read together, the two documents define the entire institutional role: the registry guarantees the existence and reachability of the mailbox; everything that happens inside the mailbox belongs to the resource holder. Validation is a measurement function, not an intake function.

What validation does when the mailbox fails

The operational mechanics are documented by RIPE NCC staff on RIPE Labs. Validation proceeds in order over LIR organisation objects, then LIR resource objects, then End User (sponsored) objects. When a mailbox fails, automated emails give the LIR roughly three weeks to act; staff then intervene manually, starting with contacts in the LIR Portal and broadening their search if necessary. Two further reminders are sent at one-week intervals, and staff take over one week after the final reminder. https://labs.ripe.net/author/angela_dallara/how-we-will-be-following-up-with-invalid-abuse-contacts/ https://labs.ripe.net/author/angela_dallara/abuse-c-validation-update-on-progress-and-some-numbers/

The consequence ladder is deliberately asymmetric. For LIR organisation objects, unresponsiveness can escalate toward member closure and resource deregistration — with the resource holder given a further three months to remediate before termination takes effect. For LIR resource objects and End User objects, the NCC will not terminate anything; it adds a comment to the RIPE Database noting that the abuse contact failed validation, with a link directing users to the responsible LIR. https://labs.ripe.net/author/angela_dallara/how-we-will-be-following-up-with-invalid-abuse-contacts/

The 2017-02 proposal adds the historical record: the RIPE NCC treats closure and deregistration as "a last resort, to be used only when there is no other way to have the incorrect attribute fixed," and over five years it investigated and resolved more than 1,000 external reports on incorrect abuse-mailbox attributes without ever triggering the closure and deregistration procedure. https://www.ripe.net/community/policies/proposals/2017-02/

The May 2026 delta: one notification channel fewer

On 7 May 2026, the RIPE NCC published a revised version of RIPE-858, "Closure of Members, Deregistration of Internet Resources and Legacy Internet Resources." Section A of that document covers termination of the Standard Service Agreement leading to member closure; Section B covers deregistration of Internet number resources; Section C covers termination of a Legacy Services Agreement. Upon SSA termination, the NCC stops services, deregisters the relevant resource records and revokes RPKI certificates; legacy Internet resources are treated separately and are not automatically deregistered. https://www.ripe.net/publications/docs/ripe-858/

A same-day announcement to the ncc-services-wg mailing list by RIPE NCC legal counsel Theodoros Fyllaridis documents precisely what changed. Section 1.2.1.1 ("Violation of RIPE Policies and RIPE NCC Procedures," sub-section "Procedure") was amended by deleting "and a reminder by postal mail" and "email and." Section 1.2.2 ("Termination with Immediate Effect"), clause 1.2.2.c — covering a member's failure to submit a valid Commercial Trade Register extract — was amended by deleting "and a notification by postal mail" and "and postal." The stated rationale: postal mail was inefficient, often failed to reach its destination, and created significant cost and administrative workload, "since email is legally binding, and members remain responsible for keeping their contact details up to date in accordance with the SSA." https://www.ripe.net/publications/docs/ripe-858/

The substantive escalation outcomes are stated to be unchanged. What changed is the notice surface: a member now faces the most severe documented sanction in the abuse-contact regime with email as the only channel through which the escalating warnings arrive. For an institution whose entire accountability role in this domain is premised on mailboxes existing and being read, the symmetry is at least ironic, and at most material: the registry relies on the same single-channel assumption for its own enforcement notices that it cannot verify for anyone else's.

The accountability gap that remains

Three features of this control surface deserve to be named together.

First, the complainant has no registry-level recourse. The report is delivered to the party complained about; if that party ignores it, the NCC's published position is that it can do nothing. https://www.ripe.net/languages/en/abuse/

Second, the validation regime measures delivery, not response. A mailbox that exists, is current and auto-files every complaint as unread passes every check the NCC runs. https://www.ripe.net/publications/docs/ripe-705/ https://labs.ripe.net/author/angela_dallara/how-we-will-be-following-up-with-invalid-abuse-contacts/

Third, the evidence base is entirely operator-reported. Every number in this chain — 2,320 validation investigations and 86,959 validated addresses in 2025, the 1,000-plus external reports resolved over five years, the never-triggered closure — originates with the institution itself or its staff. No independent, non-operator source in the public record corroborates what happens to complaints at the mailbox level, whether postal reminders ever produced notice that email did not, or any case-level resolution data. https://www.ripe.net/publications/docs/ripe-858/ https://www.ripe.net/community/policies/proposals/2017-02/ https://labs.ripe.net/author/angela_dallara/abuse-c-validation-update-on-progress-and-some-numbers/

That absence is not proof of failure. It is proof that the reporting party's experience — the only part of this system a victim of abuse directly touches — is unaudited by anyone outside the operator community.