Adskil protokollen fra modtagerens berettigelse
BIMI berettigelse fastslås ikke ved at finde ordet DMARC i en DNS record. Operatøren skal bestemme den gældende autentificeringspolitik, om den faktiske meddelelse består de påkrævede kontroller, og hvad den påtænkte modtager i øjeblikket kræver, før der vises et logo. Det er relaterede, men forskellige spørgsmål. En aktuel protokolspecifikation og en udbyders operationelle hjælpeside kan også afvige i terminologi eller migreringstidspunkt, så beviset har brug for datoer og eksplicit omfang.
Denne artikel sammenligner bevarede primære kilder. Googles opsætningsside blev opdateret den 26. oktober; Yahoo BIMI side blev hentet uden en tilsvarende synlig revisionsdato. RFC 9989 leverer den aktuelle DMARC -protokolkontekst. Artiklen tester ikke en lejer eller udleder, at en udbyder har implementeret alle aspekter af den nyere RFC. BIMI forbliver kladdearbejde, og modtagerdisplay er ikke en universel protokolgaranti.
Registrer Googles faktiske offentliggjorte betingelser
Googles BIMI opsætningsside siger, at meddelelser skal være godkendt af DMARC og lister p=quarantine eller p=reject, med pct=100. Det kræver også en VMC eller CMC for dets dokumenterede certifikatstøttede arbejdsgang og understøtter ikke selvstændig implementering af SVG-kun i Gmail . Registrer disse udsagn som Googles offentliggjorte kvalificeringsvejledning, ikke som en komplet definition af DMARC eller bevis for et bestemt meddelelsesresultat. Googles opsætningskrav
Dens SVG-krav og hostinginstruktioner danner yderligere porte. En passende DMARC politik gør ikke et ugyldigt billede egnet, opnår ikke et certifikat eller gør PEM'en offentligt tilgængelig. Omvendt reparerer et gyldigt certifikat ikke en svigtende afsenderes tilpassede godkendelse. Brug en tjekliste med separate rækker, så et team ikke ved et uheld kan markere hele projektet klar efter kun at have udfyldt DNS-politikrækken.
Overvåg pct-uoverensstemmelsen i stedet for at skjule den
RFC 9989 forælder de tidligere DMARC specifikationer og fjerner pct-tagget. Dens appendiks forklarer den historiske procentmekanisme og introducerer testmærket t med y- og n-værdier. Dette er en meningsfuld protokolændring, mens den bevarede Google BIMI side stadig eksplicit nævner pct=100. Begge observationer bør bevares i stedet for lydløst at omskrive begge kilder for at få dem til at fremstå identiske. RFC 9989 , Bilag A.6
Det operationelle svar er at bekræfte den aktuelle modtagers anvendelighed, før en produktionspolitik ændres på grundlag af dette misforhold. Påstå ikke, at Google ignorerer, kræver på ledningen eller internt oversætter et bestemt tag, medmindre aktuelle beviser fastslår denne adfærd. Behandl det ikke som en universelt bevist BIMI berettigelseserstatning for pct, blot fordi RFC forklarer deres historiske forhold. Udbyderimplementering og udbyderdokumentation kan udvikle sig på forskellige tidsplaner.
En kildeanvendelighedspost bør derfor omfatte RFC-versionen, udbyderens sidedato, den nøjagtige omstridte tilstand og det uløste spørgsmål. Bed den ansvarlige korrekturlæser om at løse det med aktuel udbyderbevis eller en autoriseret observation med passende omfang. Denne artikel udfører ikke denne bekræftelse. Konflikten er en grund til en gate, ikke en grund til at svække håndhævelsen eller improvisere et kompatibilitetskrav.
Sammenlign Yahoo angivne betingelser uafhængigt
Yahoo egen BIMI side kræver en karantæne eller afvisning af DMARC politik, en BIMI rekord peger på en gyldig SVG, massemail og tilstrækkeligt omdømme og engagement for afsenderadressen. Det siger, at VMC'er ikke er påkrævet i øjeblikket, selvom en medfølgende VMC informerer om den generelle berettigelse. Dens side ærer underdomæne BIMI poster, mens den foretrækker opsætning af organisationsdomæne. Disse er Yahoo-specifikke erklæringer, ikke beviser på, at Gmail deler det samme certifikat eller visningspolitik. Yahoo BIMI -krav
Fortolk ikke Yahoo fravær af en pct-betingelse på denne side som bevis for enhver mulig tag-håndteringsadfærd. Registrer, hvad kilden rent faktisk siger, og hvad den efterlader uspecificeret. Ligeledes betyder dets bulk-mail og omdømmeforhold, at en enkelt personlig testmeddelelse muligvis ikke repræsenterer den dokumenterede logo-visningspopulation. Opfind ikke en numerisk sendetærskel, når den anmeldte kilde ikke leverer en.
Forbind politik til faktisk meddelelsesgodkendelse
DMARC evaluerer justering mellem det synlige Fra-domæne og en forbigående SPF eller DKIM identitet efter sine regler. En offentliggjort håndhævelsespræference tvinger ikke enhver legitim afsender til at bestå. Inventar afsendertjenesterne og identificer, hvilke identiteter de autentificerer, før du foreslår en strengere behandling. Ændringer i politik kan påvirke legitime arbejdsgange, så en logo-deadline må ikke omgå mail-teamets beredskabs- og godkendelsesproces. RFC 9989 godkendelse og justering
For en senere kontrolleret observation skal du beholde den faktisk modtagne meddelelse og betroede godkendelsesresultater. Accepter ikke et påstået pass fra en vilkårlig header uden at identificere det producerende system og tillidsgrænsen. Behold politikopdagelse, meddelelsesgodkendelse og logovisning som separate resultater; en besked kan passere godkendelse uden at opfylde en modtagers yderligere visningsbetingelser. RFC 8601 tillidsgrænse
Originalt regneark for modtagerberettigelse
Opret én række pr. modtager og mailstrøm. De følgende foreslåede felter forhindrer en generisk " BIMI klar"-status i at skjule vigtige forskelle. Ingen reel implementering er blevet evalueret med dette regneark.
- Kilde: modtagerside, genfindingsdato, synlig revisionsdato og protokolreferenceversion.
- Domænepolitik: nøjagtig gældende registrering og ethvert organisatorisk eller underdomænespørgsmål.
- Dokumentation uoverensstemmelse: omstridt tag eller tilstand, beviser og uafklaret anvendelighed ejer.
- Beskedbevis: synlig fra, autentificerede identiteter, justering og pålidelig resultatkilde.
- Aktiv: godkendt SVG-version, modtagerdimensioner og strukturelle fund.
- Certifikat: påkrævet kategori, udstederstatus og hostet PEM-afhængighed.
- Hentning og visning: offentlig endepunktsbevis, modtagerklient, observationstid og grænser.
- Beslutning: kvalificeret, ikke kvalificeret eller ukendt for denne stream, med resterende betingelser.
Hold overvågnings- og håndhævelsesbeslutninger adskilt fra displayeksperimenter. Hvis en eksisterende afsender ikke kan justeres, skal du løse afsenderkonfigurationen og forretningspåvirkningen i stedet for at ændre en logofil gentagne gange. Hvis godkendelsen bestå, men intet logo vises, skal du undersøge certifikat, hosting, support og skønsberettigelse uden at erklære DMARC brudt udelukkende fra den manglende grafik.
Fiktivt eksempel: én tjekliste skjuler to modtagere
Fictional Silver Orchard udarbejder en lanceringstjekliste, der siger " DMARC pass, certifikat valgfrit." Denne formulering fusionerer Yahoo certifikatposition med Gmail forskellige dokumenterede arbejdsgange. En korrekturlæser bemærker også, at en ældre intern guide behandler pct som et uændret universel protokolkrav, mens RFC 9989 fjernede det, og Googles nuværende side stadig viser pct=100. Holdet har to dokumentationsspørgsmål, ikke bevis for, at nogen af modtagerne ikke fungerer korrekt.
Det foreslåede næste trin er at opdele tjeklisten i kildedaterede modtagerrækker og eskalere spørgsmålet om tag-anvendelighed, før du ændrer produktions DNS . Hver strøm ville have brug for faktiske beskedbeviser og sine egne aktiv- og certifikattjek. Ingen Silver Orchard-meddelelse, DNS post eller modtager blev testet. Eksemplet illustrerer, hvordan en generisk tjekliste kan skjule uafklarede antagelser.
Kataloget kræver en modtagerspecifik berettigelsesmatrix og bevis for DNS , logo, certifikat og meddelelsesgodkendelse. Dette manuskript leverer en foreslået matrix og dokumenterede forskelle, ikke de operationelle beviser. Originale beviser, menneskelig SMV, kildeanvendelighed, produktionsruter, visuel tilgængelighed og ejerfrigivelse forbliver åbne. Ingen politikændring, livetest eller berettigelsesgaranti er underforstået.