Zusammenfassung

  • Das abuse-c-Regime entstand aus dem 2011 angenommenen Richtlinienvorschlag 2011-06 und wird durch die Dokumente ripe-563 (2012) und ripe-705 definiert; für Autonome Systemnummern und direkte Allokationen ist der Kontakt verpflichtend, spezifischere Objekte erben ihn über die Organisationsreferenz.
  • Die Validierung ist quantifiziert: Laut dem RIPE-87-Protokoll (2024) existieren rund 90.000 distincte abuse-c-Kontakte, mit etwa 2.000 Prüfungen pro Woche, von denen 6 bis 8 Prozent fehlschlagen; die RIPE-80-Präsentation von 2019 ermittelte 93 Prozent von 77.168 abuse-mailbox-Attributen als bestanden und 7 Prozent als fehlgeschlagen.
  • Die seit 1. März 2016 bekannte Lücke ist strukturell: Wie die RIPE NCC im Anti-Abuse-WG-Thread im Januar 2016 einräumte, lässt sich die Pflege der Kontaktobjekte „in der Praxis schwer durchsetzen, da abuse-c kein Pflichtattribut im RIPE-DB-Schema ist“.
  • Die NCC hat selbst Platzhalterkontakte erzeugt: Seit Dezember 2013 (Phase 1) bzw. November 2014 (Phase 2) wurden fehlende abuse-c-Werte mit den Mitgliederlisten- bzw. Sponsoring-LIR-Adressen befüllt – Verwalter also, die von der Institution selbst benannt wurden, ohne dass der Verantwortliche sie gewählt hätte.
  • Der Fallback ist dokumentiert: Erreicht die NCC den verantwortlichen Halter nicht, ersetzt sie die E-Mail-Adresse durch den funktionierenden Abuse-Kontakt der (Sponsoring-)LIR – die Quelle benennt damit eine Korrekturpraxis, deren Ergebnisse nicht öffentlich ausgezählt werden.

Die Kontrollkette des benannten Verwalters

Das Regime ist in drei Dokumenten definiert. Der Richtlinienvorschlag 2011-06 führte das abuse-c-Attribut auf inetnum-, inet6num- und aut-num-Objekten ein, das auf ein Rollenobjekt mit geschütztem abuse-mailbox-Attribut verweist. Das Dokument ripe-563 (2012) und der Nachfolger ripe-705 beschreiben das Modell: Verpflichtend für Autonome Systemnummern und direkte Allokationen, hierarchisch vererbt auf spezifischere Adressbereiche, mit mindestens jährlicher Validierung der abuse-mailbox durch die RIPE NCC und Nachverfolgung im Fehlfall. Die Pflegepflicht liegt beim Ressourcenhalter, also der LIR oder der sponsierenden LIR.

Diese Verwaltungspflicht ist nicht formell. Wie die Labs-Beschreibung der Implementierung dokumentiert, hat die NCC von Dezember 2013 an für Allokationen, deren LIRs nicht gehandelt hatten, selbst abuse-c-Werte gesetzt – unter Verwendung der E-Mail-Adresse der jeweiligen Mitgliederliste. In Phase 2 ab November 2014 fügte die NCC automatisch den Abuse-Kontakt der sponsierenden LIR in die Organisationsobjekte gesponserter Ressourcen ein, wenn die Verwalter nicht aktualisiert hatten. Der Halter kann diese Daten jederzeit ändern; getan hat das ein Teil von ihnen nicht.

Die Quantifizierung der Pflegemängel stammt aus den NCC-eigenen Berichten. Das RIPE-87-Transkript von Marco Schmidt (Registration Services, 2024) nennt rund 90.000 distincte abuse-c-Kontakte – grob 20.000 auf LIR-Organisationsobjekte, etwa 58.000 auf Ressourcenobjekte und ungefähr 15.000 auf unabhängige Ressourcenobjekte – sowie rund 2.000 Validierungs-E-Mails pro Woche, von denen „etwa 6 bis 8 Prozent“ fehlschlagen, wobei ein fehlgeschlagener Test nicht zwingend einen toten Kontakt bedeutet, da Timeout-bedingte Fehlschläge bei Wiederholung aufgehen.

Die RIPE-80-Präsentation von 2019 ergab von 77.168 distincten abuse-mailbox-Attributen 71.711 (93 Prozent) bestandene und 5.457 (7 Prozent) fehlgeschlagene automatisierte Prüfungen; etwa 8.000 Attribute wurden in jenem Jahr aktualisiert. Dieselbe Präsentation stellt ausdrücklich fest, dass die damals gültige Politik keine ausreichende Validierung der tatsächlichen Erreichbarkeit des Postfachs bietet – und dass Politikabsicht ist, nicht zu prüfen, wie das Postfach überwacht wird oder welche Meldungen dort bearbeitet werden.

Die NCC beschreibt die Mechanik der externen Prüfung in der RIPE-87-AAWG-Präsentation: Ein Werkzeug kontrolliert Format und DNS-Einträge und prüft mit ping, ob das Postfach existiert und E-Mail annimmt; bei Erfolg wird keine E-Mail gesendet. Fehlschläge lösen einen Verifikationslink an die abuse-c-Adresse, ein Ticket bei der NCC und die Kontaktaufnahme mit der (Sponsoring-)LIR aus – zuerst automatisch, dann durch Personal.

Die Schema-Lücke von 2016

Im Anti-Abuse-WG-Thread von Januar 2016 erklärte die NCC (Tim Bruijnzeels), Phase 1 sei im Dezember 2013 und Phase 2 im November 2014 abgeschlossen; seitdem trügen LIRs und Endnutzer die Verantwortung.

„In der Praxis hat es sich als schwierig erwiesen, dies durchzusetzen, da abuse-c kein Pflichtattribut im RIPE-DB-Schema ist.“ Die NCC schlug seinerzeit vor, für Platzhalter die E-Mail des Endnutzer-Organisationsobjekts statt der sponsierenden LIR zu verwenden – mit der Begründung, Endnutzer hätten keinen Anreiz, wenn die LIR-Adresse eingetragen ist, LIRs seien „unangenehm überrascht“ gewesen, ihre Adresse im abuse-c gesponserter Organisationen zu finden, und veraltete Sponsoring-Verweise seien nicht bereinigt worden. Seit dem 1.

März 2016 wird bei Aktivierung einer neuen LIR automatisch ein Abuse-Kontakt erzeugt, der änderbar, aber nicht entfernbar ist. Der DB-WG-Co-Vorsitzende Denis Walker präzisierte im selben Thread die Vererbung: Spezifischere inet(6)num-Objekte übernehmen org und abuse-c vom überlagernden Objekt; zwei Organisationen können sich ein Rollenobjekt teilen.

Der zugrundeliegende Qualitätsvorbehalt war vor der Einführung der Jahresvalidierung größer beschrieben worden. Im Richtlinienvorschlag 2017-02 hielt die Community fest, ripe-563 habe keine Validierung vorgesehen, abuse-c-Informationen seien „oft veraltet oder ungenau“, die NCC erhalte jährlich mehrere hundert Berichte über ungültige Kontaktdaten, die Datenbank enthielt rund 70.000 distincte abuse-mailbox-Attribute, und ein vorläufiger Stichprobentest deutete an, dass 10 bis 25 Prozent davon falsch oder inaktiv sein könnten.

Das angenommene Follow-up-Modell (Annahme im Juni 2018) verlangt von der verantwortlichen LIR die Prüfung ungültiger Postfächer; bei Nichtreaktion greifen bestehende Verfahren zur Schließung und Deregistrierung.

In Ketten aus Weiterverkäufern entsteht ein weiterer, dokumentierter Verwaltungstyp: Das NCC-FAQ zur Pflege von abuse-c bei Zuweisungen erklärt, dass LIRs Zuweisungsobjekte ihrer Kunden typischerweise selbst pflegen und die Organisationsreferenz selbst eintragen müssen; ein reines Kunden-Rollenobjekt braucht keine Personenverweise, ist öffentlich ohne Abfragelimit, und seine Inhalte gelten als Geschäftsdaten. Missbrauchsmeldungen für die Adressen des Kunden laufen dann an den Kundenkontakt statt an den der übergeordneten Allokation. Wer diesen Posteingang liest, lässt sich aus dem Objekt nicht ablesen.

Was der Datensatz beweist – und was nicht

Zur Abgrenzung: RIPE-658 (10. Februar 2016) ist eine Erhebung über Abuse-Kontakt- und CERT-Datensätze, kein Validierungsergebnis, und enthält keine Pass/Fail-Statistiken; die in diesem Bericht zitierten Zahlen stammen ausschließlich aus den oben genannten NCC-Dokumenten. Die Erreichbarkeitsprüfung misst, ob ein Postfach E-Mail annimmt – nicht, ob jemand die Meldungen dort bearbeitet. Die geprüfte Prüfpolitik (ripe-705) verlangt genau das nicht.

Die öffentliche Aufzeichnung zeigt damit eine klare Kette: Die Institution hat ein Kontaktmodell geschaffen, dessen Pflichtattribut im Schema fehlt; sie hat fehlende Werte in zwei Phasen selbst befüllt; sie misst seither Defizite in fünf- bis siebenprozentiger Größenordnung pro Prüfrunde; und sie ersetzt nicht erreichbare Verwalter durch die funktionierenden Kontakte der (Sponsoring-)LIR, ohne dass diese Ersetzungen öffentlich ausgezählt würden. Wer einen toten Posteingang verantwortet, ist damit im Zweifel die LIR, im Einzelfall aber ein Platzhalter, den die NCC selbst eingerichtet hat.

Quellen