Een BIMI record is geen weergavegarantie
A BIMI record builder kan helpen bij het formatteren van een voorgestelde DNS bewering, maar kan niet garanderen dat een ontvanger het logo zal tonen. Publicatie, geldigheid van activa, markeringsbewijs, geschiktheid voor authenticatie en ontvangersbeleid zijn afzonderlijke voorwaarden. De bouwer moet de beslissingen achter elk veld uitleggen en identificeren wat nog niet is geverifieerd. Een kopieerbaar record zonder deze grenzen kan een nuttig configuratiehulpmiddel veranderen in een niet-ondersteunde belofte.
De behouden Implementatiegids BIMI Group beschrijft de praktische opstelling, terwijl Installatiedocumentatie van Google beschrijft de ontvangerspecifieke vereisten. Geen van beide bronnen bewijst dat EmailAuth een builder implementeert of dat elke ontvanger zich identiek gedraagt. Dit manuscript stelt output- en testvereisten voor; er is geen record gegenereerd voor een echt domein, gepubliceerd of gescand.
Bepaal de domein- en selectorcontext
Leg het beoogde verzendende domein vast, keuzeschakelaar, DNS publicatie-eigenaar en goedgekeurde logo-identiteit. Een bouwer mag er niet stilletjes van uitgaan dat de standaardselector elk bericht of elke merkworkflow vertegenwoordigt. Selectiebegeleiding van BIMI Group legt het gebruik van selector uit en de relatie ervan met berichtsignalering. De toepasselijke selector moet verbonden zijn met het beoogde verzendproces en mag niet alleen gekozen worden omdat DNS naam ervan bekend is.
Houden BIMI selectornamen gescheiden van DKIM selectoren. Ze dienen verschillende doeleinden en bezetten verschillende opzoekcontexten. Een bouwer moet de naam van de publicatie-eigenaar die hij voorstelt uitleggen, inclusief hoe de DNS editor relatieve of volledig gekwalificeerde namen verwacht. Het mag niet blindelings een domeinachtervoegsel dupliceren of beweren dat de invoerconventie van één provider overal van toepassing is. Bestaand staats- en providergedrag vereist geautoriseerde beoordeling vóór publicatie.
Leg elk voorgesteld veld uit
De annotatie moet de versiebewering, het logolocatieveld en elk bewijslocatieveld dat wordt ondersteund door de gerichte richtlijn of specificatieversie identificeren. Er moet worden vermeld welke waarden worden opgegeven, welke tijdelijke aanduidingen zijn en waarom deze nodig zijn voor de beoogde ontvanger. Voeg geen echte URL of certificaatlocatie in zonder de goedkeuring van de domeineigenaar en bewijs dat het eindpunt de beoogde asset bedient.
Onbekende of niet-ondersteunde velden vereisen expliciete afhandeling in de eigen validatie van de bouwer. Omdat BIMI richtlijnen en -voorstellen evolueren, moet de tool de ondersteunde regelset identificeren in plaats van een universele verwerkingsregel voor elke tag uit te vinden. Het testplan moet onderscheid maken tussen input die de bouwer weigert te genereren en een claim over hoe elke ontvanger omgaat met een onbekende bewering. Er is hier geen gedrag van niet-ondersteunde tags getest.
Controleer de asset- en HTTPS-vereisten
BIMI Group SVG-begeleiding beschrijft het strengere SVG Portable/Secure-profiel. Een bouwer mag geen enkele afbeeldings-URL accepteren als gelijkwaardig bewijs. De voorgestelde output moet verwijzen naar een goedgekeurd item met een hash van de bewaarde inhoud en een validatierecord, terwijl de structurele en visuele beoordeling gescheiden blijven. Een logo dat in een browser verschijnt, voldoet mogelijk nog steeds niet aan de relevante profielvereisten.
Google vereist HTTPS-hosting voor BIMI bestanden in de gedocumenteerde configuratie. De bouwer moet vaststellen of het hosting-eindpunt is gecontroleerd en of de opgehaalde bytes overeenkomen met de goedgekeurde asset. HTTPS-transportbewijs bewijst niet dat het merk in aanmerking komt voor een certificaat of dat de ontvanger wordt weergegeven. Als er geen ophaalactie is uitgevoerd, zou de uitvoer niet-geverifieerd moeten zijn in plaats van een https-voorvoegsel als een succesvolle verbindingstest te behandelen.
Reikwijdte markeer bewijsmateriaal en vereisten voor de ontvanger
In de behouden richtlijnen van Google staat dat Gmail een ondersteunde versie vereist VMC of CMC en beschrijft het VMC-gerelateerde vinkjesonderscheid. Andere ontvangers kunnen andere geschiktheidsregels hebben. De bouwer moet zich afvragen welke ontvangers er toe doen en hun huidige vereisten vermelden voordat hij een veld voor bewijslocatie presenteert als universeel voldoende of onnodig. Er wordt geen certificaataankoop of goedkeuring door de uitgever geïmpliceerd door het invoeren van een URL.
De Yahoo BIMI -begeleiding illustreert een andere reikwijdte van de ontvanger, inclusief de behandeling van VMC vereisten en andere geschiktheidsoverwegingen. Dit contrast ondersteunt een zorgvuldige, ontvangerspecifieke beoordeling, en niet de bewering dat elk bericht dat aan de gepubliceerde checklist voldoet, een logo zal tonen. De bouwer moet vermijden een onvolledige configuratie te bestempelen als gegarandeerde merkzichtbaarheid.
Houd DMARC geschiktheid en afzendergereedheid gescheiden
Begeleiding van BIMI ontvangers kan DMARC-gerelateerde voorwaarden opleggen, maar een bouwer mag er niet van uitgaan dat een DNS handhavingsbeleid bewijst dat elke legitieme afzender zich op één lijn bevindt. RFC 9989 definieert de huidige DMARC gedrag en zijn grenzen. De voorgestelde BIMI uitvoer moet gekoppeld zijn aan een afzonderlijke gereedheidsbeoordeling in plaats van het authenticatiebeleid stilzwijgend te wijzigen om te voldoen aan een formulier voor het instellen van een logo.
Wanneer de documentatie bij de ontvanger conventies gebruikt die verschillen van de huidige protocolvocabulaire, bewaar dan de brondata en de toepasbaarheidsvraag. Herschrijf niet automatisch een beleid en bedenk geen nieuw versietoken. De taak van een BIMI -bouwer is niet de toestemming om DMARC te wijzigen, merkbewijs aan te schaffen of de verzendconfiguratie van een leverancier te wijzigen. Deze besluiten hebben hun eigen goedgekeurde reikwijdte en verificatie nodig.
Bereid een wijzigingsplan voor met exacte records
Het inspecteren van de bestaande staat en het voorbereiden van een beoogde diff staan los van publiceren. De bouwer moet onderscheid maken tussen de vervanging van een goedgekeurd record en de toevoeging van een concurrerende bewering bij dezelfde eigenaar. RFC 1035 definieert TXT structuur, inclusief het onderscheid tussen de strings binnenin een record en aparte registers. Bewaar niet-gerelateerde TXT gegevens en de volledige betrokken recordset in het wijzigingsplan.
Registreer het herstelmateriaal, de goedkeuring van de eigenaar en het observatieplan na de wijziging. Een gegenereerde tekenreeks mag niet automatisch een DNS schrijfbewerking autoriseren. Als de tool publicatie ondersteunt, heeft die mogelijkheid afzonderlijk bewijs nodig van huurderbinding, goedkeuring en verificatie; dit manuscript beweert niet dat EmailAuth het aanbiedt. Er is voor deze oefening geen DNS status gelezen of gewijzigd.
Een geannoteerd bouwer-werkblad
Maak een werkblad met domein, selector, exacte publicatie-eigenaar, voorgestelde bewering, het doel van elk veld, asset-hash, eindpuntbewijs, markeringsbewijsstatus en beoogde ontvangers. Voeg bronregelversies, verwijzing naar de huidige status, beoogde diff, goedkeuringseigenaar en onopgeloste vereisten toe. Houd de uitgangsvaliditeit, bedrijfsgereedheid en ontvangerweergave als afzonderlijke statussen.
De vereiste testgevallen moeten betrekking hebben op een positief ondersteunde bewering, ongeldige invoer, dubbele records en niet-ondersteunde velden. Elke case heeft originele input, verwacht gedrag en daadwerkelijke tooloutput nodig zodra een geautoriseerde test is uitgevoerd. Label een armatuur niet als geslaagd omdat de voorgestelde output er plausibel uitziet. Een documentatievoorbeeld is geen uitgevoerde bouwtest en dit concept bevat geen productieregistratie of gemeten resultaten.
Fictieve diagnose: een geldige bewering zonder bewijsmateriaal
Een fictief team genereert een syntactisch plausibel BIMI record dat naar een logo verwijst en gaat ervan uit dat elke ontvanger het nu zal zien. In de voorgestelde beoordeling wordt gevraagd of het item aan het profiel voldoet, of het ophalen van HTTPS is geverifieerd, welk markeringsbewijs er bestaat en welke vereisten voor de ontvanger van toepassing zijn. De opmaak van de plaat beantwoordt op zichzelf geen van deze vragen.
Het team zou de gereedheid voor vertoning onopgelost laten en het ontbrekende geautoriseerde bewijsmateriaal verzamelen. Het zou geen certificaat kopen of het authenticatiebeleid wijzigen uitsluitend om de status van een bouwer groen te maken. Dit scenario is fictief en beschrijft geen echte ontvangerstoring of productbeperking. Het laat zien waarom de uitvoer geannoteerd en voorwaardelijk moet blijven.
Publiceer alleen de aangetoonde claim
De catalogus vereist een geannoteerd record en positieve, ongeldige, dubbele en niet-ondersteunde testcases. Die originele artefacten blijven open, net als de beoordeling door menselijke specialisten, de toepasbaarheid van de bron, productieroutes, toegankelijkheid en vrijgave door de eigenaar. Dit ontwerp levert vereisten en een fictieve oefening op, geen geïmplementeerd gereedschapsgedrag of een belofte van logo-weergave. Een publiceerbaar voorbeeld moet de feitelijk ondersteunde output en tests behouden, terwijl de discretie van de ontvanger zichtbaar blijft.