E-Mails signieren mit DKIM

Ursprünglich sollte das Verfahren DomainKeys Identified Mail nur die Spam-Flut eindämmen. Doch da es gefälschte Absenderadressen entdeckt, hilft es besser gegen Phishing. Erst zusammen mit der Spam-Reputation des Absenders verringert es auch die Viagra-Werbung in der Inbox.

Spammer wollen normalerweise unerkannt bleiben, nicht nur, um den inzwischen horrenden Geldstrafen zu entgehen, die ihnen in den USA drohen. Daher versenden Sie Mail-Müll meist mit falschen Absenderadressen. Phisher, die arglose Nutzer auf gefälschte Internet-Seiten locken wollen, um ihnen Passwörter, PINs und TANs abzuluchsen, senden grundsätzlich unter falscher Flagge – schließlich müssen ihre Nachrichten ja wie die von einer Bank wirken, damit der Trick funktioniert. Ihr böses Handwerk wäre viel schwieriger, wenn sich feststellen ließe, dass eine E-Mail wirklich von dem kommt, der sich als Absender ausgibt. Dazu sollten gutwillige Versender die Urheberschaft ihrer Nachrichten in automatisch auswertbarer Form bestätigen.

Das könnten die Anwender selbst übernehmen, indem sie alle ihre Mails mit einer digitalen Signatur versehen. In jedem brauchbaren E-Mail-Programm erfordert eine solche PGP- oder S/MIME-Unterschrift höchstens einen Klick. Doch mehr als 15 Jahre nach der Einführung von PGP bleibt der Anteil vom Nutzer signierter E-Mail verschwindend gering.

Folglich muss der Absender von Servern geprüft und bestätigt werden. Ein Protokoll dafür heißt SPF (ursprünglich Sender Permitted From, jetzt Sender Policy Framework). So wie im DNS in MX-Records steht, welcher Server die Mail für eine Domain annimmt, schreibt der Postmaster einfach auch ins DNS, welche Server sie für diese Domain verschicken. Wenn von einer anderen IP-Adresse Mail mit dieser Absender-Domain kommt, unterbricht der empfangende Server einfach die Verbindung.

In der Praxis zeigte sich schnell ein prinzipielles Problem: Wenn ein Anwender oder eine Mailingliste außerhalb der ursprünglichen Absender-Domain die E-Mail weiterleitet, passen Server-IP und Absenderadresse nicht mehr zusammen. Außerdem muss der Postmaster ständig daran denken, den SPFEintrag im DNS mit Änderungen an seinem Mail-Server synchron zu halten. Im Moment führt SPF deshalb zu mehr fälschlich abgelehnten Nachrichten als es Spam aussortiert. Sowohl bei Yahoo als auch bei Cisco entstanden 2004 Verfahren, die das Beste der beiden Ideen kombinieren: Um den Nutzer nicht zu belasten, bringt der Server an jeder E-Mail eine kryptografische Signatur an, die von der IP-Adresse des Servers unabhängig ist. Beide Firmen warfen Ihre Bemühungen zusammen und so entstand 2007 der Internetstandard DKIM (inzwischen ergänzt um einige Präzisierungen im RFC 5672). In der freien Wildbahn trifft man häufig noch Signaturen nach dem prinzipiell kompatiblen aber überholten Yahoo-Verfahren an.

Digitale Unterschriften sind Brot und Butter der Kryptografie. Der Unterzeichner erzeugt sich ein Paar von Schlüsseln: Was mit dem einen verschlüsselt ist, kann man nur mit dem anderen entschlüsseln. Wenn der Absender den einen Schlüssel geheim hält und den anderen veröffentlicht, funktioniert das als Unterschrift. Denn was sich mit dem öffentlichen Schlüssel entschlüsseln lässt, muss mit dem geheimen Gegenstück verschlüsselt worden sein. Wenn also der öffentliche Schlüssel passt, muss die Nachricht von jemandem kommen, der den geheimen Schlüssel besitzt.

Um die Nachricht auch für Empfänger lesbar zu erhalten, die DKIM noch nicht entschlüsseln können, wird sie nicht komplett verschlüsselt, sondern zuvor eine Art Quersumme der Buchstaben berechnet, der so genannte Hash. In die Nachricht wird dann nur noch der mit dem geheimen Schlüssel verrechnete Hash eingefügt. Das Ergebnis der Hash-Funktion ändert sich stark, sobald sich die Nachricht auch nur wenig ändert. Deshalb passt die Unterschrift nicht mehr, wenn die Nachricht manipuliert wurde. Die entscheidende Idee ist nun, dass nicht jeder einzelne Nutzer, sondern der absendende Server die E-Mail signiert. Sofern der Postmaster auf seinen geheimen Schlüssel gut aufpasst, ist damit sichergestellt, dass die Nachricht von seinem Server kam und anschließend nicht mehr verändert wurde. Das hindert zum Beispiel Phisher daran, einfach eine echte Bank-Mail abzufangen und einen Link auf ihre Seite einzufügen.

Sicherungskasten

Kopfsache

Um den Inhalt einer E-Mail (den Body) zu signieren, genügen der verschlüsselte Hash und ein Hinweis auf den Schlüssel. Doch DKIM sichert auch die Header gegen Manipulationen und soll möglichst flexibel einsetzbar sein, auch in mehrstufigen Mail-Systemen und bei E-Mail-Dienstleistern. Daher sind einige Zusatzinformationen erforderlich. Der Server fügt in die E-Mail einen zusätzlichen Header "DKIM-Signature" ein, an dem sich die Probleme und Prinzipien des Verfahrens zeigen. Er sieht beispielsweise so aus:

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple;
d=example.net; s=mail200801; i=dau@sub.example.net;
h=Date:From:To:Subject:Message-ID:References:Content-
Type:Content-Disposition:Content-Transfer-Encoding;
bh=8FBe8u6BvmKcvYyKlx+oYvPBSj4=; b=I+oWYOxFAk
...
Ajcxdz66BEmd8Mqs9lD2U=

Der Header besteht aus mehreren Feldern, die jeweils aus einem Buchstaben, gefolgt von einem Gleichheitszeichen und dem Wert bestehen. Hinter v= steht die benutzte Version des DKIM-Standards, die seit der Veröffentlichung des RFC "1" lauten sollte. Mit a= werden Hash- und Verschlüsselungsalgorithmus angegeben.

Hinter c= verbirgt sich die "Canonicalization": Auf dem Weg der Mail kann es passieren, dass Server die Mail anders umbrechen, die Großschreibung ändern und Leerzeichen einfügen oder löschen. Besonders bei den Headern ist das üblich, um sie leserlicher zu gestalten. Doch solche im Mail-Standard erlaubte Änderungen würden die Signatur entwerten. Wenn jedoch der Versender vor dem Signieren und der Empfänger vor dem Prüfen der Signatur die Nachricht auf die gleiche Weise umformatieren, bleibt die Unterschrift gültig. Hier bedeutet relaxed unter anderem, Umbrüche aus den Headern zu entfernen und mehrere Leerzeichen zu einem zusammenzuführen. Hingegen erlaubt strict keinerlei Änderungen. Die Empfehlung lautet, wie im Beispiel die Header relaxed zu behandeln und den Rest der Mail strict, was die beiden durch einen Schrägstrich getrennten Angaben bewirken.

Mit d= wird die Domain angegeben, mit deren Schlüssel die Nachricht signiert wurde. Das muss nicht unbedingt der im From:-Header angegebene Absenderadresse entsprechen, zum Beispiel wenn eine Mailingliste im Spiel ist. Zusätzlich gibt s= einen "Selektor" an, den Namen des Schlüssels. Der Versender legt seinen öffentlichen Schlüssel unter diesem Namen in der Subdomain _domainkey in seinem DNS-Server ab, und zwar als Eintrag vom Typ TXT. So kann jeder Empfänger den Schlüssel leicht abfragen und eine zusätzliche Infrastruktur zur Schlüsselverwaltung entfällt. Außerdem ist es nicht nötig, dass eine vertrauenswürdige Stelle die Echtheit des Schlüssels bestätigt, denn nur der Absender kann seinem DNS-Server einen Eintrag hinzufügen.

Der Schlüssel lässt sich auch auf der Kommandozeile mit dem Befehl nslookup -type=TXT mail200801._domainkey.example.net abfragen. Der zurückgelieferte TXT-Record ähnelt auf den ersten Blick der Signatur:

v=DKIM1; k=rsa;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0N
...
lK5b7PeJHBv4MejV0G3hwIDAQAB

Die Felder enthalten die DKIM-Version (v=, optional), den Schlüsseltyp (k=, optional) und den Schlüssel selbst (p=). Durch unterschiedliche Selektoren kann eine Domain mehrere Schlüssel benutzen. Der RFC empfiehlt, den Schlüssel regelmäßig zu wechseln und den alten als ungültig zu kennzeichnen. Dazu lässt der Admin den TXT-Record in seinem DNS, löscht jedoch den eigentlichen Schlüssel, also den Teil hinter p=. Über eine Versionsnummer oder Datumsangabe im Selektor lässt sich dann leicht zwischen gültigen und widerrufenen Schlüsseln umschalten. Die Signatur umfasst den Körper der Mail und die Header, um beispielsweise sicherzustellen, dass sich kein Fälscher als Absender ins From: einträgt. Damit unterwegs eingefügte oder unwichtige Header die Signatur nicht stören, enthält der DKIM-Header eine Liste der signierten Felder (h=). Hier können auch Header stehen, die in der E-Mail gar nicht vorkamen, um zu verhindern, dass sie unterwegs eingefügt werden. Das Feld i= enthält die "Identity", für die signiert wurde. Das kann der komplette Absender sein oder auch die (Sub-)Domain, für die der signierende Server zuständig ist. Das Beispiel zeigt, dass die E-Mail-Adresse durchaus zu einer Subdomain der mit d= angegebenen Domain gehören darf. Im Header steht der Hash des Body (bh=), damit der Empfänger Veränderungen auch dann bemerken kann, wenn der öffentliche Schlüssel durch eine DNS-Störung nicht verfügbar ist oder widerrufen wurde. Am Ende steht dann mit b= die eigentliche Signatur.

Vertrauenssache

Eine korrekte DKIM-Signatur zeigt dem Empfänger, dass die Mail den Server passiert hat, auf dem der private Schlüssel liegt, der zu dem per DNS veröffentlichten passt. Doch bedeutet eine fehlende Signatur nur dann, dass die Nachricht gefälscht wurde, wenn der Absender ausnahmslos alle E-Mails signiert. Solche "Policy"-Informationen waren auch Bestandteil des Yahoo-Verfahrens DomainKeys, doch DKIM lagert sie in einen eigenen RFC aus, der noch nicht verabschiedet ist. Das Protokoll soll "Sender Signing Practices (SSP)" heißen und den Umgang mit nicht oder ungültig signierten Nachrichten regeln.

DKIM – auch ohne SSP – stellt sicher, dass die E-Mail aus der Domain des angegebenen Absenders stammt. Gegen Phishing mit prinzipbedingt gefälschten Absendern hilft das Verfahren sofort. Doch schon jetzt gibt es den ersten signierten Spam zum Beispiel von Yahoo- und Googlemail-Adressen. Eine korrekte Signatur allein reicht folglich nicht als Filterkriterium; der Postmaster muss zusätzlich einschätzen, ob aus einer per DKIM bestätigten Domain Spam zu erwarten ist. Damit befasst sich der Standard jedoch nicht, da es keine technische Frage ist, sondern eine des guten Rufs. Bekannte Absender kann der Admin dank DKIM am Spamfilter vorbeilassen, doch bislang fehlt es an Verfahren, um die Reputation eines unbekannten Senders zu berücksichtigen. Mit Karmasphere gibt es aber schon einen ersten Versuch, diese Information zu sammeln und maschinenlesbar zur Verfügung zu stellen.

Praxis-Einsatz

Praxis

Über ein halbes Jahr ist der DKIM-Standard nun alt, trotzdem haben erst wenige Admins ihren Servern das Verfahren beigebracht. Dabei lässt es sich selbst in ein mit Anti-Spam- und Anti-Virenfiltern bis an die Zähne bewaffnetes Mailsystem integrieren – wenn die Planung stimmt.

Eine DKIM-Signatur in der E-Mail schadet keinem, aber das Verfahren hilft umso besser bei der Spam-Vermeidung, je mehr Domains ihre Mail signiert verschicken. Postmaster, die ihrem Mail-Server das Signieren und Verifizieren ein- und ausgehender E-Mails gemäß RFC 4871 beibringen möchten, sollten zuerst sicherstellen, dass der eigene Mail-Server nicht zum Spam-Versand missbraucht werden kann. Denn wenn er eine untergeschobene Mail mit der Absender-Signatur adeln würde, wäre das fatal für die Reputation. Die Empfänger könnten die Signatur nicht mehr als Kriterium zum Filtern benutzen und sie wäre somit überflüssig. Wenn der Server wasserdicht läuft, folgt die Planung, an welcher Stelle im Mailtransport eine Nachricht bearbeitet werden soll. Nur so bringt DKIM einerseits den etablierten Ablauf nicht durcheinander und andererseits kommen die bestehenden Prozesse DKIM bei seiner Arbeit nicht in die Quere.

Erst nach der Planungsphase generiert der Postmaster die Schlüssel und integriert sie in den SMTP- und den DNS-Dienst. Damit kann das System dann DKIM-Signaturen hinzufügen und es kann auch DKIM-Signaturen in Mails erkennen. Um anhand der so gewonnenen Signatur-Informationen Spam- und Phishing-Mails herauszufiltern, muss der Postmaster zuletzt die Regeln seiner Content-Filter anpassen.

Bitte hier unterschreiben

Ein typischer Mailserver besteht aus mehreren Komponenten für die einzelnen Aspekte des Mailtransports. Ein SMTP-Server – in diesem Artikel wird es Postfix sein – hat die Aufgabe, E-Mails aus dem Internet anzunehmen; eine Mailinglisten-Software wie mailman verteilt Nachrichten an Abonnenten und eine Content Inspection Engine (hier: amavisd-new) regelt die Überprüfung der Nachrichten durch Filter wie SpamAssassin und trennt damit Gut von Böse.

Grundsätzlich kann der annehmende Server schon während der SMTP-Session mit dem Absender die Signatur prüfen, bevor er die Mail annimmt (Position 1 in der Abbildung oben rechts). Oder die Prüfung findet erst im Content-Filter statt, wenn die Mail bereits im System ist (Position 2). Bei der ersten Variante liefert der absendende Server die Mail an den DKIM-tauglichen Server und wartet innerhalb der SMTP-Session auf die Quittung. Der empfangende Server prüft – ganz RFC-konform – die Unterschrift, bevor er antwortet und gibt bei einem Fehlschlag sofort eine Fehlermeldung zurück. Dafür spricht, dass der absendende Server sofort weiß, woran er ist und den Absender informieren kann. Andernfalls geht die Verantwortung für die weitere Beförderung auf den empfangenden Mailserver über und der absendende kann die Nachricht aus seiner Warteschlange entfernen.

Dagegen spricht, dass sich die frühe Prüfung in der Realität eher selten robust implementieren lässt. Denn bis ein gut beschäftigter Server sich entschieden hat, ob er die Nachricht annehmen will, kann der andere schon längst die SMTP-Sitzung abgebrochen haben. Denn erstens muss der Verifizierer sich den passenden öffentlichen Schlüssel per DNS aus den Weiten des Internet besorgen. Zweitens kosten die kryptographischen Berechnungen einiges an CPU-Zeit. Je nach Last auf dem empfangenden Server kann das so lange dauern, dass der Sende-Timeout des absendenden zuschlägt und er die Sitzung beendet. In der Regel versucht er es zwar dann später wieder, aber die Prüfung kann auch dann wieder zu lange dauern und schließlich schickt er die Nachricht unvollbrachter Dinge an den Anwender zurück.

Vor allem, wenn keine gesicherten Erkenntnisse über die Systemressouren und das Lastverhalten des eigenen Mailsystems vorliegen, ist es deshalb besser, die Signatur später zu prüfen. Dazu akzeptiert der Server die Mail und erst die anschließende Filterkette verarbeitet sie, wenn kein ungeduldiger Absender-Server mehr zu bedienen ist. Allerdings muss der Server eine Nachricht, die er einmal angenommen hat, auch dem Anwender zustellen. Wie weit der Postmaster beim späten Filtern noch gehen darf, ohne sich juristischen Ärger einzuhandeln, behandelt der Kasten auf Seite 123 im kostenpflichtigen Artikel Spam-Golem.

Wann signieren?

Wann signieren?

Bei der Entscheidung über den besten Zeitpunkt zum Signieren der ausgehenden EMail sind andere Aspekte wichtig. Eine Signatur bezeugt den Zustand der Nachricht im Moment des Signierens. Wird die E-Mail danach verändert, stimmt die Signatur nicht mehr. Genau so werden Manipulationen erkannt. Wenn das Mailsystem die Nachricht nach dem Unterzeichnen noch selbst verändert, verschickt es manipulierte und damit ungültige Mails. Ein Beispiel hierfür ist der Footer, den Mailinglisten-Manager üblicherweise an ausgehende Mails anhängen. Der erste Ansatz, dieses Problem zu umgehen, besteht darin, die Signatur so spät wie möglich anzubringen, nämlich erst, wenn alle anderen Komponenten des Mailsystems die Nachricht bearbeitet haben und eine weitere Veränderung von Header und Body ausgeschlossen ist.

Der andere Ansatz ist, die Signatur so zu verfassen, dass bestimmte Modifikationen sie nicht entwerten. Eine DKIM-Signatur kann so gestaltet werden, dass sie nur eine bestimmte Länge des Body signiert. So kann die Mailingliste ihren Footer anhängen, ohne die Signatur zu zerstören. Dieser Toleranzbereich birgt allerdings auch die Möglichkeit des Missbrauchs: Der Footer kann nachträglich durch eine unerwünschte Botschaft ersetzt werden; zusätzliche HTML-Elemente können den signierten Text komplett überlagern und angefügte Attachments verleiten den Empfänger zum Doppelklick. Die Architekten des DKIM-RFCs raten daher auch ausdrücklich von einer Längenangabe in der Signatur ab.

Eine sichere Methode wäre, die erste Signatur des Absenders über eine eingeschränkte Länge der E-Mail anzubringen und nach Bearbeitung der E-Mail durch einen Mailinglisten-Manager eine zweite Signatur anzufertigen, die sich dann auf die vollständige E-Mail erstreckt. Jede der Signaturen ist für sich gültig und eine Manipulation könnte automatisch erkannt werden, bevor der Postmaster zum Ohrenarzt muss, weil ein Kollege ihm am Telefon sehr deutlich mitgeteilt hat, wie sehr er signierten Spam verabscheut. In welcher Reihenfolge die Signaturen abzuarbeiten sind, erkennt das verifizierende Programm übrigens an der Reihenfolge, in der sie angebracht sind. Das ist möglich, weil der RFC von der signierenden Instanz fordert, ihre DKIM-Signatur immer an oberster Stelle in die Mail einzufügen. Die doppelte Signatur ist allerdings nur dann sinnvoll, wenn verschiedene Teile des Mailsystems vollkommen unabhängig voneinander arbeiten.

In der Regel genügt es, eine einzige Signatur über die gesamte Länge der Nachricht möglichst spät anzubringen. So geht auch das hier beschriebene System vor. Damit enden die Vorüberlegungen und der Postmaster kann mit der Einrichtung beginnen. Zuerst erzeugt er den Signier-Schlüssel. Der öffentliche Teil des Schlüssels wandert in den DNS-Server zum Abruf für entfernte Verifizierer. Den privaten Teil des Schlüssels erhält das signierende Programm dkim-milter, das über das Sendmail-Milter-Protokoll in den SMTP-Server eingebunden wird. Zuletzt gilt es, im SpamAssassin die Signaturprüfung mit Hilfe des Perl-Moduls Mail::DKIM zu aktivieren und passende Regeln für die Behandlung der Nachrichten zu definieren.

Schlüsseldienst

Schlüsseldienst

Die Verfasser des DKIM-RFCs wollen wohl, dass ihr Standard sich möglichst schnell verbreitet, denn anders als für RFCs sonst üblich haben sie viele Bemerkungen mit Praxisbezug eingebaut. So auch das openssl-Kommando, das den privaten Schlüssel erstellt: openssl genrsa -out mail200801.private 1024. Der Name der Schlüsseldatei ist beliebig. Um den Überblick zu behalten, empfiehlt es sich jedoch, sie genauso zu nennen wie den DNS-Eintrag; Details dazu weiter unten. Die Schlüssellänge von 1024 Bit entspricht der Minimalanforderung des RFC, reicht aber derzeit vollkommen aus. Nun muss der öffentliche Schlüssel in die Datei mail200801.public extrahiert werden. Das geschieht mit openssl rsa -in mail200801.private -out mail200801.public -pubout -outform PEM.

Der DKIM-Standard sieht momentan ausschließlich vor, dass der öffentliche Schlüssel per DNS als TXT-Record verbreitet wird. Später soll ein eigener Record-Typ definiert werden. Der Inhalt der eben erzeugten PEM-Datei eignet sich jedoch noch nicht als DNS-Record. Das Kommando grep -v -e "^-" mail200801.public | tr -d "\n" entfernt den Public-Key-Header und -Footer sowie die Zeilenumbrüche.

Die vollständige Zeile für einen Eintrag in der Zone-Datei des DNS-Servers bind sieht dann so aus wie im Listing oben. Der Name des Records besteht aus dem Namen des Schlüssels und der Subdomain "_domainkey ". Es empfiehlt sich, wie hier gezeigt, in den Schlüsselnamen eine Versionsnummer einzufügen, denn Signatur-Schlüssel sollen aus Sicherheitsgründen regelmäßig ausgetauscht werden. Gleichzeitig sollen nicht mehr aktiv genutzte Schlüssel nicht gelöscht, sondern widerrufen werden. Zum Widerrufen setzt der Admin einfach einen Record ohne Schlüssel in seinen DNS: mail200801._domainkey IN TXT "v=DKIM1\; p=" Durch die Versionsnummer sind Überschneidungen zwischen aktiven und widerrufenen Schlüsseln ausgeschlossen. Die im RFC vorgeschriebene Subdomain "_domainkey " mit dem vorangestellten Unterstrich verhindert, dass der Key-Eintrag mit anderen Namen kollidiert.Neben dem mit p= eingeleiteten öffentlichen Schlüssel enthält der DNS-Record noch einige Parameter. Gemeinsam ist ihnen die Notation, bei der Parameter und Wert mit einem Gleichheitszeichen ohne Leerzeichen angegeben und mit einem per Backslash geschützten Semikolon "\; " abgeschlossen werden.

Der v-Parameter benennt die benutzte Version des DKIM-Standards. Er ist zwar optional, wird aber im RFC ausdrücklich empfohlen. Das v= muss als erster Eintrag genannt werden, wenn es überhaupt vorkommt. Bislang ist nur DKIM1 erlaubt. Als Nächstes folgt der k-Parameter, der den Schlüsseltyp (key type) spezifiziert. Auch er ist optional; die Vorgabe lautet "rsa ". Zuletzt vor dem Schlüssel steht der t-Parameter, der Sondereigenschaften spezifiziert, zum Beispiel, ob es sich um einen Testlauf (t=y) handelt. Dann nämlich dürfen Verifizierer die Signatur zwar prüfen, das Ergebnis aber nicht in Bewertungen der Nachricht einfließen lassen. Sobald der Postmaster sich seiner DKIM-Installation sicher ist, sollte er also einen TXT-Record ohne das t=y online stellen.Testweise fragt man den Eintrag mit dem Kommando dig mail200801._domainkey.example.com TXT +short ab. Unter Windows tut es der Befehl nslookup -type=TXT mail200801._domainkey.example.com.

Signatur

Signatur

Mit dem Milter-Protokoll von Sendmail lassen sich on the fly sowohl Header als auch Body einer E-Mail modifizieren. Wietse Venema, geistiger Vater von Postfix, empfand alle Ansätze für ein eigenes Protokoll als "poor use of human and system resources " und brachte seinem Server daher ebenfalls Milter bei. Die Postfix-Implementierung verfügt zwar aufgrund der anderen internen Struktur nicht über dieselben Milter-Makros wie Sendmail. Aber seit Version 2.4 reicht der Funktionsumfang für die DKIM-Signierung aus.

Weil der Standard recht neu ist, ändert sich die Software derzeit noch häufig und die Distributionen hinken hinterher. Daher ist es meist nötig, die DKIM-Applikation selbst zu kompilieren, in diesem Fall dkim-milter. Wer sich dazu gezwungen sieht, muss dann auch regelmäßig nachsehen, ob dkim-milter ein Sicherheitsupdate braucht. Es empfiehlt sich, auf das Paket der Distribution umzusteigen, sobald das alle Funktionen unterstützt, damit dann wieder automatische Sicherheitsupdates greifen.

Voraussetzung sind die "Milter Development-Libraries ". Diese erhalten Postfix-Anwender indem sie über einen Paketmanager entweder das sendmail-devel- oder libmilterdev-Paket installieren; da die Milter-Schnittstelle sich nicht mehr ändert, genügt hier das Paket der Distribution. Danach kompilieren und installieren die etwas ungewöhnlichen Befehle

sh ./Build
sh ./Build install

das Programm dkim-filter. Es ist ratsam, für den Filter einen nicht privilegierten Benutzer anzulegen, zum Beispiel mit dem Namen "dkim ". Er sollte in keinem Zusammenhang mit dem Mailsystem stehen, insbesondere nicht zu derselben Unix-Gruppe gehören. Seine Einstellungen entnimmt dkim-filter den Kommandozeilenoptionen und einer Konfigurationsdatei, die man dem Programm über den Kommandozeilenschalter -x mitgibt. Das Listing unten auf dieser Seite zeigt eine einfache Konfiguration. Achtung Postfix-Admins! Die Notation sieht ähnlich wie Postfix-Syntax aus, ist es aber nicht. Mit diesen Einstellungen signiert dkim-filter alle ausgehenden Mails der Domain example.com, aber keine ihrer Subdomains (SubDomains-Parameter). Das Programm läuft ausschließlich im Signier-Modus (Mode), weil das Verifizieren im hier vorgestellten Mailsystem SpamAssassin übernimmt.

Nach dem Start mit root-Rechten läuft das Programm unter dem nicht-privilegierten Account dkim weiter. Damit es trotzdem den Signier-Schlüssel aus der mit KeyFile angegebenen Datei verwenden kann, muss der Admin die Zugriffsrechte anpassen:

chown dkim mail200801.private
chmod 0400 mail200801.private

Nach dem Start wartet dkim-filter auf dem mit Socket spezifizierten Kanal auf eingehende Verbindungen. Der Canonicalization-Parameter legt für Header und Body fest, wie Umbrüche und Leerzeichen behandelt werden. Im Beispiel erlaubt relaxed/simple, dass die signierten Header beim Prüfen mehr Whitespace enthalten als beim Signieren, während der Body exakt so ankommen muss, wie er signiert wurde. Das ist sinnvoll, weil eventuell Server auf dem Weg der Mail die Header "optimieren ", indem sie lange Einträge umbrechen und anschließend mit Leerzeichen einrücken.

Manche Header sind für die Authentizität der Mail nicht wichtig und werden unterwegs besonders häufig geändert oder entfernt. Damit das nicht jedes Mal die Signatur zerstört, kann der Postmaster sie von Anfang an mit dem Parameter OmitHeaders von der Signatur ausnehmen (siehe S. 124). Der Selector-Parameter sagt dkim-filter, welchen Namen er für den öffentlichen Schlüssel in die Signatur eintragen soll. Er muss dem zuvor erzeugten DNS-Eintrag entsprechen, damit der Verifizierer sich später den passenden TXT-Record besorgen kann. Für den Testbetrieb veranlassen die zusätzlichen Optionen Syslog Yes und SyslogSuccess Yes dkim-filter, Fehler- und Erfolgsmeldungen ins Systemlog zu schreiben. Der Befehl dkim-filter -x /etc/mail/dkim-filter.conf startet das Programm mit der richtigen Konfigurationsdatei. Es verzieht sich in den Hintergrund (Background-Parameter) und wartet auf Aufträge. Mit dem Kommando lsof -i | grep 8891 prüft root schnell, ob dkim-filter wie gewünscht auf Port 8891 lauscht. Dann ist es Zeit, Postfix und den neuen Helfer miteinander ins Gespräch zu bringen. Das soll wie eingangs erklärt möglichst spät passieren, in der skizzierten Systemarchitektur also erst, wenn amavisd-new eine Nachricht wieder an das Postfix-Mailsystem zurückgibt. Ein dedizierter SMTP-Server nimmt die Nachricht entgegen. Auch er holt sich seine Konfiguration aus der Datei master.cf.

Domain example.com
SubDomains No
Mode s
UserID dkim
KeyFile /etc/mail/mail200801.private
Socket inet:8891@127.0.0.1
Canonicalization relaxed/simple
OmitHeaders Return-Path,Received,Comments,Keywords,Bcc,Resent-Bcc
Selector mail200801
Background Yes

Die Zeile -o smtpd_milters=inet:localhost:8891 am Ende dieses Abschnitts genügt. Postfix übergibt die Mail nun an den Milter und versendet das Ergebnis, sobald es von dkim-filter zurückkommt. Nach einem postfix reload ist der dkim-filter in den Postfix-E-Mail-Transport eingebaut und kann getestet werden.

Wer noch feilen möchte, kann sich unter anderem den KeyList-Parameter von dkim-filter ansehen. Dieser Parameter liest eine Tabelle ein, in der Domain- und sogar User-spezifisch Signier-Schlüssel zugewiesen werden können.

Prüfprotokoll

Prüfprotokoll

Solange die meisten Domains unsignierte Mails verschicken, eignet sich eine fehlende oder falsche Unterschrift noch nicht als alleiniges Kriterium zum Aussortieren einer EMail. Daher sollte das Ergebnis der Signaturprüfung in den Spam-Score von SpamAssassin eingehen. SpamAssassin bringt zwar ein Plug-in für die DKIM-Auswertung mit, braucht aber zusätzlich das Perl-Modul Mail::DKIM. Wie bei dkim-milter enthalten viele Distributionen veraltete Pakete, sodass der Admin gezwungen ist, mit dem Kommando cpan Mail::DKIM das aktuelle einzuspielen. Eventuell bietet die Installationsroutine an, weitere Modulen einzurichten, was man ihr jedoch nur erlaubt, wenn die Linux-Distribution sie nicht anbietet.Um das DKIM-Plug-in zu aktivieren, setzt man in der versionsspezifischen Konfigurationsdatei /etc/mail/spamassassin/v320.pre die Option loadplugin Mail::SpamAssassin::Plugin::DKIM. Sie ist dort schon vorhanden, aber auskommentiert. SpamAssassin muss jetzt nur noch erfahren, wie DKIM-signierte Nachrichten zu behandeln sind. Passende Anweisungen werden global gültig in die Datei /etc/mail/spam assassin/local.cf geschrieben. Das Effektivste ist, korrekt signierte E-Mails aus bekannten Domains zu bevorzugen. Dazu dient der Befehl whitelist_from_dkim (siehe Listing unten).

whitelist_from_dkim *@charite.de charite.de
whitelist_from_dkim *@cisco.com cisco.com
whitelist_from_dk *@ebay.com ebay.com
whitelist_from_dk *@ebay.de ebay.de
score USER_IN_DKIM_WHITELIST -4.0
score DKIM_VERIFIED -1.3
score DKIM_POLICY_TESTING 0
score USER_IN_DK_WHITELIST -4.0
score DK_VERIFIED -1.1

Einige wichtige E-Mail-Absender wie eBay haben noch nicht auf DKIM umgestellt, sondern nutzen das Vorgängerverfahren DomainKeys. Sowohl Mail::DKIM als auch das SpamAssassin-Plug-in kommen mit beiden Signaturtypen zurecht. Es genügt daher, diese Spätzünder mit gesonderten DK-Regeln zu behandeln, wie das Beispiel es zeigt. Nun bleibt nur noch das Tuning, wie die korrekte Signatur in die Berechnung des Spam-Score (der "Spamhaftigkeit") einer Nachricht eingehen soll. SpamAssassin regelt das über die score-Einträge und bringt schon bei der Installation Vorschläge mit, die die Entwickler optimieren, indem sie ihr Programm auf abgefangenen Spam (und Nicht-Spam) loslassen. Derzeit wirkt ein Eintrag auf der DKIM-Whitelist (USER_IN_DKIM_WHITELIST) mit einem Score von -100 extrem stark; alle weiteren Spam-Tests werden bedeutungslos. Andererseits fällt eine DKIM-Verifizierung ohne Whitelist-Eintrag fast gar nicht ins Gewicht (-0.001). Das mag daran liegen, dass DKIM bislang kaum eingesetzt wird und daher noch nicht in die Statistik eingehen kann. Erste Praxiserfahrungen zeigen, dass man diese Gewichte getrost verschieben darf. Auf dem System des Autors werden Mitglieder der DKIM-Whitelist nur mit einem Bonus von -4.0 Punkten belohnt. Wer nicht explizit ge- "whitelisted" wurde, aber korrekt signiert, erhält 1.3 Punkte Abzug von der Spamhaftigkeit. Einzig diejenigen, die DKIM noch im Testbetrieb fahren, erhalten keine spezielle Behandlung. Analog werden die Nutzer von DomainKeys bewertet.

Selbst bekannt konformen Sender sollte man nicht durch besonders hohe Scores Tür und Tor öffnen. Denn eine gesunde Policy schafft definierte Beziehungen und nicht grenzenloses Vertrauen. Es könnte ja durchaus sein, dass der Sender plötzlich an anderer Stelle eindeutige Spam-Merkmale erkennen lässt, die durch die eine DKIM-Regel maßlos überstimmt kein Gehör mehr finden. Es ist letztlich also wie bei einer Bewerbung – der Gesamteindruck muss stimmen. Wer wissen will, wie SpamAssassin wertet, sichert die zu prüfende Mail als Datei heraus und ruft als der User, der SpamAssassin auch im Mailsystem ausführt, per Kommandozeile auf: spamassassin < maildatei. Der X-Spam-Status-Header nennt die Tests, die durchgeführt wurden und den Gesamtscore. So lässt sich an einer signierten und einer unsignierten Mail von demselben Absender schön nachvollziehen, wie die neuen SpamAssassin-Regeln in local.cf greifen. DKIM ist noch verhältnismäßig wenig verbreitet. Es hat das Potenzial, viel mehr Verbindlichkeit – und damit Sicherheit – in den täglichen E-Mail-Verkehr zu bringen. Funktionstüchtige Software ist vorhanden und auch die Implementierung ist nur erträglich kompliziert. Für bekannte Kommunikationspartner sind schnell Regeln eingerichtet, so dass sich die investierte Zeit bezahlt macht. (rek)