Un enregistrement généré est un artefact de décision
A Enregistrement DMARC Le générateur peut formuler une proposition de politique, mais il ne peut pas décider quels sont les expéditeurs légitimes de l'organisation, quel risque commercial elle accepte ou si une destination de reporting est autorisée. Le résultat doit expliquer chaque choix politique et les hypothèses qui le sous-tendent. Une chaîne copiable sans ces décisions peut encourager la publication d'une politique syntaxiquement plausible qui ne correspond pas aux flux de messagerie réels de l'organisation.
RFC 9989 définit le format et le mécanisme actuels de la politique. Cet article propose les exigences pour un générateur et une révision des résultats annotés. Il ne prétend pas EmailAuth implémente un générateur, produise un enregistrement prêt pour la production ou modifie DNS . Les cas de test originaux requis et les preuves opérationnelles restent distincts du cadre explicatif.
Établir le domaine politique et la propriété
Enregistrez le domaine pour lequel la politique est en cours de préparation, le propriétaire de l'entreprise, le propriétaire de la publication DNS et les flux de travail d'envoi légitimes concernés. Distinguez le nom exact du propriétaire où une stratégie serait publiée des identités de domaine utilisées par les expéditeurs. Un générateur ne doit pas choisir silencieusement un domaine parent ou enfant en fonction d'une étiquette d'affichage ou d'une limite organisationnelle supposée.
La découverte actuelle des politiques inclut le Promenade dans l'arborescence DNS décrit par RFC 9989. L'annotation du générateur doit expliquer la portée prévue et toutes les hypothèses liées à l'héritage qui doivent être révisées, plutôt que de promettre que un enregistrement affecte uniquement l’adresse saisie par l’utilisateur. Le comportement réellement applicable dépend de la norme et de l'implémentation du récepteur. Aucune hiérarchie de domaine ou politique existante n'a été interrogée lors de ce travail.
Expliquer la politique demandée et l'état de préparation
La politique demandée exprime la préférence d'évaluation du propriétaire du domaine dans le cadre du protocole ; cela ne constitue pas une garantie de la décision finale du destinataire ni une déclaration selon laquelle chaque expéditeur légitime est prêt. Avant de recommander l’application, exigez un examen de l’état de préparation de chaque expéditeur et une décision autorisée concernant les échecs restants. Un générateur peut présenter des choix et des conséquences, mais il ne doit pas inventer l'approbation commerciale qui les sous-tend.
Expliquer alignement choix séparément de la sévérité des politiques. Le domaine visible From, authentifié SPF l'identité et DKIM le domaine de signature a défini des relations sous DMARC. Un alignement strict et détendu ne sont pas simplement des étiquettes pour une sécurité globale plus forte ou plus faible ; leurs implications opérationnelles dépendent de la structure des domaines et des services d'envoi de l'organisation. Conservez la justification sélectionnée et les dépendances non résolues dans la sortie annotée.
Conserver la version actuelle et la sémantique des balises
RFC 9989 spécifie toujours la valeur de version sensible à la casse DMARC1 . Un générateur ne doit pas annoncer un nouveau document de normes comme un passage à DMARC2. La position et la valeur requises de la balise de version doivent être validées en fonction du format actuel. Les balises inconnues doivent être ignorées par le traitement du protocole selon la définition formelle, de sorte que l'outil doit distinguer un avertissement de balise non prise en charge d'une règle inventée selon laquelle chaque balise inconnue invalide l'ensemble de la politique.
L'annexe A.6 explique la suppression de PCT et l'introduction de t avec les valeurs y et n. Un générateur actuel ne devrait pas conserver un curseur de pourcentage obsolète comme s’il s’agissait d’un contrôle normatif actuel, ni supposer que le remplacement de chaque pourcentage historique par t constitue une migration universelle sûre. Il doit documenter la norme qu'il cible, la sémantique exacte des tests et les questions de compatibilité qui restent en suspens pour l'environnement prévu.
Traitez les destinations de reporting comme des destinataires approuvés
RFC 9990 définit la déclaration globale et la vérification des destinations externes. Un générateur doit expliquer que la publication d'une demande de rapport et la réception de rapports sont des étapes différentes. Il doit identifier le destinataire proposé, la finalité des données et si l'autorisation de destination externe applicable est en place. Ne déduisez pas une autorisation simplement parce qu’un utilisateur a collé une adresse dans un formulaire.
Cet article ne fournit pas d'adresse de déclaration, ne publie pas d'enregistrement d'autorisation et n'envoie pas de données à un tiers. Un résultat proposé doit utiliser des espaces réservés clairement non opérationnels jusqu'à ce qu'une destination soit approuvée. L'annotation doit également indiquer que la disponibilité du rapport dépend des récepteurs et de la livraison, donc l'inclusion d'un URI ne garantit pas des observations complètes. Les choix de rapport d'échec, s'ils sont proposés, nécessitent leur propre spécification prise en charge et leur propre examen de confidentialité plutôt que d'être regroupés de manière informelle dans un paramètre de rapport global.
Expliquer la gestion des enregistrements existants et des doublons
Un générateur doit se demander quel est le lien entre la politique proposée et l'état publié existant. La production d’un deuxième candidat de politique chez le même propriétaire peut créer un résultat différent du remplacement d’un enregistrement existant approuvé. Le résultat doit donc décrire la différence exacte prévue et préserver le matériel de restauration, pas simplement dire d'ajouter ceci Enregistrement TXT. Les données TXT existantes non liées ne doivent pas être supprimées en tant qu’effet secondaire de la génération de politiques.
RFC 1035 définit la structure de l'enregistrement TXT . Plusieurs chaînes dans un enregistrement TXT ne sont pas identiques à plusieurs enregistrements de stratégie. L'annotation et les tests doivent préserver cette distinction afin que l'affichage d'un éditeur n'induise pas l'opérateur en erreur. Aucun état DNS existant n’a été inspecté ici ; la gestion des doublons reste une exigence de test proposée plutôt qu'un résultat vérifié.
Une feuille de travail annotée
Créez une feuille de travail avec le domaine politique, le propriétaire de la publication, l'enregistrement proposé, la signification de chaque balise, la justification sélectionnée, les preuves préalables et le propriétaire de l'approbation. Ajoutez une référence à l'état existant, la différence exacte prévue, l'autorisation du destinataire du rapport, les limitations de compatibilité, le plan de vérification et les critères de restauration. Gardez la syntaxe générée séparée du statut d’approbation et de publication. Un formulaire rempli ne doit pas automatiquement impliquer l’autorisation d’effectuer une modification en direct.
L'ensemble de luminaires requis doit inclure un cas valide positif, une version non valide ou des cas au format requis, des candidats de politique en double et un comportement de balise non pris en charge. Indiquer séparément les résultats attendus de la norme actuelle et les règles de présentation du produit. Conservez la version du générateur, l’entrée du test et la sortie observée lorsque des tests autorisés sont exécutés ultérieurement. Ce projet n'a pas généré ni évalué ces appareils et ne fait aucune déclaration de conformité de mise en œuvre.
Diagnostic fictif : un curseur de pourcentage masque la décision
Une équipe fictive utilise un ancien formulaire de politique avec un curseur de pourcentage et suppose que la sélection d'un nombre plus petit rend toute modification d'application sûre. L'examinateur demande quelle norme le formulaire met en œuvre, quel est le niveau de préparation légitime de l'expéditeur de l'organisation et comment le résultat proposé se comportera chez les destinataires concernés. L'apparence du contrôle ne répond pas à ces questions.
La réponse proposée consiste à obtenir le comportement actuel lié aux normes, à documenter la décision politique et à vérifier un plan de changement exact plutôt que de traduire mécaniquement le curseur dans une autre balise. Aucun véritable générateur ou fournisseur n'est accusé de ce comportement. L'exercice est fictif, sans enregistrement généré, ni modification DNS ni test du récepteur effectué. Cela illustre pourquoi la logique politique doit rester visible aux côtés de la syntaxe.
Exiger des preuves avant d'appeler la sortie prête
Un résultat de générateur utile indique quelles entrées ont été fournies, quelles hypothèses demeurent et ce qui doit se produire avant la publication. Cela peut aider un propriétaire qualifié à prendre une décision cohérente sans prétendre que le texte formaté établit une application sûre. L'autorité finale reste celle du processus de changement commercial et technique approuvé.
Le catalogue nécessite un enregistrement annoté et des cas de test positifs, invalides, en double et avec des balises non prises en charge. Ces artefacts originaux restent ouverts. L'examen par un spécialiste humain, l'applicabilité des sources, les itinéraires de production, l'accessibilité et la libération par le propriétaire restent également ouverts. Ce projet fournit une proposition de feuille de travail et un diagnostic fictif, et non une politique prête à publier, des tests terminés ou des fonctionnalités vérifiées de l'outil EmailAuth .