Évitez l'examen tout ou rien
Une page d'aide d'un fournisseur peut toujours citer RFC 7489 tout en décrivant avec précision un écran de compte courant ou un itinéraire d'envoi pris en charge. À l’inverse, une page nouvellement datée peut répéter des conseils de protocole historiques. L’unité de révision utile est l’instruction ou la revendication individuelle, et non l’ancienneté de la citation seule. Un auditeur doit identifier ce qui reste valable, ce que les normes actuelles ont modifié et ce qui dépend de la mise en œuvre réelle par le prestataire.
RFC 9989 fournit le noyau actuel DMARC spécification et décrit les modifications par rapport à RFC 7489 . Les rapports d'agrégation et de défaillance sont désormais spécifiés séparément dans RFC 9990 et RFC 9991. Utilisez ces sources pour évaluer les déclarations de protocole, mais ne les traitez pas comme une preuve qu'un fournisseur a déjà modifié chaque champ de l'interface utilisateur ou déployé un évaluateur. RFC 9989 , Annexe C; RFC 9990 , section 1; RFC 9991 , section 1
Préserver le contexte exact du produit
Avant d'annoter un guide, enregistrez son URL, la date de conservation, le produit, le plan ou la portée du compte là où cela est indiqué, la région, l'itinéraire et les conditions préalables pertinentes. Une marque de fournisseur peut contenir plusieurs produits de messagerie avec différents chemins de configuration. Un guide pour une route SMTP personnalisée peut ne pas s'appliquer à une route API par défaut, et les instructions pour un produit de messagerie hébergé peuvent ne pas couvrir un autre produit de la même société.
Gardez les valeurs générées par le compte distinctes des exemples explicatifs. Un échantillon de guide sélecteur ou la cible DNS ne doit pas être copiée en tant que valeur de production universelle. De même, une instruction d’interface utilisateur peut rester utile même lorsque l’explication des normes qui l’entourent doit être mise à jour. Préservez cette distinction afin que le lecteur ne rejette pas une condition préalable à l'intégration valide simplement parce qu'un RFC historique apparaît dans l'introduction.
Ce manuscrit ne vérifie pas le compte courant d'un fournisseur nommé et n'affirme pas qu'un service spécifique n'est pas conforme. Il fournit une méthode pour un futur examen fondé sur la source. Toute instruction réelle sur le produit doit être vérifiée par rapport à un guide principal lisible et au contexte du compte autorisé avant d'être présentée comme applicable.
Classer chaque instruction par autorité
Utilisez au moins quatre catégories d'annotations : flux de travail du produit, exigences du protocole, éligibilité ou politique spécifique au fournisseur et recommandation explicative. Les flux de travail des produits nécessitent des preuves actuelles du fournisseur. Les exigences du protocole nécessitent la section de spécification appropriée. L'éligibilité du fournisseur peut être plus stricte ou d'une portée différente que le minimum du protocole et ne doit pas être généralisée à chaque destinataire. Les recommandations doivent divulguer leur justification et leurs limites.
Pour chaque ligne, écrivez l'acteur et la condition. Le comportement de découverte de politique d'un destinataire est différent de la tâche de publication DNS d'un propriétaire de domaine. Une exigence de configuration d'un champ de compte particulier peut être nécessaire pour ce service sans modifier la syntaxe d'enregistrement de la norme. L’autorisation de réception d’une destination de rapport est distincte de la demande de l’expéditeur d’y envoyer des rapports.
Lorsqu'une phrase combine des catégories, divisez-la. Par exemple, une instruction visant à saisir une adresse de reporting peut constituer une étape valide de l'interface utilisateur, tandis qu'une affirmation selon laquelle toute adresse externe reçoit automatiquement des rapports est incomplète. La révision devrait préserver l'étape utile et joindre la condition d'autorisation manquante plutôt que de remplacer l'ensemble du guide par des conseils génériques.
Comparez les concepts modifiés spécifiques
La valeur actuelle de la version principale DMARC reste DMARC1 . Une révision ne doit pas inventer un enregistrement DMARC2 ou impliquer que la mise à jour d'une citation RFC nécessite un changement de version DNS . La spécification actuelle documente également la suppression de PCT, tandis que le registre IANA conservé marque cette balise comme historique. Ces faits corroborent l’affirmation selon laquelle PCT est un contrôle d’échantillonnage standard actuel sans prouver comment chaque fournisseur déployé le gère.
La découverte de politiques et la détermination du domaine organisationnel nécessitent également une comparaison avec la spécification actuelle plutôt qu'avec un ancien algorithme simplifié. Les déclarations de rapport doivent être vérifiées par rapport à RFC 9990 ou RFC 9991 selon le cas. Enregistrez la différence exacte et sa signification opérationnelle ; n'utilisez pas "DMARCbis a tout changé » en remplacement d’une évaluation au niveau de la section. RFC 9989 , sections 4.7, 4.10 et annexe A.6; Registre des balises IANA DMARC
Feuille de travail d'annotation et critères d'acceptation
Créez une feuille de travail contenant l'extrait du guide, l'instantané de la source, la portée du produit, la catégorie d'instructions, l'autorité actuelle, l'annotation proposée et les preuves de mise en œuvre encore requises. Attribuez l'un des quatre résultats suivants : conservé le cas échéant, conservé avec une note de portée, mis à jour parce que la revendication des normes a changé ou non résolu en attente de preuves du fournisseur. Il s’agit là de résultats éditoriaux et non d’affirmations selon lesquelles un système de production aurait réussi un test.
La feuille de travail doit également identifier le propriétaire qui peut confirmer les valeurs spécifiques au compte et tout test autorisé séparément nécessaire pour établir le comportement. Si le guide du fournisseur est inaccessible, étiquetez l'écart source plutôt que de remplacer une séquence de configuration générique et de la qualifier de vérifiée.
L'acceptation nécessite que chaque annotation repose sur sa propre preuve. Un évaluateur devrait être en mesure de voir pourquoi une étape de navigation sur écran a été conservée alors qu'une explication de protocole a été révisée. Conservez l'extrait original et la formulation proposée afin que le changement n'introduise pas accidentellement un nouvel engagement, une fonctionnalité non prise en charge ou une promesse de délivrabilité universelle.
Revue fictive d'une page de configuration citée par un héritage
Imaginez une page de fournisseur fictive avec trois instructions : saisissez le nom généré par le compte. DKIM enregistrements, ajoutez une adresse de reporting via l'écran des paramètres et utilisez PCT comme contrôle de déploiement de la norme actuelle. La page cite RFC 7489 . Aucune page nommée de ce type n’a été auditée ici ; ces instructions inventées illustrent la méthode de classification.
L'étape DKIM peut rester valide si la documentation actuelle du produit et les valeurs du compte la prennent en charge. L'étape d'adresse de reporting peut rester valide en tant qu'action d'interface utilisateur tout en nécessitant une explication d'autorisation externe supplémentaire. La déclaration PCT nécessiterait une annotation conforme aux normes actuelles, tandis que la gestion réelle de ce champ par le fournisseur resterait une question de mise en œuvre. Une seule citation conduit donc à trois résultats de revue différents.
L'action suivante proposée consiste à conserver les instructions du produit pris en charge, à corriger le langage des normes et à obtenir des preuves spécifiques au fournisseur pour un comportement non résolu. Il ne s’agit pas de supprimer tous les enregistrements existants, de contourner les exigences de configuration ou de déclarer le fournisseur non sécurisé. L’exemple fictif montre à quel point un examen minutieux peut être utile sans revendiquer excessivement l’accès ou les résultats des tests.
Séparer les versions opérationnelles et éditoriales
Une mise à jour éditoriale peut améliorer un guide avant que la vérification de la production ne soit terminée, à condition que ses limites soient visibles. Ne décrivez pas un document annoté comme preuve qu'un compte réel est correctement configuré. À l’inverse, un test de compte réussi ne doit pas être généralisé à chaque forfait client, région ou implémentation de récepteur.
Le catalogue nécessite des annotations identifiant quelles étapes restent valides, lesquelles ont changé et lesquelles dépendent de la mise en œuvre du fournisseur. Un véritable guide annoté spécifique à la source reste ouvert pour ce projet. Aucun déploiement actuel de fournisseur nommé, navigation de compte, modification DNS ou test de message n'est revendiqué. La porte des preuves originales et les cinq autres portes de libération restent ouvertes.
Avant la publication opérationnelle, obtenez la source lisible réelle du fournisseur et conservez les extraits exacts, les dates de source et les références aux normes actuelles. Un réviseur qualifié doit vérifier que chaque instruction retenue correspond à la portée du produit et que le comportement de mise en œuvre non résolu reste non résolu. Cette approche produit un guide utilisable sans prétendre qu’une ancienne citation prouve à elle seule soit l’exactitude, soit l’échec.