Beginnen Sie mit einem Verhalten, nicht mit einem Ersatzdatensatz
Eine Standardmigration wird beherrschbar, wenn jede Implementierungsentscheidung eine benannte Spezifikation und einen verantwortlichen Eigentümer hat. Ein DNS -Editor, ein Ausrichtung Die Engine und ein Aggregate-Report-Parser führen nicht die gleiche Aufgabe aus. Ich rufe alle drei auf:DMARC „Unterstützung“ verbirgt Abhängigkeiten, die wichtig sind, wenn sich eine Komponente ändert und eine andere auf einer älteren Implementierung verbleibt. Das praktische Ergebnis ist eine Komponente-zu-Anforderungs-Karte mit Versionen, Schnittstellen und beibehaltenen Akzeptanznachweisen und nicht eine Erklärung, dass der gesamte Bestand aktualisiert wurde.
Der aktuelle Dokumentensatz wurde im Mai 2026 veröffentlicht. RFC 9989 definiert den Kernmechanismus und ist veraltet RFC 7489 und RFC 9091 . RFC 9990 umfasst die aggregierte Berichterstattung; RFC 9991 deckt die Fehlerberichterstattung ab und aktualisiert auch RFC 6591 . Neue RFC-Editor-Datensätze werden identifiziert RFC 9989 Und RFC 9990 als vorgeschlagene Standards. Der veröffentlichte RFC 9991 Text identifiziert seine Standards Track-Kategorie. Dabei handelt es sich um veröffentlichte Spezifikationen, nicht um unvollendete Entwürfe, die Veröffentlichung legt jedoch nicht die Implementierung eines bestimmten Empfängers fest.
Geben Sie der Kernmaschine einen genauen Vertrag
Weisen Sie Datensatzanalyse, Richtlinienerkennung, Organisationsdomänenerkennung und Identifikatorausrichtung zu RFC 9989 Abschnitte 4.7–4.10. Die Autorendomäne stammt von der Nachricht RFC5322 .Von Feld. Eine erkannte Richtliniendomäne kann sich von dieser Autorendomäne unterscheiden Organisationsbereich Die Verwendung für die entspannte Ausrichtung ist eine weitere explizite Ausgabe. Wenn diese Unterscheidungen in einer Schnittstelle verloren gehen, kann ein korrekter Parser-Feed zu einer falschen Entscheidungsmaschine führen.
Der DNS Eintrag beginnt weiterhin mit v=DMARC1. „DMARCbis„ ist ein Name für die Arbeit an Standards und nicht für die Erlaubnis, DMARC2 zu erfinden. Die aktuelle Erkennung verwendet begrenztes DNS Tree-Walking, anstatt eine historische Checkliste mit öffentlichen Suffixen als gesamten Algorithmus zu behandeln. Die Tags psd, np und t erfordern eine separate Entscheidungsabdeckung. Die IANA Registrierung Markierungen pct, rf und ri historisch; Es wird nicht bestätigt, ob ein bereitgestelltes Produkt sie ignoriert, interpretiert oder offenlegt.
Behalten Sie die Unterscheidung zwischen einem normalen DMARC Fehler, nicht verfügbaren DNS Informationen, einer ungültigen Richtlinie und der endgültigen Nachrichtendisposition eines Empfängers bei. RFC 9989 Abschnitt 4.10.1 enthält eine spezielle Behandlung für ungültige Richtlinien-Tags, wenn ein syntaktisch gültiger Aggregate-Report-URI verbleibt. Eine vereinfachende Regel „Jede fehlerhafte Richtlinie wird zu keiner“ würde ihre Bedingungen zunichte machen. Notieren Sie den genauen Abschnitt neben dem Parser-Fall, der ihn ausführt.
Behandeln Sie aggregiertes Feedback als eigene Implementierung
Ordnen Sie den Aggregatproduzenten, den XML-Validator, den Berichtskonsumenten, die Duplikatbehandlung und die Bereitstellungsintegration zu RFC 9990 Abschnitte 3–4 und Anhang A. Die Berichtsschnittstelle benötigt die tatsächlich ausgewertete Richtlinie, die Authentifizierungsergebnisse, die Anzahl der Nachrichten und den Kontext des Berichtszeitraums. Ein Dashboard, das XML anzeigt, ist kein Beweis dafür, dass der Upstream-Empfänger die richtige Richtlinie ausgewählt hat oder dass alle relevanten Absender in den Daten enthalten sind.
Externe Berichtsziele verdienen eine eigene Komponentenzeile. Bei der Zielgenehmigung handelt es sich um eine technische Missbrauchskontrolle, nicht um die Einwilligung zur Übermittlung willkürlicher Organisationsdaten. Stellen Sie die Berichtserstellung, die Zielüberprüfung und Zugriffs-/Aufbewahrungsentscheidungen unter unterschiedliche Akzeptanzkriterien. RFC 9990 Abschnitt 7 befasst sich mit dem Datenschutz, während Abschnitt 8 vor böswilligen oder falschen Berichtsinhalten warnt. Parser-Hardening und Source Trust gehören daher neben der Schemavalidität in die Karte.
Verwenden Sie einen Aggregatparser nicht erneut für Fehlerberichte
Fehlerrückmeldung ist ein anderer Kanal mit unterschiedlichen Offenlegungsrisiken. RFC 9991 regelt dessen Generierung und Format und arbeitet mit den referenzierten Spezifikationen für die Berichterstattung über Authentifizierungsfehler. Die Rufanforderungs- und Fo-Bedingungen entsprechen nicht der Rua-Aggregation. Ein Empfänger kann die Meldung von Fehlern ablehnen und das Fehlen einer Fehlerbericht ist kein Beweis dafür, dass alle Nachrichten weitergeleitet wurden.
Es kann zu einer Fehlerberichtsintegration kommen Nachrichtenkopfzeilen oder Inhalte, die eine aggregierte Pipeline nicht transportieren soll. Identifizieren Sie, wer es anfordern kann, wohin es gesendet werden kann, wie eingehendes Material enthalten ist und welche Datenschutzprüfung gilt. Aktivieren Sie es niemals nur, um eine Feature-Matrix vollständig erscheinen zu lassen. Grundlegende Teilnahmevoraussetzungen, optionale Fehlerberichte und die beworbenen Funktionen eines kommerziellen Produkts sind unterschiedliche Behauptungen, die unterschiedliche Nachweise erfordern.
Arbeiten Sie ein fiktives Komponenteninventar durch
Stellen Sie sich einen fiktiven Dienst mit sechs Modulen vor: Policy Decoder, Discovery Resolver, Alignment Evaluator, Aggregat Builder, XML Consumer und Failure Collector. Die ersten drei entsprechen RFC 9989 . Die nächsten beiden beziehen sich hauptsächlich auf RFC 9990 . Der Kollektor ist hauptsächlich auf RFC 9991 abgebildet. Gemeinsam genutzte Speicher- und Sicherheitskontrollen übernehmen die Anforderungen jedes von ihnen verwalteten Berichtspfads. Bei dieser Bestandsaufnahme handelt es sich um ein Originaldokumentationsbeispiel und nicht um eine Aussage über die Architektur von EmailAuth .
Behalten Sie für jedes Modul seine tatsächliche Build-ID, relevante Abschnitte, Ein-/Ausgabevertrag, Eigentümer und Abnahmevorrichtung bei. Eine fiktive Discovery-Fixture kann eine ausgewählte Richtlinie und ihre Quelldomäne an eine fiktive Aggregat-Fixture übergeben; Die Berichtszeile sollte diese Unterscheidung beibehalten und nicht stillschweigend die sichtbare Von-Domäne ersetzen. Führen Sie dann eine Fehlerberichtsanforderung ein und bestätigen Sie, dass das Design sie an einen separat autorisierten Verarbeitungspfad weiterleitet. Hierbei handelt es sich um vorgeschlagene Schecks, nicht um abgeschlossene Ausführungen.
Halten Sie Status, Errata und Bereitstellung getrennt
Der genaue Auftrag lautet: Ordnen Sie jede Implementierungskomponente RFC 9989 , 9990 oder 9991 zu und prüfen Sie die Errata. Eine tatsächliche Implementierungsabdeckung wurde nicht bereitgestellt. Der aktuelle Errata-Abruf ist fehlgeschlagen und wurde gestoppt. Daher kann in diesem Entwurf nicht behauptet werden, dass die Dokumente keine Errata enthalten. RFC 9989 Diskussion der gelösten RFC 7489 Errata ist ein historischer Kontext und keine neue Errata-Überprüfung für die drei neuen Dokumente.
Vor der Veröffentlichung muss der Implementierungseigentümer den tatsächlichen Bestand abgleichen, der Standardseigentümer muss aktuelle Fehler beheben und der Empfängertest-Eigentümer muss versionierte Interoperabilitätsnachweise aufbewahren. Auch Fachprüfung, Produktionswegkontrolle, Sichtabnahme und Veröffentlichungsgenehmigung bleiben offen. Das nützliche Ergebnis heute ist eine überprüfbare Karte, die fehlende Beweise aufdeckt, ohne einen aktualisierten Standard in eine nicht unterstützte Behauptung einer universellen Bereitstellung umzuwandeln.