Ein generierter Datensatz ist ein Entscheidungsartefakt
A DMARC Eintrag Der Generator kann eine vorgeschlagene Richtlinie formatieren, aber nicht entscheiden, welche legitimen Absender die Organisation hat, welches Geschäftsrisiko sie akzeptiert oder ob ein Berichtsziel autorisiert ist. Die Ausgabe sollte jede politische Entscheidung und die dahinter stehenden Annahmen erläutern. Eine kopierbare Zeichenfolge ohne diese Entscheidungen kann die Veröffentlichung einer syntaktisch plausiblen Richtlinie fördern, die nicht zu den tatsächlichen E-Mail-Flüssen der Organisation passt.
RFC 9989 Definiert das aktuelle Richtlinienformat und den aktuellen Mechanismus. In diesem Artikel werden Anforderungen an einen Generator und eine Überprüfung der kommentierten Ausgabe vorgeschlagen. Es wird nicht behauptet, dass EmailAuth einen Generator implementiert, einen produktionsbereiten Datensatz erstellt oder DNS ändert. Die erforderlichen Originaltestfälle und Betriebsnachweise bleiben vom Erläuterungsrahmen getrennt.
Legen Sie die Richtliniendomäne und den Besitz fest
Erfassen Sie die Domäne, für die die Richtlinie erstellt wird, den Geschäftsinhaber, den Eigentümer DNS Veröffentlichung und die legitimen Sendeworkflows im Geltungsbereich. Unterscheiden Sie den genauen Besitzernamen, unter dem eine Richtlinie veröffentlicht würde, von den Domänenidentitäten, die von den Absendern verwendet werden. Ein Generator sollte nicht stillschweigend eine übergeordnete oder untergeordnete Domäne basierend auf einer Anzeigebezeichnung oder einer angenommenen Organisationsgrenze auswählen.
Die aktuelle Richtlinienerkennung umfasst die DNS Tree Walk beschrieben von RFC 9989. Die Anmerkung des Generators sollte den beabsichtigten Umfang und alle vererbungsbezogenen Annahmen erläutern, die überprüft werden müssen, anstatt dies zu versprechen ein Rekord wirkt sich nur auf die vom Benutzer eingegebene Adresse aus. Das tatsächlich anwendbare Verhalten hängt von der Standard- und Empfängerimplementierung ab. Während dieser Arbeit wurde keine Domänenhierarchie oder vorhandene Richtlinie abgefragt.
Erläutern Sie die angeforderte Richtlinie und Bereitschaft
Die angeforderte Richtlinie drückt die Bewertungspräferenz des Domaininhabers gemäß dem Protokoll aus; Es ist keine Garantie für die endgültige Entscheidung des Empfängers oder eine Aussage darüber, dass jeder legitime Absender bereit ist. Bevor Sie eine Durchsetzung empfehlen, fordern Sie eine Überprüfung der Bereitschaft jedes einzelnen Senders und eine autorisierte Entscheidung über verbleibende Fehler. Ein Generator kann Entscheidungen und Konsequenzen präsentieren, aber er sollte nicht die dahinter stehende Geschäftsgenehmigung erfinden.
Erklären Ausrichtung Auswahlmöglichkeiten getrennt vom Schweregrad der Richtlinie festlegen. Die sichtbare Absenderdomäne, authentifiziert SPF Identität und DKIM Unter der signierenden Domäne sind Beziehungen definiert DMARC. Strikte und lockere Ausrichtung sind nicht nur Bezeichnungen für stärkere und schwächere Gesamtsicherheit; Ihre betrieblichen Auswirkungen hängen von der Domänenstruktur und den Sendediensten der Organisation ab. Behalten Sie die ausgewählte Begründung und die ungelösten Abhängigkeiten in der kommentierten Ausgabe bei.
Behalten Sie die aktuelle Version und Tag-Semantik bei
RFC 9989 gibt weiterhin den Versionswert DMARC1 an, bei dem zwischen Groß- und Kleinschreibung unterschieden wird. Ein Generator sollte kein neues Standarddokument als Umstellung auf DMARC2 ankündigen. Die erforderliche Position und der erforderliche Wert des Versions-Tags sollten entsprechend dem aktuellen Format validiert werden. Unbekannte Tags müssen von der Protokollverarbeitung gemäß der formalen Definition ignoriert werden, daher sollte das Tool eine Warnung über nicht unterstützte Tags von einer erfundenen Regel unterscheiden, die besagt, dass jedes unbekannte Tag die gesamte Richtlinie ungültig macht.
Anhang A.6 erklärt die Entfernung von pct und die Einführung von t mit y- und n-Werten. Ein aktueller Generator sollte keinen veralteten Prozentsatz-Schieberegler weiterführen, als wäre es eine aktuelle normative Kontrolle, und auch nicht davon ausgehen, dass das Ersetzen jedes historischen Prozentsatzes durch t eine sichere universelle Migration ist. Es sollte den angestrebten Standard, die genaue Testsemantik und die Kompatibilitätsfragen dokumentieren, die für die vorgesehene Umgebung noch offen sind.
Behandeln Sie Meldeziele als genehmigte Empfänger
RFC 9990 Definiert die aggregierte Berichterstattung und Überprüfung externer Ziele. Ein Generator sollte erklären, dass das Veröffentlichen einer Berichtsanforderung und das Empfangen von Berichten unterschiedliche Schritte sind. Es sollte den vorgeschlagenen Empfänger, den Datenzweck und die Frage angeben, ob die entsprechende Genehmigung für externe Ziele vorliegt. Schließen Sie nicht auf eine Autorisierung ab, nur weil ein Benutzer eine Adresse in ein Formular eingefügt hat.
Dieser Artikel gibt keine Meldeadresse an, veröffentlicht keinen Autorisierungsdatensatz und sendet keine Daten an Dritte. Eine vorgeschlagene Ausgabe sollte eindeutig nicht betriebsbereite Platzhalter verwenden, bis ein Ziel genehmigt wird. In der Anmerkung sollte auch darauf hingewiesen werden, dass die Verfügbarkeit von Berichten von Empfängern und Zustellung abhängt. Daher ist die Angabe eines URI keine Garantie für vollständige Beobachtungen. Sofern Optionen zur Fehlerberichterstattung angeboten werden, erfordern sie eine eigene unterstützte Spezifikation und Datenschutzprüfung, anstatt sie beiläufig in einer aggregierten Berichtsumgebung zu bündeln.
Erläutern Sie den Umgang mit vorhandenen Datensätzen und Duplikaten
Ein Generator sollte fragen, in welcher Beziehung die vorgeschlagene Richtlinie zum bestehenden veröffentlichten Status steht. Die Erstellung eines zweiten Richtlinienkandidaten beim gleichen Eigentümer kann zu einem anderen Ergebnis führen als das Ersetzen eines genehmigten vorhandenen Datensatzes. Die Ausgabe sollte daher den beabsichtigten genauen Unterschied beschreiben und das Wiederherstellungsmaterial beibehalten, und nicht einfach sagen, dass man dies hinzufügen soll TXT Eintrag. Vorhandene, nicht verwandte TXT Daten sollten nicht als Nebeneffekt der Richtlinienerstellung gelöscht werden.
RFC 1035 Definiert TXT Datensatzstruktur. Mehrere Zeichenfolgen innerhalb eines TXT Eintrags sind nicht dasselbe wie mehrere Richtlinieneinträge. Die Anmerkungen und Tests sollten diese Unterscheidung wahren, damit die Anzeige eines Editors den Bediener nicht irreführt. Hier wurde kein vorhandener DNS Status überprüft; Der Umgang mit Duplikaten bleibt eine vorgeschlagene Testanforderung und kein verifiziertes Ergebnis.
Ein Arbeitsblatt mit kommentierter Ausgabe
Erstellen Sie ein Arbeitsblatt mit der Richtliniendomäne, dem Veröffentlichungseigentümer, dem vorgeschlagenen Datensatz, der Bedeutung jedes Tags, der ausgewählten Begründung, den erforderlichen Nachweisen und dem Genehmigungseigentümer. Fügen Sie einen Verweis auf den vorhandenen Status, den genauen beabsichtigten Unterschied, die Autorisierung des Berichtsempfängers, Kompatibilitätsbeschränkungen, einen Überprüfungsplan und Rollback-Kriterien hinzu. Halten Sie die generierte Syntax getrennt vom Genehmigungs- und Veröffentlichungsstatus. Ein ausgefülltes Formular sollte nicht automatisch die Erlaubnis bedeuten, eine Live-Änderung vorzunehmen.
Der erforderliche Fixture-Satz sollte einen positiven gültigen Fall, Fälle mit ungültiger Version oder erforderlichem Format, doppelte Richtlinienkandidaten und nicht unterstütztes Tag-Verhalten umfassen. Geben Sie die erwarteten Ergebnisse der aktuellen Norm und die Präsentationsregeln des Produkts separat an. Behalten Sie die Generatorversion, den Testeingang und den beobachteten Ausgang bei, wenn autorisierte Tests später ausgeführt werden. Dieser Entwurf hat diese Vorrichtungen nicht generiert oder ausgewertet und erhebt keinen Anspruch auf Implementierungskonformität.
Fiktive Diagnose: Ein Prozentschieber verbirgt die Entscheidung
Ein fiktives Team verwendet ein altes Richtlinienformular mit einem Prozentschieberegler und geht davon aus, dass die Auswahl einer kleineren Zahl jede Durchsetzungsänderung sicher macht. Der Prüfer fragt, welchen Standard das Formular implementiert, wie hoch die legitime Absenderbereitschaft der Organisation ist und wie sich die vorgeschlagene Ausgabe bei relevanten Empfängern verhält. Das Erscheinungsbild des Steuerelements beantwortet diese Fragen nicht.
Die vorgeschlagene Reaktion besteht darin, aktuelles, mit Standards verknüpftes Verhalten zu ermitteln, die Richtlinienentscheidung zu dokumentieren und einen genauen Änderungsplan zu überprüfen, anstatt den Schieberegler mechanisch in ein anderes Tag zu übersetzen. Dieses Verhalten wird keinem echten Erzeuger oder Anbieter vorgeworfen. Die Übung ist fiktiv, es werden weder Datensätze generiert noch DNS Änderungen durchgeführt oder ein Empfängertest durchgeführt. Es verdeutlicht, warum neben der Syntax auch die politische Begründung sichtbar bleiben muss.
Fordern Sie Beweise an, bevor Sie die Ausgabe als bereit bezeichnen
Ein nützliches Generatorergebnis gibt an, welche Eingaben geliefert wurden, welche Annahmen bestehen bleiben und was vor der Veröffentlichung passieren muss. Es kann einem qualifizierten Eigentümer helfen, eine konsistente Entscheidung zu treffen, ohne zu behaupten, dass formatierter Text eine sichere Durchsetzung gewährleistet. Die letzte Autorität verbleibt beim genehmigten geschäftlichen und technischen Änderungsprozess.
Der Katalog erfordert einen mit Anmerkungen versehenen Datensatz sowie positive, ungültige, doppelte und nicht unterstützte Tag-Testfälle. Diese Originalartefakte bleiben offen. Auch die Prüfung durch menschliche Spezialisten, die Anwendbarkeit der Quelle, die Produktionswege, die Zugänglichkeit und die Freigabe durch den Eigentümer bleiben offen. Dieser Entwurf enthält ein vorgeschlagenes Arbeitsblatt und eine fiktive Diagnose, keine zur Veröffentlichung bereite Richtlinie, abgeschlossene Tests oder überprüfte Funktionen EmailAuth -Tools.