BIMI opdagelse forbinder en beskeds Fra-domæne og vælger til en DNS påstand. Det vigtige spørgsmål er, hvilken post en modtager har ret til at bruge, ikke om en TXT værdi tilfældigvis indeholder ordet BIMI . Denne artikel følger draft-brand-indicators-for-message-identification-15 , et internetudkast fra oktober 2026, i stedet for at præsentere det som en offentliggjort RFC.
Anmærk påstanden
Referencer: Kilde §4.3.
I v=BIMI1; l=https://assets.example/logo.svg; a=https://assets.example/mark.pem, v identificerer protokolversionen, l peger på indikatoren og en peger på myndighedsbevis. Udkastet kræver versionen først og nøjagtige bogstaver. Det tillader en tom myndighedsplacering; et valgfrit mærke på protokolniveau fjerner ikke en modtagers certifikatkrav. Eksemplet bruger to URL'er for klarhedens skyld, mens Googles nuværende PEM-baserede eksempel kan bruge et tomt l med certifikatets placering i en. Følg den relevante modtagersti i stedet for at antage, at hver syntaktisk variant skaber det samme visningsresultat.
Udkastet låner DKIM tag-værdi syntaks. Gentagelse af et tag er ikke en måde at definere alternativer på. Ukendte tags ignoreres af den angivne udvidelsesmodel; de har ikke tilladelse til at opfinde ny semantik. Hold håndtering af ukendt tag adskilt fra en ugyldig påkrævet værdi.
Følg opdagelsens navn
Referencer: Kilde §5.1, Kilde §6.4, Kilde §7.2.
Uden en eksplicit BIMI vælger bruges standardvælgeren. En eksplicit vælger bæres i BIMI-vælger; det er ikke automatisk DKIM s værdi. For en besked fra notices.example.com og selector seasonal er det oprindelige navn seasonal._bimi.notices.example.com . Afsnit 7.2 trin 6 bevarer denne vælger i dens organisatoriske fallback-algoritme. Afsnit 6.4 beskriver dog tilbagefald til standardpåstanden på Organisationsdomænet. Disse udtalelser er i modstrid med udkast -15. Denne artikel beskriver afsnit 7.2-algoritmen, ikke en universel implementeret adfærd: verificer den tilsigtede modtagerimplementering, før du stoler på en af de to alternativer. Publicer den tilsigtede valgte påstand direkte, hvor det er praktisk, i stedet for at designe omkring denne uløste inkonsistens.
Draft -15 beskriver også lokale delevælgeradfærd gennem lp'er. Det er en versionsfølsom funktion: dokumenter, hvilken implementering der understøtter det, før du designer en kampagne omkring det. Den private anmeldelsespakkes parser-opstilling implementerer ikke lokal-del-normalisering, header-godkendelse, organisationsdomæneberegning eller modtagercache.
Undersøg det komplette svar
Referencer: Kilde §7.2.
A TXT post kan bestå af flere tegnstrenge, der danner én logisk værdi. Det adskiller sig fra to separate kvalificerede påstandsposter. Udkastets opdagelsesprocedure stopper, hvis det berettigede rekordsæt ikke er unikt. Forespørg hele sættet, og bevar citatgrænserne i det indfangede svar. En forhåndsvisning af DNS kontrolpanelet kan skjule denne skelnen.
Den private anmeldelsespakkes afgrænsede parser-tilfælde accepterer det almindelige eksempel inden for den understøttede delmængde, afviser duplikerede påstande, detekterer gentagne l-tags, afviser HTTP-placeringer, afviser en forkert indbygget version og accepterer en ellers gyldig post, der indeholder et ukendt fremtidigt tag. Disse er udførte beslutningstest, ikke observerede svar fra en postkasseudbyder. Deres smalle parser bør ikke installeres som en produktionsvalidator.
Foretag en kontrolleret korrektion
Ret det specifikke postnavn eller -værdi, forespørg igen på den autoritative server, og inspicér derefter et rekursivt svar efter det relevante cache-interval. Behold både svar og den tidligere rekord. Test den faktiske modtagende udbyder igen, før du erklærer visningen gendannet. Ændring af DKIM vælgere, DMARC politik eller e-mail-routing er ikke en passende generel løsning til et BIMI TXT -syntaksproblem.