Behandeln Sie BIMI Bereitschaft als mehrere Beweisebenen
A BIMI Der Prüfer sollte zwischen DNS Veröffentlichung, Logo-Struktur, HTTPS-Abruf, Zertifikatnachweis und Empfängerberechtigung unterscheiden. Ein gültig aussehender Datensatz beweist nicht, dass das Logo akzeptabel ist, und ein erfolgreich abgerufenes Bild garantiert nicht, dass ein Postfachanbieter es anzeigt. Die Ausgabe sollte erkennen, welche Ebene beobachtet wurde, welche Regel angewendet wurde und was nicht überprüft wurde, anstatt das gesamte BIMI in einem einzigen Durchgang zu komprimieren.
Die behalten Implementierungsleitfaden der BIMI Group Und Dokumentation zur Google-Einrichtung Bereitstellung von praktischem Quellenmaterial mit unterschiedlichem Umfang. Die Gruppenrichtlinien stellen keinen Anspruch darauf dar, dass BIMI ein Internetstandard ist und dass die Google-Anforderungen für das dokumentierte Empfängerverhalten von Google gelten. In diesem Manuskript werden Checker-Anforderungen, eine nicht implementierte EmailAuth Ausgabe oder ein abgeschlossener Scan vorgeschlagen.
Behalten Sie die DNS Identität und den DNS-Selektor bei
Notieren Sie das genaue Wähler und den Namen des zu prüfenden Richtlinieneigentümers, den abgefragten Datensatztyp, den Resolver oder die maßgebliche Quelle und die Beobachtungszeit. Das Ergebnis eines Standardselektors sollte nicht stillschweigend einen anderen Selektor ersetzen. Der Prüfer sollte mehrere Kandidatendatensätze und fehlerhafte Eingaben gemäß der unterstützten BIMI Spezifikation oder den dokumentierten Leitlinien identifizieren und dabei die Quellversion sichtbar machen. Ohne den entsprechenden Nachrichtennachweis sollte daraus nicht abgeleitet werden, welches Logo eine echte Nachricht ausgewählt hat.
RFC 1035 bietet die TXT Eintrag Struktur, die zur Wahrung der Datensatzgrenzen erforderlich ist. Mehrere Zeichenfolgen innerhalb eines TXT Eintrags unterscheiden sich von mehreren TXT Einträgen desselben Eigentümers. Die Ausgabe sollte diese Grenzen beibehalten, bevor Richtlinienfelder interpretiert werden. Hier wurde keine Benutzerdomänenabfrage durchgeführt, daher gibt es keine tatsächliche Veröffentlichung BIMI Datensatz oder Auswahlergebnis in diesem Entwurf.
Bewerten Sie das Logo als Asset, nicht als Screenshot
SVG-Anleitung BIMI Group beschreibt die Anforderungen von SVG Portable/Secure und erklärt, dass das Profil strenger ist als SVG Tiny 1.2. Ein Logo, das in einem Browser korrekt aussieht, kann dennoch nicht unterstützte Strukturen, Referenzen oder interaktive Inhalte enthalten. Ein Prüfer sollte das tatsächlich abgerufene Asset und seinen Inhalts-Hash identifizieren und dann Profilergebnisse anhand eines benannten Regelsatzes melden.
Halten Sie die visuelle Überprüfung getrennt von der strukturellen Validierung. Ein strukturell akzeptables Objekt kann bei kleinen Größen immer noch schwer zu erkennen sein oder schlechte Zugänglichkeitseigenschaften aufweisen. Ein optisch ansprechendes Bild kann im Profil scheitern. Der Prüfer sollte nicht die eine Form der Überprüfung als Beweis für die andere bezeichnen. Dieses Manuskript hat kein Kandidaten-Asset erhalten, keinen Validator ausgeführt und kein Logo gerendert; Sein Arbeitsblatt spezifiziert die Beweise, die eine autorisierte Überprüfung benötigen würde.
Trennen Sie den HTTPS-Transport vom Markennachweis
Die Dokumentation von Google erfordert HTTPS-Hosting für BIMI Dateien und beschreibt die unterstützten Zertifikatdateianforderungen. Das TLS -Zertifikat, das die Hosting-Verbindung schützt, unterscheidet sich von einem VMC oder CMC mit dem Logo verbunden. Ein Prüfer sollte diese gesondert kennzeichnen. Eine gültige HTTPS-Verbindung beweist weder die Berechtigung für ein Markenzertifikat noch die Gültigkeit des an diesem Endpunkt gehosteten Beweisdokuments.
Notieren Sie zum Abruf die angeforderte URL, gegebenenfalls den endgültigen Endpunkt, den Antwortstatus, den Inhaltstyp, Bytes oder Hash, die Verbindungszeit und das Ergebnis der Zertifikatsvalidierung. Wenn eine Umleitung erfolgt, behalten Sie die beobachtete Kette bei und bewerten Sie sie anhand der tatsächlichen Quellanforderungen, anstatt eine universelle Umleitungsregel zu erfinden. Ein umleitungsfreier Endpunkt kann eine betriebliche Empfehlung sein, ohne fälschlicherweise als universelle normative Anforderung eingestuft zu werden.
Scope-Zertifikat und Empfängeranforderungen
In den von Google beibehaltenen Einrichtungsleitfäden heißt es, dass Gmail eine VMC oder CMC von unterstützten Ausstellern erfordert, und unterscheidet die VMC-bezogenen Verifiziertes Häkchen. Das ist kein Versprechen, dass jeder Empfänger das gleiche Zertifikat benötigt oder den gleichen Indikator aufweist. Der Prüfer sollte den beabsichtigten Empfänger und die aktuell dokumentierten Berechtigungsregeln identifizieren, bevor er fehlende Zertifikatsnachweise als allgemeinen BIMI Fehler interpretiert.
Die Eignung des Emittenten ist eine weitere Grenze. CMC Dokumentation von DigiCert beschreibt die Zertifikatsvalidierungs- und Zulassungsanforderungen. Ein Prüfer kann auf diesen Prozess verweisen, aber er kann keine rechtliche Markenbestimmung vornehmen oder die Genehmigung des Ausstellers anhand eines DNS Eintrags bestätigen. Hier fand keine Zertifikatsanmeldung, kein Logo-Eigentumsanspruch oder eine Emittententransaktion statt.
Halten Sie DMARC Bereitschaft deutlich
Die dokumentierte BIMI Berechtigung von Google umfasst DMARC-bezogene Bedingungen. Der Prüfer sollte die aktuelle empfängerspezifische Anforderung angeben und nicht stillschweigend seine eigene Richtlinienpräferenz ersetzen. Auf Protokollebene RFC 9989 definiert den Strom DMARC Verhalten, einschließlich Änderungen gegenüber älteren Konventionen. Wenn sich die Anbieterrichtlinien und das aktuelle Protokollvokabular unterscheiden, geben Sie die Anwendbarkeitsfrage an, anstatt so zu tun, als hätten sich alle Implementierungen gemeinsam geändert.
Eine veröffentlichte Durchsetzungsrichtlinie beweist nicht, dass alle legitimen Absender übereinstimmen oder dass eine bestimmte empfangene Nachricht die anderen Kriterien des Empfängers erfüllt. Bewahren Sie die Bereitschaft des Senders und die Beobachtung des Empfängers in separaten Beweisfeldern auf. Reputation, Nachrichtenkontext und Ermessensspielraum des Empfängers können sich auf die Anzeige auswirken. Daher sollte ein Prüfer vermeiden, allein aufgrund von Konfigurationsnachweisen auf eine garantierte Logo-Anzeige zu schließen.
Ein geschichtetes Schachbrett-Arbeitsblatt
Erstellen Sie Zeilen für DNS Besitzer und -Selektor, TXT Struktur, Logo-URL, abgerufenes Asset, SVG-Profilergebnisse, HTTPS-Verbindung, Mark-Evidence-Dokument und vorgesehener Empfänger. Jede Zeile sollte Quellregel, Beobachtungszeit, Beweisreferenz, Status und Einschränkung enthalten. Verwenden Sie Status wie „beobachtet“, „nicht bestanden“, „nicht getestet“ und „nicht anwendbar“, anstatt fehlende Beweise in „Bestanden“ oder „Nicht bestanden“ zu zwingen.
Behalten Sie bei einem Zertifikatsvalidierungsfehler den genauen Endpunkt, den überprüften Hostnamen, die Verbindungszeit, die Fehlerstufe und den sicheren Zertifikatsnachweis bei, der zur Reproduktion der Diagnose erforderlich ist. Unterscheiden Sie ein abgelaufenes Zertifikat, eine Hostnamen-Diskrepanz, einen Vertrauensfehler und einen nicht erreichbaren Dienst nur dann, wenn tatsächliche Beweise die Kategorie unterstützen. Der Katalog erfordert insbesondere zeitgestempelte TLS -Verbindungsnachweise, die den Endpunkt und den Fehler identifizieren; In dieser Arbeit wurde kein solcher Zusammenhang versucht.
Fiktive Diagnose: Das Logo wird geladen, aber die Berechtigung ist ungeklärt
Ein fiktives Team sieht sein Logo in einem Browser geöffnet und geht davon aus, dass ein Prüfer BIMI für vollständig erklären sollte. In der vorgeschlagenen Überprüfung wird darauf hingewiesen, dass das Browser-Rendering weder das erforderliche SVG-Profil validiert, noch den Mark-Evidence-Status festlegt oder die Empfängerberechtigung nachweist. Der HTTPS-Endpunkt funktioniert möglicherweise, während eine dieser anderen Ebenen nicht überprüft wird.
Das Team würde einen autorisierten Asset-Hash, Validator-Ergebnisse, Verbindungsnachweise und die aktuellen Anforderungen des vorgesehenen Empfängers sammeln. Es würde kein Zertifikat kaufen, kein Logo hochladen oder DNS ändern, nur um einem Checker-Label zu genügen. Dieses Szenario ist fiktiv, es gibt kein reales Logo, Endpunkt oder Empfängerergebnis. Es veranschaulicht, warum jede Ebene ihr eigenes Ergebnis und ihre eigene Erklärung benötigt.
Meldebereitschaft ohne vielversprechende Anzeige
Ein nützliches Prüfergebnis beschreibt, welche Konfigurations- und Asset-Anforderungen nachgewiesen wurden und welche empfängerspezifischen Bedingungen noch offen sind. Ein erfolgreicher Abruf sollte nicht in das Versprechen umgewandelt werden, dass für jeden Empfänger ein Logo angezeigt wird. Der Wert liegt in einer klaren nächsten Aktion, die durch Beweise untermauert ist, und nicht in einem übermütigen Bereitschaftsabzeichen.
Die erforderlichen ursprünglichen TLS Fehlernachweise bleiben offen, zusammen mit der Überprüfung durch einen menschlichen Spezialisten, der Anwendbarkeit der Quelle, den Produktionswegen, der Zugänglichkeit und der Freigabe durch den Eigentümer. Dieser Entwurf verwendet aufbewahrte Dokumentationsaufnahmen mit ihren Aufnahmedaten und enthält keine Live-Scans, Uploads oder Veröffentlichungen. Ein veröffentlichbares Tool-Beispiel benötigt tatsächlich autorisierte Beweise und ein Ergebnis, das an den getesteten Endpunkt- und Empfängerbereich gebunden ist.