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.confwie 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über opendkim.conf. Ich gehe in dieser Anleitung davon aus, dass Sie die dort vorgesehenen Defaulteinstellungen durch das Einfügen von Kommentarzeichen deaktivieren. (Einzig RUNDIR 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 in name.txt einzubauen. Ohne die Option verwendet opendkim-genkey die Zeichenkette example.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 verwendet opendkim-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 Dateien 201611.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 tuxis.txt in einem TXT-Eintrag in der DNS-Konfiguration Ihres Hostnamens zu speichern. Dabei verwenden Sie die Zeichenkette vor dem Schlüsselwort IN 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äßig milter_protocol = 6. Die Konfiguration funktioniert also auch, wenn Sie die Einstellung ganz weglassen.

• Vielleicht fragen Sie sich, was der Unterschied zwischen smtpd_milters und non_smtpd_milters ist: Die smtpd_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. durch sendmail 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 :-)