Définir l’adoption et la disponibilité comme des mesures distinctes
MTA-STS l'adoption peut faire référence à la découverte DNS , à la récupération d'une politique syntaxiquement valide, à la publication d'un mode d'application ou à la compatibilité observée avec la route MX de réception du domaine. La disponibilité de l'hôte de stratégie est une autre propriété : elle concerne si le point de terminaison HTTPS était accessible et valide au moment de l'observation. Une étude devrait définir ces mesures séparément au lieu de considérer une seule tentative réussie comme une adoption complète de la sécurité des transports.
RFC 8461 définit la découverte MTA-STS , la récupération des politiques, la validation et la mise en cache. Il prend en charge une conception de mesure reproductible, et non une affirmation selon laquelle un ensemble de données existe. Cet article ne contient aucune analyse de domaine, aucun pourcentage de disponibilité, aucun test de connexion ou aucune conclusion longitudinale. Tous les exemples sont explicitement hypothétiques.
Établir la population du domaine de réception
MTA-STS concerne la route de messagerie du domaine destinataire. Une liste de sites Web, de marques d’expéditeurs sortants ou d’organisations clientes ne constitue pas automatiquement une liste appropriée de domaines de réception. Définir l'unité, la méthode de sélection et les exclusions avant la collecte. Enregistrez si l'échantillon inclut des domaines sans route de messagerie utilisable et comment ces cas affectent chaque métrique plutôt que de les supprimer silencieusement.
Gelez la liste d'entrée et conservez sa source, sa date, ses règles de normalisation et son hachage. Si la liste change entre les exécutions, conservez l’historique des adhésions. Un domaine entrant ou sortant de l'échantillon peut modifier l'adoption apparente sans aucun changement dans sa politique. N’appelez pas un échantillon de convenance une estimation globale à moins que le plan d’échantillonnage ne conforte cette inférence. Ce manuscrit ne fournit pas une telle estimation.
Séparer la découverte DNS de la récupération HTTPS
RFC 8461 définit l'enregistrement de découverte chez le propriétaire _mta-sts et l'emplacement de récupération de la politique sous l'hôte mta-sts sur le chemin bien connu. L'identifiant de découverte signale les changements de politique ; il ne s'agit pas d'une empreinte digitale de certificat ni d'une preuve que le point de terminaison fonctionne actuellement. Enregistrez la réponse DNS , le propriétaire, le résolveur et l'heure indépendamment de l'observation HTTPS ultérieure.
La norme exige HTTP 200 OK pour la récupération de la stratégie et indique que les expéditeurs ne doivent pas suivre les redirections HTTP dans cette procédure de récupération. Il indique également que les expéditeurs ne doivent pas utiliser la mise en cache HTTP pour la récupération des politiques, contrairement à la mise en cache des politiques MTA-STS . La méthode doit préserver l’état de la réponse et le comportement de redirection plutôt que d’accepter toute destination de navigateur qui semble réussie. Aucun point de terminaison n'a été récupéré ni redirigé suivi au cours de ce travail.
Valider la politique et la connexion selon les règles indiquées
La politique contient la version, le mode, les modèles MX et l'âge maximum selon la syntaxe RFC 8461 . Conservez les octets réels et la version de l'analyseur. Une stratégie utilisant le mode test n’est pas la même catégorie mesurée que le mode application. Une politique d'absence est un autre état qui devrait être nommé plutôt que réduit à un décompte générique d'adoption. Signalez la gestion du type de contenu avec la force des exigences de la norme : les expéditeurs doivent valider le texte/plain, plutôt que d'inventer une exigence universelle plus forte.
La validation du certificat HTTPS est une observation distincte. Enregistrez le nom d'hôte demandé, le point de terminaison, l'heure et le résultat de validation réel. Une panne de réseau, une panne de certificat, un état inattendu et une stratégie mal formée ont des significations différentes et doivent rester séparés dans le journal des erreurs. Ne déduisez pas qu’une politique est absente simplement parce qu’un emplacement d’observation n’a pas pu l’atteindre, et n’ignorez pas les erreurs de connexion pour produire un numérateur d’adoption plus grand.
Comparez les modèles de stratégie avec l'itinéraire MX prévu
Une politique syntaxiquement valide peut toujours décrire les mauvais hôtes de réception. RFC 8461 définit la correspondance exacte des noms d'hôtes MX et des modèles de caractères génériques. Un caractère générique n'est pas un glob sans restriction n'importe où dans un nom ; la méthode doit implémenter la syntaxe et la correspondance définies par la norme. Conservez les observations MX et la décision correspondante pour chaque hôte dans la portée mesurée.
Une récupération HTTPS à elle seule ne permet pas d'établir que chaque point de terminaison MX offre un service TLS valide correspondant à la stratégie. Si l'étude n'effectue pas d'observations SMTP autorisées, indiquez que la compatibilité des routes n'est pas mesurée. Si des tests ultérieurs sont approuvés, conservez la preuve de connexion et la population distinctes de la disponibilité de l'hôte de stratégie. Ne réclamez pas une application de bout en bout uniquement à partir DNS et du HTTP.
Tenir compte du comportement des politiques mises en cache
Les expéditeurs peuvent conserver une politique MTA-STS pour son âge maximum selon le protocole. Une panne temporaire de l'hôte de stratégie peut donc affecter un expéditeur disposant d'une stratégie mise en cache utilisable différemment d'un expéditeur découvrant le domaine pour la première fois. Une sonde de mesure externe ne connaît généralement pas l'état du cache de chaque expéditeur. L’étude ne doit pas traduire directement les temps d’arrêt des terminaux en une période universelle de courrier non protégé.
De même, l’identifiant de découverte et la version de politique observée nécessitent un enregistrement temporel. Si une politique change pendant la collecte, conservez la séquence plutôt que de joindre l'ancienne observation DNS à un nouveau corps sans explication. Des mesures répétées doivent enregistrer l’état de la sonde et tout traitement intentionnel du cache. La méthode doit distinguer son comportement de mesure d'un envoi complet MTA mise en œuvre.
Concevoir le planning de disponibilité avant la collecte
Définissez à l’avance les emplacements des sondes, la cadence, le délai d’attente, la politique de nouvelle tentative et les règles de classification. Un point de terminaison qui échoue une fois et réussit lors d'une nouvelle tentative ne doit pas disparaître de l'enregistrement d'erreur. Signalez les tentatives d’observations, les observations réussies et les catégories d’échecs en utilisant un dénominateur clair. Si des fenêtres de maintenance ou des points de vue inaccessibles sont exclus, conservez les raisons et montrez comment les exclusions modifient le résultat.
Aucun objectif de cadence ou de niveau de service n’est imposé universellement par cet article. Choisissez un horaire adapté à la question de recherche et à l'autorisation, en évitant une charge excessive. Documentez la version de l'outil et ses dépendances afin qu'un autre analyste puisse reproduire la méthode. Les conclusions sur la disponibilité réelle nécessitent des données collectées ; un calendrier proposé ne constitue pas une preuve qu'un service a atteint ou manqué un objectif.
Une feuille de calcul d'ensemble de données versionnée
Créez des champs pour l'exemple de version, le domaine de réception, l'heure d'observation, le résultat de la découverte DNS , l'identifiant de stratégie, le point de terminaison HTTPS, le statut, le résultat du certificat, le type de contenu, hachage du corps, mode analysé, modèles MX et âge maximum. Ajoutez des références d'observation MX , des résultats de correspondance, une catégorie d'erreur, un historique de tentatives et un motif d'exclusion. Conservez les preuves brutes séparément des classifications normalisées.
RFC 8460 définit les rapports SMTP TLS , qui peuvent fournir une autre perspective lorsqu'ils sont légitimement disponibles. De tels rapports ne sont pas équivalents à une sonde de disponibilité externe et ne couvrent pas automatiquement chaque expéditeur. Le cas échéant, documentez séparément leur source et leur portée. Ce projet n'a collecté ni enquêtes ni rapports et n'implique pas de corrélation exacte entre eux.
Diagnostic fictif : une panne de point final devient une réclamation
Une étude fictive observe l'échec d'une récupération HTTPS et étiquette le domaine de réception comme n'ayant aucune protection MTA-STS pendant toute la journée. L'examen proposé identifie les preuves manquantes : l'observation portait sur un moment et un point d'observation précis, et les expéditeurs peuvent avoir mis en cache des politiques. La conclusion correcte est plus précise, décrivant l'échec de la récupération et sa catégorie d'erreur dans le calendrier mesuré.
L’équipe conserverait les observations ultérieures et rapporterait le dénominateur plutôt que d’effacer l’échec ou de l’extrapoler dans un comportement de messagerie universel. Il s'agit d'un exemple méthodologique fictif, et non d'une panne observée ou d'une réclamation concernant un domaine nommé. Aucune sonde réseau ou test de livraison de courrier électronique n'a été exécuté.
Publier uniquement des résultats reproductibles
Le catalogue nécessite un ensemble de données versionné, une méthode de requête et un journal d'erreurs/exclusions qu'un autre analyste peut reproduire. 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. Cette ébauche fournit un plan d’étude et un diagnostic fictif, et non des décomptes d’adoption, des résultats de disponibilité ou une évaluation de bout en bout de la sécurité des transports.