Summary

  • The legacy Svea netblock 193.105.138.0/24 displays a mailbox on a Verizon domain as its abuse contact on multiple independent mirrors, while its own registry abuse-c handle is AR23510-RIPE.
  • The same Verizon-domain mailbox is displayed for unrelated holders including Moore Europe Capital Management, IP-Only Networks AB and Rackspace Ltd., indicating a broadly inherited carrier-era contact rather than a Svea-specific channel.
  • RIPE policy 2017-02 (ripe-705) requires annual abuse-mailbox validation, but the validation is a technical deliverability check only — it never sends mail and never certifies that anyone reads what arrives.
  • No public source located for this briefing demonstrates that any Svea or Verizon abuse mailbox is staffed, monitored, or responds to reports.

The registry facts first. AS211899 (as-name SVEA) is registered to ORG-SBA155-RIPE, Svea Bank AB, registration number 556158-7634, with abuse-c handle SEAR1-RIPE and admin-c/tech-c JE4899-RIPE — Jorgen Edstrom, whose person record still carries the address of the dissolved Svea Ekonomi AB [http://whois.ipip.net/AS211899]. The routed prefix 193.105.138.0 - 193.105.138.255, netname SVEA-EKONOMI-SE, descr "Svea Ekonomi AB", status ASSIGNED PI, was created 2010-02-18 and last modified 2021-02-02. It is registered to ORG-SBSA5-RIPE (Svea Billing Services AB) with abuse-c AR23510-RIPE, maintained via SWIPNET-LIR-MNT and sponsored by ORG-TA44-RIPE (Tele2) [http://whois.ipip.net/AS211899/193.105.138.0/24]. Yet the rendered "% Abuse contact" line on that object is a mailbox on the se.verizon.com domain — an address on a different party's domain than the object's own abuse-c handle. IPinfo independently shows the same abuse contact for the range [https://ipinfo.io/AS211899/193.105.138.0/24].

The operational significance comes from what the same mailbox does elsewhere. The identical Verizon-domain address is rendered as the abuse contact for 195.95.143.0/24 (Moore Europe Capital Management), which carries a notify address on the same Verizon Business domain [https://whois.ipip.net/AS22775/195.95.143.0/24], for 193.43.151.0/24 (IP-Only Networks AB, AS12552) [https://whoismind.com/ips/193.43.151.0/24], and for 193.142.244.0/24 (Rackspace Ltd., AS15395) [https://whoismind.com/ips/193.142.244.0/24]. A mailbox displayed for a Swedish bank, a UK financial firm, a Swedish ISP and a UK hosting company across the same RIPE region is not a channel any one of them chose; it is a carrier-era default inherited through the UUNET/MCI-to-Verizon-Business lineage. The se.verizon.com domain still resolves on ns.emea.verizonbusiness.com and the legacy auth200/210.ns.uu.net nameservers [https://whoisfreaks.com/tools/dns/lookup/se.verizon.com], which is why validation can pass: the domain and mail servers are technically configured.

That is precisely what RIPE's enforcement regime checks. Policy 2017-02, implemented in ripe-705, requires abuse-mailbox attributes to be validated at least annually [https://www.ripe.net/publications/docs/ripe-705/], [https://www.ripe.net/community/policies/proposals/2017-02/] and [https://www.ripe.net/manage-ips-and-asns/resource-management/policy-implementation-status/policy-implementation-archive/2017-02-regular-abuse-c-validation/]. RIPE NCC's own documentation of the validation mechanism describes checks on syntax, DNS and mail-server configuration; it does not send mail to the mailbox and does not and cannot certify that reports are read or acted on [https://labs.ripe.net/author/angela_dallara/how-we-will-be-validating-abuse-c/]. The RIPE87 Abuse Working Group materials make the same boundary explicit: the registry certifies reachability, not responsiveness [https://ripe87.ripe.net/wp-content/uploads/presentations/72-RIPE87-AAWG-final.pdf]. The same surface is exposed by the RIPEstat abuse-contact finder [https://stat.ripe.net/widget/abuse-contact-finder]; cross-checks against an unrelated IPv6 whois record [https://bash.ws/whois/2a00:801:212:bf71:c526:ec18:36bd:4775], the AS39651 mirror [http://whois.ipip.net/AS39651], the UUNET-to-Verizon lineage [https://en.wikipedia.org/wiki/UUNET] and Tele2's construction of Sweden's internet [https://www.tele2.com/about/our-history/our-stories/theres-no-question-about-it-tele2-built-internet-in-sweden/] situate this contact in its carrier-era context.

For a reporter or a board assessing this surface, the practical consequence is an asymmetry: a validator can return "valid" for a mailbox that no human being has read for years. The netblock's displayed contact is a third party's legacy default; the object's own abuse-c handles (SEAR1-RIPE at the AS level, AR23510-RIPE at the netblock level) were not retrievable in full from public mirrors checked for this briefing [http://whois.ipip.net/AS211899/193.105.138.0/24] and [http://whois.ipip.net/AS211899]; and the maintainer chain points to Tele2's SWIP-RIPE role rather than to either the Verizon domain or Svea itself. None of this proves that any mailbox is dead. It proves that the public record cannot distinguish a functioning abuse-handling function from an unmonitored registry pointer — and that the validation regime, by design, does not close that gap.

The only accountability that demonstrably fired against Svea Bank AB came from a channel entirely outside this surface: Finansinspektionen's anti-money-laundering action announced 17 December 2025 with a fine of SEK 170 million, documented in earlier BTW reporting on the same subject [https://btw.media/en/svea-abuse-contact-durability-en] and [https://btw.media/en/svea-eknonomi-abuse-role-en]. A financial supervisor acted through its own failure channel; the abuse-contact surface produced no published outcome at all. The two facts together frame the institutional question this briefing leaves open: when the record certifies deliverability and never demonstrates response, what observable event — a timestamped reply, a validation report naming the mailbox, a published enforcement outcome — would ever distinguish a working contact from one that exists only in the registry?