Un enregistrement BIMI n'est pas une garantie d'affichage
A Enregistrement BIMI Le constructeur peut aider à formater une assertion DNS proposée, mais il ne peut pas garantir qu'un récepteur affichera le logo. La publication, la validité des actifs, la preuve de la marque, l'éligibilité à l'authentification et la politique du destinataire sont des conditions distinctes. Le constructeur doit expliquer les décisions derrière chaque domaine et identifier ce qui reste non vérifié. Un enregistrement copiable sans ces limites peut transformer une aide à la configuration utile en une promesse non prise en charge.
Les retenus Guide de mise en œuvre du Groupe BIMI décrit la configuration pratique, tandis que Documentation de configuration de Google décrit ses exigences spécifiques au récepteur. Aucune des deux sources ne prouve EmailAuth implémente un générateur ou que chaque récepteur se comporte de manière identique. Ce manuscrit propose des exigences de sortie et de test ; aucun enregistrement n'a été généré pour un domaine réel, publié ou numérisé.
Établir le contexte du domaine et du sélecteur
Enregistrez le domaine d'envoi prévu, sélecteur, propriétaire de la publication DNS et identité du logo approuvée. Un constructeur ne doit pas supposer silencieusement que le sélecteur par défaut représente chaque message ou chaque flux de travail de marque. Conseils de sélection du groupe BIMI explique l'utilisation du sélecteur et sa relation avec la signalisation des messages. Le sélecteur applicable doit être connecté au processus d'envoi prévu plutôt que choisi uniquement parce que son nom DNS est familier.
Garder BIMI noms de sélecteur séparés de DKIM sélecteurs. Ils répondent à des objectifs différents et occupent des contextes de recherche différents. Un constructeur doit expliquer le nom du propriétaire de la publication qu'il propose, y compris la manière dont l'éditeur DNS attend des noms relatifs ou pleinement qualifiés. Il ne doit pas dupliquer aveuglément un suffixe de domaine ni prétendre que la convention de saisie d'un fournisseur s'applique partout. Le comportement actuel de l’État et du fournisseur nécessite un examen autorisé avant publication.
Expliquer chaque champ proposé
L'annotation doit identifier l'assertion de version, le champ d'emplacement du logo et tout champ d'emplacement de preuve pris en charge par la version d'orientation ou de spécification ciblée. Il doit indiquer quelles valeurs sont fournies, lesquelles sont des espaces réservés et pourquoi elles sont nécessaires pour le destinataire prévu. N'insérez pas d'URL réelle ou d'emplacement de certificat sans l'approbation du propriétaire du domaine et sans la preuve que le point de terminaison dessert l'actif prévu.
Les champs inconnus ou non pris en charge nécessitent une gestion explicite dans la propre validation du générateur. Étant donné que les orientations et les propositions BIMI évoluent, l'outil doit identifier l'ensemble de règles pris en charge plutôt que d'inventer une règle de traitement universelle pour chaque balise. Le plan de test doit distinguer les entrées que le constructeur refuse de générer d'une affirmation sur la manière dont chaque récepteur gère une assertion inconnue. Aucun comportement de balise non pris en charge n'a été testé ici.
Vérifier les actifs et les prérequis HTTPS
Conseils SVG du Groupe BIMI décrit le profil SVG Portable/Secure plus strict. Un constructeur ne doit accepter aucune URL d’image comme preuve équivalente. Le résultat proposé doit faire référence à un actif approuvé avec un hachage de contenu et un enregistrement de validation conservés, tout en séparant l'examen structurel et visuel. Un logo qui apparaît dans un navigateur peut toujours ne pas répondre aux exigences de profil pertinentes.
Google nécessite un hébergement HTTPS pour les fichiers BIMI dans sa configuration documentée. Le constructeur doit identifier si le point de terminaison d'hébergement a été vérifié et si les octets récupérés correspondent à l'actif approuvé. La preuve de transport HTTPS n’établit pas l’éligibilité au certificat de marque ni l’affichage du destinataire. Si aucune récupération n'a été effectuée, la sortie doit indiquer non vérifié plutôt que de traiter un préfixe https comme un test de connexion réussi.
Preuves de la marque de portée et exigences du destinataire
Les directives retenues par Google indiquent que Gmail nécessite un VMC ou CMC et décrit la distinction des coches liées à VMC. D'autres destinataires peuvent avoir des règles d'éligibilité différentes. Le constructeur doit se demander quels récepteurs sont importants et citer leurs exigences actuelles avant de présenter un champ de localisation de preuves comme universellement suffisant ou inutile. La saisie d'une URL n'implique pas l'achat d'un certificat ou l'approbation d'un émetteur.
Le Conseils Yahoo BIMI illustre une portée de récepteur différente, y compris son traitement des exigences VMC et d'autres considérations d'éligibilité. Ce contraste soutient un examen minutieux spécifique au destinataire, et non une affirmation selon laquelle chaque message répondant à la liste de contrôle publiée affichera un logo. Le constructeur doit éviter de qualifier une configuration incomplète de garantie de visibilité de la marque.
Séparez l’éligibilité DMARC et la préparation de l’expéditeur
Les instructions du récepteur BIMI peuvent imposer des conditions liées au DMARC, mais un constructeur ne doit pas supposer qu'une politique d'application DNS prouve que chaque expéditeur légitime s'aligne. RFC 9989 définit le courant DMARC le comportement et ses limites. Le résultat BIMI proposé devrait être lié à une évaluation de préparation distincte plutôt que de modifier silencieusement la politique d'authentification pour satisfaire un formulaire de configuration de logo.
Lorsque la documentation du récepteur utilise des conventions qui diffèrent du vocabulaire de protocole actuel, conservez les dates sources et la question d'applicabilité. Ne réécrivez pas automatiquement une politique et n’inventez pas un nouveau jeton de version. La tâche d'un constructeur BIMI n'est pas l'autorisation de modifier DMARC , d'acheter des preuves de marque ou de modifier la configuration d'envoi d'un fournisseur. Ces décisions nécessitent leur propre portée et vérification approuvées.
Préparer un plan de changement précis
L'inspection de l'état existant et la préparation d'un diff prévu sont distinctes de la publication. Le constructeur doit distinguer le remplacement d'un enregistrement approuvé de l'ajout d'une assertion concurrente chez le même propriétaire. RFC 1035 définit la structure TXT , y compris la distinction entre les chaînes au sein un enregistrement et des enregistrements séparés. Conservez les données TXT non liées et l'ensemble complet des enregistrements concernés dans le plan de modification.
Enregistrez le matériel de restauration, l'approbation du propriétaire et le plan d'observation après modification. Une chaîne générée ne doit pas autoriser automatiquement une écriture DNS . Si l'outil prend en charge la publication, cette fonctionnalité nécessite des preuves distinctes de liaison, d'approbation et de vérification du locataire ; ce manuscrit ne prétend pas EmailAuth le propose. Aucun état DNS n'a été lu ou modifié pour cet exercice.
Une feuille de travail de construction annotée
Créez une feuille de calcul avec le domaine, le sélecteur, le propriétaire exact de la publication, l'assertion proposée, l'objectif de chaque champ, le hachage d'actif, la preuve du point final, le statut de la preuve de marque et les destinataires prévus. Ajoutez les versions de règles source, la référence à l'état actuel, les différences prévues, le propriétaire de l'approbation et les conditions préalables non résolues. Conservez la validité de sortie, la disponibilité opérationnelle et l'affichage du récepteur dans des états distincts.
Les cas de test requis doivent couvrir une assertion positive prise en charge, une entrée invalide, des enregistrements en double et des champs non pris en charge. Chaque cas nécessite une entrée originale, un comportement attendu et une sortie réelle de l'outil une fois qu'un test autorisé est exécuté. N'étiquetez pas un appareil réussi car le résultat proposé semble plausible. Un exemple de documentation n'est pas un test de constructeur exécuté, et ce brouillon ne contient ni un enregistrement de production ni des résultats mesurés.
Diagnostic fictif : une affirmation valable sans preuve manifeste
Une équipe fictive génère un enregistrement BIMI syntaxiquement plausible pointant vers un logo et suppose que chaque destinataire le verra désormais. L'examen proposé demande si l'actif répond au profil, si la récupération HTTPS a été vérifiée, quelles preuves de marque existent et quelles exigences du récepteur s'appliquent. Le formatage du dossier ne répond à lui seul à aucune de ces questions.
L’équipe laisserait l’état de préparation en suspens et rassemblerait les preuves autorisées manquantes. Il n’achèterait pas de certificat ni ne modifierait la politique d’authentification uniquement pour faire passer le statut de constructeur au vert. Ce scénario est fictif et ne décrit pas une véritable panne de récepteur ou une limitation du produit. Cela montre pourquoi le résultat doit rester annoté et conditionnel.
Publier uniquement la revendication démontrée
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, tout comme 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. Ce projet fournit des exigences et un exercice fictif, sans comportement d'outil implémenté ni promesse d'affichage de logo. Un exemple publiable doit conserver la sortie et les tests réellement pris en charge tout en gardant la discrétion du récepteur visible.