Traitez les instructions BlueHornet comme un itinéraire historique
La source de ce guide est le livre blanc de trois pages de BlueHornet Networks, « Email Authentication: An Informational Primer and How-To », protégé par copyright 2013. Il décrit un arrangement DNS géré par le client avec l'assistance du fournisseur. DKIM approvisionnement. Il s’agit d’une référence de mise en œuvre historique, et non d’une confirmation que les mêmes contrôles de compte, infrastructure, processus de support ou disponibilité de service s’appliquent aujourd’hui. Elle ne doit pas remplacer les instructions relatives à une plateforme successeure simplement en raison d'une relation d'entreprise. Le compte réel et l’applicabilité actuelle du produit restent ouverts. Livre blanc BlueHornet, pages 1 à 3
La distinction opérationnelle utile dans ce document est la division des responsabilités. Le client identifie le domaine d'envoi et le contexte du compte, BlueHornet génère le matériel d'authentification approprié, le client publie les données DNS fournies et le fournisseur termine sa configuration. Un examen responsable peut préserver cette chaîne de dépendances sans prétendre qu'un ancien exemple est une configuration actuelle prête à coller. Aucun accès au compte, échange de support, publication DNS ou test de message n'a eu lieu pour ce brouillon.
Identifiez le domaine prévu et l'utilisation CNAME existante
Les instructions historiques demandent au client d'identifier les domaines destinés à l'envoi. Ils disent explicitement que ces domaines ne peuvent pas être les mêmes que ceux du CNAME utilisé avec BlueHornet. Préservez cette contrainte de fournisseur lors de l’évaluation de cet itinéraire documenté. Ne traitez pas silencieusement un alias de suivi, un nom d'hôte Web et une identité de signature comme interchangeables simplement parce qu'ils partagent le suffixe de domaine de l'organisation. Livre blanc BlueHornet, « Configuration DKIM », page 2
Préparez un inventaire d’identité avant de demander un changement. Enregistrez le domaine d'envoi exact, visible depuis le domaine, l'adresse de réponse prévue, l'utilisation CNAME existante et le propriétaire responsable. Si plusieurs unités commerciales ou agences partagent le compte, identifiez quel propriétaire de domaine approuve chaque itinéraire. La capacité d'un opérateur de campagne à sélectionner une adresse n'établit pas en soi l'autorité de publier des enregistrements dans DNS de ce domaine.
L'inventaire doit également identifier les sélecteurs existants et les autres services utilisant le même espace de noms. Évitez d'écraser une dépendance d'authentification fonctionnelle lorsque vous essayez de recréer l'illustration historique. Le propriétaire et la valeur de l'enregistrement réellement pris en charge doivent provenir de la configuration de service applicable, et non d'un diagramme ou d'un diagramme. un enregistrement vu sur le domaine de quelqu'un d'autre. Toute différence non résolue entre les instructions historiques et le comportement du compte courant appartient à la décision de libération.
Séparez le provisionnement du fournisseur et la publication DNS
Le livre blanc demande au client de fournir le ou les domaines et le nom d'utilisateur BlueHornet associé à un représentant des services de gestion de la délivrabilité ou à la gestion de compte. Il décrit ensuite le fournisseur générant les éléments clés, le client saisissant les données fournies dans la zone et le client informant le contact afin que BlueHornet puisse terminer la configuration DKIM . L'intervalle d'exécution indiqué par le fournisseur est une information historique et non une promesse de niveau de service actuel. Livre blanc BlueHornet, pages 2–3
Pour une implémentation proposée, liez la référence du compte, le domaine approuvé, les données DNS publiques fournies et l'approbation de la modification dans un seul enregistrement contrôlé. N'incluez pas de mots de passe ou de clés privées dans la feuille de calcul. Le transfert du compte et du nom d'utilisateur de la source ne constitue pas une autorisation d'envoyer des informations d'identification ou de contacter un tiers sans l'autorisation du propriétaire du domaine. Cet article décrit un processus de révision, et non une instruction déjà exécutée au nom du lecteur.
Un enregistrement DKIM public et un signataire activé établissent des faits différents. La signature identifie son domaine de signature et sélecteur; le destinataire utilise ces informations pour trouver du matériel de vérification. Un enregistrement publié ne peut pas constituer une signature d'application, et un paramètre côté application ne peut pas garantir que DNS diffuse le matériel public correct. Le plan d'acceptation doit conserver les deux responsabilités et éventuellement les relier via une véritable observation de message autorisée. RFC 6376 , sections 3.5 et 3.6.2.2
Ne transformez pas l’illustration en données DNS réutilisables
Le PDF historique contient une capture d'écran de l'éditeur DNS et des domaines illustratifs. Ce sont des exemples, pas des valeurs générées pour le compte du lecteur. Obtenez le propriétaire actuel pris en charge, le type d’enregistrement et la valeur publique complète avant de planifier la publication. Conservez le nom complet séparément de la chaîne saisie dans un éditeur DNS , car un fournisseur peut ajouter un suffixe de zone ou interpréter différemment l'entrée relative. Livre blanc BlueHornet, page 3 RFC 1035 , section 5.1
Enregistrements TXT peut contenir plusieurs chaînes de caractères. Une longue valeur de clé publique peut apparaître encapsulée ou divisée sans représenter plusieurs enregistrements distincts. Vérifiez la valeur logique et enregistrez les limites plutôt que de supposer que le formatage visuel est la représentation filaire. À l’inverse, une capture d’écran tronquée ne peut pas fournir les éléments clés manquants. Ne reconstruisez jamais une clé publique à partir du début visible d’un exemple. RFC 1035 , section 3.3.14
Réévaluer l’ancien cadrage SPF et Sender ID
Le livre blanc SPF les instructions apparaissent sous « Configuration de l’ID de l’expéditeur ». Ils incluent un exemple d'autorisation pour BlueHornet et expliquent qu'une politique SPF existante doit être étendue plutôt que remplacée. Ce principe de préservation est utile, mais le cadre historique ne constitue pas une description complète du SPF ou du SPF d'aujourd'hui. DMARC sémantique. La capture d'écran et la prose illustrent également différents qualificatifs finaux ; ni l’un ni l’autre ne devrait décider silencieusement de la politique actuelle de l’organisation. Livre blanc BlueHornet, page 3
Utilisez les règles SPF actuellement applicables lors de l’examen d’un enregistrement proposé. SPF évalue le SMTP pertinent COURRIER DE identité ou Identité HELO, pas simplement l'adresse De visible. Publiez SPF au format TXT , maintenez une politique applicable et examinez les termes de requête DNS évalués dans les dépendances imbriquées. L’ajout d’une autre stratégie indépendante ne fusionne pas les autorisations. La limite d'évaluation de dix termes n'est pas simplement un décompte de requêtes réseau ou de chaînes d'inclusion de niveau supérieur. RFC 7208 , sections 2.3 à 2.4, 3.1 à 3.3 et 4.6.4
Ne présumez pas que l’autorisation de l’ancien exemple reste applicable à un locataire actuel ou à un autre produit. Confirmez l’itinéraire sortant réel et les informations de sortie approuvées. De même, n’acceptez pas les affirmations historiques concernant le chargement des images du fournisseur de boîte aux lettres, les seuils de réclamation ou la vitesse de traitement comme des avantages actuels. Ils ne sont pas nécessaires pour expliquer la responsabilité de configuration et n'établissent pas de garantie de livraison.
Exiger des preuves de message au-delà de l'achèvement du fournisseur
Lorsque des preuves autorisées séparément sont disponibles, examinez un message de chaque itinéraire concerné. Enregistrez son domaine From visible, l'identité de l'enveloppe pertinente, le domaine et le sélecteur de signature DKIM , ainsi que les résultats d'authentification du destinataire. DMARC nécessite un résultat SPF ou DKIM satisfaisant et aligné. Une signature valide pour un domaine non lié ou un pass SPF pour une identité non alignée n'établit pas en soi le succès DMARC . RFC 9989 , section 4.4
Le livre blanc lui-même prévient que l'authentification ne constitue pas un chemin garanti vers la boîte de réception. Conservez cette limitation. L'authentification ne remplace pas l'évaluation de la réputation, les préférences du destinataire ou d'autres décisions du destinataire, et elle ne prouve pas que la demande commerciale d'un message est sûre. Un enregistrement de publication, un message d'achèvement du fournisseur et un résultat de message reçu doivent rester des éléments de preuve distincts. Livre blanc BlueHornet, « Pourquoi s'authentifier ? », page 1 RFC 9989 , section 2.4
Diagnostic fictif : un vieux schéma confondu avec une approbation actuelle
Dans une entreprise fictive, Brookline Events, un administrateur trouve le livre blanc de 2013 alors qu'il prépare une évaluation de la plateforme de messagerie. Un collègue propose de copier son sélecteur et son exemple SPF dans la zone active et de traiter l'ancien intervalle d'achèvement comme un engagement de lancement. Le domaine d'expéditeur proposé est également le nom d'hôte déjà utilisé pour le CNAME de la plateforme. Aucun incident ou test de ce type n’a été observé ; il s’agit d’un exercice d’acceptation fictif.
L'examinateur s'arrête aux preuves d'applicabilité manquantes. L'équipe identifie le produit de compte réel, résout la contrainte de nom d'hôte documentée et obtient les données d'enregistrement public actuellement prises en charge avant de proposer des modifications. Il préserve les autres expéditeurs autorisés et maintient ouvertes les tâches d’achèvement du fournisseur et de vérification des messages. Le document historique éclaire les questions et les responsabilités ; il n'autorise pas à lui seul un nouveau déploiement.
Feuille de travail vierge d'acceptation d'itinéraire historique
- Produit/compte réel et applicabilité du workflow 2013 : ____.
- Domaine d'envoi approuvé, visible Du domaine et du propriétaire du domaine : ____.
- Utilisation existante de BlueHornet CNAME et résolution des contraintes : ____.
- Contact du fournisseur autorisé et référence du compte non secret : ____.
- Propriétaires des documents publics actuellement fournis, types et valeurs complètes : ____.
- Politique SPF existante et expéditeurs légitimes retenus : ____.
- Opérateur DNS , approbation des modifications et enregistrement de restauration : ____.
- Preuve d'approvisionnement, de publication et d'achèvement du fournisseur : ____.
- Identités autorisées des messages reçus et alignement résultat: ____.
- Différences historiques/actuelles non résolues et approbateur de la version : ____.
La feuille de calcul est vide. Les preuves originales, l'examen humain/PME, l'applicabilité de la source, les itinéraires de production, l'examen visuel/d'accessibilité et la libération du propriétaire restent ouverts. Aucune capacité de service actuelle, aucune exécution de locataire ou aucun résultat d'authentification réussi n'est revendiqué.