Un analyseur qui accepte un bon rapport XML n'a réussi qu'un test restreint. Une suite de validation utile vérifie ce qu'elle extrait, ce qu'elle rejette, comment elle gère les variations prises en charge et si les nouvelles tentatives modifient les totaux. Traitez les valeurs normalisées attendues comme faisant partie du montage, et non comme un résultat que le test est autorisé à inventer.
Déclarer le contrat pris en charge
Références : RFC 9990 §3.1.1, RFC 9990 §3.2.
Enregistrez les versions de l'analyseur, du runtime, du décompresseur et du schéma. Indiquez quels formats et extensions de rapport sont pris en charge et comment les entrées héritées sont gérées. RFC 9990 définit le format d'agrégation et le modèle d'extension actuels ; la prise en charge des anciens formats est une décision de compatibilité distincte.
Construisez d’abord un appareil valide minimal. Enregistrez ses octets, son hachage, ses métadonnées attendues, son intervalle, son adresse IP source, son nombre, ses identités et ses résultats alignés. Ne considérez pas une analyse XML réussie comme suffisante : vérifiez les types et les significations des champs. Conservez les valeurs facultatives manquantes distinctes des données obligatoires non valides.
Testez les erreurs sémantiques courantes
Références : RFC 9990 §3.1.1.9, RFC 9990 §3.1.1.11, RFC 9989 §5.3.5.
Inclure brut DKIM passer sous un domaine non lié avec un échec DKIM aligné, et brut SPF passer sans alignement. Incluez un cas où un mécanisme aligné réussit tandis que l'autre échoue. Vérifiez que le résultat normalisé n’exige pas que les deux mécanismes réussissent ou n’assimile pas le succès brut à l’alignement.
Ajoutez une disposition signalée qui diffère d’une inférence simpliste issue d’une politique publiée. Conserver les motifs de remplacement disponibles. Pour le schéma actuel, incluez la valeur ActionDispositionType plutôt que de la rejeter en tant que valeur héritée inconnue ; RFC 9990 Annexe A le définit pour passer DMARC avec une politique d’application. Séparez explicitement les attentes liées aux formats hérités. Testez plusieurs résultats DKIM sans supprimer toutes les signatures sauf la première. Le but est de préserver ce que dit le rapport, et non de fabriquer une nouvelle évaluation du récepteur à partir de données incomplètes.
Exercer des dossiers structurels et de sécurité
Références : RFC 9990 §3.2, RFC 9990 §8.1.
Référence: Prévention des entités externes XML OWASP, conseils généraux.
Utilisez des valeurs requises non valides, du XML mal formé, des extensions d'espace de noms prises en charge, des versions non prises en charge, des éléments facultatifs manquants et une imbrication délimitée excessive. Testez les limites de taille compressées et étendues, les entrées interrompues et les sentinelles de référence externes inoffensives de manière isolée. Définissez si chaque entrée est acceptée, mise en quarantaine ou rejetée et pourquoi.
Une extension prise en charge ne doit pas disparaître silencieusement si une analyse en aval prétend la préserver. Une construction non prise en charge devrait produire un résultat de compatibilité explicite plutôt que d'être reclassée comme échec d'authentification. Gardez les tests de sécurité petits et limités en ressources ; ne générez pas de charges de travail destructrices simplement pour démontrer une limite.
Vérifier le comportement des doublons et des transactions
Références : RFC 9990 §3.5.4.
Importez un appareil, rejouez-le et redémarrez le travailleur avant de rejouer à nouveau. Le rapport comptabilisé doit rester unique selon la règle des doublons documentés. Ajoutez une pièce jointe différente revendiquant la même identité de rapport et exigez une décision explicite de conflit. Les pièces d’identité identiques ne suffisent pas à elles seules à exclure des preuves différentes sans examen.
Injectez une interruption contrôlée avant de valider. Confirmez qu'aucun enregistrement partiel n'affecte les métriques de production et qu'une nouvelle tentative autorisée donne le résultat attendu une fois. Testez les sorties d'observation nulle comme étant indisponibles plutôt que de les diviser par zéro ou de fabriquer un taux de réussite parfait.
Travailler sur une ligne d'acceptation
Le luminaire synthétique F1 contient 90 observations avec passe DKIM alignée et dix sans mécanisme de passage aligné. Son nombre inclus attendu est de 100 et le nombre de passes observées attendu est de 90. La relecture de F1 doit laisser les deux valeurs inchangées. Une copie volontairement tronquée doit être rejetée sans augmenter ni l'un ni l'autre des totaux.
Enregistrez les valeurs attendues avant l'exécution. Comparez les résultats réels, les mesures des ressources et les diagnostics avec cette référence. Il s'agit d'une spécification d'acceptation de l'analyseur, et non d'une affirmation selon laquelle un analyseur commercial ou locataire l'a réussi. Un nouveau modèle arithmétique/relecture hors ligne distinct vérifie les valeurs 100/90 et les comptes inchangés sur les identités répétées ; il n'analyse ni ne valide un rapport XML RFC 9990 . Si un cas échoue, conservez le défaut et le montage exact afin qu'une révision ultérieure puisse le reproduire.
Changements de porte sur les résultats enregistrés
Conservez une matrice contenant l'ID de l'appareil, le hachage, l'objectif, le résultat attendu, le résultat réel, la configuration de l'analyseur et la décision de révision. Exiger que tous les cas obligatoires soient réussis au niveau de la révision déployée, avec des exceptions documentées pour les fonctionnalités non prises en charge. Réexécutez après des modifications de dépendance ou de normalisation et comparez les effets des métriques historiques avant de retraiter les rapports stockés. La validation de l'analyseur doit protéger à la fois la disponibilité du système et la signification des chiffres utilisés pour les décisions politiques.