BIMI - Brand Indicators for Message Identification

Yahoo, AOL und Fastmail haben damit angefangen und Mitte 2021 ist Google Mail dazu gestoßen. Höchste Zeit sich auch mit BIMI zu beschäftigen? BIMI ist ein weiteres Konzept, welches zwar nicht direkt "Spam" verhindert aber qualifizierten Absendern einen Weg eröffnen soll, ihre Mails "sichtbarer" zu machen. Wobei sicherlich auch das "Marketing" hier einen Rolle spielt.

BIMI steht noch am Anfang und ich sehe noch keine hohe Priorität diese Funktion umzusetzen. (Stand Jun 2021)

Überlegungen

E-Mail ist erst einmal ein prinzipiell unsicheres Medium. Genau wie bei Postbrief kann der Absender gefälscht sein und ihnen etwas vorgaukeln. Als Empfänger müssen sie daher genau prüfen, ob die empfangene Mail in der Form sinnvoll ist oder jemand ihnen etwas Böses will. Das Problem ist nicht neu und es gibt schon länger alternative Verfahren, um die Authentizität einer Mail schon beim Empfang zu überprüfen, z.B.

  • SMIME/PGP
    Hätte jeder Absender ein Zertifikat, dann könnten die Mails signiert werden und wären damit fälschungssicher. Leider nutzen viel zu wenig Menschen heute SMIME/PGP und es ist auch nicht ganz einfach einzusetzen, auch wenn Verschlüsselungsgateways wie NoSpamProxy hier die Hürde deutlich reduzieren. Die meisten Empfänger können damit aber nicht viel Anfangen und noch weniger Mailserver lehnen Mails mit defekter Signatur ab.
  • SPF (Spam und UCE - Filter: SPF, SenderID)
    Der Absender veröffentlicht die IP-Adressen seiner Mailserver zur Domäne und der Empfänger kann so Mails von anderen "bösen" Systemen gleich ablehnen. Allerdings muss ihr System die Mails gegen SPF prüfen und auch ablehnen. Immer mehr Firmen bietet SPF-Informationen ab aber noch mehr nutzen dies nicht oder stellen die Information "unscharf" ein, d.h. ihr Server kann wieder nicht ablehnen. Dann gibt es noch Weiterleitungen/Umleitungen/Mailverteiler etc., die damit ein Problem haben.
  • DKIM (Spam und UCE - Filter: DKIM)
    Ein zweiter Weg ist die Signatur der Mail mittels DKIM und die Veröffentlichung der Schlüssel per DNS. Dies ist nicht mit PGP/SMIME zu verwechseln aber der Absender kann so die Authentizität überprüfbar machen. Problem hier: Noch weniger Firmen können DKIM und noch weniger Server überprüfen DKIM beim Empfang.
  • DMARC (DMARC)
    Wie ein Empfänger die SPF/DKIM-Regeln auswerten soll, können Sie per DMARC weiter vorgeben.

All das sind Methoden, mit denen sich ein Empfänger gegen Fälschungen des Absenders oder des Inhalts schützen können und Absender ihre Domain absichern können. Wenn ein System nun über diese Wege sichergestellt hat, dass der Absender korrekt und die Mail nicht verändert wurde, dann sollten wir das dem Anwender auch zeigen. Und hier kommt BIMI mit ins Spiel.

Microsoft Produkte zeigen schon länger vor einem Namen einer Person entweder das hinterlegte Bild oder die Initialen an.

  • Outlook
  • Teams

Die Bilder sehen Sie nur, wenn sowohl Bilder hinterlegt sind aber auch der Absender "überprüft" werden konnte. Der Anwender kann dann aber sicher sein, dass die Information von dieser Person stammt. Das ist zwar immer noch kein Schutz gegen geknackte Zugangsdaten aber ein recht guter Indikator einer legitimen Mail.

Proprietäre Funktionen

Nun geht es darum, diese Funktion auch "ins Internet" zu bringen, d.h. ein externer Absender schafft alle Voraussetzungen, dass mein Mailserver die Identität des Absenders prüfen kann und besorgt sich dann ein "Logo" für den Absender, welches anstelle der Initialen angezeigt wird. Das Verfahren ist gar nicht neu, wen Sie "Consumer"-Postfächer bei GMX oder WEB.DE haben. Hier werden schon viele Jahre die netten Symbole der "bevorzugten Partner" angezeigt. Unter dem Begriff "Trusted Dialog" nutzen die Firmen der United Internet-Gruppe, Freenet und Telekom diese Sonderbehandlung, um Mails zu "kennzeichnen". Vor der Mail ist dann das entsprechende Firmenlogo zu sehen.

Das funktioniert aber nur in einem direkten Verhältnis zwischen den Firmen, die sich hier zusammen gefunden haben. Im Internet kann aber nicht jeder Administrator die Partnerschaften individuell einstellen. Auch Microsoft hat hier ein eigenes Verfahren, namens "Brand Cards". Leider gibt es dazu noch wenig Informationen und es funktioniert wohl derart, dass die Firmen sich bei MIcrosoft unter https://business.microsoft.com registrieren. Die Daten erscheinen dann auch bei der BING-Suche, Outlook.com und Office 365.

Ich bin gespannt, wie bald weitere Dienste die Anzeige eines Markenzeichens beim Absender aktivieren.

BIMI beim Sender

Aktivität Erledigt

Kennzeichnung mit SFP/DKIM/DMARC

Zuerst müssen Sie sicherstellen, dass alle von ihnen versendeten Mails ihrer veröffentlichten DMARC-Richtlinie entsprechen. Sie müssen daher eine DMARC-Policy veröffentlichen und zumindest ihre Mailserver per SPF bekannt geben. Besser ist noch die Unterstützung von DKIM.

Achtung:
Eigentlich alle Empfänger erwarten einen strengen SPF und DMARC-Eintrag, d.h. mit "Reject" oder mindestens "Quarantäne" um sicherzustellen, dass die Domain der Absender-Adresse (Envelope und Header) nicht gefälscht sind.

Bild bereitstellen

Zuerst muss ich das Bild als eine SVG-Datei bereitstellen. Ich bin von einem kleinen GIF/JPG-Bild ausgegangen, welches ich mit einem der vielen verfügbaren Online-Konvertern in eine SVG-Datei gewandelt habe.

JPG:  -> SVG

Das ist für einen schnellen Hack sicher ausreichend aber nicht professionell. Der Name "SVG" steht für "Scalable Vector Graphics" und idealerweise zeichnen Sie das Logo neu mit Vektoren und nicht als Bitmap. Und selbst beim SG-Format selbst gibt es noch Besonderheiten

The specific SVG profile used by BIMI is defined as SVG Portable/Secure (SVG P/S).  It is a profile of the SVG Tiny 1.2 format standardized by the World Wide Web Consortium (W3C). The SVG P/S profile is more strict than SVG Tiny 1.2, meaning an SVG Tiny 1.2 image will require modifications in order to be compliant with BIMI.
Quelle: https://bimigroup.org/creating-bimi-svg-logo-files/

Achtung
Einige Empfänger erwarten eine Signatur.

Das Bild habe ich dann einfach auf der MSXFAQ unter der folgenden URL bereitgestellt:

https://www.msxfaq.de/images/bimi.svg

Ihr Browser sollte das Bild einfach anzeigen. Wenn Sie es aber sehr groß skalieren, dann sehen Sie die JPG-Artefakte.

Die BIMI-Spezifikation sieht auch digital signierte Bilder vor. Dies sind für GMail sogar erforderlich. Die SVG-Datei wird dabei in einer PEM-Datei eingebettet und ebenfalls im BIMI-Eintrag der DNS veröffentlicht.

DNS Veröffentlichung

Der nächste Schritt ist die Bereitstellung der Information im DNS. Ähnlich dem Verfahren bei DKIM können Sie mehrere Einträge mit Selectoren verwenden, die Sie dann in der Mail selbst referenzieren. Es gibt aber auch einen Default-Eintrag:

default._bimi.msxfaq.de TXT "v=BIMI1; l=https://www.msxfaq.de/images/bimi.svg"

Den habe ich entsprechend im DNS addiert und kann per NSLOOKUP einfach geprüft werden:

C:\>nslookup -q=TXT default._bimi.msxfaq.de

default._bimi.msxfaq.de text =
        "v=BIMI1; l=https://www.msxfaq.de/images/bimi.svg"

Message Header (Optional)

Wenn ich nicht "Default" als Selector nutze, dann muss ich meinem Mailserver natürlich noch sagen, dass ich BIMI implementiert habe und wie der Client den richtigen DNS-Eintrag findet. Über eine Exchange Transport-Regel kann ich z.B. folgenden SMTP-Header addieren lassen.

BIMI-Selector: v=BIMI1; s=default;

Mit dem Selector "default" kann ich mir den Eintrag auch sparen, da alle BIMI-kompatiblen Clients immer auch nach "default._bimi.<EnvelopeFrom-Domain>" fragen sollten.

Ein Sender kann aber über diesen Header unterschiedliche Logos, z.B. für unterschiedliche Produkte, beim Empfänger einblenden lassen.

Logo Verifikation

Aktuell sieht es so aus dass Sie die Verwendung eines "Logos" von einem "Verified Mark Certificate (VMC)" überprüfen lassen müssen.

BIMI beim Empfänger

Wenn der Absender alles richtig gemacht hat, dann kann der Empfänger nun die Informationen prüfen. Hier gibt es nun die Wahl, ob der empfangende Mailserver diese Aufgabe übernimmt oder der Mailclient. Eine Prüfung auf dem Client wäre denkbar aber ist nicht vorgesehen.

7.8. Handle Existing BIMI-Location and BIMI-Indicator Headers
Regardless of success of the BIMI lookup, if a BIMI-Location or a BIMI-Indicator header is already present in a message it MUST be either removed or renamed. This is because the MTA performing BIMI- related processing immediately prior to a Mail Delivery Agent (or within the same administrative realm) is the only entity allowed to specify the BIMI-Location or BIMI-Indicator headers (e.g. not the sending MTA, and not an intermediate MTA).
Quelle: https://datatracker.ietf.org/doc/html/draft-blank-ietf-bimi-02#section-7.8

Der MTA empfängt und verarbeitet die Mail. Wenn die Mail schon Header enthält, muss er diese entfernen oder umbenennen und seine eigene Prüfung anhängen. Der letzte MTA vor der Übergabe der Mal an die Zustellung ins Postfach ist die einzige Instanz, die eine BIMI-Prüfung durchführt und das Ergebnis als Header an den Client weiter reicht.

Der Mail-Client selbst, der die Mail beim Benutzer letztlich anzeigt, beschränkt sich auf die Nutzung des vom letzten MTA angehängten BIMI-Ergebnis und führt selbst keine Überprüfung durch. Das vereinfacht die Implementierung auf dem Client aber vor allem erscheint der Client selbst nicht bei irgendwelchen externen Servern, um z.B. Informationen nachzuladen.

Der Mailserver muss  dann aber das Ergebnis der BIMI-Prüfung irgendwie an den Client bekommen. Das erfolgt über weitere Header

BIMI-Indicator Header
   BIMI-Indicator is the header a Mail Receiver inserts to pass a
   verified Indicator to the MUA.
   The header contains the SVG of the Indicator encoded as base64, and
   is inserted by the MTA after performing the required checks and
   obtaining the applicable domain's published Assertion Record.  The
   contents of this tag MUST match the SVG Indicator content retrieved
   from the URI specified in the BIMI-Location header.  If he Indicator
   was supplied as a gzipped SVGZ file then the MTA MUST uncompress the
   file before base64 encoding.

   base64string    =  ALPHADIGITPS *([FWS] ALPHADIGITPS)
                      [ [FWS] "=" [ [FWS] "=" ] ]

   And the formal definition of the BIMI Indicator Header, using ABNF,
   is as follows:
   bimi-indicator-header = bimi-sep base64string \[bimi-sep\]

Quelle: Brand Indicators for Message Identification (BIMI)
   https://datatracker.ietf.org/doc/html/draft-blank-ietf-bimi-01#section-6.3

Damit hier aber kein Missbrauch möglich ist, sollte der Mailserver, welcher die Nachricht aus dem Internet annimmt, diesen Header auf jeden Fall entfernen. Nicht, das ein interner moderne Client das von extern durch den Spammer mitgelieferte Bild anzeigt und damit den Anwender täuscht.

Wer nutzt BIMI?

Die ersten Firmen sind entweder große Mailhoster, die sehr viele Privatkonten betreiben und passende dazu die großen Versender, die viel B2C-Geschäfts haben. Hier ist der Aufwand für BIMI interessant, weil Millionen von Privatkunden die "schönen Logos" im Posteingang sehen und die Absender ihre Sichtbarkeit verbessern. Insofern ist es nicht verwunderlich, dass neben Google auch Proofpoint, SendGrid, MailChim, Fastmail hinter der BIMI-Group (https://bimigroup.org/) stecken.

Sie können einfach per DNS-Auflösung schauen, wer einen BIMI-Eintrag veröffentlicht hat.

nslookup -q=TXT default._bimi.<dns-Domain>

Der Text-Record enthält die Adressen zur Bild und zum Zertifikat, damit der Empfänger das Bild auch prüfen kann. Die folgende Tabelle habe ich im Nov 2024 zuletzt aktualisiert.

Domain  BIMI Eintrag Status
amazon.com
amazon.de
...

Amazon hat sogar ein BIMI-Zertifikat mit vielen Namen:

"v=BIMI1;
 l=https://d3frv9g52qce38.cloudfront.net/amazondefault/order_595575549_logo.svg;
 a=https://d3frv9g52qce38.cloudfront.net/amazondefault/amazon_web_services_inc_2024.pem"

OK 

cnn.com 

 
"v=BIMI1; 
 l=https://amplify.valimail.com/bimi/time-warner/I0vDrJpkRnB-cable_news_network_inc2025.svg; 
 a=https://amplify.valimail.com/bimi/time-warner/I0vDrJpkRnB-cable_news_network_inc2025.pem"

OK

linkedin.com

 
"v=BIMI1; 
 l=https://media.licdn.com/media/AAYQAQQhAAgAAQAAAAAAABrLiVuNIZ3fRKGlFSn4hGZubg.svg;
 a=https://media.licdn.com/media/AAYAAQQhAAgAAQAAAAAAALe_JUaW1k4JTw6eZ_Gtj2raUw.pem; "

OK

booking.com 

 
"v=BIMI1; 
 l=https://r.bstatic.com/static/img/newsletters/booking_bimi_icon_300.svg; 
 a=https://q-xx.bstatic.com/data/mm/booking_com_202411.pem;"

OK 

dhl.de 

 
"v=BIMI1;
 l=https://www.dhl.com/dhl-email-logo/dhl-bimi.svg;
 a= https://www.dhl.com/dhl-email-logo/dhl-vmc_20241108.pem"

OK 

news.miele.de 

 
"v=BIMI1; 
 l=https://digital-commerce.miele.com/miele-download/bimi/miele___cie__kg_941163124.svg; 
 a=https://digital-commerce.miele.com/miele-download/bimi/miele___cie__kg_941163124.pem"

OK 

msxfaq.de

 
"v=BIMI1; l=https://www.msxfaq.de/images/bimi.svg"

Keine PEM 

Auf der anderen Seite gibt es viel viel mehr bekannte Domains, die auch viele Mail senden aber noch keinen BIMI-Eintrag vorweisen, wie microsoft.com, googe.com, gmail.com, gmx.net, web.de, facebook.com, Whatsapp.com etc. Es ist schon etwas ein Henne/Ei-Problem. Solange nur wenige Clients ein BIMI-Bild anzeigen und empfangende Mailserver das Bild addieren, loht sich der Aufwand und insbesondere die doch hohen Kosten für ein BIMI-Zertifikate nicht. Sogar die Mitglieder des Anfangs (aol.com, yahoo.com) haben keinen BIMI-Eintrag mehr.
Interessant ist es primär für Firmen mit sehr vielen Mails an viele private Empfänger, die z.B. in ihrem Webclient auch das Logo sehen. Insofern ist verständlich, dass z.B. DHL.DE und BOOKING.COM dabei sind.

Risiko Fälschung1

Was auf den ersten Blick wie ein Vorteil für die Endanwender aussieht, kann sehr leicht auch missbraucht werden. Was hindert z.B. einen Phishing-Absender seine ähnlich lautende Domains mit dem bekannten Logo aufzuwerten? Der Anwender sieht dann das Firmenlogo und vertraut dieser Mail und seinem Mailsystem. Auf dieses Risiko gehen sogar die Autoren des RFC-Vorschlags selbst ein:

Ob aber eine manuell gepflegte White-List hier eine Lösung ist, wage ich doch stark zu bezweifeln. Der Ansatz einer Signierung, der im Draft zwar beschrieben aber nicht erzwungen wird, hilft hier auch nicht weiter. Google fordert die Firmen sogar auf, ihre "Logos" bei Google zur Prüfung vorzulegen:

Organizations who authenticate their emails using Sender Policy Framework (SPF) or Domain Keys Identified Mail (DKIM) and deploy DMARC can provide their validated trademarked logos to Google via a Verified Mark Certificate (VMC). BIMI leverages Mark Verifying Authorities, like Certification Authorities, to verify logo ownership and provide proof of verification in a VMC. Once these authenticated emails pass our other anti-abuse checks, Gmail will start displaying the logo in the existing avatar slot.
Quelle: https://cloud.google.com/blog/products/identity-security/bringing-bimi-to-gmail-in-google-workspace

Das Risiko eines Logo-Missbrauchs ist gerade für Spammer attraktiv und würde BIMI umgehend nutzlos machen. Worauf auch Google noch mal hinweist:

For logo validation, BIMI is starting by supporting the validation of trademarked logos, since they are a common target of impersonation. Today, Entrust and DigiCert support BIMI as Certification Authorities, and in the future the BIMI working group expects this list of supporting validation authorities to expand further.
Quelle: https://cloud.google.com/blog/products/identity-security/bringing-bimi-to-gmail-in-google-workspace

Risiko Fälschung2

Aber selbst, wenn dies alles erfolgt, scheinen einige Empfänger auch andere Domains als URL zuzulassen. Ich habe zum Test auf der MSXFAQ.DE folgenden Eintrag gesetzt:

default._bimi.msxfaq.de text = "v=BIMI1; l=https://www.dhl.com/dhl-email-logo/dpdhl_bimi.svg"

Wenn ich dann auf MXTOOLBOX meine Domain abfrage, dann wird mit das DHL-Logo angezeigt:

Nun wollte ich es natürlich wissen und habe als MSXFAQ.DE eine Mail an ein Google-Mail Konto gesendet.

Hier ist zumindest am 13. Juli 2021 kein DHL-Logo erschienen. GoogleMail scheint hier im DNS-TXT-Record nicht jedes Bild zu nutzen. Allerdings hatte ich auch keinen "Selector" im Header drin. Das ist laut RFC aber auch nicht erforderlich sondern hilft eher Firmen mit mehreren "Produkten" das passende Logo einblenden zu lassen. Ohne den Header wird der Selektor aus der Domain der "Envelope FROM"-Adresse abgeleitet. Dafür hatte mein Kollege aus dem NoSpamProxy-Teams mehr Glück. Er nutzt den Open Source "FaimailClient", der selbst BIMI macht und konnte hier das Logo von Booking.com fremdverwenden.

Das sollte so nicht passieren und ist wohl ein Implementierungsfehler. Zudem ist Booking.com aktuell wohl einer der wenigen Firmen die schon ein signiertes BIMI-Logo anbieten. Da müssten die Architekten und Entwickler noch mal ran und z.B. einen strengen Abgleich der Logo-URL zur Maildomain erzwingen.

Risiko Fälschung1: falsches Bild

Was sollte mich hindern, ein Bild bei meiner Domain zu hinterlegen, welches eine andere Firma zeigt. Sie bekommen also eine Mail von info@postbank.msxfaq.de und per BIMI blende ich ein Postbank-Logo ein. Wie viele Anwender werden wohl darauf reinfallen und nicht neben dem Bild auch noch die Domain der Mailadresse zu prüfen? Da es meine Domain ist, kann ich sogar SPF; DKIM und DMARC auf streng setzen und der empfangende Server ist wirklich sicher, dass die Absenderdomain korrekt ist.

Die Lösung hierzu heißt, dass das Bild signiert wird. Das macht z.B. DHL:

C:\>nslookup -q=TXT default._bimi.dhl.de

default._bimi.dhl.de text =

"v=BIMI1;l=https://www.dhl.com/dhl-email-logo/dhl-bimi.svg; a= https://www.dhl.com/dhl-email-logo/dhl-vmc.pem"

Im BIMI-Record von DHL ist nicht nur die URL zum Bild drin, sondern auch noch eine URL zu einer PEM-Datei. Diese können Sie im Browser einfach aufrufen und sehen eine BASE64-kodiertes Zertifikat.

Kopieren Sie den Text in einen Editor und speichern Sie ihn als PEM oder CER-Datei. Windows kann diese Datei dann direkt anzeigen und halt folgende Daten

Aussteller: CN = DigiCert Verified Mark RSA4096 SHA256 2021 CA1 O = DigiCert, 
Inc. C = US
Gültigkeit:  1 Jahr
Antragsteller: 1.3.6.1.4.1.53087.1.4 = 003056421
1.3.6.1.4.1.53087.1.3 = EM
1.3.6.1.4.1.53087.1.13 = Registered Mark
CN = Deutsche Post DHL Research and Innovation GmbH
O = Deutsche Post DHL Research and Innovation GmbH
STREET = Heinrich-Brüning-Straße 5
L = Bonn
S = Nordrhein-Westfalen
C = DE
SERIALNUMBER = HRB 9000
2.5.4.15 = Private Organization
1.3.6.1.4.1.311.60.2.1.1 = Bonn
1.3.6.1.4.1.311.60.2.1.2 = Nordrhein-Westfalen
1.3.6.1.4.1.311.60.2.1.3 = DE
Schlüsselverwendung: Unbekannte Schlüsselverwendung (1.3.6.1.5.5.7.3.31)

Interessant ist aber das Feld "Logo", welches anscheinend die SVG-Datei enthält.

Damit stellt sich natürlich die Frage, wie die ausstellende PKI das Bild überprüft. Der Inhaber der Domain muss also anstatt eines Hostnamens beim HTTPS-Zertifikat oder Mailadresse bei SMIME ein Bild senden und die PKI muss diese Bild "prüfen". Das wird wohl nur ein Mensch durchführen. Interessant ist in dem Fall, dass die PKI auf einem Windows 11 Client von Okt 2023 nicht als "Trusted" eingestuft wird.

In diesem Fall ist Digicert der Aussteller. Aber ich bin sicher, dass sich diesen Markt auch die anderen PKIs nicht entgehen lassen. Digicert ruft dafür z.B. 1499 US$ auf.

Der BIMI-Text im DNS enthält bei DHL die einfache URL für ein Bild als auch die URL zu einem signierten Bild. Nun liegt es natürlich am Empfänger, dass er z.B. nur signierte Bilder anzeigt. GMail scheint zwingend auf signierte SVG-Dateien zu setzen.

Risiko Tracking der Zustellung

Der Empfänger MTA nimmt die Mail an und wenn er BIMI versteht, dann wird er das Bild per HTTP herunterladen und als Header in die Mail einbinden. Dieser "Abruf" kann vom Webserver natürlich erfasst werden, um die Zustellung zu verfolgen.

Theoretisch könnte ich sogar für jede individuelle Mail einen eigenen "Selector" im Header vorgeben, der dann durch einen präparierten DNS-Server mit einer individuellen URL beantwortet wird. So kann ich dann über den https-Abruf für jede Mail erkennen, wann der Ziel-MTA die Mail angenommen und das BIMI-Ion nachgeladen hat.

Technisch sicherlich möglich aber ich bin noch nicht sicher, welchen Mehrwert ein Absender davon hat. Er kann erst einmal erkennen, dass es das Postfach vermutlich gibt, wobei ein guter Mailserver dann schon die Annahme verweigert hätte. Und der Absender kann erkennen, das etwas am Ziel schon BIMI unterstützt und sich daher eines der andere Risiken vielleicht ausnutzen lassen könnte.

Weitere Links