Behandl BIMI -beredskab som flere bevislag
A BIMI checkeren skal skelne mellem DNS udgivelse, logostruktur, HTTPS-hentning, certifikatbevis og modtagerens berettigelse. En registrering, der ser gyldigt ud, beviser ikke, at logoet er acceptabelt, og et vellykket hentet billede garanterer ikke, at en postkasseudbyder vil vise det. Outputtet skal identificere, hvilket lag der blev observeret, hvilken regel der blev anvendt, og hvad der forbliver ubekræftet i stedet for at komprimere hele BIMI til en enkelt gennemgang.
Den tilbageholdte BIMI Group implementeringsvejledning og Google opsætningsdokumentation levere praktisk kildemateriale med forskelligt omfang. Gruppevejledningen er ikke en påstand om, at BIMI er en internetstandard, og Googles krav gælder for Googles dokumenterede modtageradfærd. Dette manuskript foreslår kontrolkrav, ikke implementeret EmailAuth output eller en gennemført scanning.
Bevar DNS identiteten og -vælgeren
Optag det nøjagtige vælger og policeejerens navn under gennemgang, den forespurgte posttype, resolver eller autoritativ kilde og observationstid. Et standardvælgerresultat bør ikke stille og roligt stå for en anden vælger. Checkeren skal identificere flere kandidatposter og forkert udformet input i henhold til dens understøttede BIMI specifikation eller dokumenterede vejledning, med denne kildeversion synlig. Det bør ikke udlede, hvilket logo et rigtigt budskab er valgt uden det relevante budskabsbevis.
RFC 1035 giver TXT post struktur nødvendig for at bevare registreringsgrænser. Flere strenge inden for én TXT post adskiller sig fra flere TXT poster hos samme ejer. Outputtet bør bevare disse grænser, før der fortolkes politikområder. Ingen brugerdomæneforespørgsel blev udført her, så der er ingen faktisk publiceret BIMI rekord eller vælgerresultat i dette udkast.
Evaluer logoet som et aktiv, ikke et skærmbillede
BIMI Group SVG vejledning beskriver SVG Portable/Secure-krav og forklarer, at profilen er strengere end SVG Tiny 1.2. Et logo, der ser korrekt ud i en browser, kan stadig indeholde ikke-understøttet struktur, referencer eller interaktivt indhold. En checker skal identificere det faktisk hentede aktiv og dets indholdshash og derefter rapportere profilresultater mod et navngivet regelsæt.
Hold visuel gennemgang adskilt fra strukturel validering. Et strukturelt acceptabelt aktiv kan stadig være svært at genkende i små størrelser eller have dårlige tilgængelighedsegenskaber. Et visuelt attraktivt billede kan svigte profilen. Checkeren bør ikke kalde den ene form for anmeldelse bevis for den anden. Dette manuskript fik ikke et kandidataktiv, kørte en validator eller gengav et logo; dets arbejdsark specificerer beviserne for en autoriseret gennemgang.
Adskil HTTPS-transport fra mærkebevis
Googles dokumentation kræver HTTPS-hosting for BIMI -filer og beskriver dets understøttede certifikatfilkrav. TLS -certifikatet, der beskytter hostingforbindelsen, er forskelligt fra et VMC eller CMC forbundet med logoet. En brik bør mærke disse separat. En gyldig HTTPS-forbindelse beviser hverken berettigelse til et mærkecertifikat eller gyldigheden af bevisdokumentet, der er hostet på det pågældende slutpunkt.
For hentning skal du registrere den anmodede URL, endelige slutpunkt, hvor det er relevant, svarstatus, indholdstype, bytes eller hash, forbindelsestid og certifikatvalideringsresultat. Hvis der sker omdirigering, skal du beholde den observerede kæde og vurdere den i forhold til de faktiske kildekrav i stedet for at opfinde en universel omdirigeringsregel. Et omdirigeringsfrit slutpunkt kan være en operationel anbefaling uden at blive fejlmærket som et universelt normativt krav.
Omfangscertifikat og modtagerkrav
Googles bevarede opsætningsvejledning angiver, at Gmail kræver en VMC eller CMC fra understøttede udstedere og adskiller de VMC-relaterede verificeret flueben. Det er ikke et løfte om, at hver modtager kræver det samme certifikat eller viser den samme indikator. Checkeren bør identificere den påtænkte modtager og aktuelle dokumenterede berettigelsesregler, før den fortolker manglende certifikatbevis som en universel BIMI fejl.
Udstederens berettigelse er en anden grænse. DigiCerts CMC dokumentation beskriver dets certifikatvalidering og berettigelseskrav. En checker kan pege på denne proces, men den kan ikke foretage en juridisk varemærkeafgørelse eller attestere udstedergodkendelse fra en DNS post. Ingen certifikatansøgning, logoejerskabskrav eller udstedertransaktion fandt sted her.
Hold DMARC beredskab adskilt
Googles dokumenterede BIMI kvalificering omfatter DMARC-relaterede betingelser. Checkeren bør citere det nuværende modtagerspecifikke krav i stedet for stille at erstatte sin egen politikpræference. På protokolniveau, RFC 9989 definerer strøm DMARC adfærd, herunder ændringer fra ældre konventioner. Hvis udbyderens vejledning og det aktuelle protokolordforråd er forskellige, skal du angive anvendelighedsspørgsmålet i stedet for at lade som om, at alle implementeringer er ændret sammen.
En offentliggjort håndhævelsespolitik beviser ikke, at hver legitim afsender er tilpasset, eller at en bestemt modtaget meddelelse opfylder modtagerens øvrige kriterier. Hold afsenderberedskab og modtagerobservation i separate bevisfelter. Omdømme, meddelelseskontekst og modtagerens skøn kan påvirke visningen, så en checker bør undgå en konklusion om garanteret logovisning alene fra konfigurationsbeviser.
Et lagdelt tern regneark
Opret rækker til DNS ejer og -vælger, TXT struktur, logo-URL, hentet aktiv, SVG-profilfund, HTTPS-forbindelse, marke-bevisdokument og påtænkt modtager. Hver række skal indeholde kilderegel, observationstid, bevisreference, status og begrænsning. Brug statusser som observeret, mislykket, ikke testet og ikke anvendelig i stedet for at tvinge manglende beviser til at bestå eller ikke bestå.
For en certifikatvalideringsfejl skal du beholde det nøjagtige slutpunkt, kontrolleret værtsnavn, forbindelsestid, fejltrin og sikker certifikatbevis, der er nødvendig for at reproducere diagnosen. Skeln kun mellem et udløbet certifikat, hostnavn-uoverensstemmelse, tillidssvigt og uopnåelig service, når faktiske beviser understøtter kategorien. Kataloget kræver specifikt tidsstemplet TLS -forbindelsesbevis, der identificerer slutpunktet og fejlen; ingen sådan forbindelse blev forsøgt i dette arbejde.
Fiktiv diagnose: logoet indlæses, men berettigelsen er uafklaret
Et fiktivt hold ser sit logo åbent i en browser og antager, at en checker skal erklære BIMI for komplet. Den foreslåede gennemgang bemærker, at browsergengivelse ikke validerer den påkrævede SVG-profil, etablerer markeringsbevisstatus eller demonstrerer modtagerens berettigelse. HTTPS-slutpunktet fungerer muligvis, mens et af disse andre lag forbliver ubekræftet.
Teamet ville indsamle en autoriseret aktivhash, valideringsresultater, forbindelsesbeviser og den påtænkte modtagers aktuelle krav. Det ville ikke købe et certifikat, uploade et logo eller ændre DNS blot for at opfylde en brik-etiket. Dette scenarie er fiktivt, uden noget reelt logo, slutpunkt eller modtagerresultat observeret. Det illustrerer, hvorfor hvert lag har brug for sit eget resultat og forklaring.
Rapportér parathed uden at love visning
En nyttig checker-konklusion beskriver, hvilke konfigurations- og aktivkrav der blev demonstreret, og hvilke modtagerspecifikke betingelser der forbliver åbne. Det bør ikke konvertere en vellykket hentning til et løfte om, at der vises et logo for hver modtager. Værdien er en klar næste handling understøttet af beviser, ikke et overmodigt parathedsmærke.
Det påkrævede originale TLS fejlbevis forbliver åbent sammen med gennemgang af menneskelig specialist, kildeanvendelse, produktionsruter, tilgængelighed og ejerudgivelse. Dette udkast bruger bevarede dokumentariske optagelser med deres optagelsesdatoer og indeholder ingen live-scanninger, uploads eller publikationer. Et publicerbart værktøjseksempel kræver faktisk autoriseret bevis og et resultat afgrænset til dets testede slutpunkt og modtageromfang.