Zusammenfassung

  • RFC 9990 normiert einen XML-Aggregatbericht mit der von einem Mail Receiver beobachteten Policy, Quell-IP-Zeilen, Zählwerten und Authentisierungsergebnissen für einen Berichtszeitraum.
  • Ein DNS-bestätigter externer rua-Empfänger darf die Berichtsbeziehung annehmen; die Bestätigung ist weder eine Vollständigkeitsgarantie noch eine Befugnis zur automatischen Durchsetzung.

Es beginnt oft mit einem technisch korrekten Vorgang. Ein Bericht wird zugestellt, als XML gelesen, in Felder zerlegt und im Dashboard als auffällige Reihe angezeigt. Der Vorgang ist reproduzierbar. Die Schlussfolgerung daraus ist es nicht zwangsläufig.

RFC 9990 nennt die veröffentlichte Policy ausdrücklich die vom empfangenden System beobachtete Konfiguration. Ein record enthält die Aussage, bestimmte IP-Adressen seien beim Zustellen von Nachrichten für die Author Domain an dieses System gesehen worden. Der Bericht sagt damit etwas Bestimmtes über eine Empfangsperspektive. Er sagt nicht, dass jede andere Mail-Infrastruktur denselben Verkehr, dieselbe Policy-Entscheidung oder dieselbe Ursache gesehen hat.

Das ist keine Abschwächung der Daten. Eine Zeile kann einen nicht katalogisierten Versender, einen Schlüsselwechsel, einen Weiterleitungsfehler oder eine relevante Mengenverschiebung sichtbar machen. Sie kann aber weder die Person hinter einer Nachricht identifizieren noch Absicht, Täuschung oder einen universellen Zustellstatus beweisen. SPF- und DKIM-Ergebnisse stehen im auth_results-Teil, werden von RFC 9990 jedoch hinsichtlich DMARC als nicht interpretiert bezeichnet. Auch ein Policy-Override-Grund beschreibt eine lokale Entscheidung des Empfängers, nicht die Schuld einer Gegenpartei.

Wer aus einem Dashboard unmittelbar Lieferanten sperrt, Konten einschränkt oder eine p-Änderung ausrollt, fügt deshalb eine neue Entscheidungsebene hinzu. Diese Ebene muss sichtbar bleiben. Sie braucht den ursprünglichen Bericht, die Abgleichlogik, den Entscheider, den Zeitpunkt und eine Rücknahmeoption. Ein sauber lesbares Feld darf nicht unbemerkt zum Ersatz für diese Kette werden.

Der Berichtszeitraum ist kein lückenloses Ereignisprotokoll

Die Spezifikation verlangt Metadaten, policy_published und mindestens einen Datensatz. Die Zeitangaben in den Metadaten beschreiben den Berichtszeitraum in UTC; normalerweise ist das ein Tag und die Perioden sollen sich nicht überschneiden. Sie benennen ausdrücklich nicht die erste und letzte Nachricht, die der Empfänger in dieser Periode beobachtet hat.

Damit ist eine häufige Inferenz ausgeschlossen. Kein Eintrag in einem Tagesbericht beweist nicht, dass eine Quelle nie sendete. Ein hoher Eintrag beweist nicht, dass das Volumen außerhalb dieses Empfängers gleich war. Der Zeitraum ist ein Messrahmen, nicht eine vollständige Verkehrsgeschichte. Vor einer eingreifenden Policy sollte ein Betreiber deshalb mit eigenen Versandprotokollen, der Liste autorisierter Quellen, DNS- und Schlüsselhistorie, Weiterleitungsinformationen, Anbieterwechseln und Beobachtungen unabhängiger Empfänger vergleichen.

Das Rohdokument, sein Hash, die extrahierten Felder und ein von einem Dashboard berechneter Risikowert gehören in getrennte Aufzeichnungen. „Kritisch“ ist kein RFC-Feld. Es ist eine vom Systembetreiber verantwortete Interpretation und muss auch als solche angefochten werden können.

Eine bestätigte Adresse ist eine Empfangsbeziehung, keine Datenverfassung

Mit rua kann ein Domain Owner mitteilen, wohin Aggregatberichte gesendet werden sollen. Liegt der Host außerhalb der eigenen Organizational Domain, muss der Mail Receiver das externe Ziel in DNS prüfen. Nur bei einer positiven Bestätigung gilt die externe Berichtsbeziehung als autorisiert; ohne sie muss die URI ignoriert werden. Die Regel verhindert, dass jemand einen fremden Empfänger als Opfer einträgt und durch massenhaft fehlgeschlagene Nachrichten Berichtsstürme auslöst.

Eine positive Antwort beantwortet genau eine Frage: Ist der Report Consumer bereit, Berichte für diese Beziehung zu empfangen? Sie regelt nicht die Mitarbeitenden des Dienstleisters, die Aufbewahrungsdauer, die Weitergabe, die Zusammenführung mit anderen Daten oder eine Sanktion gegen eine Quelle. RFC 9990 weist darauf hin, dass Datenschutzrichtlinien oder Nutzungsbedingungen des Mail Receivers eine Drittübermittlung einschränken können. Der Bericht enthält keine Inhalte, individuellen Mailadressen oder IP-Adressen einzelner Personen; er kann dennoch eine Analyse des Datenverkehrs auf Domainebene ermöglichen.

Für jeden externen Consumer braucht es daher eine eigene Betriebsvereinbarung: zugelassene Policy-Domains, Zweck, verantwortliche Person, Zugriffsgruppe, erlaubte Transformationen, Unterauftragsverarbeiter, Aufbewahrung, Löschung, Weitergabe und Incident-Kontakt. Der DNS-Eintrag muss mit dieser Vereinbarung übereinstimmen. Er ersetzt sie nicht.

Korrekte Zustellung, valides XML und wahre Behauptungen sind drei Prüfungen

Der Bericht wird als XML-Anhang per Mail übertragen und normalerweise mit GZIP komprimiert. Berichtstragende Mailströme müssen selbst DMARC-konform und aligned pass sein; damit wird das Risiko reduziert, dass ein Report Consumer betrügerische Berichte verarbeitet. Dateinamen und Report-ID unterstützen die Behandlung von Duplikaten.

Diese Mechanismen beweisen nicht die Wahrheit der Nutzdaten. RFC 9990 warnt ausdrücklich davor, dass aggregierte Daten gefälscht und in großer Menge eingespeist werden können, um Policy- oder Plattformarchitekturentscheidungen zu beeinflussen. Ebenso können fehlerhafte Berichte den Dekompressor oder XML-Parser mittels Zip Bomb oder XML Bomb erschöpfen. Ein bekannter Absenderpfad und eine gut geformte Datei sind keine Freigabe für ihre Behauptungen.

Deshalb muss die Eingangsstufe zuerst begrenzen: komprimierte und entpackte Größe, XML-Tiefe, Rechenzeit, Schema und Speicherzugriff. Das Rohmaterial bleibt zugriffsbeschränkt. Ist das Format fraglich, darf der Evaluator den Bericht verwerfen oder für die Abstimmung mit dem Generator zurückstellen. Erfolgreiches Parsen ist nicht dasselbe wie verlässliche Evidenz; verlässliche Evidenz ist nicht dasselbe wie ein angemessener Eingriff.

RFC 9989 beschreibt die Folgeebene nüchtern: Je nach Versandrhythmus kann ein Domain Owner viele Monate Aggregatberichte konsumieren müssen, bevor er sicher ist, dass seine gesamte Mail korrekt authentisiert wird; die Wahl von p hängt von seinen Bedürfnissen ab. Der Bericht bereitet eine lokale Policy-Entscheidung vor. Er erlässt sie nicht.

Redaktionelle Auslegung: eine begrenzte gemeinsame Schicht

Das ist eine redaktionelle Einordnung und keine IETF-Norm. Gemeinsames Format, prüfbarer Empfangspfad und Reflexionsschutz reichen für Interoperabilität. Sichtbar bleiben muss: welcher Receiver beobachtete, welcher Validator annahm, wer die Policy änderte und welche Wirkung danach tatsächlich gemessen wurde.