Spam und UCE - Filter: DKIM

Andere Bezeichnungen: Identified Internet Mail, IIM, DomainKeys Identified Mail

Viele Spammer verstecken sich hinter falschen Absenderadresse, was letztlich den angeblichen Absender stört. Rückläufer, unzustellbarkeitsmeldungen aber auch die Frage der Authentizität u.a. kosten Zeit und Bandbreite. Daher möchte der Absender sicherstellen, dass niemand mit seinem Namen etwas sendet. Hierzu gibt es mehrere Ansätze.

So nutzen SPF und RMX die IP-Adresse des einliefernden Gateways zur Validierung. Problem hierbei ist aber, dass eben ein Server und nicht die Mail selbst validiert werden kann. DKIM ist ein Ansatz, bei der die Mail digital signiert wird, so dass jede Station und sogar der letzte Mailserver prüfen kann, ob die Mail verändert wurde und die Domäne des Absender korrekt ist. Nebenbei wird so sichergestellt, dass die Mail wirklich vom Mailserver des Absenders signiert werden musste.

Exchange Online kann Mails per DKIM signieren und das sollten Sie möglichst auch tun: DKIM mit Office 365
Exchange On-Premises kann es nicht selbst. Aber auf https://GitHub.com/Pro/dkim-exchange gibt es einen Transport Agent und vorgeschaltete Spamfilter wie z.B. NoSpamProxy können dies natürlich auch.

So funktioniert es

DKIM funktioniert über eine asymmetrische Verschlüsselung der kompletten Mail.

  • PublicKey im DNS
    Im DNS wird ein Public Key für die Domäne des Senders hinterlegt. Dazu wird entweder ein TXT oder der eigens definierte Resource Record (RR)  "_domainkey" genutzt.
    Hier eine Ausgabe von Yahoo, einer der treibenden Institutionen hinter Domainkey/DKIM. Interessant ist, dass viele andere Firmen, die DKIM angeblich können, per DNS keine Abfrage gestatten. Gerade Cisco hat z.B. noch keinen "_domainkey"-Eintrag (Stand 28. Mai 2007)
> set q=any
> _domainkey.yahoo.com

_domainkey.yahoo.com text =

"t=y; o=~; n=http://antispam.yahoo.com/domainkeys"
_domainkey.yahoo.com internet address = 66.94.234.13
_domainkey.yahoo.com internet address = 216.109.112.135
  • Sender: Signierung der Mail (Body und Header)
    Der sendende Mailserver signiert die Mail indem ein Hashwert gebildet und mit dem private Key verschlüsselt am Anfang des Headers addiert wird.
    DKIM Generation
  • Empfänger testet
    Der annehmende Mailserver sieht anhand des Headereintrags diese Einstellung, liest den PublicKey per DNS aus und prüft die Signatur des Header. Passt sie, dann ist die Absenderadresse korrekt, ansonsten ist es ein Versuch mit einer falschen Absenderadresse zu senden.

Da im Header auch die "FROM"-Adresse des Absenders mit drin ist und der zum Public Key der Domäne passende Private Key sicher kein Spammer hat, kann niemand eine falsche FROM-Adresse verwenden. Und wenn schon einmal sicher ist, dass der Absender nicht gefälscht ist, dann lassen sich auch schnell Datenbanken mit "guten und schlechten" Absendern erstellen. Also eine Art Reputation für Absender.

Yahoo nutzt aktuell dieses Verfahren, bei dem ausgehende Mails mit einer Signatur gesendet werden.

Mit einer passenden Software könnten Sie dann prüfen, ob eine Mail, die angeblich von Yahoo kommt, auch wirklich von Yahoo ist. Das hilft, damit ein Spammer nicht mehr eine Yahoo Adresse fälscht.

Die Argumente

Was so einfach aussieht ist bei weitem nicht so einfach.

  • Ende zu Ende Signatur
    Der Absender signiert die Mail und der Empfänger  prüft. Es ist dabei keine Erweiterung des SMTP-Standards erforderlich, da die komplette Verarbeitung Teil der "Mail" ist. Es ist daher auch nicht relevant, welche und wie viele Relays dazwischen sind.
  • Kostengünstig das keine CA
    Jeder Mailversender kann sich selbst ein Schlüsselpaar erstellen, die Mails mit DKIM signieren und im DNS den dazu gehörigen Public Key bereit stellen. Das spart Kosten, da keine "teure" CA involviert sein muss.
  • Neuer Angriff: DNS-Spoofing
    Allerdings kann damit wirklich jeder ohne Validierung Mails versenden, so lange er nur den Public Key im DNS unterbringen kann oder dem Empfänger eben das vorgaukelt. Bei DNS ist es nun mal so, dass ein Server nicht den DNS-Server der anderen Domäne fragt, sondern meist über Forwarder des Providers geht. Diesem System kommt dann eine besondere Rolle zu. Wird dieser Service "gehackt", dann haben Spammer offene Türen.
  • Bedingter Schutz da nur "Positiv Kennung"
    Nur weil ein Spammer oder Virus sich nicht mehr hinter einer falschen Mailadresse verstecken kann, wird er nicht aufhören zu spammen. Zumal in der RFC auch drin steht, dass man keine Mail ablehnen sollte, wenn DKIM nicht verfügbar ist oder gar fehl schlägt. DKIM bestätigt also nur beim Erfolg, dass der Absender auch tatsächlich von der Domäne gekommen ist.
  • Key-Generierung und DNS
    Der Absender muss ein Schlüsselpaar generieren, was schon an sich fehleranfällig ist und den Public Key richtig im DNS eintragen. Um den Public Key im DNS eintragen zu können, muss der Absender dies auch können. Viele Webhoster erlauben noch nicht diese Eintragungen. Ich frage mich, warum ich den Domainkey nicht einfach z.B.: auf meinem Webserver als Zertifikat, XML-Datei o.ä. hinterlegen kann. Den Inhalt des Webserver kann ich sicher einfacher selbst pflegen.
  • Newsletter und "Resend"
    DKIM hat zum einen den Vorteil, dass eine Mail von einem Absender durch einen Listserver tausendfach an die Teilnehmer der Loste versendet werden kann. Die Mail selbst ändert sich ja nicht, was bei SPF ein Problem ist. Aber dies ist zugleich auch das Risiko. Ein Angreifer muss nur eine Mail von ihnen erhalten und kann diese millionenfach versenden. Der original Sender kann sich nicht dagegen wehren, und der Empfänger kann natürlich behaupten, dass Sie wirklich der Absender sind. Wenn ich jemandem schaden wollte, dann warte ich nur auf eine Mail von diesem Absender mit gültigem DKIM. Zumindest wenn ein Dienstleister tausende Empfänger mit einem Rundschreiben versendet, kann es kaum rausfinden, welcher Empfänger die Mail "weiter gegeben" hat.
  • Reihenfolge der Header
    Es gibt Mailserver, die die Reihenfolge der Header neu aufbauen. In diesem Fall "bricht" natürlich die Signatur. Dies ist gerade bei Spamfiltern, Virengateways etc. der Fall, die damit sicherstellen wollen, dass die Mail komplett demontiert, geprüft und konform zusammen gesetzt wurde.
  • Public Key Austausch
    Laut RFC  sollte die Prüfung der Signatur möglichst früh erfolgen. Es kann ja sein, dass ein Sender seinen Schlüssel ändert. Zwar kann man im DNS auch mehrere Public Keys hinterlegen, aber es kann passieren, dass eine Validierung beim Empfänger fehlschlägt, weil der Sender schon den Key geändert hat oder der DNS Cache noch nur die alten Keys bereitstellt.
  • Relay Bye Bye ?
    Bei der Übertragung fügt jeder Server in der Regel einen Eintrag für den Hop im "Header" dazu. Das bedeutet aber auch, dass die Signatur des Headers dann nicht mehr stimmt.
    Auf der Infoseite zu Yahoo steht dazu "..and the private key is made available to their DomainKey-enabled outbound email servers". Dies bedeutet, dass ich einen meiner privaten Schlüssel den ausgehenden Mailservern, z.B.: auch einem ausgehenden Relay beim Provider übergebe.
    In der RFC steht aber, dass nur die Zeilen nach dem DKIM-Header bezogen werden. Ein Addieren von Zeilen davor ist wohl unkritisch.
  • Kein Early Reject möglich
    Abgesehen davon, dass die RFC abrät, Nachrichten mit einer fehlgeschlagenen DKIM-Prüfung abzulehnen ist eine früher Ablehnung nicht möglich. Zudem der Header der Mail übertragen werden, ehe Sie geprüft werden kann.

Vermutlich wird es noch lange dauern, bis dieses Verfahren effektiv zum Schutz beiträgt. Ich persönlich gebe da SPF oder CallerID bessere Chancen, auch wenn Yahoo solch ein Verfahren durchführt.

Persönliche Meinung

Nur weil Cisco und Yahoo einen Standard aus der Taufe heben, muss dies nicht besser oder schlechter als der Versuch von Microsoft und anderen sein, SPF/SenderID zu pushen. Das Problem bleibt, dass sowohl Absender als auch Empfänger diese Tests alle erst implementieren müssen. Dies wird sicherlich "Jahre" dauern und es ist nicht mal sicher, dass dies die Spamflut eindämmt. Es kann allerdings helfen, dass Firmen, die die Identität der Absender prüfen möchten und Absender, die DKIM implementieren, hier den Vorteil haben, gefälschte Mails (Phishing) zu erkennen bzw. korrekte Mails deutlich machen zu können.

Ich persönlich würde mich freuen, wenn alle Firmen einen DKIM-Key im DNS veröffentlichen und ihre Mail signieren,  aber ich befürchte, dass dies nur eine Minderheit letztlich tut und damit das Verfahren nur geringe Vorteile bringt. Interessanter wäre hier wirklich die digitale Signierung der Verbindungen TLS oder der Mails selbst (SMIME), auch wenn dazu offizielle Zertifikate erforderlich wären.

Allerdings geben ich SMIME oder TLS auf dem Gateway eher eine Chance, weil damit Mails mit einem sehr viel länger bekannten Standard digital signiert werden und die Signatur über ein von einer CA ausstellten CA erfolgt. Der empfangende Mailserver muss also nicht erst im DNS nach dem Public Key schauen, sondern hat ihn schon in der Signatur samt Aussteller. Und wenn der empfangende Mailserver dies noch nicht kann, dann kann immer noch der Client die Prüfung vornehmen. Es ist also sehr viel einfacher, über den Weg gefälschte Absender zu erkennen und abzulehnen.

DKIM prüfen

Wenn Sie die Header eine Mail haben, und eine DKIM-Signatur prüfen wollen, dann machen Sie das besser nicht von Hand sondern mit einem Tool oder einer Library. Es ist schlicht unmöglich manuell aus dem DKIM-Eintrag die Felder zu extrahieren, darüber Hashwerte zu erstellen und die Signatur mit dem per DNS erhaltenen öffentlichen Schlüssel zu verifizieren. Das "Header From"-Feld ist übrigens immer Teil der Signatur, auch wenn es nicht explizit aufgeführt wird. Eine Mail kann auch mehrere Signaturen haben und sie können alle prüfen. Allerdings werden vielleicht nicht alle Signaturen auch gültig sein. Die RFC6376 schreibt dazu

- The order in which Verifiers try DKIM-Signature header fields is not defined; Verifiers MAY try signatures in any order they like.
- Survivability of signatures after transit is not guaranteed, and signatures can fail to verify through no fault of the Signer. Therefore, a Verifier SHOULD NOT treat a message that has one or more bad signatures and no good signatures differently from a message with no signature at all
- When a signature successfully verifies, a Verifier will either stop processing or attempt to verify any other signatures, at the discretion of the implementation.
https://www.rfc-editor.org/rfc/rfc6376.html#page-44

Aber solange eine Signatur ein "PASS" liefert, gibt es einen Mailserver in der Kette, der dem Absender soweit vertraut dass er die FROM-Adresse mit signiert hat. Der Signierer muss dazu nicht einmal eine Schlüssel der Absender-Domain haben:

1.1. Background
... DKIM does not define any meaning to the occurrence of a match between the content of a "d=" tag and the value of, for
example, a domain name in the RFC5322.From field,..
Quelle: RFC 6377 DomainKeys Identified Mail (DKIM) and Mailing Lists

Allerdings kommt da irgendwann dann DMARC ins Spiel, welches hier eine andere Funktion vorgibt. Sobald es für die Absenderdomain einen DMARC-Eintrag gibt, kommt ein "Alignment" zum Tragen und eine Mail wird nur dann nicht als "Fail" klassifiziert, wenn SPF oder DKIM ein PASS liefern, wobei die DKIM-Prüfung strenger gehandhabt wird:

(SPF=PASS or DKIM=PASS)
AND
(header-from and envelope-from is aligned or DKIM domain d= aligned with header-from).

Verifiers MUST confirm that the domain specified in the "d=" tag is the same as or a parent domain of the domain part of the "i=" tag.
The domain part of the (i=) address MUST be the same as, or a subdomain of, the value of the "d=" tag.
https://www.rfc-editor.org/rfc/rfc6376.html

Hier ein paar Links zu Webseiten und Libraries zur DKIM-Verifizierung.

Es gibt verschiedene Webseiten, an die Sie eine Testmail senden können und ihnen dann einen Report zurück senden. Dies ist hilfreich, wenn sie DKIM; SPF, DMARC für ihren eigenen Server einsetzen und daher darüber senden.

Für schnelle Analysen habe ich die Seite "appmaildev.com" gefunden. Hier können Sie auch einen Header per Web-Formular hochladen.

Einsatz unter Exchange

Keine Exchange On-Premises-Version unterstützt aktuell DKIM.
Exchange Online hingegen kann schon DKIM signieren. Siehe auch DKIM mit Office 365

Das bedeutet aber nicht, dass Sie nicht dennoch ihre ausgehenden Mails per DKIM signieren können. Sie müssen aber entweder Exchange um eine passende Zusatzsoftware erweitern oder auf dem Weg nach extern könnte ein Mailrelay, z.B. ein vorgelagerter Spamfilter, in ihrem Auftrag eine DKIM-Signatur anbringen, ehe die Mail durch das Internet zum Ziel übertragen wird.

Sie können also auf jedem Exchange Server einen Transport Agent installieren oder auf dem Weg nach extern ein passendes Produkt kaufen:

Die meisten Firmen werden aber meist sowieso ein Gateway zwischen Internet und Exchange betreiben, so dass die Funktion auch dort implementiert werden kann. Entsprechende Unterstützung bietet aktuell z.B. Sendmail, mdaemon, SpamAssasin, Postfix und andere

DKIM und Office 365

Office 365 Unterstützt sowohl DKIM als Verifikation für eingehende Mails als auch die Kennzeichnung beim Versand von ausgehenden Mails. Dazu muss der Administrator im DNS einen Verweis auf die Office 365 Keys addieren und natürlich in der Powershell DKIM aktivieren.

Leider ist aktuell die DKIM-Umsetzung beim Durchleiten von Mails defekt, denn Exchange online addiert nicht nur die Standardfelder, sondern berücksichtigt auch noch das Feld "X-MS-Exchange-SenderADCheck" in der Signatur. Genau das Feld wird von Exchange Online beim Empfang einer Mail aber von 1 auf 0 gesetzt, da der Absender ja nicht verifiziert ist. Wenn diese Mail dann umgeleitet wird, bricht die DKIM-Signatur.

DKIM und Strafverfolgung

Stellen Sie sich vor, jemand nutzt Mail für Erpressung, Droh-Mail, antisemitische Äußerungen o.ä. Wenn Sie Mail dann per DKIM signiert ist, dann lässt sich beim Empfang schon prüfen, ob Absender und Inhalt unverändert sind. Allerdings fügt kein Endanwender diese Signaturen an. Es ist immer der Mailserver, der für die Domain zuständig ist und den privaten Schlüssel hat. DKIM ist also nicht mit SMIME zu verwechseln. Der Absender könnte immer noch sagen, er war es nicht, weil beim Provider jemand die Mail eingekippt hat oder sein Konto kompromittiert war.

Hinzu kommt dass das Schlüsselpaar zur Signierung auch einfach gewechselt werden kann. Vielleicht haben Sie vor einigen Tagen oder Wochen eine DKIM-signierte Mail bekommen und damit hat ihr empfangender Mailserver die Signatur geprüft und das Ergebnis im Header addiert. Diese Eintragungen kommen aber von ihren Server und könnten also auch von ihnen gefälscht werden.

Wenn der Absender aber nach dem Versand das Schlüsselmaterial getauscht hat, können Sie die DKIM-Prüfung nicht wiederholen. Angeblich soll dies auch schon mal einem Politiker zum Verhängnis geworden sein, dass die DKIM-Signatur auch später immer noch verifizierbar ist.

Das soll nun aber nicht als Aufruf verstanden werden, die DKIM-Zertifikate im Abstand weniger Tage immer wieder zu tauschen.

Weitere Links