Ersetzen Sie das Prozentversprechen durch eine explizite Entscheidung
Ein Rollout-Plan, der besagt, dass „auf zehn Prozent der fehlgeschlagenen E-Mails eine Ablehnung angewendet werden soll“, muss überprüft werden, bevor er im Rahmen der Aktualisierung wiederverwendet wird DMARC Spezifikation. RFC 9989 entfernt den pct-Mechanismus und definiert ein Testsignal namens t. Dies ist eine Änderung der verfügbaren Richtliniensprache und kein Beweis dafür, dass jeder Empfänger seine Software geändert hat. Die praktische Aufgabe besteht darin, herauszufinden, was der bestehende Plan schützen sollte, und diese Absicht dann mit der aktuellen Semantik und dem beobachteten Altverhalten zu vergleichen.
Übersetzen Sie einen Prozentsatz nicht mechanisch in einen Testwert. Ein Prozentplan versucht zu begrenzen, wie viel Verkehr eine Behandlung erhält. Ein Testsignal ändert die angeforderte Behandlung und kann eine Sonderbehandlung auslösen. Das sind verschiedene Kontrollen. Unternehmer sollten entscheiden, welche legitimen Routen im Vergleich dargestellt werden müssen, welche Auswirkungen von Ausfällen akzeptabel sind und welche Beweise die nächste Richtlinienänderung ermöglichen würden.
Verstehen Sie, was die aktuelle Spezifikation erfordert
RFC 9989 Anhang A.6 erklärt, dass das historische Verhalten von pct außerhalb seiner Endpunkte inkonsistent war und dass pct=0 nützliche Bedeutungen für die Sonderbehandlung erhalten hat. Der aktualisierte Mechanismus behält ein Testkonzept anstelle eines allgemeinen Prozentsatzes bei Wähler. Die Datensatzversion bleibt v=DMARC1; Es gibt keine DNS Umstellung auf eine Versionszeichenfolge namens DMARC2.
Unter Abschnitt 4.7, t ist standardmäßig n. Mit t=y, liegt die angegebene Behandlung fehlerhafter Nachrichten eine Ebene unter der ausgewählten Richtlinie: „Ausweisen“ wird zu „Quarantäne“ und „Quarantäne“ wird zu „Keine“. Die ausgewählte Richtlinie „Keine“ bleibt davon unberührt. Das Signal kann auch eine besondere Behandlung durch den auswertenden Akteur veranlassen und ändert nichts an der Generierung von DMARC -Berichten. Hierbei handelt es sich um spezifizierte Semantiken, nicht um eine Garantie für den endgültigen Ordner, die Ablehnungsantwort oder das Lieferergebnis bei jedem Empfänger.
Behalten Sie die ausgewählte p-, sp- oder np-Richtlinie in der Bewertung bei. Das Testen ist nicht auf die Richtlinienzeichenfolge beschränkt, die ein Bediener zufällig zuerst in einem Dashboard sieht. Die Domäne und der Erkennungspfad bestimmen, welche Richtlinie gilt. Eine korrekte Erklärung von t kann eine Untersuchung, bei der eine andere Domäne als der eigentliche Nachrichtenautor überprüft wurde, nicht kompensieren.
Identifizieren Sie das Risiko einer gemischten Implementierung
Ein Empfänger, der t nicht erkennt, ignoriert es möglicherweise und verwendet weiterhin seine unterstützte Richtlinienlogik. Umgekehrt erhält eine Implementierung der aktualisierten Spezifikation keine prozentuale Rollout-Regel aus einem alten PCT-Wert. Ein Rekord Das Vorhandensein beider Tags ist daher keine tragbare Möglichkeit, ein einheitliches Experiment für alle Empfänger anzufordern.
Behandeln Sie den Implementierungsstatus als gemessene Eigenschaft einer benannten Umgebung und Konfiguration. Eine Herstellerankündigung, ein Berichtsformat oder ein Produktlogo allein beweisen nicht, wie eine bestimmte Nachricht verarbeitet wurde. Wenn ein Empfänger nicht überprüft werden kann, bewahren Sie die Unsicherheit auf und vermeiden Sie, seine endgültige Aktion ausschließlich einem Tag zuzuschreiben. Die lokale Handhabung des Empfängers bleibt ein separater Schritt RFC 9989 Abschnitt 5.4.
Überprüfen Sie auch die verborgenen Annahmen des alten Plans. War der Prozentsatz dazu gedacht, den Verlust legitimer E-Mails zu begrenzen, die Weiterleitung zu bewerten, das Fehlervolumen abzuschätzen oder den Berichtsdienst zu testen? Jeder Zweck erfordert unterschiedliche Beobachtungen. Die Reduzierung der Behandlung aller fehlerhaften Nachrichten ist nicht das gleiche Experiment wie die Anwendung strengerer Behandlungen auf eine ausgewählte Teilmenge, auch wenn beide Pläne informell als schrittweise Einführung beschrieben werden.
Schreiben Sie Akzeptanzkriterien, bevor Sie DNS ändern
Bereiten Sie einen Absender-für-Absender-Vergleich vor, der legitime Routen mit geringem Volumen und regelmäßigen Abständen umfasst. Behalten Sie den genauen aktuellen Datensatz, die vorgeschlagene Differenz, die anwendbaren Identitäten und repräsentativen Nachrichtenfälle bei. Notieren Sie die normale Authentifizierung und Ausrichtung Ergebnisse getrennt von ausgewählter Richtlinie, Teststatus, lokalen Überschreibungen und endgültiger Disposition. Definieren Sie die Bedingungen, die den Rollout stoppen, einschließlich fehlender Abdeckung oder unerklärlicher Fehler bei legitimen Nachrichten.
Gehen Sie mit aggregierten Beweisen vorsichtig um. RFC 9990 Abschnitt 3.3 erklärt, dass ein Berichtszeitraum politische Änderungen umfassen und gemischte Beobachtungen enthalten kann. Eine Tageskennzeichnung in einem Bericht ist kein Beweis dafür, dass jede gezählte Nachricht einer Richtlinie unterliegt. Behalten Sie den Berichtszeitraum, die beobachtete Richtlinie und den Bereitstellungszeitpunkt bei, anstatt zwei unbeschriftete Prozentsätze zu vergleichen.
Die vorgeschlagene Änderung sollte einen verantwortlichen Eigentümer und eine wiederherstellbare Basis haben. Durch das Entfernen von pct aus einem Legacy-Plan kann eine Einschränkung entfernt werden, die in einer älteren Implementierung verwendet wurde. Das Hinzufügen von t beweist nicht, dass die Einschränkung dort ersetzt wurde. Ein Rollback ändert auch den veröffentlichten Status, anstatt sofort alle zwischengespeicherten Beobachtungen neu zu schreiben, sodass der Wiederherstellungsnachweis einen eigenen Zeitplan und einen eigenen Umfang benötigt.
Fiktives Beispiel einer abgelehnten Übersetzung
In dieser fiktiven Rezension enthält „Example Manufacturing“ ein altes Arbeitsblatt p=reject und pct=10. Ein Redakteur schlägt vor, den Prozentsatz durch t=y zu ersetzen und das Ergebnis „den gleichen Zehn-Prozent-Piloten“ zu nennen. Der Prüfer lehnt diese Beschreibung ab: Die aktuelle Testsemantik fordert eine Quarantäne für fehlgeschlagene Nachrichten gemäß einer ausgewählten Ablehnungsrichtlinie, anstatt zehn Prozent für die Ablehnung auszuwählen.
Die vorgeschlagene Matrix enthält eine Spalte für die aktuelle Semantik, eine Spalte für die Legacy-Implementierung und eine Beobachtungsspalte. Der erste kann aus der Spezifikation ausgefüllt werden; Die anderen Spalten erfordern identifizierte Implementierungen und autorisierte Tests. Sie bleiben in diesem Beispiel nicht ausgeführt. Für die Übung wurde kein DNS Eintrag veröffentlicht, der Empfänger abgefragt oder eine Nachricht zugestellt.
Die nächste Entscheidung besteht darin, sich auf das eigentliche Experiment zu einigen, beispielsweise das Testen einer spezifizierten Handhabung unter Beobachtung repräsentativer legitimer Abläufe, anstatt eine ungenaue Kennzeichnung beizubehalten. Die Organisation muss dann die Beweise sammeln, die dieses Experiment stützen, bevor sie einen Produktionsübergang genehmigt.
Halten Sie die Beweismittelschleusen sichtbar
Die genaue ursprüngliche Anforderung bleibt offen: Vergleichen Sie einen alten PCT-basierten Plan mit der aktuellen Testsemantik und älteren/aktuellen Empfängerbeobachtungen. Das fiktive Arbeitsblatt liefert keine bereitgestellten Beobachtungen und kann diese Anforderung nicht abschließen. Auch der Inbetriebnahme-Gate bleibt sichtbar: Validieren Sie aktuelle Primärspezifikationen und bewahren Sie ein ausgearbeitetes Beispiel vor dem Entwurf auf. Der Primärtext und ein fiktionaler Vorentwurf wurden beibehalten; Die Anwendbarkeit der Umsetzung, die menschliche KMU-Genehmigung und etwaige Betriebsfreigaben bleiben ungeklärt. Durch dieses Manuskript wird keine Veröffentlichung oder Änderung der Richtlinien genehmigt.