Zusammenfassung

  • Der Abuse-Kontakt von AS211899 (SVEA, ORG-SBA155-RIPE, Svea Bank AB, reg-nr 556158-7634) ist die Rolle SEAR1-RIPE; Spiegelrenderungen zeigen als tatsächliche Mailbox eine persönliche Mailbox auf der eigenen Maildomain des Betreibers, verbunden mit widersprüchlichen last-modified-Zeitpunkten (2022-12-01 gegenüber 2026-05-13).
  • Der PI-Block 193.105.138.0/24 (netname SVEA-EKONOMI-SE, descr 'Svea Ekonomi AB', ORG-SBSA5-RIPE, Svea Billing Services AB) rendert seinen Abuse-Kontakt als ein Mailbox eines Drittanbieters.
  • RIPE-Richtlinie (ripe-705; Vorschlag 2017-02) verlangt ein obligatorisches abuse-c in Organisationsobjekten, ein einzelnes abuse-mailbox in einem Rollenobjekt, uneingeschränkte Sichtbarkeit und mindestens jährliche Validierung – aber die Validierung prüft nur die technische Konfiguration, nicht ob Meldungen ankommen oder bearbeitet werden.
  • Keine unabhängige Quelle belegt, dass irgendein Svea-Postfach Meldungen erhält oder bearbeitet; fehlende Evidenz ist kein Beweis des Gegenteils.

Der Fall im Einzelnen: Finansinspektionen, die schwedische Finanzaufsicht, verhängte gegen Svea Bank AB eine Rüge und eine Verwaltungsstrafe von 170 Mio. SEK, verkündet am 17. Dezember 2025, wegen Verstößen gegen zentrale Geldwäschevorschriften (FI-Ankündigung). Die Entscheidung erwähnt weder die RIPE-Datenbank noch Abuse-Kontakt-Pflichten; sie dient hier ausschließlich als Präzedenz für Rechenschaftsstandards. In derselben Akte (FI-Beschluss, dnr 23-13249, PDF) ist dokumentiert, dass Svea Ekonomi AB am 3. Januar 2022 vollständig in Svea Bank AB aufging und das Geschäft unter der Bank weiterlief.

Trotz dieser Fusion trägt das Personobjekt JE4899-RIPE (Jorgen Edstrom) weiterhin die Adresse 'Svea Ekonomi AB'. Der registrierte Abuse-c der AS ist SEAR1-RIPE, dessen gerenderte Mailbox die persönliche Adresse des genannten Personobjekts ist. Zugleich zeigt der PI-Block 193.105.138.0/24 ein völlig anderes Kontaktmuster: eine externe Mailbox eines Drittanbieters, obwohl der Netname und die Beschreibung auf Svea Ekonomi verweisen (ipip.net-Whois zum PI-Block).

Die RIPE-Politik definiert den Soll-Zustand klar: Die Dokumente ripe-705 und Vorschlag 2017-02 verlangen ein verpflichtendes abuse-c, eine einzelne abuse-mailbox in einer Rolle, uneingeschränkte Sichtbarkeit und jährliche Validierung. Die Abuse-c-Informationen des RIPE NCC beschreiben, was registriert werden muss – nicht, was nach dem Registrieren bewiesen werden muss.

Genau dort liegt die Lücke: Die Validierung testet nur die technische Konfiguration – Syntax, Domain, Mailserver – nicht, ob Meldungen empfangen und bearbeitet werden. Das RIPE NCC zur Missbrauchsmeldung formuliert seine Rolle begrenzt: Es validiert, dass Abuse-Kontakte gültig und aktuell sind; die Bearbeitung von Meldungen liegt beim Netzbetreiber, und wenn ein Betreiber nicht antwortet, könne die Registry nichts tun. Das Meldeverfahren greift erst nach einem vergeblichen Versuch beim Maintainer und betrifft falsche Kontaktinformationen; Streitfälle gehen an das Arbiters Panel. Netzmissbrauchsmeldungen von außerhalb des RIPE-NCC-Netzes werden nicht untersucht.

Der operative Einreichungstest besteht aus drei Kanälen: erstens der direkte Kontakt über den Maintainer der Objekte; zweitens das RIPE-NCC-Meldeverfahren für falsche Kontaktinformationen, wenn der Maintainer nicht reagiert; drittens das Arbiters Panel als Streitschlichtung. Beobachtbare Antworten, die einen funktionierenden Kanal von einem Platzhalter unterscheiden, sind eine Empfangsbestätigung, eine korrigierte Objektregistrierung oder eine verifizierbare Änderung der Mailbox.

Der konkrete Reparaturpfad ist dokumentiert und unausgeführt: Das FAQ zur Abuse-c-Konfiguration und die Abuse-Contacts-Dokumentation zeigen, dass die Abuse-Kontakt-E-Mail durch das Bearbeiten des Rollenobjekts geändert wird, das das abuse-mailbox hält – nicht durch das Umbenennen der Organisation. Bis eine solche Änderung registriert und ihre Wirkung beobachtet ist, bleibt die Kontaktoberfläche registriert, aber unbewiesen.

Evidenzgrenzen

Die whois-Spiegel (ipip.net, sitezilla, ipgeolocation.io) sind Drittanbieter-Renderings, nicht der autoritative RIPE-whois; ihre widersprüchlichen last-modified-Werte sind dokumentiert, aber nicht unabhängig aufgelöst. Ob irgendein Svea-Postfach überwacht wird, kann keine Quelle beweisen. Die FI-Sanktion betrifft nur Geldwäsche und trägt keine Feststellung zu Abuse-Kontakten. Der Validierungsstatus der Svea-Objekte im jährlichen Zyklus ist nicht öffentlich aufgeschlüsselt.

Frühere BTW-Berichterstattung vom 28.–29. September 2026 dokumentierte die gespaltene Registrierungsoberfläche, den policy-definierten Reparaturmechanismus und den Haltbarkeitstest – ohne unabhängige Evidenz für den Empfang oder die Bearbeitung von Meldungen (Erstbericht, Reparaturpfad, RIR-Watchdog-Story). Diese Briefing fügt den operativen Einreichungs- und Antworttest hinzu: was ein Melder heute tun kann und welche beobachtbare Antwort einen funktionierenden Kanal beweist.