Trennen Sie das Protokoll von der Empfängerberechtigung
BIMI Die Berechtigung wird nicht durch das Finden des Wortes festgestellt DMARC in einem DNS Eintrag. Der Betreiber muss die anwendbare Authentifizierungsrichtlinie ermitteln, ob die tatsächliche Nachricht die erforderlichen Prüfungen besteht und was der vorgesehene Empfänger aktuell benötigt, bevor er ein Logo anzeigt. Das sind verwandte, aber unterschiedliche Fragen. Eine aktuelle Protokollspezifikation und die operative Hilfeseite eines Anbieters können sich auch in der Terminologie oder dem Migrationszeitpunkt unterscheiden, sodass die Nachweise Datumsangaben und einen expliziten Umfang erfordern.
Dieser Artikel vergleicht erhaltene Primärquellen. Die Einrichtungsseite von Google wurde am 26. Oktober aktualisiert. BIMI Seite von Yahoo wurde ohne entsprechendes sichtbares Revisionsdatum abgerufen. RFC 9989 Stellt den aktuellen DMARC -Protokollkontext bereit. Der Artikel testet weder einen Mandanten noch schließt er daraus, dass ein Anbieter jeden Aspekt des neueren RFC implementiert hat. BIMI bleibt Entwurfsarbeit und die Empfängeranzeige ist keine universelle Protokollgarantie.
Notieren Sie die tatsächlich veröffentlichten Bedingungen von Google
Auf BIMI -Setup-Seite von Google heißt es, dass Nachrichten durch DMARC und Listen authentifiziert werden müssen p=quarantine oder p=reject, mit pct=100. Es erfordert auch eine VMC oder CMC für seinen dokumentierten zertifikatsgestützten Workflow und unterstützt keine eigenständige, reine SVG-Bereitstellung in Gmail . Erfassen Sie diese Aussagen als von Google veröffentlichte Leitlinien zur Berechtigung und nicht als vollständige Definition von DMARC oder als Beweis für ein bestimmtes Nachrichtenergebnis. Anforderungen für die Google-Einrichtung
Seine SVG-Anforderungen und Hosting-Anweisungen bilden zusätzliche Tore. Eine geeignete DMARC Richtlinie macht ein ungültiges Image nicht geeignet, erhält kein Zertifikat und macht das PEM nicht öffentlich zugänglich. Umgekehrt repariert ein gültiges Zertifikat nicht die ausgerichtete Authentifizierung eines fehlerhaften Absenders. Verwenden Sie eine Checkliste mit separaten Zeilen, damit ein Team nicht versehentlich das gesamte Projekt als fertig markiert, nachdem es nur die DNS-Richtlinienzeile ausgefüllt hat.
Decken Sie die PCT-Diskrepanz auf, anstatt sie zu verbergen
RFC 9989 macht die früheren DMARC Spezifikationen obsolet und entfernt das pct-Tag. Im Anhang wird der historische Prozentmechanismus erläutert und das Testtag t mit den Werten y und n vorgestellt. Dies ist eine bedeutende Protokolländerung, während auf der beibehaltenen Google BIMI Seite weiterhin ausdrücklich pct=100. Beide Beobachtungen sollten erhalten bleiben, anstatt stillschweigend eine der beiden Quellen umzuschreiben, damit sie identisch erscheinen. RFC 9989 , Anhang A.6
Die operative Reaktion besteht darin, die Anwendbarkeit des aktuellen Empfängers zu bestätigen, bevor eine Produktionsrichtlinie aufgrund dieser Diskrepanz geändert wird. Behaupten Sie nicht, dass Google ein bestimmtes Tag ignoriert, auf der Leitung verlangt oder intern übersetzt, es sei denn, aktuelle Beweise belegen dieses Verhalten. Behandeln Sie t nicht als allgemein anerkannten BIMI Berechtigungsersatz für pct, nur weil der RFC ihre historische Beziehung erklärt. Die Anbieterimplementierung und Anbieterdokumentation kann sich nach unterschiedlichen Zeitplänen entwickeln.
Ein Quellanwendbarkeitsdatensatz sollte daher die RFC-Version, das Datum der Anbieterseite, den genauen umstrittenen Zustand und die ungelöste Frage enthalten. Bitten Sie den verantwortlichen Gutachter, das Problem anhand der aktuellen Beweise des Anbieters oder einer autorisierten Beobachtung mit angemessenem Umfang zu lösen. Dieser Artikel führt diese Bestätigung nicht durch. Der Konflikt ist ein Grund für ein Tor, kein Grund, die Durchsetzung zu schwächen oder einen Kompatibilitätsanspruch zu improvisieren.
Vergleichen Sie unabhängig voneinander die von Yahoo angegebenen Konditionen
Die eigene BIMI Seite von Yahoo erfordert eine Quarantäne oder lehnt DMARC Richtlinie ab BIMI Datensatz Hinweis auf eine gültige SVG-Datei, Massenmail sowie ausreichend Reputation und Engagement für die Absenderadresse. Es heißt, dass VMCs derzeit nicht erforderlich sind, obwohl ein bereitgestellter VMC Aufschluss über die allgemeine Berechtigung gibt. Auf der Seite werden Subdomain BIMI Datensätze berücksichtigt, wobei die Einrichtung der Organisationsdomäne bevorzugt wird. Dies sind Yahoo-spezifische Aussagen und kein Beweis dafür, dass Gmail dasselbe Zertifikat oder dieselbe Anzeigerichtlinie verwendet. Yahoo BIMI Anforderungen
Interpretieren Sie das Fehlen einer PCT-Bedingung durch Yahoo auf dieser Seite nicht als Beweis für jegliches mögliches Tag-Handhabungsverhalten. Notieren Sie, was die Quelle tatsächlich aussagt und was sie offen lässt. Ebenso bedeuten die Massenversand- und Reputationsbedingungen, dass eine einzelne persönliche Testnachricht möglicherweise nicht die dokumentierte Logo-Display-Population repräsentiert. Erfinden Sie keinen numerischen Sendeschwellenwert, wenn die überprüfte Quelle keinen solchen bereitstellt.
Verbinden Sie die Richtlinie mit der tatsächlichen Nachrichtenauthentifizierung
DMARC bewertet Ausrichtung zwischen der sichtbaren From-Domäne und einem Passing SPF oder DKIM Identität unter seinen Regeln. Eine veröffentlichte Durchsetzungspräferenz zwingt nicht jeden legitimen Absender zum Passieren. Machen Sie eine Bestandsaufnahme der sendenden Dienste und ermitteln Sie, welche Identitäten sie authentifizieren, bevor Sie eine strengere Behandlung vorschlagen. Richtlinienänderungen können sich auf legitime Arbeitsabläufe auswirken. Daher darf eine Logo-Frist nicht den Bereitschafts- und Genehmigungsprozess des E-Mail-Teams außer Acht lassen. RFC 9989 Authentifizierung und -Ausrichtung
Behalten Sie für eine spätere kontrollierte Beobachtung die tatsächlich empfangene Nachricht und die vertrauenswürdigen Authentifizierungsergebnisse bei. Akzeptieren Sie keinen beanspruchten Pass von einem beliebigen Header, ohne das produzierende System und die Vertrauensgrenze zu identifizieren. Behalten Sie die Richtlinienerkennung, Nachrichtenauthentifizierung und Logoanzeige als separate Ergebnisse bei; Eine Nachricht kann die Authentifizierung bestehen, ohne die zusätzlichen Anzeigebedingungen eines Empfängers zu erfüllen. RFC 8601 -Vertrauensgrenze
Originales Arbeitsblatt zur Empfängerberechtigung
Erstellen Sie eine Zeile pro Empfänger und Mail-Stream. Die folgenden vorgeschlagenen Felder verhindern, dass ein allgemeiner Status „ BIMI bereit“ wichtige Unterschiede verbirgt. Mit diesem Arbeitsblatt wurde keine echte Bereitstellung evaluiert.
- Quelle: Empfängerseite, Abrufdatum, sichtbares Revisionsdatum und Protokollreferenzversion.
- Domain-Richtlinie: Genauer anwendbarer Datensatz und alle Organisations- oder Subdomain-Fragen.
- Nicht übereinstimmende Dokumentation: umstrittenes Etikett oder Zustand, Beweise und ungeklärter Anwendbarkeitseigentümer.
- Nachrichtennachweis: sichtbarer Absender, authentifizierte Identitäten, Ausrichtung und vertrauenswürdige Ergebnisquelle.
- Asset: genehmigte SVG-Version, Empfängerabmessungen und strukturelle Erkenntnisse.
- Zertifikat: erforderliche Kategorie, Ausstellerstatus und gehostete PEM-Abhängigkeit.
- Abruf und Anzeige: öffentliche Endpunktbeweise, Empfänger-Client, Beobachtungszeit und Grenzwerte.
- Entscheidung: berechtigt, nicht berechtigt oder unbekannt für diesen Stream, mit verbleibenden Bedingungen.
Halten Sie Überwachungs- und Durchsetzungsentscheidungen getrennt von Display-Experimenten. Wenn die Ausrichtung eines vorhandenen Absenders fehlschlägt, beheben Sie die Absenderkonfiguration und die geschäftlichen Auswirkungen, anstatt eine Logodatei wiederholt zu ändern. Wenn die Authentifizierung erfolgreich ist, aber kein Logo angezeigt wird, prüfen Sie Zertifikat, Hosting, Support und Ermessensberechtigung, ohne DMARC allein aufgrund der fehlenden Grafik für fehlerhaft zu erklären.
Fiktives Beispiel: Eine Checkliste verbirgt zwei Empfänger
Der fiktive Silver Orchard bereitet eine Start-Checkliste mit der Aufschrift „ DMARC -Bestanden, Zertifikat optional“ vor. Dieser Wortlaut verschmilzt den Zertifikatsstatus von Yahoo mit dem anderen dokumentierten Workflow von Gmail . Ein Rezensent bemerkt außerdem, dass ein älterer interner Leitfaden pct als eine unveränderte universelle Protokollanforderung behandelt, während RFC 9989 es entfernt hat und auf der aktuellen Seite von Google immer noch pct=100. Das Team hat zwei Fragen zur Dokumentation, keine Hinweise darauf, dass einer der Empfänger nicht richtig funktioniert.
Der vorgeschlagene nächste Schritt besteht darin, die Checkliste in quellendatierte Empfängerzeilen aufzuteilen und die Frage der Tag-Anwendbarkeit zu eskalieren, bevor das Produktions DNS geändert wird. Jeder Stream würde tatsächliche Nachrichtennachweise und eigene Asset- und Zertifikatsprüfungen benötigen. Es wurde keine Silver Orchard-Nachricht, kein DNS Eintrag oder Empfänger getestet. Das Beispiel veranschaulicht, wie eine generische Checkliste ungelöste Annahmen verbergen kann.
Der Katalog erfordert eine empfängerspezifische Berechtigungsmatrix und Nachweise für DNS , Logo, Zertifikat und Nachrichtenauthentifizierung. Dieses Manuskript liefert eine vorgeschlagene Matrix und dokumentierte Unterschiede, nicht die operativen Beweise. Originalbeweise, menschliches SME, Quellenanwendbarkeit, Produktionswege, visuelle Zugänglichkeit und Eigentümerfreigabe bleiben offen. Es sind keine Richtlinienänderungen, Live-Tests oder Berechtigungsgarantien impliziert.