Zusammenfassung

  • Ein am 17. September veröffentlichter Gastbeitrag im LACNIC-Blog nennt für XARF v4 mindestens sieben Felder. Die aktuelle XARF-Spezifikation führt acht obligatorische Felder auf oberster Ebene auf.
  • Im verkürzten Katalog fehlt sender. XARF trennt dieses Feld von reporter, damit etwa ein CERT oder technischer Dienst einen Bericht im Auftrag des eigentlichen Hinweisgebers übertragen kann.
  • Die Abweichung beweist weder einen verlorenen Bericht noch eine XARF-Pflicht bei LACNIC. Sie begründet einen Eingangsbeleg, der Prüfergebnis, genaue Schema-Version, Feldinventar, Rollen, Transport und Triage miteinander verbindet.

Sieben grüne Häkchen können eine Organisation verbergen

Ein Eingangsprogramm prüft sieben Positionen und meldet Erfolg. Der Bericht hat eine Version, eine ID, einen Zeitpunkt, einen Hinweisgeber, eine Quelle, eine Kategorie und einen Typ. Übertragen wurde er aber durch ein nationales CERT für eines seiner Mitglieder. Für diese zweite Organisation hat das Prüfmodell keinen Platz.

Das Beispiel ist hypothetisch. Es belegt weder einen realen Softwarefehler noch eine falsche Missbrauchsmeldung. Es zeigt, wie eine knappe Dokumentation eine Rollenentscheidung in Code verwandeln kann.

Auslöser ist der am 17. September erschienene LACNIC-Blogbeitrag „How to Keep an Abuse Report from Getting Lost in Your Mailbox“ von Guillermo Pereyra. Er beschreibt XARF v4 als gemeinschaftlich gepflegtes JSON-Format mit 32 Vorfalltypen in sieben Kategorien.

Der Beitrag spricht von mindestens sieben benötigten Feldern: Schema-Version, eindeutige Kennung, Vorfallszeit, reporter, Missbrauchsquelle, Kategorie und Typ. Die derzeitige technische XARF-v4-Spezifikation nennt dagegen acht obligatorische Felder auf oberster Ebene: xarf_version, report_id, timestamp, reporter, sender, das Feld zur Quellenkennung, category und type.

Die Referenz der gemeinsamen Felder bestätigt diese Liste und verlangt weitere Eigenschaften innerhalb beider Organisationsobjekte. Kategoriespezifische Schemas können zusätzliche Pflichtfelder vorsehen. Acht bezeichnet daher den universellen oberen Rahmen, nicht sämtliche erforderlichen Werte eines konkreten Berichts.

Der Blogbeitrag kennt das achte Feld. Direkt danach erklärt er den Unterschied: reporter ist die Organisation, die einen Missbrauch erkannt oder beanstandet hat; sender ist die Organisation, die den Bericht überträgt. Auch das JSON-Beispiel enthält beide. Zudem weist die Seite darauf hin, dass die Ansichten des Autors nicht notwendig die von LACNIC sind.

Damit ist die Feststellung klar begrenzt. Die Quellen zeigen nicht, dass LACNIC einen Sieben-Felder-Parser betreibt, dass XARF im Einsatz versagt oder dass eine konkrete Meldung wegen der Formulierung unbearbeitet blieb. Beobachtbar ist allein die Diskrepanz zwischen Kurzzählung und aktueller Spezifikation.

Gerade das fehlende Feld trägt jedoch eine wichtige Herkunftsinformation. Hinweisgeber und Absender sind häufig identisch. Bei ausgelagerten Meldewegen kann ein technischer Dienst, ein Markenschutzunternehmen, ein Anti-Abuse-Anbieter oder ein nationales CERT für eine andere Stelle senden.

Der Empfänger muss dann getrennt beantworten können: Wer erhebt den Vorwurf? Welches System hat ihn authentifiziert und übertragen? Wer kann einen Formatfehler korrigieren? Handelt es sich um dieselbe Beschwerde auf zwei Transportwegen oder um zwei unabhängige Beobachtungen? Ein einziges Herkunftsfeld reicht dafür nicht.

Ohnehin ist Schemakonformität nur der Anfang. XARF bezeichnet source_port, evidence, evidence_source und confidence als empfohlene gemeinsame Felder. Je nach Kategorie kommen weitere Pflichten hinzu. Der Standardmodus verlangt die allgemeinen und kategoriespezifischen Pflichtfelder; der strikte Modus zusätzlich die empfohlenen Angaben.

Ein formal gültiger Bericht kann deshalb ohne Beweisanlage eintreffen. Eine Anlage kann unbrauchbar sein. Eine perfekte Nachricht kann bei der Zustellung scheitern, in der falschen Warteschlange landen, ungelesen bleiben oder bestrittene Tatsachen behaupten. Syntax, Zustellung, Weiterleitung, Prüfung, Entscheidung und Abhilfe sind getrennte Zustände.

Der Blogbeitrag hält diese Grenze aufrecht. Belege seien im Schema empfohlen, machten einen Bericht praktisch aber oft erst handlungsfähig. Freitext bleibe gültig, wenn betroffene Ressource, UTC-Zeit, Missbrauchsart, Evidenz und ein erreichbarer Kontakt enthalten sind. Guter Freitext ist besser als schlechtes JSON; XARF ist keine Erlaubnis, andere Meldungen zu ignorieren.

Den regionalen Rahmen setzt Abschnitt 12 des LACNIC Policy Manual. Der Missbrauchskontakt muss aktiv betreut werden, manuelle und automatische Meldungen sind zulässig, ein Formular darf nicht erzwungen werden. Die Regel verlangt Erreichbarkeit und Bearbeitung, schreibt aber XARF nicht vor und bestätigt keine Behauptung im Einzelfall.

Auch der Transport hat eine beschränkte Aufgabe. Der Beitrag nennt ARF und RFC 5965. Das RFC definiert ein erweiterbares E-Mail-Format, lässt aber Zieladresse, Inhaltsprüfung und Vertrauensbildung ausdrücklich außerhalb seines Gegenstands. RFC 6650 ist die spätere Anwendungserklärung. Eine geordnete Hülle ersetzt kein Urteil.

Die passende Kontrolle ist ein kompakter Eingangsbeleg. Er hält Schemaname und semantische Version fest, dazu den Hash der verwendeten Datei oder Dokumentation und das genaue Inventar allgemeiner wie kategoriespezifischer Anforderungen. reporter und sender bleiben getrennte Rollen, selbst wenn sie denselben Wert tragen.

Hinzu kommen Prüfmodus, Ergebnis und Warnungen; Anzahl und Hash eines Belegpakets; Transport-ID, Eingangspunkt und Empfangszeit; zuständige Warteschlange, Triage-Status und Korrekturweg. Ein Hash beweist Bytegleichheit, nicht die Wahrheit des Inhalts.

Wird die Dokumentation korrigiert, lässt sich dann feststellen, welche Meldungen unter welcher Regel geprüft wurden. Nur die betroffene Menge muss erneut validiert werden. Ohne diesen Beleg bezeichnet „gültiges XARF“ keine reproduzierbare Eigenschaft, sondern eine wechselnde lokale Annahme.

Quellen