Zusammenfassung

  • Der erste Entwurf der „Abuse Contact Policy Update“ machte aus einer zuvor empfohlenen, optionalen IRT-Verknüpfung ein Pflichtfeld: Direkt von AFRINIC vergebene inetnum-, inet6num- und aut-num-Einträge sollten einen gültigen, überwachten und aktiv betreuten abuse-c-Kontakt führen.
  • Der legitime Kern war klar: Ein einheitlicher, objektiv erreichbarer Rollen-Kontakt senkt Suchkosten, verhindert fehlgeleitete Meldungen und hält ein öffentliches Register brauchbar. Eine Zustellprüfung gehört zur Datenpflege.
  • Die vorgeschlagene Prüfung überschritt diesen Kern. Manuelles Eingreifen, ein Filterverbot, das Verbot verpflichtender Meldeformulare, Zusicherungen über Maßnahmen und Antworten, Prüfungen nach Ermessen sowie der Bezug zu Richtlinienverstoß und Widerrufsverfahren machten aus Kontaktpflege eine Aufsicht über Betriebsverhalten.
  • AFRINIC ist ein privater technischer Buchhalter und Koordinator nach mauritischem Gesellschaftsrecht, keine Behörde. Es besitzt keine hoheitliche, gesetzgeberische, regulatorische, polizeiliche, staatsanwaltschaftliche, strafende, konfiskatorische oder öffentlich-rechtlich rechtsprechende Befugnis.
  • Die tragfähige Alternative ist eine schmale Erreichbarkeitsregel: objektive Zustellbarkeit, vorhersehbare Mitteilung, eine angemessene Heilungsfrist, fortbestehender Korrekturzugang und ein datierter Hinweis zur Datenqualität — mit einer absoluten Trennwand zwischen einem Kontaktmangel und jeder Beeinträchtigung der Kontrolle über Nummernressourcen.

L3 — Die Fünf-Tage-Prüfmaschine

Der erste Schritt wirkte beinahe banal. Ein Betreiber erhält zwei E-Mails. Die erste führt ihn über eine URL zu einem Formular; die zweite liefert den Code, der dort einzugeben ist. Ein CAPTCHA soll automatisierte Einreichungen abhalten. Ein Kästchen soll bestätigen, dass die hinterlegte Mailbox regelmäßig beobachtet wird, dass auf eingehende Missbrauchsmeldungen Maßnahmen folgen und dass der Absender eine Antwort erhält. Der Code bleibt nicht lange gültig. Nach höchstens zwei Geschäftstagen ohne erfolgreiche Bestätigung wird der Kontakt vorläufig als ungültig behandelt, und AFRINIC nimmt die nächsthöhere organisatorische Ebene in Anspruch.

Der zuständige Local Internet Registry, kurz LIR, erhält für die Korrektur höchstens drei weitere Geschäftstage. Bleibt auch diese Frist ohne Ergebnis, kann aus dem vorläufigen ein dauerhafter Ungültigkeitsstatus werden. Scheitert später eine erneute Prüfung, soll dies als Verstoß gegen die Richtlinie gelten.

In dieser Abfolge stecken zwei sehr verschiedene Funktionen, obwohl sie technisch über dasselbe Postfach laufen. Die erste ist die Pflege eines Verzeichnisses. Wer eine öffentliche IP-Adresse oder eine autonome Systemnummer untersucht, soll erkennen können, an welche betriebliche Stelle eine Missbrauchsmeldung gehört. Eine nicht zustellbare Mailbox ist ein Datenfehler. Die zweite Funktion ist die Beurteilung dessen, was hinter der Adresse geschieht: Beobachtet der Betreiber auf die richtige Weise? Greift irgendwann ein Mensch ein? Filtert das System zu viel? Genügt eine Eingangsbestätigung? Wurde eine Maßnahme ergriffen?

Erhielt der Melder eine Antwort? Das sind keine bloßen Eigenschaften eines Registerfeldes. Es sind Fragen der betrieblichen Organisation und, sobald Konsequenzen an ihnen hängen, Fragen von Aufsicht und Sanktion.

Der Entwurf vom 12. August 2018 trug die Kennung AFPUB-2018-GEN-001-DRAFT01 und sollte Abschnitt 8.0 des damals maßgeblichen Policy-Handbuchs ersetzen. Verfasser war Jordi Palet Martinez. Es handelte sich um den ersten Entwurf einer später mehrfach überarbeiteten Initiative, nicht um eine bereits geltende Vorschrift. Diese Unterscheidung ist für jede Bewertung unverzichtbar. Der Text zeigt, welche Befugnisse und Verfahren vorgeschlagen wurden. Er beweist weder, dass sie angenommen oder umgesetzt wurden, noch dass AFRINIC auf dieser Grundlage jemals einer bestimmten Organisation Ressourcen entzog oder ein Mitglied anderweitig bestrafte.

Vor diesem Vorschlag war das Problem nicht völlig ungeregelt. AFRINIC hatte bereits einen eigens für Missbrauchskontakte vorgesehenen IRT-Objekttyp. Seit der 2011 beschlossenen und 2012 umgesetzten Vorgängerregel konnten inetnum-, inet6num- und aut-num-Objekte auf einen solchen Incident Response Team-Kontakt verweisen. Diese Referenz blieb jedoch optional. Mitglieder wurden zu ihrer Nutzung ermuntert, waren aber nicht verpflichtet, jedes unmittelbar zugeteilte Ressourcenobjekt auf diese Weise mit einer einheitlichen Anlaufstelle zu verbinden.

Ein öffentlicher Datensatz konnte deshalb formal vorhanden und dennoch für einen Melder umständlich sein: unterschiedliche Kontaktfelder, veraltete Adressen oder keine eindeutig erkennbare Missbrauchsstelle.

Entwurf 1 setzte genau dort an. Für jede von AFRINIC direkt vergebene Ressource sollte der zugehörige inetnum-, inet6num- oder aut-num-Eintrag zwingend einen abuse-c-Verweis enthalten. Dahinter sollte mindestens eine gültige, überwachte und aktiv verwaltete Missbrauchsmailbox stehen. Bei untergeordneten Objekten ließ der Vorschlag mehr Beweglichkeit zu: Sie konnten den Kontakt des übergeordneten Eintrags übernehmen oder einen eigenen veröffentlichen. Die Mailbox sollte über WHOIS, Programmierschnittstellen und künftige technische Zugriffsformen uneingeschränkt auffindbar sein.

Damit wurde aus einer empfohlenen Option ein gemeinsames Verzeichniselement für direkt registrierte Ressourcen.

Für diese Änderung gibt es einen starken sachlichen Grund. Eine Beschwerde über Spam, Schadsoftware, Angriffe oder eine kompromittierte Maschine ist wertlos, wenn sie die zuständige Stelle nicht erreicht. Melder müssen sonst Organisationswebseiten durchsuchen, allgemeine Kontaktadressen ausprobieren oder mehrere Zwischenstellen anschreiben. CERTs, Netzbetreiber und betroffene Nutzer verlieren Zeit. Fehlgeleitete Beschwerden erzeugen auf beiden Seiten Arbeit, ohne die Störung einer Lösung näherzubringen. Ein standardisiertes Feld reduziert diese Such- und Weiterleitungskosten.

Wenn alle unmittelbar registrierten Objekte auf eine erkennbare Rollenadresse zeigen, wird die Zuordnung maschinenlesbar und die Verantwortung im öffentlichen Datensatz nachvollziehbarer.

Auch eine Prüfung ist nicht von vornherein problematisch. Adressen veralten, Personal wechselt, Domains werden umgestellt und Postfächer können unbemerkt voll laufen. Ein Register, das eine öffentlich erreichbare Betriebsstelle verspricht, darf kontrollieren, ob die dort hinterlegte Adresse technisch noch Nachrichten annimmt. Eine Validierung bei Anlage oder wesentlicher Änderung kann Tippfehler früh erkennen. Eine vorhersehbare Wiederholung kann tote Postfächer sichtbar machen, bevor ein Sicherheitsvorfall eintritt.

Der benignste Fall für Entwurf 1 ist daher überzeugend: Ein optionales IRT-Feld garantierte keine überall erkennbare Anlaufstelle; ein gemeinsames abuse-c-Feld und eine objektive Zustellprüfung verbesserten die Brauchbarkeit des Registers.

Der Entwurf begnügte sich jedoch nicht mit einem erfolgreichen Zustellversuch. Er schrieb vor, dass an irgendeinem Punkt ein manueller Eingriff erfolgen müsse. Die Missbrauchsmailbox dürfe nicht filtern. Eine erste automatische Empfangsbestätigung war zulässig, doch der Betreiber durfte den Absender nicht dazu zwingen, statt einer E-Mail ein Webformular zu verwenden. Bei der Validierung sollte die bestätigende Person nicht nur zeigen, dass sie den Code empfangen hatte.

Sie sollte auch ihr Verständnis von Verfahren und Richtlinie bekräftigen, regelmäßige Überwachung zusagen, erklären, dass Maßnahmen ergriffen würden, und versichern, dass eine Meldung eine Antwort erhalte.

Damit wechselte der Gegenstand der Prüfung. Zustellbarkeit lässt sich mit einer begrenzten, beobachtbaren Tatsache beschreiben: Nimmt die angegebene Rollenadresse eine standardkonforme Nachricht an, oder meldet das zuständige Mailsystem einen dauerhaften Fehler? Die geforderten Zusicherungen beantworteten etwas anderes. Sie sollten AFRINIC Gewissheit darüber geben, wie ein Betreiber seine Warteschlange organisiert, welche Eingänge er einem Menschen vorlegt und welche Kommunikation er nach außen schuldet. Schon die Frage, ob „Maßnahmen“ ergriffen wurden, verlangt eine Auslegung.

Eine Maßnahme kann eine Quarantäne, eine Nachfrage, eine Kundenbenachrichtigung, ein stilles Monitoring, die Zurückweisung mangelhafter Belege oder die Feststellung sein, dass der Bericht einen fremden Netzausschnitt betrifft. Ein Register kann das nicht anhand eines Mailbox-Codes sachgerecht entscheiden.

Das Filterverbot zeigt den Kategorienwechsel besonders deutlich. Missbrauchspostfächer sind attraktive Ziele für Spam, Schadanhänge, Phishing und massenhaft automatisierte Hinweise. Ein großer Betreiber kann ein spezialisiertes Ticketsystem, Dateitypprüfungen, Rate Limits und mehrere Sicherheitsschichten unterhalten. Ein kleiner Betreiber kann dieselbe Aufgabe mit wenigen Mitarbeitern und strengeren Eingangsschranken bewältigen. Ob ein Filter vernünftig ist, hängt von Bedrohungsmodell, Volumen, Fehlalarmquote, Personal und technischer Architektur ab.

Ein Register, das jede Filterung untersagt, pflegt nicht länger die Richtigkeit seines Eintrags. Es gestaltet die Sicherheitsarchitektur der eingetragenen Organisation.

Dasselbe gilt für Webformulare. Ein Formular kann für einen Melder lästig sein, besonders wenn es zwingend Angaben verlangt, die er nicht besitzt. Es kann aber auch strukturierte Zeitstempel, betroffene Adressen, Logauszüge und Rückrufmöglichkeiten erfassen, vertrauliche Anhänge trennen und doppelte Meldungen zusammenführen. Die vernünftige Regel hängt vom konkreten Missbrauchstyp und der betrieblichen Umgebung ab. Ein Register darf anzeigen, wohin eine Meldung gehört. Es darf nicht ohne eigene Zuständigkeit darüber befinden, dass E-Mail stets der richtige Eingangskanal und ein verpflichtendes Formular stets unzulässig ist.

Sonst wird aus dem publizierten Weg eine Vorschrift über die innere Fallbearbeitung.

Entwurf 1 verstetigte diese Einwirkung. Die Prüfung sollte nicht nur bei Erstellung oder Änderung des Eintrags stattfinden, sondern regelmäßig mindestens alle drei Monate sowie immer dann, wenn AFRINIC es für angezeigt hielt. Um eine nur auf bekannte Testnachrichten trainierte Automatik zu erschweren, durften Domain, Betreff und Text bestimmter Prüfungen verändert werden. Das Ziel — Scheinkontakte zu entdecken — war nachvollziehbar. Die offene Ermessensklausel beseitigte jedoch Vorhersehbarkeit.

Für den Betreiber wurde aus einem klar terminierten Datenpflegeereignis eine potenziell jederzeit ausgelöste Compliance-Interaktion, deren Bestehen von der Behandlung wechselnder Nachrichten abhing.

Der Fünf-Tage-Ablauf verschärfte diese Unbestimmtheit durch Zeitdruck. Zwei Geschäftstage sind nicht dasselbe wie zwei beliebige Kalendertage, doch auch ein Geschäftstagsbegriff löst die betrieblichen Unterschiede nicht auf. Feiertage fallen in verschiedenen Ländern auf verschiedene Tage. Ein Kontakt kann wegen Personalwechsel, Schichtübergabe oder einer laufenden Domainmigration kurzfristig nicht reagieren. Ein Code kann in einem Sicherheitssystem festhängen, obwohl echte Missbrauchsmeldungen korrekt in das Ticketsystem gelangen.

Eine Nachricht kann als verdächtig isoliert werden, gerade weil sie Link, Code und Handlungsaufforderung kombiniert. Nichts davon beweist, dass der Ressourceninhaber einen tatsächlichen Missbrauch ignoriert.

Nach dem ersten Fristversäumnis sollte der Kontakt vorläufig ungültig werden und eine Eskalation an den LIR beginnen. Weitere höchstens drei Geschäftstage sollten die Korrektur ermöglichen. Danach war dauerhafte Ungültigkeit vorgesehen. Bei einer späteren erneuten erfolglosen Validierung rückte der Richtlinienverstoß in den Vordergrund. Der Entwurf verwies für Nichtbefolgung auf eingehendere Schritte unter einschlägigen AFRINIC-Richtlinien oder -Verfahren, insbesondere auf solche im Zusammenhang mit dem Widerruf von Ressourcen. Auch eine vermittelnde Rolle AFRINICs zwischen Meldenden und Betreibern war vorgesehen.

Aus einem Datenqualitätsmangel entstand so eine Bahn, die in den Bereich der Ressourcenbeziehung hineinführte.

Die zeitgenössische Mitarbeiterbewertung bestätigte diese Lesart des vorgeschlagenen Mechanismus. Sie verstand abuse-c als Pflichtfeld für direkt vergebene inetnum-, inet6num- und aut-num-Objekte, die Prüfung als Vorgang bei Anlage und mindestens vierteljährlich und eine fehlgeschlagene Verifizierung als Richtlinienverstoß, auf den die üblichen Maßnahmen folgen könnten. Für Entwicklung, Tests und Einführung veranschlagte die Bewertung mindestens eineinhalb Monate. Bemerkenswert ist zugleich, was sie nicht enthielt: Für diesen ersten Entwurf waren keine Anmerkungen der Rechtsberatung verzeichnet.

Eine technische Aufwandsschätzung beantwortet aber nicht die vorgelagerte Frage, woher eine private Registerstelle eine strafähnliche Entscheidungsbefugnis über fremdes Betriebsverhalten nehmen sollte.

Spätere Unterlagen dürfen nicht rückwirkend in diesen Text hineingelesen werden. Am 20. November 2018 erschien Entwurf 2. Die Debatte auf AFRINIC-29 Ende November über verifizierte Kontakte, mögliche Beschränkungen von MyAFRINIC, Auswirkungen auf Stimmrechte, Verhältnismäßigkeit und den Vorwurf einer „Internet-Polizei“ gehört daher zur weiteren Entwicklung, nicht zum Wortlaut des Entwurfs vom 12. August. Die Ko-Vorsitzenden hielten damals keinen Konsens fest und gaben den Vorschlag zur weiteren Arbeit zurück. Auch der Jahresbericht beschreibt die Initiative aus einer späteren Jahressicht, nachdem Entwurf 2 bereits vorlag.

Insgesamt wurden sieben Fassungen verzeichnet. Entwurf 7 wurde erst am 17. Mai 2021 eingereicht; heutige Unterlagen beschreiben diese spätere Fassung als ratifiziert. Keine dieser Angaben macht Entwurf 1 nachträglich zu einer angenommenen oder vollzogenen Richtlinie. Die historische Frage ist enger und gerade deshalb aufschlussreicher: Welche institutionelle Logik war bereits im ersten Versuch angelegt? Die Antwort liegt im Zusammenschalten eines sinnvollen Pflichtkontakts mit Verhaltenszusicherungen, kurzer Eskalation und widerrufsbezogener Folge. Die fünf Tage waren nicht bloß ein Erinnerungsfenster für eine fehlerhafte Adresse.

Sie waren die Mechanik, durch die ein Registereintrag in einen Compliance-Test verwandelt werden sollte.

Diese Präzision schützt auch vor einer falschen Gegenbehauptung. Nicht jede Mailboxprüfung ist ein Übergriff. Es ist durchaus Aufgabe eines Registers, seine veröffentlichten Kontaktdaten brauchbar zu halten. Problematisch wird die Prüfung erst, wenn sie von der objektiven Frage „Ist dieser Rollen-Kontakt erreichbar?“ zur normativen Frage „Behandelt der Betreiber eingehende Vorwürfe so, wie die Registerstelle es verlangt?“ wechselt. Entwurf 1 legte beide Fragen in dasselbe Formular, dieselbe Uhr und dieselbe Eskalation.

Deshalb muss die Bewertung den legitimen Registerkern anerkennen und dennoch die daran montierte Durchsetzungsschale klar zurückweisen.