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.

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 signierte SVG-Datei.

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.

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.sv"

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 es schon?

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.

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 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