DomainKeys Identified Mail (DKIM) Signatur für sicheren E-Mailverkehr
Da die E-Mail-Zustellung von vielen Mailservern abgelehnt wird, hier ein Versuch dies mit einer DKIM Signatur zu beheben.
Beschreibung von https://kofler.info/dkim-konfiguration-fuer-postfix/ übernommen:
DKIM-Konfiguration für Postfix
OpenDKIM installieren und einrichten
OpenDKIM ist eine Open-Source-Implementierung von DKIM. Das Programm kann gleichermaßen ausgehende Mails mit einem eigenen Schlüssel signieren als auch die Signatur eintreffender Mails überprüfen. OpenDKIM ist mit diversen MTAs kompatibel. Diese Anleitung zeigt das Zusammenspiel von DKIM mit Postfix, wobei das Hauptaugenmerk des Artikels beim korrekten Signieren liegt. Das Ziel ist es also, Postfix so zu konfigurieren, dass es ausgehende Mails DKIM-konform signiert und so die Wahrscheinlichkeit mindert, dass die Mail vom Empfänger als Spam betrachtet wird.
Zuerst installieren Sie OpenDKIM:
apt-get install opendkim opendkim-tools
Dann richten Sie ein Verzeichnis für die DKIM-Schlüssel ein:
mkdir /etc/opendkim
mkdir /etc/opendkim/keys
chown -R opendkim:opendkim /etc/opendkim
chmod go-rw /etc/opendkim/keys
Konfigurationsdatei opendkim.conf
Die zentrale Konfigurationsdatei von OpenDKIM ist /etc/opendkim.conf
. Erstellen Sie opendkim.conf
wie im folgenden Muster. Details zu den Dateien trusted
, key.table
und signing.table
, auf die die Konfiguration verweist, folgen gleich. Einzelheiten zu den diversen opendkim.conf
-Optionen können Sie mit man opendkim.conf
nachlesen.
# Datei /etc/opendkim.conf
# OpenDKIM agiert als Mail Filter (= Milter) in den
# Modi signer (s) und verifier (v) und verwendet eine
# Socket-Datei zur Kommunikation (alternativ: lokaler Port)
Mode sv
# Socket local:/var/run/opendkim/opendkim.sock
Socket inet:12345@localhost
# OpenDKIM verwendet diesen Benutzer bzw.
# diese Gruppe
UserID opendkim:opendkim
UMask 002
PidFile /var/run/opendkim/opendkim.pid
# OpenDKIM bei Problemen neustarten,
# aber max. 10 mal pro Stunde
AutoRestart yes
AutoRestartRate 10/1h
# Logging (wenn alles funktioniert eventuell reduzieren)
Syslog yes
SyslogSuccess yes
LogWhy yes
# Verfahren, wie Header und Body durch
# OpenDKIM verarbeitet werden sollen.
Canonicalization relaxed/simple
# interne Mails (signieren, nicht verifizieren)
InternalHosts refile:/etc/opendkim/trusted
# Hosts, denen vertraut wird (vermeidet Warnungen beim Logging)
ExternalIgnoreList refile:/etc/opendkim/trusted
# welche Verschlüsselungs-Keys sollen für welche
# Domains verwendet werden
# (refile: für Dateien mit regulären Ausdrücke)
SigningTable refile:/etc/opendkim/signing.table
KeyTable /etc/opendkim/key.table
# diesen Signatur-Algorithmus verwenden
SignatureAlgorithm rsa-sha256
# Always oversign From (sign using actual From and a null From to prevent
# malicious signatures header fields (From and/or others) between the signer
# and the verifier. From is oversigned by default in the Debian pacakge
# because it is often the identity key used by reputation systems and thus
# somewhat security sensitive.
OversignHeaders From
/etc/default/opendkim: Bitte beachten Sie, dass unter Debian und Ubuntu beim Start von OpenDKIM auch die Datei
/etc/default/opendkim
ausgewertet wird. Dort durchgeführte Einstellungen haben Vorrang gegenüberopendkim.conf
. Ich gehe in dieser Anleitung davon aus, dass Sie die dort vorgesehenen Defaulteinstellungen durch das Einfügen von Kommentarzeichen deaktivieren. (EinzigRUNDIR
sollten Sie belassen.)
Keine Signatur für interne Mails
Die Datei trusted
gibt an, welchen Hosts der Mail-Server vertraut, d.h., für welche Hosts auf die DKIM-Signatur verzichtet wird. Ersetzen Sie die drei tuxis.de
-Einträge durch entsprechende Einträge mit dem Hostnamen Ihres Mail-Servers!
# Datei /etc/opendkim/trusted 127.0.0.1 ::1 localhost tuxis
tuxis.de
Welcher Schlüssel für welchen Hostnamen?
Als nächstes richten Sie mit einem Editor die Dateien signing.table
und key.table
gemäß dem folgenden Muster ein. signing.table
gibt an, für welche From
-Adressen welcher Schlüssel verwendet werden soll. Die zweite Spalte in signing.table
bezieht sich dabei auf die erste Spalte in key.table
.
# Datei /etc/opendkim/signing.table
# für E-Mails von xxx@tuxis.de
den Schlüssel 'tuxis
' # zum Signieren verwenden *@tuxis.de
tuxis
key.table
gibt dann den tatsächlichen Ort der Schlüsseldateien an. Die zweite Spalte besteht dabei aus drei Teilen: Dem Hostnamen (hier tuxis.de
), dem Selektor (hier 201611
) und dem eigentlichen Dateinamen. Die Verwendung einer Zeitangabe für den Selektor hilft dabei einen Überblick zu behalten, wann die Schlüssel erzeugt wurden — hier also im Nov. 2016.
# Datei /etc/opendkim/key.table
# der Schlüssel 'tuxis
' befindet sich in # des Datei /etc/opendkim/keys/tuxis
.private tuxis
tuxis.de
:201611:/etc/opendkim/keys/tuxis
.private
Wenn Ihr Mail-Server für mehrere Hosts zuständig ist, ergänzen Sie key.table
und signing.table
um entsprechende Einträge für alle weiteren Hosts.
Schlüssel generieren
Das Kommando opendkim-genkey
erzeugt einen privaten Schlüssel (name.private
) und einen öffentlichen Schlüssel (name.txt
). Der private Schlüssel verbleibt am Server und darf nicht in falsche Hände geraten! Der öffentliche Schlüssel wird später im DNS-TXT-Record des Mail-Servers gespeichert. Die wichtigsten Optionen des Kommandos lauten:
-d domain
gibt an, für welche Domain die Schlüssel gelten sollen. Die Option wird aktuell nur dazu verwendet, um einen Kommentar inname.txt
einzubauen. Ohne die Option verwendetopendkim-genkey
die Zeichenketteexample.com
.-
-b 2048
gibt an, dass ein Schlüssel in der Länge von 2048 Bits generiert werden soll. Größere Schlüssel sind momentan mit der gängigen Mail-Server-Infrastruktur inkompatibel. Standardmäßig verwendetopendkim-genkey
1024 Bits, was aber vielfach als nicht mehr als ausreichend sicher erachtet wird. -
-r
gibt an, dass der Schlüssel ausschließlich zur Signatur von E-Mails verwendet werden darf (restricted). -
-s selector
gibt eine Selektor-Zeichenkette an, um das Schlüsselpaar zu identifizieren (standardmäßig:default
). Die Selektor-Zeichenkette bestimmt die Namen der Schlüsseldateien.-s 201611
bewirkt also, dass die Dateien201611.txt
und „201611.private` erzeugt werden. Vorsicht. Eventuell schon vorhandene Schlüsseldateien werden ohne Rückfrage überschrieben.
Um also Schlüssel zu erzeugen, die zum obigen Beispiel passen, führen Sie das folgende Kommando aus:
cd /etc/opendkim
opendkim-genkey -d tuxis.de
-b 2048 -r -s 201611
Die resultierenden Dateien sehen so aus:
cat 201611.private
-----BEGIN RSA PRIVATE KEY-----
totalGeheimBlaBla123
...
-----END RSA PRIVATE KEY-----
cat 201611.txt
201611._domainkey IN TXT (
"v=DKIM1; k=rsa; s=email; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCA...73Qzl5Czna79"
"7955/zX7Bp10e/lATZbVtP6Qu6eC2TMpWx06bEDRZ...oAtNNuhQIDAQAB"
) ; ----- DKIM key 201611 for tuxis.de
Die Dateien müssen nun noch entsprechend der Angaben in key.table
platziert werden. Zuletzt stellen Sie sicher, dass nur der Benutzer opendkim
auf die Dateien und Verzeichnisse zugreifen darf:
cd /etc/opendkim
mv 201611.private keys/tuxis
.private mv 201611.txt keys/tuxis
.txt chown -R opendkim:opendkim /etc/opendkim chmod -R go-rwx /etc/opendkim/keys
DNS-TXT-Eintrag hinzufügen
Der nächste Schritt besteht darin, den öffentlichen Teil der DKIM-Schlüssels, also in der Logik dieses Beispiels den Inhalt von
in einem TXT-Eintrag in der DNS-Konfiguration Ihres Hostnamens zu speichern. Dabei verwenden Sie die Zeichenkette vor dem Schlüsselwort tuxis
.txtIN
für das Feld Hostname des DNS-Eintrags und den gesamten Text zwischen den runden Klammern für das Feld Destination. In der Weboberfläche meines Hosters sieht der Dialog zum Einrichten eines neuen DNS-Eintrags vom Typ TXT
so aus:
Auf das Icon mit dem Stift klicken!!
host -t TXT 201611._domainkey.tuxis.de
201611._domainkey.tuxis.de
descriptive text "v=DKIM1\; k=rsa\; s=email\; " "p=MIIBIjANBgkqhkiG9w0BAQEF...."
OpenDKIM testen
Die geänderten Einstellungen erfordern einen Neustart von OpenDKIM:
service opendkim restart
Sobald der auf dem Nameserver gespeicherte öffentliche Schlüssel verfügbar ist (das testen Sie mit dem Kommando host -t TXT
, siehe oben), können Sie mit dem Kommando opendkim-testkey
lokal überprüfen, ob alles korrekt eingerichtet ist. Sofern das Kommando keine Fehlermeldungen liefert, ist alles OK. Die Option -vvv
bewirkt, dass das Kommando zumindest einige Debugging-Daten liefert.
opendkim-testkey -d tuxis.de
-s 201611 -vvv opendkim-testkey: using default configfile /etc/opendkim.conf opendkim-testkey: checking key '201611._domainkey.tuxis.de
' opendkim-testkey: key not secure opendkim-testkey: key OK
Key not secure weist darauf hin, dass kein DNSSEC verwendet wird. Das hat aber nichts mit DKIM zu tun. Sollte hingegen die Meldung record not found erscheinen, kann OpenDKIM den erforderlichen Schlüssel nicht finden — dann liegt wirklich ein Konfigurationsproblem vor.
Bevor Sie die Postfix-Konfiguration ändern
Ich gehe hier davon aus, dass Postfix schon läuft und als MTA aktiv ist. Änderungen im laufenden Betrieb sind natürlich immer heikel. Wenn Sie etwas falsch machen, kann es passieren, dass eintreffende E-Mails abgewiesen werden. Diese sind dann endgültig verloren sind.
Deswegen ist es besser, vor Beginn der Umbauten soft_bounce=yes
in main.cf
einzubauen (und natürlich ständig ein scharfes Auge auf die Logging-Dateien zu werfen). Mit soft_bounce=yes wandelt Postfix alle 5xx-Fehlern (Permanent Failure) in 4xx-Fehler (Persistent Transient Failure) um. Der Sender wird daher nach einiger Zeit einen neuerlichen Zustellversuch unternehmen, die E-Mail ist nicht verloren.
Vergessen Sie nicht, nach Fertigstellung und Test der geänderten Konfiguration wieder soft_bounce=no
einzustellen!
Postfix-Konfiguration für OpenDKIM erweitern
Damit Postfix ausgehende E-Mails mit OpenDKIM signiert, muss OpenDKIM als Mail Filter (= Milter) eingerichtet werden. Dazu sind in der Postfix-Konfiguration die Parameter smtpd_milters
und non_smtpd_milters
vorgesehen. Wenn OpenDKIM der einzige Milter ist, sieht die korrekte Konfiguration so aus:
# in /etc/postfix/main.cf
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:12345
non_smtpd_milters = inet:localhost:12345
Vielleicht gab es bisher schon Milter — dann kommt der OpenDKIM-Milter (getrennt durch ein Komma) eben dazu. Bei meinem Mail-Server ist z.B. zusätzlich auch SpamAssasin aktiv:
# in /etc/postfix/main.cf
milter_default_action = accept
milter_protocol = 6
smtpd_milters = unix:spamass/spamass.sock, inet:localhost:12345
non_smtpd_milters = inet:localhost:12345
Einige Anmerkungen zu den Parametern:
milter_default_action = accept
bedeutet, dass Postfix auch dann Mails akzeptieren soll, wenn ein Milter defekt ist, nicht reagiert, falsch konfiguriert ist etc.-
In vielen Anleitungen ist von
milter_protocol = 2
die Rede. Das gilt aber nur für alte Postfix-Versionen (älter als 2.6). Bei aktuellen Postfix-Versionen gilt standardmäßigmilter_protocol = 6
. Die Konfiguration funktioniert also auch, wenn Sie die Einstellung ganz weglassen. -
Vielleicht fragen Sie sich, was der Unterschied zwischen
smtpd_milters
undnon_smtpd_milters
ist: Diesmtpd_milters
gelten für E-Mails, die über das SMTP-Protokoll geliefert werden.non_smtpd_milters
gilt dagegen für lokale E-Mails, die z.B. durchsendmail
oder durch ein PHP-Script erzeugt und versendet werden. In der obigen Konfiguration wird für solche Mails auf den Spam-Test verzichtet.
DKIM im Zusammenspiel Postfix/OpenDKIM testen
Als erstes senden Sie sich selbst eine Mail und werfen dann einen Blick in den Header. Dieser sollte eine Zeile enthalten, die mit DKIM-Signatur
beginnt, z.B. wie im folgenden Beispiel:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tuxis.de
; s=201611; t=1479644038; bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=; h=To:From:Subject:Date:From; b=VI6TIDLrzG8nAUYWwt5QasKJkkgU+Sv8sPGC1fynSEGo0GSULGgCjVN6KXPfx1rgm 1uX2sWET/oMCpxjBFBVUbM7yHGdllhbADa2SarzYhkoEuNhmo+yxGpXkuh0ttn4z7n OmkLwjrdLafMOaqSBrXcTMg/593b/EQXtouEvHqOG59d0fubIGCJBF6DG5gcITS9CP q9tiVwIDVuQqynL9Crodl+2IObcvl15MeK2ej322qrjrTij6vZOru9SeVno4LNTkQ7 tOT4s14BGLx8aRe5YXZj38AWsR6DxkT6OzM+3TnOhIfX3ZdkufMz8AUnTNuLhViZ1M betE0x1iOi/HQ==
Senden Sie nun eine E-Mail von Ihrem eigenen Mail-Server an einen Mail-Server, von dem Sie wissen, dass er DKIM unterstützt und verwendet. Eine gute Wahl ist Google (also Gmail). In der Gmail-Weboberfläche öffnen Sie die E-Mail und führen Original anzeigen aus. Das Ergebnis sollte analog wie beim folgenden Screenshot aussehen:

Key Rotation
Aus Sicherheitsgründen wird empfohlen, die DKIM-Schlüssel zumindest vierteljährlich zu wechseln. Das ist allerdings mit hohem Aufwand verbunden: neue Schlüssel generieren, Konfigurationsdateien anpassen, DNS-TXT-Einträge anpassen etc. Zudem müssen bei jedem Wechsel für einige Tage beide Schlüssel in der DNS-Konfiguration bleiben, einerseits, weil sich DNS-Änderungen nur relativ langsam im Internet verbreiten, andererseits, weil E-Mails mitunter erst nach Tagen zugestellt werden (z.B. wenn ein Empfänger-Server vorübergehend nicht erreichbar ist) .
Für große Mail-Provider lässt sich der regelmäßige DKIM-Schlüsselwechsel sicher gut automatisieren. Entsprechende Scripts für den Schlüsselwechsel lassen sich natürlich auch für den privaten Mail-Server zusammenbasteln, aber solche Scripts stoßen bei den DNS-Daten an ihre Grenzen: Wer keinen eigenen Nameserver betreibt, wird die DNS-Konfiguration für die eigene Domain zumeist über die Weboberfläche seines Hosters ändern (und da man muss schon dankbar sein, wenn dort überhaupt die Möglichkeit besteht, TXT-Einträge zu verwalten). Das automatisierte Verändern der DNS-TXT-Einträge wird aber kaum möglich sein.
Ganz so zwingend wie von manchen Autoren angegeben scheint die Key Rotation nicht zu sein. Wenn Sie eine E-Mail via Gmail versenden, fügt Google die folgenden Zeilen in den Mail-Header ein:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-transfer-encoding;
bh=wPz35cXFAjOtHhgvJJVlP3LVP7on2SV5azh+UjTRZMM=;
b=FGSZV2FXjjed0+ByOySbvQMcDM4v+MWXtLDBNU8pgnV6I2k2V0vd6dOpINS+F2e9fl
k1sH/EJFeqhit5l8MxhhfCCkP0BNZi3PCQ22i75CPh3ghLz8sjk1W4N03ls/+k3kcPrI
VcRoCN5LYlgxSGn4wCSfGFI+ctYiDMw3gGLJoRgTCGA9wLzNEZCSo1Y2agaDDpkgSr3P
4BmcGBE/PzTD8TCWgLw+cRiLDkfA9YvK2A/kR7aQ6292wHkO1S2z6V4jYOir+YWJHQZh
fPxWAZLeazJ7DvWoQXpI1W+nMgU84xgdAEGPHOXzEzJ33l8Hgq5jNrw6+M0aXhLrVj5k
8Y9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding;
bh=wPz35cXFAjOtHhgvJJVlP3LVP7on2SV5azh+UjTRZMM=;
b=X8pFM/V1hDFQL6oBOoDaYHl9xxUgCZvUmEa4AUjcWe7I9ZTX27wuTH6U926gHVUyY3
fS4K9Iji+K9xFvcSVSU2wY8SDFcy1VlabECONlKX78nhZdWUFuX33C8uiI/Az+ATku9A
SDo6yy8xi6jGxPuBQhbQ9lir6jlpakWUV52bnk6GDBvumVfn4rC+N/UMUn4SJo69wTV1
6/Y436G01VkTMoec+yGpm4XFqksWSsoipLfBHQAiVFnGa1l7yDdbpuvnbNZxGvGj2u6G
YjU2p3S9P3HcyclvWzDpS7KEU7NjRWXoWzUuGs/yJpOUyS9eXBwn39mzUsiXb2Ds/JTa
wHYw==
Werfen Sie einen Blick auf die Selektoren der beiden DKIM-Signaturen: Der eine wurde offensichtlich 2012 eingerichtet, der andere 2013 :-)