Summary

  • The RIPE NCC's abuse-mailbox enforcement ladder is fully documented: annual validation under RIPE-705, LIR follow-up, and a 30/60/90-day closure sequence under RIPE-858 that ends in SSA termination, record deregistration and RPKI certificate revocation.
  • No published validation report, tracked-report outcome, arbitration request or compliance action certifies whether the Svea abuse-mailbox attribute has ever been validated, found correct or found wanting; a requested RIPE NCC press release on "corrective actions" concerning Svea could not be located in any retrieved source.
  • The RIPE NCC does publish enforcement outcomes in other matters — including a documented termination and five-year membership ban for fraudulent documents — so the publication format exists and simply has not been applied, publicly, to the Svea abuse surface.
  • Published closure counts (29 closures for unresponsiveness in 2024, 3 in 2025) concern general unresponsiveness, not abuse-c-specific enforcement, and must not be read as evidence either for or against Svea-specific action.
  • The Svea record itself is frozen: the person object JE4899-RIPE still carries the dissolved "Svea Ekonomi AB" address with a last-modified date of 2022-04-11, and the legacy block 193.105.138.0/24 routes abuse to a third-party mailbox with a last-modified date of 2021-02-02.

A surface frozen in time

The registry facts frame the enforcement question. AS211899, announced as "SVEA", is registered to the organisation object ORG-SBA155-RIPE — Svea Bank AB, registration number 556158-7634 — sponsored through ORG-TA44-RIPE on the Tele2/SWIPNET side, with the abuse contact set to the role object SEAR1-RIPE, as the third-party registry mirror of the record shows (IPIP.NET mirror of AS211899). The person object behind the AS's administrative and technical contact, JE4899-RIPE for Jorgen Edstrom, still carries an address reading "Svea Ekonomi AB" — a company that ceased to exist as a legal entity when it merged into Svea Bank AB on 3 January 2022 — and the object has not been modified since 11 April 2022 (IPIP.NET mirror of AS211899; BTW, the Svea remedy path).

The legacy address block tells a parallel story. The inetnum 193.105.138.0/24, described as SVEA-EKONOMI-SE, routes abuse contact to a third-party mailbox at abuse[at]se.verizon.com and has not been touched since 2 February 2021 (IPIP.NET mirror of AS211899; BTW, the Svea remedy path). A surface that routes abuse reports for a dissolved company's address block to another company's mailbox is precisely the kind of condition RIPE's abuse-contact policy exists to catch. Whether it was caught is the question the rest of this article examines.

The ladder, as policy defines it

RIPE policy is unusually explicit about what should happen. RIPE-705, "Abuse Contact Management in the RIPE Database", obliges the RIPE NCC to validate the abuse-mailbox attribute at least annually and, where the attribute is deemed incorrect, to follow up "in compliance with relevant RIPE Policies and RIPE NCC procedures" (RIPE-705). Structurally, the abuse-c attribute lives in the organisation object and references a role object that carries the abuse-mailbox; the RIPE NCC began setting abuse-c attributes for allocated resources in 2013 (RIPE NCC, abuse-c information).

The escalation backstop is defined in the closure procedure. RIPE-858, "Closure of Members, Deregistration of Internet Resources and Legacy Internet Resources", sets out what happens when a member violates RIPE policies or procedures: an initial notice carrying a three-month termination threat, a reminder at 30 days, a second at 60 days, and official termination of the Sponsorship Agreement after 90 days. On termination, services stop, number-resource records are deregistered and RPKI certificates are revoked (RIPE-858). Its predecessor RIPE-833, published on 18 October 2024, already established that a member is suspended on receipt of such a notice and that termination follows three months later (RIPE-833).

The policy proposal that created the annual validation regime, 2017-02, supplies the aggregate history. Over five years, it records, the RIPE NCC investigated and resolved more than 1,000 external reports about incorrect abuse-mailbox attributes without ever triggering the closure and deregistration procedure; even once closure is triggered, a holder still has three months to resolve the problem before deregistration (RIPE NCC, Regular abuse-c Validation proposal; alternate policy listing of the same proposal).

What the RIPE NCC's own tooling can and cannot prove

The operational layer was described by the RIPE NCC itself at RIPE 87, in a presentation by Jeremy Walder and Marco Schmidt to the Anti-Abuse Working Group. The abuse-c verification tool checks formatting, DNS and mailbox existence without sending email; a failed test triggers a verification link, a ticket and contact with the sponsoring LIR. Roughly six to eight per cent of abuse contacts fail the test, and around 2,000 contacts are checked weekly. The same presentation notes that if a member remains unresponsive for a long time, membership can be terminated (RIPE 87 AAWG presentation, November 2023).

Note the boundary the tooling itself draws: verification proves a mailbox exists and can receive mail. It never measures whether a delivered report is read, answered or acted on. RIPE's instruments can police the plumbing of the abuse contact, not the behaviour behind it — a limitation BTW's earlier filing-test analysis documented, and one the RIPE NCC has acknowledged in its own framing that it can verify the attribute but cannot compel the operator to respond (BTW, the Svea remedy path).

The record's silence, stated precisely

Against that machinery, what does the public record show for Svea? Three negative findings, each narrower than it may first appear.

First, no published validation report, tracked-report outcome, arbitration request or compliance action certifies whether the Svea abuse-mailbox attribute has been validated, found correct or found wanting (BTW, the Svea remedy path; BTW, RIPE ABUSE: the documented last resort that has not fired). Second, a document titled "RIPE NCC corrective actions Svea" — the kind of press release that would close this gap — could not be located in any source retrieved for this investigation (the requested press-release URL); absence of retrieval is not proof of non-existence, but no evidence of its existence was found either. Third, the SEAR1-RIPE role object's underlying content could not be retrieved from the primary registry through the tools used, and third-party mirrors disagree even on the organisation object's last-modified timestamp (one shows 2022-12-01, others 2026-05-13) and on which contact is displayed as operative (IPIP.NET mirror of AS211899; BTW, the Svea remedy path).

The silence is not an artefact of the RIPE NCC lacking a publication habit. In another matter entirely, the registry published an enforcement outcome in detail: it terminated the membership of a party that had submitted fraudulent documents, imposed a five-year membership ban, reverted unauthorised transfers and reported the fraudulent documents to police (RIPE NCC Registry Investigation Report). The publication format for enforcement exists. It has simply never been applied, publicly, to the Svea abuse-contact surface.

Reading the closure counts without conflation

Two aggregate numbers tempt a careless reader. Published closure counts show 29 closures for unresponsiveness in 2024 and 3 in 2025. These concern general unresponsiveness, not abuse-c-specific enforcement, and per located reporting the closure and deregistration backstop has never been triggered for abuse-mailbox conduct at all (BTW, RIPE ABUSE: the documented last resort that has not fired). Neither figure can be read as evidence that Svea was pursued, and neither can be read as evidence that it was exempted. They belong to a different category of conduct.

What the aggregate record does establish is a pattern: over the five years covered by the 2017-02 proposal, more than 1,000 external reports about incorrect abuse-mailbox attributes were investigated and resolved without a single closure or deregistration (RIPE NCC, Regular abuse-c Validation proposal). The ladder's final rung is documented but, on the available record, unfired for abuse-mailbox conduct anywhere in the registry — which makes the specific question for Svea not "why was Svea punished?" but "where in the ladder, if anywhere, did the Svea case stop?" That question has no published answer.

What a fired ladder would look like

The value of this negative finding lies in what it makes checkable. If any stage of the ladder had fired for Svea, the observable traces would exist: a validation-failure ticket referenced to the sponsoring LIR, an escalation notice under RIPE-858's 30/60/90-day sequence, a suspension note, or — at the end — deregistered records and revoked RPKI certificates. None of these traces is published for Svea. If instead the mechanism has fired silently, that too is now a documented possibility: the public record supports neither conclusion, and prior BTW reporting already recorded that the registry can police whether a mailbox exists but cannot compel the operator behind it to answer reports (BTW, RIPE ABUSE: the documented last resort that has not fired).

Three conditions would move the question from unanswerable to answered. A published validation status for the ORG-SBA155-RIPE abuse-mailbox attribute would show where the annual cycle placed it. A tracked-report outcome for any complaint filed through the RIPE NCC's public channels would show whether the follow-up obligation in RIPE-705 was engaged. A per-case enforcement publication, in the format the Registry Investigation Report already uses for other matters, would show whether any stage of the ladder was reached.

Until one of these appears, the honest description of the Svea abuse-contact surface remains: registered valid, operationally unproven, and — on the public record — never visibly enforced against, and never visibly cleared.