Zusammenfassung

  • Ein Domain Owner kann nach RFC 9991 detaillierte DMARC-Fehlerberichte anfordern; der Mail Receiver entscheidet weiterhin, ob er einen Bericht erzeugt, welche Art er sendet und welche Daten seine Richtlinie freigibt.
  • Die Prüfung eines externen Ziels bestätigt dessen Bereitschaft, Berichte für eine bestimmte Beziehung zu empfangen. Sie genehmigt nicht automatisch Inhalt, Adressen, Aufbewahrung oder automatisierte Reaktion.
  • Belastbar ist nur eine Kette, die Authentifizierungsfehler, DNS-Anfrage, Offenlegungsentscheidung, Reduktion, Zustellung, Prüfung und Wirkung getrennt belegt.

Der Denial-of-Service-Fall zeigt die Autoritätsfrage besonders klar. Der Domain Owner hat ruf veröffentlicht. Jeder einzelne Mail Receiver beobachtet tatsächlich eine fehlgeschlagene Nachricht. Dennoch darf die Summe wahrer Einzelbeobachtungen nicht zu einem unkontrollierten Strom an ein gemeinsames Ziel werden.

Dasselbe gilt für den Inhalt. Ein echter Fehler macht eine Nachricht untersuchenswert, aber nicht automatisch vollständig offenlegbar.

ruf äußert einen Wunsch, kein Auskunftsgebot

RFC 9991 erschien im Mai 2026 im IETF Standards Track. Er beschreibt Failure Reports für eine Nachricht oder mehrere Nachrichten mit derselben Fehlerursache. Sie liefern schneller und genauer Daten als Tagesaggregate.

RFC 9989 definiert ruf als Zielwunsch und fo als Auswahl von Fehlerbedingungen. Der Domain Owner kann damit seine Diagnoseabsicht weltweit auffindbar machen.

Die operative Entscheidung bleibt beim Mail Receiver. RFC 9991 verknüpft die Erzeugung ausdrücklich damit, dass der Receiver bereit ist, den angeforderten Bericht bereitzustellen. Er entscheidet nach eigener Policy, beobachtetem Fehler und fo, welche Berichtsart er sendet — wenn überhaupt.

Der Domain Owner kennt legitime Sender und Missbrauch seines Namens. Der Receiver hält die Nachricht, dient dem Empfänger und trägt das Offenlegungsrisiko. Das Protokoll koordiniert beide Rollen, ohne die zweite der ersten unterzuordnen.

Von der Statistik zur Kopie der Kommunikation

RFC 9990 fasst Beobachtungen nach Zeitraum, Quell-IP, Anzahl, Alignment und Disposition zusammen. Ein solcher Aggregate Report kann Fehlkonfigurationen und Kampagnen sichtbar machen, ohne jede Nachricht weiterzugeben.

RFC 9991 verwendet das Abuse Reporting Format. RFC 5965 verlangt einen menschenlesbaren Teil, maschinenlesbare Felder und die Originalnachricht oder den vollständigen Headerblock. RFC 6591 liefert Felder für Authentifizierungsfehler.

Damit ändern sich die Daten. Header können Kommunikationspartner und Weiterleitungswege zeigen; der Body kann interne Planung, Personalentscheidungen, Termine oder Rechtsberatung enthalten. Eine Mailingliste kann Mitglieder, ein Forwarder das zuvor unbekannte Endziel offenbaren.

Nicht jeder Fehler ist Angriff. Weiterleitung, Listenänderung, falsche Konfiguration, DNS-Störung und Missbrauch können ähnlich aussehen. Selbst bei echter Fälschung werden private Daten unbeteiligter Empfänger nicht automatisch erforderlich.

RFC 9991 empfiehlt deshalb zielgerichtete, zeitlich begrenzte Nutzung, kontrollierte URI, Reduktion oder Redaction und sicheren Transport. Viele große Provider beschränken oder deaktivieren Failure Reports und bevorzugen Aggregate. Das ist eine legitime Ausübung der Receiver-Policy.

Externe Autorisierung ist schmal

Zeigt ruf auf eine andere Organizational Domain, übernimmt RFC 9991 das externe Prüfverfahren aus RFC 9990. Das Ziel muss die erwartete Berechtigung für Berichte dieser Policy Domain veröffentlichen.

Die Rückbestätigung verhindert unfreiwillige Anmeldung und Reflection. Ihr Ergebnis lautet: Dieses externe Ziel akzeptiert diese Berichtsbeziehung. Es lautet nicht: Jeder Header und Body ist notwendig; jeder Mitarbeiter darf lesen; Weiterleitung, langfristige Speicherung oder Training sind erlaubt.

Für diese Fragen braucht es eine zweite, überprüfbare Beziehung: anfordernde Domain, Receiver, tatsächlicher Consumer, Zweck, Datenprofil, Stichprobe, Zugriff, Unterauftragnehmer, Ort, Dauer, Löschung und Incident-Pflicht. DNS muss damit übereinstimmen, kann sie nicht ersetzen.

Auch die Regel für psd=y ist bewusst restriktiv. Ohne besondere Vereinbarungen darf ein ruf auf einer Public-Suffix-Policy nicht berücksichtigt werden. Breite Namensraumwirkung ist kein Sammelmandat für untergeordnete Domains.

Identity-Alignment bezeichnet den Test

RFC 9991 fügt Identity-Alignment hinzu. Die aktuelle Registrierung bei IANA MARF Parameters beschreibt eine Liste der Mechanismen, die keine ausgerichtete Identität authentifizierten, beziehungsweise none bei Erfolg aller Versuche.

Das Feld präzisiert, ob DKIM, SPF oder beide am Alignment scheiterten. Es identifiziert keinen Menschen und beweist weder Betrug noch Absicht. Ein UI-Label „Identität ungültig“ würde „Alignment“ entfernen und eine neue Aussage erfinden.

Darum gehören Feldname, geprüfte Domains, Methode, Receiver, Zeit und Rohresultat zusammen. Personenbezogene Attribution braucht zusätzliche Belege.

Redaction schafft selbst eine Korrelationsfläche

RFC 6590 erlaubt konsistente Transformation privater Strings. Derselbe Wert erhält denselben Ersatz, sodass wiederholte Reports korreliert werden können, ohne den Klartext zu zeigen.

Ein stabiles Pseudonym ist jedoch Macht zur Verknüpfung. Ohne Key-Epochen, Zeitfenster und Zweckbindung wird es zur dauerhaften Schattenidentität.

Message-ID, Zeitpunkt, seltener Betreff, Received-Kette und fremde Logs können eine Nachricht erneut identifizieren. Freitext in allen Sprachen lässt sich nie vollständig automatisch erfassen. RFC 6590 warnt vor genau diesem Restrisiko.

Die Policy muss daher Felder, Transformation, Schlüssel, Epoch, Korrelationsfenster, Tests und Restdaten versionieren. redacted=true genügt nicht. Ist kein verhältnismäßiger Bericht möglich, sind Aggregate oder Unterdrückung richtige Ergebnisse.

Das Berichtssystem braucht eigene Abwehr

RFC 5965 bezeichnet ARF-Felder als Assertions, die nicht zwangsläufig stimmen. Ein syntaktisch gültiger Bericht kann falsch oder absichtlich irreführend sein. Auch eine authentische Quelle kann bösartige Anhänge oder Fehlinterpretationen weitergeben.

Der Report Consumer prüft Beziehung, Herkunft, Format, Größe und Konsistenz, isoliert aktiven Inhalt und vergleicht mit eigenen Versand-, Schlüssel- und Kontodaten. RFC 6449 behandelt Feedback Loops als operative Vereinbarung, nicht als automatische Sanktionsinstanz.

RFC 9991 verlangt Rate Limits. Grenzen müssen nach Policy Domain, Quelle, Ziel, Tenant und Gesamtdienst gelten; sonst können viele kleine Einzelbudgets ein gemeinsames Ziel überlasten. Gleichartige Vorfälle lassen sich mit Incidents zusammenfassen.

Aktive Links sollten neutralisiert und Anhänge entfernt werden. Consumer brauchen getrennte Streams, Sandbox, Segmentierung und begrenzten Zugang. Report-Mail sollte selbst DMARC-aligned sein, damit ein Bericht nicht den nächsten Bericht erzeugt.

Die laufende Kette ist der Nachweis

Heng Lus Reality Layers trennen Fehler, Anfrage, Offenlegungsentscheidung, Bytes, Zustellung, Interpretation und Wirkung. Wahrheit auf einer Ebene erteilt keine Befugnis für die nächste.

Minimum Initial Specification legt Tags, Felder, externe Prüfung und Fail-safe in die gemeinsame Schicht. Zweck und Datenfreigabe bleiben lokaler Verantwortung.

Running-Code Primacy verlangt den ausgeführten Pfad: Evaluator, Policy, Erzeugungszweig, Transformation, DNS-Antwort, übertragener Hash, Consumer und beobachtete Folge.

RFC 9991 schafft ein präzises Diagnoseinstrument. Ohne getrennte Autorität für Menge und Inhalt könnte dasselbe Instrument eine präzise Verstärkung liefern.