Vérifiez les dépendances avant de modifier DNS
Publier un BIMI L'assertion est un petit changement DNS avec plusieurs dépendances externes. L'enregistrement peut faire référence à un logo ou à un document de preuve hébergé par une autre équipe, et le fournisseur destinataire peut rejeter un fichier autrement lisible parce que son certificat ou ses conditions d'authentification ne sont pas remplies. Commencez par un domaine approuvé, un plan spécifique au récepteur et des versions exactes des actifs plutôt qu'une chaîne TXT générique.
Ce guide couvre le flux de travail documenté du sélecteur par défaut. Le document BIMI version 15 retenu décrit des sélecteurs et des règles de découverte supplémentaires, mais il reste un brouillon Internet et non une RFC. N'introduisez pas d'informations avancées sélecteur comportement simplement parce qu’une plateforme d’envoi peut insérer un en-tête ; confirmez d’abord l’implémentation prévue de l’expéditeur et du destinataire. BIMI Internet-Draft 15, sections 4.3–4.4.
Établir le propriétaire correct et la valeur d'assertion
Pour le cas simple par défaut à example.com, le propriétaire de l'assertion est default._bimi.example.com. La balise de version est v=BIMI1; l'emplacement de l'indicateur utilise l=, et l'emplacement des preuves d'autorité utilise a=. Le projet définit l'emplacement des preuves comme une syntaxe facultative, mais cela ne rend pas les preuves facultatives pour chaque destinataire. BIMI Internet-Draft 15, section 4.3.
Une illustration fictive de double emplacement est v=BIMI1; l=https://assets.example.com/brand/logo.svg; a=https://assets.example.com/brand/mark.pem. Il ne s'agit pas d'un enregistrement de production, d'un actif hébergé ou d'une recommandation de certificat. Ne remplacez ni une véritable assertion ni une véritable URL de certificat par ces exemples de valeurs.
Google documente une configuration basée sur PEM pour Gmail , y compris un exemple avec un champ vide l= valeur et l'emplacement du certificat dans a=. Un enregistrement SVG uniquement n'est pas le même chemin d'implémentation. Sélectionnez le formulaire pris en charge par le destinataire cible et les preuves fournies plutôt que de traiter chaque exemple publié comme interchangeable. Configuration de Google BIMI , étapes 2 à 4.
Vérifiez la politique d'authentification applicable
Confirmez le domaine d'auteur et la stratégie de domaine organisationnel applicable à l'aide de la version actuelle. DMARC règles de découverte. Inspectez ensuite les messages réels provenant de l’itinéraire prévu pour une authentification alignée. Le groupe BIMI appelle à l'application et note la prise en charge limitée des enregistrements auto-déclarés, mais ni le texte de la politique ni le résultat du générateur d'enregistrements ne prouvent qu'un expéditeur est prêt. Guide de mise en œuvre BIMI; RFC 9989 , sections 4.4 et 4.10.
La documentation du fournisseur doit être lue avec son contexte de version. La page Google actuelle comprend toujours pct=100, alors que RFC 9989 supprimé cette balise. Conservez cette divergence comme question de compatibilité pour l'administrateur de messagerie. N'utilisez pas un paramètre de pourcentage ou un mode de test comme raccourci revendiqué vers l'éligibilité BIMI , et n'affaiblissez pas l'application existante lors du débogage d'un problème d'actif sans rapport. RFC 9989 , Annexe A.6.
Vérifiez les ressources que l'assertion publiera
Le propriétaire de l'hébergement doit fournir les URL HTTPS publiques exactes, les octets prévus et leurs hachages. Une récupération proposée doit confirmer que la réponse est l'actif ou l'ensemble de certificats attendu plutôt qu'une page de connexion, une page d'erreur de marque ou une redirection vers une ressource non liée. Enregistrez le statut, l'URL finale, le type de contenu, la taille et le résultat TLS . Ces observations doivent provenir du chemin de production réel, et pas seulement d'un aperçu de fichier local.
Pour un chemin de marque-certificat, vérifiez les preuves et la chaîne délivrées par rapport aux exigences du fournisseur cible. Les instructions de Google décrivent son offre groupée PEM et l'ordre en chaîne fourni par l'émetteur. Le certificat du serveur HTTPS protège la récupération ; ce n'est pas le VMC ou CMC qui fournit des preuves de marque. Vérifiez les deux relations indépendamment. Configuration de Google BIMI , exigences du serveur Web et étapes 2 à 3.
Aucune URL publique n'a été récupérée pour le compte d'un déploiement réel ici. Si l’équipe ne peut pas fournir un actif ou un certificat approuvé, laissez cette dépendance non résolue au lieu de créer un espace réservé qui pourrait être confondu avec une preuve valide.
Publier via l'autorité DNS appropriée
Identifiez le service DNS faisant autorité pour le propriétaire exact et inspectez les enregistrements existants avant d’apporter une modification. Confirmez si l'éditeur attend une étiquette d'hôte relative ou un nom complet. Conservez la valeur et la durée de vie précédentes et utilisez une demande de modification révisée qui nomme le propriétaire, le type et la valeur prévus. Évitez de dupliquer des assertions concurrentes portant le même nom de découverte.
Après une publication autorisée, les contrôles proposés comprennent creusez @AUTH_IP default._bimi.example.com . TXT +norécurse et creusez @RESOLVER_IP default._bimi.example.com . TXT. Les points de terminaison majuscules sont des espaces réservés. Enregistrez les horodatages, les réponses complètes, les limites d'enregistrement et les valeurs réelles. Ces commandes sont des observations proposées et non exécutées.
Vérifiez la cohérence faisant autorité avant d'expliquer le désaccord comme une mise en cache. Comparez ensuite les chemins récursifs pertinents pour le récepteur prévu où ces observations sont disponibles. Un TTL DNS ou la fenêtre d'affichage estimée d'un fournisseur ne garantit pas que chaque récepteur a actualisé ou affichera un logo.
Valider un message et planifier la récupération
Envoyez un message contrôlé via le flux de travail exactement approuvé uniquement une fois que ses conditions préalables sont prêtes. Conservez le domaine d'auteur, les identités de signature, les résultats d'authentification fiables et tous les diagnostics BIMI pertinents. Enregistrez une observation d'affichage séparément avec le fournisseur de boîte aux lettres, la version du client et la date. Le chemin BIMI d'Apple Mail, par exemple, dépend du fournisseur de réception fournissant les chèques et les en-têtes spécifiés par Apple. Conseils sur le serveur Apple BIMI.
Si la récupération échoue, réparez la dépendance hébergée ou restaurez l'assertion précédente approuvée dans le cadre du plan de modification. Si l’authentification échoue, étudiez l’expéditeur et la stratégie. Si seul l’affichage est absent, ne déduisez pas une erreur DNS sans vérifier la ligne du récepteur. Conserver les anciennes preuves nécessaires à une restauration sécurisée et autorisée ; ne réduisez pas largement la protection DMARC pour récupérer un logo.
La porte de preuve exacte est « une matrice d’éligibilité spécifique au destinataire et des preuves pour l’authentification DNS , du logo, du certificat et du message ». Cette ébauche fournit une matrice documentaire et une illustration de documents fictifs. Aucune publication en direct, requête DNS , validation de certificat, changement de locataire ou test de message/affichage n'a eu lieu, de sorte que la porte opérationnelle et l'approbation de la libération du propriétaire restent ouvertes.