Mailserver 4 von 10: Mailsignatur mit OpenDKIM

Jahrelang habe ich mich davor gedrückt, doch endlich ist es geschafft - die Einrichtung eines eigenen Mailservers. In einer kleinen Artikelserie möchte ich einmal meine Erfahrungen und Konfigurationsschritte festhalten. Diese Serie basiert auf zahllosen Tutorials, Best Practices, Gesprächen mit Mailserver-Betreibern, aus endlosem Dokumentationen lesen und dem Wissen der Bücher "Postfix" von Kyle D. Dent und "Postfix - Einrichtung, Betrieb und Wartung" von Ralf Hildebrandt und Patrick Ben Koetter. Vielleicht werden sie ja nützlich für andere Leute sein, die das gleiche erreichen wollen.

Doch eines vorab: Die Einrichtung und der Betrieb eines Mailservers ist eine komplexe Sache. Klar, die Software lässt sich schnell installieren, doch fertig ist man danach noch lange nicht, wenn man ernsthaft damit arbeiten möchte.

Der Fahrplan der Artikelserie:

  1. Einleitung
  2. Mailempfang und Mailversand mit Dovecot und Postfix
  3. Virenprüfung mit ClamAV
  4. Mailsignatur mit OpenDKIM
  5. Spamprüfung mit SpamAssassin
  6. Mailabruf mit Dovecot
  7. Mailboxen konfigurieren mit mailconf.phs
  8. Mails synchronisieren mit mailsync.phs
  9. Mailqueue überwachen mit mailqueue.phs
  10. SpamAssassin anlernen mit maillearn.phs

Nachdem wir im letzten Artikel unseren ersten Milter zum Scannen von Viren eingeführt haben, werden wir heute einen weiteren Milter konfigurieren, um unsere Reputation als Mailserver zu steigern.

Das Thema Reputation ist im Mailumfeld sehr wichtig. Kein Mailserver-Betreiber möchte, dass sein eigener Mailserver einen schlechten Ruf bei anderen Mailserver-Betreibern hat. Denn das führt im Endeffekt dazu, dass eigene Mails bei den anderen Betreibern entweder langsamer oder gar nicht zugestellt werden. Um das zu verhindern, gibt es mehrere Schritte. Ein korrekt gesetzter rDNS-Eintrag ist einer davon. Der Einsatz von DKIM ist ein weiterer.

Bei DKIM wird im Grunde folgendes gemacht: Jede ausgehende E-Mail wird mit einem privaten Schlüssel signiert. Der öffentliche Schlüssel, der benötigt wird, um die Signatur zu prüfen, wird im DNS hinterlegt. So wird eine Vertrauensbeziehung zwischen einem Server und einer Domain hergestellst. Gleichzeitig erhöht sich die Wahrscheinlich, dass ein Server, der die passenden Schlüssel kennt, tatsächlich für die entsprechenden Domains zuständig ist.

Wie immer beginnt alles damit, dass wir das benötigte Paket - in diesem Fall OpenDKIM - installieren und anschließend unseren Mailserver stoppen, bis die Konfiguration abgeschlossen ist. Das Stoppen des Mailservers ist nicht zwingend erforderlich, jedoch können wir so sicher gehen, dass alle geänderten Einstellungen tatsächlich übernommen werden:

1
2
3
4
5
6
7
8
sudo apt-get update

sudo apt-get install opendkim opendkim-tools

sudo /etc/init.d/opendkim stop

sudo /etc/init.d/dovecot stop
sudo /etc/init.d/postfix stop

Das aktuelle OpenDKIM-Paket von Debian legt die Konfiguration direkt in der Datei "/etc/opendkim.conf" ab. Da wir jedoch noch weitere Dateien benötigen werden, legen wir erst einmal weitere Ordner an:

1
2
sudo mkdir /etc/opendkim/
sudo mkdir /etc/opendkim/keys/

Nun könenn wir uns die Grundkonfiguration in der Datei "/etc/opendkim.conf" etwas genauer ansehen. Diese ist im Defaultzustand leider sehr unvollständig. Meine sieht wie folgt aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# Log to syslog
Syslog                  yes

#become a different user
UserID                  opendkim:opendkim

# define configuration files
KeyTable                /etc/opendkim/keys.conf
SigningTable            /etc/opendkim/domains.conf
ExternalIgnoreList      /etc/opendkim/trusted.conf
InternalHosts           /etc/opendkim/trusted.conf

# non-default configuration
AutoRestart             yes
AutoRestartCount        0
AutoRestartRate         60/1h
Socket                  inet:10030@127.0.0.1

# 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 package
# because it is often the identity key used by reputation systems and thus
# somewhat security sensitive.
OversignHeaders         From

Hier ein paar Anmerkungen, die ich für wichtig halte:

  • UserID: Standardmäßig läuft OpenDKIM als Root, einfach nur, weil diese Konfigurationseinstellung fehlt. Das ist merkwürdig, denn der Nutzer "opendkim" wird per Default angelegt.
  • KeyTable, SigningTable, ExternalIgnoreList, InternalHosts: Die Konfiguration der eigenen Domains, sowie der zugehörigen Schlüssel, erfolgt - ähnlich wie bei Postfix - in separaten Dateien.
  • AutoRestart, AutoRestartCount und AutoRestartRate: OpenDKIM kann sich bei Problemen selbst neu starten, was hier aktiviert wird. Allerdings sollte die Anzahl der Neustarts limitiert werden, da OpenDKIM sich ansonsten tausende Male neu startet.
  • Socket: Auch diesen Milter werden wir wieder per TCP/IP ansprechen. Viele Tutorials nehmen fälschlicherweise an, dass diese Konfiguration nur in der Datei "/etc/default/opendkim" vorgenommen werden kann. Der Milter wird über die Adresse "127.0.0.1:10030" erreichbar sein.

Als nächstes heißt es, OpenDKIM mit den benötigten Informationen zu versorgen. Ein wichtiger Schritt ist, dem Milter bekannt zu geben, für welche Domains er überhaupt E-Mails signieren soll. Das machen wir in der Datei "/etc/opendkim/domains.conf":

1
2
# domain -> dns entry
example.com send2014._domainkey.example.com

Das sieht wahrscheinlich im ersten Moment etwas merkwürdig aus. Die Erklärung ist jedoch recht simpel. Wie bereits gesagt, wird bei DKIM ein öffentlicher Schlüssel im DNS hinterlegt - und zwar in Form von TXT-Records. Diese Datei gibt nun an, dass für die Domain "example.com" der TXT-Record sich unter dem Namen "send2014._domainkey.example.com" wiederfindet. Die Struktur des DNS-Eintrags lautet immer "<Selektor>._domainkey.<Domain>". Der Selektor bietet die Möglichkeit, dass für eine Domain gleichzeitig mehrere Schlüssel gültig sind - z.B. wenn man mehrere Mailserver für die gleiche Domain betreibt. Diese Informationen werden uns gleich nochmal begegnen.

Als nächstes legen wir schnell die Datei "/etc/opendkim/trusted.conf" an. Diese benötigen wir lediglich, um zu definieren, wer alles unsere internen Hosts sind. Diese beschränke ich auf Localhost:

1
2
3
# hostnames
127.0.0.1
localhost

Die folgende Datei "/etc/opendkim/keys.conf" wird noch einmal spannend, denn dort definieren wir, für welche Domain und welchen Selektor welche Schlüsseldatei verwendet wird:

1
2
# dns entry -> domain:selector:keyfile
send2014._domainkey.example.com example.com:send2014:/etc/opendkim/keys/send2014.private

Hier steht schlussendlich drin, wie der DNS-Eintrag "<Selektor>._domainkey.<Domain>" nach Domain und Selektor aufgedröselt ist und in welcher Datei sich der private Schlüssel für's Signieren befindet.

Apropos Schlüssel: Die DKIM-Schlüssel lassen sich relativ leicht mit dem Tool "opendkim-genkey" generiert werden. Dafür muss einfach nur die Domain und der Selektor übergeben werden. Der private Schlüssel und der zu setzende TXT-Record werden dann im aktuellen Verzeichnis abgelegt:

1
2
3
4
5
6
cd /etc/opendkim/keys/

sudo opendkim-genkey -d example.com -s send2014

sudo chmod 640 /etc/opendkim/keys/send2014.*
sudo chgrp opendkim /etc/opendkim/keys/send2014.*

In der Datei "*.private" befindet sich der private DKIM-Schlüssel, während in der "*.txt" der Inhalt des TXT-Records für den DNS-Server zu sehen ist. Dieser Record enthält den öffentlichen DKIM-Schlüssel. Ihr solltet euch nun die Zeit nehmen, den TXT-Record in eurem DNS-Server einzurichten:

1
send2014._domainkey IN TXT "v=DKIM1; k=rsa; p=[...]"

Abschließend müssen wir nun nur noch den Milter in Postfix einbinden. Dafür ändern wir in der Datei "/etc/postfix/main.cf" einfach folgende zwei Einstellungen:

1
2
3
4
smtpd_milters     = inet:127.0.0.1:10020
                    inet:127.0.0.1:10030
non_smtpd_milters = inet:127.0.0.1:10020
                    inet:127.0.0.1:10030

Die Reihenfolge ist hier wichtig. Der DKIM-Milter sollte immer als letztes ausgeführt werden, da vorher ja noch Änderungen durch andere Milter verursacht werden können, die natürlich mitsigniert werden sollen.

Wenn das erledigt ist, können der Milter und der Mailserver wieder gestartet werden:

1
2
3
4
sudo /etc/init.d/opendkim start

sudo /etc/init.d/dovecot start
sudo /etc/init.d/postfix start

Testen könnt ihr die Funktionsfähigkeit eures Setups, indem ihr einfach wieder testweise eine E-Mail verschickt. In dieser sollte sich dann folgender Header finden lassen:

1
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=example.com; s=send2014; [...]

Wenn das der Fall ist: Herzlichen Glückwunsch! Du hast gerade DKIM-Signaturen in deinem Mailserver eingerichtet und damit die Reputation deines Servers gesteigert. 🙂

Da wir gerade beim Thema Reputation sind: Es gibt noch etwas anderes, das man nutzen kann, um die Reputation des eigenen Mailservers zu steigern und gleichzeitig Spam ein wenig einzudämmen. Die Rede ist von SPF-Records im DNS. Diese dienen dazu, festzulegen, von welchem Server aus E-Mails für eine Domain verschickt werden dürfen.

Folgendermaßen können solche Einträge aussehen: Es wird festgelegt, dass E-Mails für die jeweilige Domain vom eigentlichen Server ("A") versendet werden dürfen. Weiterhin dürfen E-Mails vom zugehörigen Mailserver ("MX") versandt werden. E-Mails von allen anderen Servern sollen als Spam verworfen werden ("-all").

1
2
3
4
@ IN SPF "v=spf1 a mx -all"
@ IN TXT "v=spf1 a mx -all"
* IN SPF "v=spf1 a mx -all"
* IN TXT "v=spf1 a mx -all"

Sollte euer DNS-Server es nicht ermöglichen, SPF-Records zu setzen, könnt ihr wenigstens die TXT-Records als Fallback eintragen. 🙂

Das war es dann auch schon für dieses Mal. Im nächsten Artikel werden wir dann unseren letzten Milter konfigurieren, um Spam erfolgreich mit Hilfe von SpamAssassin zu erkennen.

Update:
@cheatha hat mich darauf hingewiesen, dass im Beispiel der "keys.conf"-Datei ein kleiner kosmetischer Fehler steckte. Ich habe ihn beseitigt. 🙂

Signierte Grüße, Kenny

P.S.: Solltet ihr im letzten Artikel den Virenscan für ausgehende Mails in der Datei "/etc/postfix/master.cf" deaktiviert haben, so müsst ihr nun die Mailsignatur dort separat aktivieren:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
submission inet n       -       -       -       -       smtpd
  -o smtpd_milters=inet:127.0.0.1:10030
  -o myhostname=<submit.example.com>
  -o smtpd_tls_cert_file=/etc/postfix/tls/<submit_example_com>.crt
  -o smtpd_tls_key_file=/etc/postfix/tls/<submit_example_com>.key
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING
smtps     inet  n       -       -       -       -       smtpd
  -o smtpd_milters=inet:127.0.0.1:10030
  -o myhostname=<submit.example.com>
  -o smtpd_tls_cert_file=/etc/postfix/tls/<submit_example_com>.crt
  -o smtpd_tls_key_file=/etc/postfix/tls/<submit_example_com>.key
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

2 Kommentare » Schreibe einen Kommentar

  1. Mittlerweile verwendet man keine SPF-Records im DNS mehr, stattdessen hat es sich durchgesetzt, nur TXT-Records zu benutzen. (https://tools.ietf.org/html/draft-ietf-spfbis-4408bis-15#section-13.1). Wichtig ist natürlich, besonders auch bei der Verteilung von DKIM-Schlüsseln, dass man DNSSec einsetzt, um die Einträge gegen Manipulation abzusichern.
    Bei DKIM bedeutet ein Eintrag "v=spf1 a:mail.sebi.org mx:gmail.com -all" z.B., dass alle Adressen zulässig sind, für die ein A- oder AAAA-Record zum Namen "mail.sebi.org" existiert. (Stünde dort nur "a", dann würden nur A- bzw. AAAA-Records akzeptiert, die direkt für "sebi.org" hinterlegt sind.). Zusätzlich werden alle Adressen akzeptiert, die in den A- und AAAA-Records aller für "gmail.com" gelisteten MX-Server auftauchen. (Da GMail auch DKIM richtig umsetzt und die Header mit einem eigenen Key signiert, kann man dadurch seine Domain auch als Absender bei GMail benutzen, ohne dass DKIM oder SPF hier Probleme machen. )

    • Wie es halt immer so ist bei eingeführten Standards: die expliziten SPF-Records wird man nicht so schnell wieder los. 😀

Schreibe einen Kommentar

Um Ihnen beim weiteren Kommentieren auf dieser Webseite die erneute Eingabe Ihrer Daten zu ersparen, wird beim Absenden Ihres Kommentars ein Cookie an Ihren Browser gesendet und von diesem gespeichert. Mit dem Absenden eines Kommentars auf dieser Webseite stimmen Sie der Speicherung und Übertragung dieses Cookies explizit zu.

Pflichtfelder sind mit * markiert.