Bekreft avhengighetene før du redigerer DNS
Publisering av a BIMI påstand er en liten DNS endring med flere eksterne avhengigheter. Posten kan referere til en logo eller bevisdokument som et annet team er vert for, og mottakerleverandøren kan avvise en ellers lesbar fil fordi dens sertifikat eller autentiseringsbetingelser ikke er oppfylt. Begynn med et godkjent domene, mottakerspesifikk plan og eksakte aktivaversjoner i stedet for en generisk TXT streng.
Denne veiledningen dekker den dokumenterte arbeidsflyten for standardvelger. Det beholdte BIMI versjon-15-dokumentet beskriver flere velgere og oppdagelsesregler, men det forblir et Internett-utkast, ikke en RFC. Ikke introduser avansert velger oppførsel bare fordi en sendeplattform kan sette inn en overskrift; bekrefte den tiltenkte implementeringen av sender og mottaker først. BIMI Internet-Draft 15, avsnitt 4.3–4.4.
Etablere riktig eier- og påstandsverdi
For den enkle standardsaken på example.com, er påstandseieren default._bimi.example.com. Versjonskoden er v=BIMI1; indikatoren plasseringen bruker l=, og myndighetsbevisplasseringen bruker a=. Utkastet definerer bevisplasseringen som valgfri syntaks, men det gjør ikke bevis valgfritt for hver mottaker. BIMI Internet-Draft 15, avsnitt 4.3.
En fiktiv illustrasjon med to plasseringer er v=BIMI1; l=https://assets.example.com/brand/logo.svg; a=https://assets.example.com/brand/mark.pem. Dette er ikke en produksjonspost, et vertselement eller en sertifikatanbefaling. Erstatt verken en reell påstand eller en ekte sertifikat-URL med disse eksempelverdiene.
Google dokumenterer et PEM-basert oppsett for Gmail , inkludert et eksempel med en tom l= verdi og sertifikatplasseringen i a=. En registrering kun for SVG er ikke den samme implementeringsbanen. Velg skjemaet som støttes av målmottakeren og det leverte beviset i stedet for å behandle alle publiserte eksempler som utskiftbare. Google BIMI oppsett, trinn 2–4.
Sjekk gjeldende autentiseringspolicy
Bekreft forfatterdomenet og gjeldende policy for organisasjonsdomene ved å bruke gjeldende DMARC oppdagelsesregler. Inspiser deretter faktiske meldinger fra den tiltenkte ruten for justert autentisering. BIMI Group oppfordrer til håndhevelse og merker seg den begrensede støtten til selvhevdende poster, men verken policytekst eller et postbyggerresultat beviser at en avsender er klar. BIMI implementeringsveiledning; RFC 9989 , avsnitt 4.4 og 4.10.
Leverandørdokumentasjonen må leses med versjonskonteksten. Den nåværende Google-siden inkluderer fortsatt pct=100, mens RFC 9989 fjernet den taggen. Behold dette avviket som et kompatibilitetsspørsmål for e-postadministratoren. Ikke bruk en prosentinnstilling eller testmodus som en påstått snarvei til BIMI kvalifisering, og ikke svekk eksisterende håndheving mens du feilsøker et ikke-relatert eiendelsproblem. RFC 9989 , vedlegg A.6.
Bekreft ressursene som påstanden vil annonsere
Hosting-eieren bør oppgi de eksakte offentlige HTTPS-URLene, de tiltenkte bytene og hashene deres. En foreslått henting skal bekrefte at svaret er den forventede eiendelen eller sertifikatpakken i stedet for en påloggingsside, merkevarefeilside eller omdirigering til en ikke-relatert ressurs. Registrer status, endelig URL, innholdstype, størrelse og TLS resultat. Disse observasjonene må komme fra den faktiske produksjonsbanen, ikke bare en lokal filforhåndsvisning.
For en merke-sertifikatbane, verifiser det utstedte beviset og kjeden mot målleverandørens krav. Googles instruksjoner beskriver PEM-pakken og den utstederleverte kjedebestillingen. HTTPS-serversertifikatet beskytter henting; det er ikke VMC eller CMC som leverer merkebevis. Sjekk begge forhold uavhengig av hverandre. Google BIMI oppsett, nettserverkrav og trinn 2–3.
Ingen offentlig nettadresse er hentet på vegne av en reell distribusjon her. Hvis teamet ikke kan levere et godkjent aktiva eller sertifikat, la den avhengigheten være uløst i stedet for å konstruere en plassholder som kan forveksles med gyldig bevis.
Publiser gjennom riktig DNS autoritet
Identifiser den autoritative DNS -tjenesten for den eksakte eieren og inspiser eksisterende poster før du gjør en endring. Bekreft om redaktøren forventer en relativ vertsetikett eller et fullt kvalifisert navn. Behold den forrige verdien og TTL, og bruk en gjennomgått endringsforespørsel som navngir den tiltenkte eieren, typen og verdien. Unngå dupliserte konkurrerende påstander med samme oppdagelsesnavn.
Etter en autorisert publisering inkluderer de foreslåtte kontrollene dig @AUTH_IP default._bimi.example.com . TXT +norecurse og dig @RESOLVER_IP default._bimi.example.com . TXT. De store endepunktene er plassholdere. Lagre tidsstempler, fullfør svar, registrer grenser og de faktiske verdiene. Disse kommandoene er foreslått, ikke utførte observasjoner.
Sjekk autoritativ konsistens før du forklarer uenighet som caching. Sammenlign deretter de rekursive banene som er relevante for den tiltenkte mottakeren der disse observasjonene er tilgjengelige. En DNS TTL eller en leverandørs estimerte visningsvindu er ikke en garanti for at hver mottaker har oppdatert eller vil vise en logo.
Valider en melding og planlegg gjenoppretting
Send en kontrollert melding gjennom den nøyaktige godkjente arbeidsflyten først etter at forutsetningene er klare. Behold forfatterdomenet, signeringsidentiteter, pålitelige autentiseringsresultater og eventuell relevant BIMI diagnostikk. Registrer en visningsobservasjon separat med postkasseleverandøren, klientversjon og dato. Apple Mails BIMI bane avhenger for eksempel av mottakerleverandøren som leverer sjekkene og overskriftene Apple spesifiserer. Apple BIMI -serverveiledning.
Hvis henting mislykkes, reparer den vertsbaserte avhengigheten eller gjenopprett den godkjente tidligere påstanden under endringsplanen. Hvis autentiseringen mislykkes, undersøk avsenderen og policyen. Hvis bare visning er fraværende, ikke antyd en DNS feil uten å sjekke mottakerraden. Opprettholde de gamle bevisene som trengs for en sikker, autorisert tilbakeføring; ikke redusere DMARC beskyttelsen for å gjenopprette en logo.
Den nøyaktige bevisporten er "En mottakerspesifikk kvalifiseringsmatrise og bevis for DNS , logo, sertifikat og meldingsautentisering." Dette utkastet gir en dokumentarmatrise og fiktiv rekordillustrasjon. Ingen direktepublisering, DNS spørring, sertifikatvalidering, endring av leietaker eller melding/visningstest skjedde, så driftsporten og godkjenning av eierfrigivelse forblir åpne.