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.

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 muss die Mail erst komplett übertragen werden, ehe Sie eventuell verworfen wird.

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.

Einsatz unter Exchange

Keine Version von Exchange unterstützt aktuell DKIM und es sind auch keine Anzeichen zu sehen, dass dies in naher Zukunft der Fall sein wird. das CERN hat jedoch einen SMTP-Sink entwickelt, um DKIM für Exchange zu integrieren.

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.

Weitere Links