Zusammenfassung

  • Die offizielle RIPEstat-Dokumentation warnt, dass der vom Abuse Contact Finder zurückgegebene Abuse-Kontakt „in many cases incorrect or not available“ ist — der eigene Genauigkeitshinweis des Werkzeugs, in den Worten des Registers.
  • Die Suche arbeitet von unten nach oben: Sie gibt den ersten in den verknüpften ORGANISATION-Objekten gefundenen abuse-c zurück und ignoriert Legacy-abuse-mailbox-Attribute, sobald irgendein abuse-c existiert.
  • Die Konfidenzbewertung, die den Nutzern einst zeigte, wie wahrscheinlich ein korrekter Kontakt ist — fünf Sterne bis zu einem — wurde 2015 eingestellt; zurück blieb eine einzelne, nicht qualifizierte Adresse hinter einem API-weiten Disclaimer.
  • Dokumentierte Ausfallmodi umfassen einen Bug der Heuristik-Ära, der häufig die Register-eigene Platzhalter-Abuse-Adresse zurückgab, und ein Datenbankdesign, bei dem einst rund 30–150 separate Abfragen pro Lookup eine Hierarchie nicht eindeutiger Schlüssel hinaufkletterten.
  • Die Genauigkeit wurde seit der Einstellung der Bewertung nicht öffentlich gemessen; das RIPE NCC räumte zeitweise ein, es gebe kein Verfahren zur Korrektur eines falschen, aber validen Kontakts.

Der Abuse Contact Finder existiert wegen einer einfachen Designentscheidung. Als das abuse-c-Attribut unter RIPE-563 zum kanonischen Abuse-Kontakt wurde, verpflichtete sich das RIPE NCC, mit seinen Lookup-Werkzeugen exakt das zurückzugeben, was die Datenbank verzeichnet — nichts mehr, nichts weniger. Nach der eigenen Beschreibung des Registers arbeiten die Werkzeuge „von unten nach oben und suchen nach abuse-c:-Referenzen in ORGANISATION-Objekten, die mit den INET(6)NUM-Objekten verknüpft sind.

Der erste gefundene wird zurückgegeben“; sobald irgendeine abuse-c-Referenz existiert, werden die Legacy-abuse-mailbox-Attribute gar nicht erst betrachtet. Die Datenbankhierarchie bedeutet, dass das spezifischste überdeckende Objekt gewinnt: Eine Abfrage zu einer konkreten IP wird also vom abuse-c der Organisation beantwortet, die mit dem überdeckenden Range verknüpft ist — dem Netzwerk, zu dem die IP gehört, nicht dem Täter, wie die öffentliche Orientierung des RIPE NCC es formuliert.

Diese Unterscheidung ist wesentlich: Ein Opfer einer Phishing-Kampagne bei einem großen Provider wird korrekt-by-design an dessen Abuse-Desk geroutet; ein Opfer, das an den Desk der falschen überdeckenden Organisation geroutet wird, landet bei einem Betreiber, der über das betroffene Netzwerk gar keine Verfügungsgewalt hat.

Was das Werkzeug zurückgibt, ist daher Ausdruck des Datenbankzustands, nicht verifizierter Korrektheit. Die aktuelle Endpoint-Dokumentation ist dazu ungewöhnlich deutlich: „The main purpose of this endpoint is to return abuse contact informations for a Internet number resource. Note that this information is in many cases incorrect or not available.“ Der Endpoint liefert eine Liste dedizierter Abuse-E-Mail-Adressen und die autoritative RIR für die abgefragte Ressource — und relativiert die Genauigkeit der ersten im selben Satz, in dem er sie beschreibt.

Dieser Disclaimer ist der Überrest einer früheren, ehrlicheren Schnittstelle.

Vor 2015 bewertete der RIPEstat Abuse Contact Finder seine eigenen Ergebnisse auf einer Fünf-Sterne-Skala, und die in RIPE Labs dokumentierte Bewertungslogik ist eine Taxonomie des Zweifels: Fünf Sterne bedeuteten ein der RIPE-563 entsprechendes abuse-c-Attribut am abgefragten Objekt, den Fall, den die Politik als korrekt ansieht; vier Sterne einen abuse-mailbox in einem verwandten Objekt; drei Sterne Kontaktdaten, die nur in remarks gefunden wurden; zwei Sterne einen abuse-mailbox, der von einem spezifischeren oder übergeordneten Objekt geerbt wurde und „may not be the correct contact“; ein Stern bedeutete, dass die zurückgegebene Adresse

„quite unlikely“ korrekt ist.

Seit 2015, so die Anmerkung, „provides the RIPEstat Abuse Contact Finder no rating heuristics anymore. It only shows the abuse-c e-mail address as specified in RIPE Document 563.“ Die Unsicherheit, die die Bewertung sichtbar machte, verschwand nicht; sie wurde aus der Schnittstelle in einen Sammel-Disclaimer verlagert, den die meisten Nutzer nie lesen.

Die Vorgeschichte vor 563 erklärt, warum Konfidenz in einen Disclaimer kollabierte. Der heuristische Abuse Finder jener Ära konnte laut RIPE Labs „only a best effort suggestion of the appropriate abuse contact details“ liefern, was sich „unzuverlässig und umstritten“ erwies.

Seine Regelkette — Objektauflösung, Verfolgung von IRT-Referenzen, Aufstieg zu ROLE-, PERSON- und ORGANISATION-Objekten, Extraktion von Route- und Maintainer-Daten, Deduplikation, dann Ernte von abuse-mailboxen und abuse-bezogenen remarks — konnte rund 30 bis 150 separate Abfragen der RIPE Database pro Lookup umfassen, und zwei dokumentierte Bugs zeigten, wie diese Komplexität in der Praxis scheiterte: Platzhalterdaten führten dazu, dass das Werkzeug „frequently and incorrectly“ die Register-eigene Platzhalter-Abuse-Adresse zurückgab, und weil primäre und indizierte Schlüssel über Objekttypen hinweg nicht eindeutig sind, lieferte ein weiterer

Bug Ergebnisse ohne Bezug zur abgefragten Ressource.

Das strukturelle Problem, das der Finder erbt, ist älter als das Werkzeug. Der Policy-Proposal 2017-02, die Grundlage der heutigen regelmäßigen Validierung, hielt das quantifizierte Genauigkeitsproblem hinter abuse-c fest: ripe-563 „didn't provide for the validation of abuse-c: contact information“, das RIPE NCC erhielt „several hundred reports of invalid contact information each year“, und ein vorläufiger Zufallstest ergab, dass 10–25 % der rund 70.000 distincten abuse-mailbox-Attribute „might be incorrect or inactive“ sein könnten.

Die RIPE-80-Präsentation (2019) bezifferte später das automatisierte Regime: Von 77.168 distincten abuse-mailbox-Einträgen bestanden 71.711 (93 %) die automatisierte Validierung, 5.457 (7 %) scheiterten — und die aufgezählten Ausfallmodi (falsche E-Mails einer anderen Organisation, nie gelesene Postfächer, volle oder bounceende Postfächer, Adressen nicht existierender Mitarbeiter) sind genau die Fälle, die eine Zustellbarkeitsprüfung nicht von einem funktionierenden Desk unterscheiden kann.

Validierung misst mit anderen Worten auch für die Lookup-Schicht das Falsche. Wie das Validationsteam des RIPE NCC in RIPE Labs formulierte: „The nature of our validation is about checking that there is a working email in the RIPE Database and that this corresponds to a working mailserver that can accept emails.

We have no say in what network operators do with any abuse reports they receive.“ Ein valider abuse-c ist nicht der korrekte abuse-c; die durch 2017-02 eingeführte Validierung selbst räumt mögliche falsche Negative und falsche Positive ein, und ihr Umfang — Syntax, Domäne und Mailserver-Konfiguration, geprüft ohne Mailversand — schweigt dazu, ob die Adresse überhaupt zur richtigen Organisation gehört.

Auch die Haltung des Registers zur Korrektur falscher Ergebnisse ist dokumentiert. Eine auf der Labs-Seite festgehaltene Antwort von RIPE-NCC-Personal räumte ein, es gebe „no procedure in place for users respectively the RIPE NCC to correct/validate abuse contacts“, die von Ressourceninhabern geliefert werden. Heute bietet das NCC einen Meldeweg für Kontakte, die „invalid or missing“ sind; undokumentiert bleibt ein Korrekturverfahren für einen Kontakt, der falsch, aber technisch valide ist — der Fall, in dem der Finder jede Beschwerde zu einem Prefix zuverlässig an ein Postfach routet, das jemandem gehört, der nicht handeln kann.

Das praktische Ergebnis für den Beschwerdeführer: Die Garantie des Finders läuft nur in eine Richtung. Er ist autoritativ darüber, was die Datenbank sagt, und schweigt darüber, ob das, was die Datenbank sagt, richtig ist. Die eigene Orientierung des Registers warnt davor, das Werkzeug zu umgehen — die RIPE Database direkt abzufragen und „sending abuse complaints to any or all email addresses found“ wird als kontraproduktiv beschrieben, und die Database-Dokumentation ergänzt, eine Beschwerde „will not be handled any quicker by copying your message to any other e-mail address found in the database“.

Der Beschwerdeführer wird also in eine einzige Adresse geleitet, deren Genauigkeit nach oben hin relativiert und nach unten hin ungemessen ist.

Nichts davon ist ein Vorwurf der Vertuschung: Das Register nennt den Hinweis im ersten Absatz des Endpoints, und die Taxonomie der eingestellten Bewertung ist veröffentlicht. Was fehlt, ist Messung. Seit 2015 existiert keine öffentliche Zahl dazu, wie oft der zurückgegebene abuse-c der korrekte ist, und in der öffentlichen Aufzeichnung, auf die dieser Bericht sich stützt, fand sich keine unabhängige Studie zur Routing-Korrektheit. Der Finder beantwortet „wohin zeigt die Datenbank“ präzise und „zeigt die Datenbank in die richtige Richtung“ mit einer Schulterzuckung.

Für die Communities, deren Beschwerden in dieser Lücke verschwinden, ist die Schulterzuckung der Befund.