In der heutigen Zeit werden E-Mails oftmals nicht mehr über einen einzelnen Server verschickt. Wie sollten große Anbieter es sonst schaffen alle E-Mails Ihrer Millionen Nutzer zeitnah abzuhandeln? Spätestens wenn es zu Versand von Newslettern kommt, wird auf mehrere Server zurückgegriffen, damit zum Beispiel E-Mails der Mitarbeiter nicht in einer Warteschlange landen mit 100.000 Newslettern.
Damit diese Server vom Empfänger verifiziert werden können wurden die Mechanismen SPF, sowie DKIM eingeführt. Basierend auf diesen beiden kam später noch DMARC hinzu. Im folgenden möchte ich beschreiben, wie man diese Mechanismen mit Postfix verbindet und entsprechende Informationen publiziert.
SPF – Sender Policy Framework
Fangen wir mit SPF an. Bei SPF wird im DNS einer Domain ein TXT-Record hinterlegt. Dort gibt man in einer bestimmten Syntax an, welche Server für diese Domain verifiziert sind. Beispielhaft sieht ein SPF Record in etwa so aus:
v=spf1 ip4:1.2.3.4 ip4:1.2.3.5 a:mx.domain.tld include:other-domain.tld ?all
Dieser sagt aus, dass Mails von der IPv4 Adresse 1.2.3.4 und 1.2.3.5 verschickt werden dürfen, sowie vom Server hinter dem A-Record mx.domain.tld. Zudem sollen die Einstellungen der Domain other-domain.tld included werden und über alle anderen soll keine weiter Aussage getroffen werden mit ?all. Mit „-all“ würde man den Versand über alle anderen Mailserver verbieten. Dies kann jedoch zu Problemen führen in Szenarien, wie Beispielsweise bei der Weiterleitung von Mails. Bitte beim include aufpassen, hier gibt man einiges aus der Hand, wenn „other-domain.tld“ nicht von einem selbst verwaltet wird.
SPF mit Postfix verbinden
apt-get install postfix-policyd-spf-python
Anschließend öffnen wir die Datei /etc/postfix/master.cf und fügen folgendes hinzu:
postfix-policyd-spf unix – n n – 0 spawn user=policyd-spf argv=/usr/bin/policyd-spf
Und um die policy auch zu verwenden, editieren wir die smtpd_recipient_restrictions in /etc/postfix/main.cf. Bitte beachtet, dass ihr diese unbedingt NACH reject_unauth_destination einfügt.
smtpd_recipient_restrictions = … reject_unauth_destination check_policy_service unix:private/postfix-policyd-spf …
Danach restarten wir postfix. Bei eingehenden Mails sollte nun ein Header enthalten sein, der in etwa wie folgt aussieht:
Received-SPF: Pass (sender SPF authorized) …
Weitere Einstellungen kann man noch unter /etc/postfix-policyd-spf-python/policyd-spf.conf vornehmen.
DKIM – DomainKeys Iidentified Mail
DKIM verfolgt ebenfalls das Ziel den Absender zu verifizieren, jedoch mit anderem Ansatz. Dabei werden Headerdaten, die man auch selbst definieren kann mittels eines privaten Schlüssels signiert, während sich der öffentliche Schlüssel im DNS der jeweiligen Domain befindet. Wo dieser genau zu finden ist, bestimmt der Selector – dazu aber gleich noch mehr. Sollte man die Headerdaten, welche signiert werden sollen, selbst definiert, sollte man unbedingt darauf achten, dass es Header sind, die im Verlauf des Versands nicht verändert werden, mehr dazu aber auch im RFC6376 – Abschnitt 5.4.
Beide Verfahren dienen nur dazu den Absender zu verifizieren, es bietet daher keinen Spamschutz im eigentlichen Sinn, wie manche sich vielleicht erhoffen. Sie sind aber relativ schnell eingerichtet und manche Mailserver und Dienste bewerten Mails mit gültigem SPF und DKIM besser, daher ist die Einrichtung kein absolutes „Muss“, aber dennoch ein „Nice-to-have“.
OpenDKIM mit Postfix verbinden
apt-get install opendkim opendkim-tools
Bevor wir nun mit opendkim und postfix weiter machen generieren wir erst einmal Keys, die wir verwenden möchten:
mkdir -p /etc/opendkim/keyfiles/domain1.tld
cd /etc/opendkim/keyfiles/domain1.tld
opendkim-genkey -s mail -d domain1.tld
Damit werden zum einen die Datei mail.private generiert, die den privaten Schlüssel beinhaltet, sowie mail.txt. welche den öffentlichen Schlüssel beinhaltet. Der oben genannte Selector ist „mail“. Den öffentlichen Schlüssel können wir daher schon im DNS der Domain domain1.tld hinterlegen. Dabei handelt es sich um einen Textrecord, der in unserem Beispiel unter mail._domainkey.domain.tld hinterlegt sein muss. Ist dies erledigt geht es weiter in der Konfiguration.
Anschließend ist die Datei /etc/opendkim.conf wichtig, hier wird die zentrale Konfiguration von opendkim vorgenommen. Beispielsweise so kann eine Konfiguration aussehen:
Mode sv
AutoRestart Yes
AutoRestartRate 10/1h
UMask 002
UserID opendkim:opendkim
Syslog yes
KeyTable /etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
Canonicalization relaxed/relaxed
LogResults yes
LogWhy yes
SyslogSuccess yes
Socket inet:10080@localhost
SignatureAlgorithm rsa-sha256
Wichtig sind hier zum einen der Port, zum anderen aber natürlich die beiden Parameter KeyTable und SigningTable. Weitere Konfigurationsparameter kann man in der Dokumentation der offiziellen Seite von opendkim nachlesen. Gehen wir aber weiter in unserem Beispiel. Ein Keytable kann z.B. wie folgt aussehen:
mail._domainkey.% %:mail:/etc/opendkim/keyfiles/domain.tld/mail.private
Das „%“ in diesem Beispiel ist ein Platzhalter für die jeweilige Domain. Es werden daher alle Domains mit dem privaten Schlüssel signiert, welcher unter /etc/opendkim/keyfiles/domain.tld/mail.private liegt. Als selector wird „mail“ verwendet. Sollte man für jede Domain einen anderen Key verwenden, was auch im Normalfall so ist, dann kann man einfach folgende Änderungen vornehmen:
mail._domainkey.domain1.tld domain1.tld:mail:/etc/opendkim/keyfiles/domain1.tld/mail.private
mail._domainkey.domain2.tld domain2.tld:mail:/etc/opendkim/keyfiles/domain2.tld/mail.private
Kommen wir zum SigningTable. Hier wird festgelegt, welche Mails mit welchem Eintrag im KeyTable signiert werden.
*@domain1.tld mail._domainkey.domain1.tld
*@domain2.tld mail._domainkey.domain2.tld
Auch hier kann man aber mit Wildcards und Platzhaltern arbeiten und Beispielsweise folgenden Eintrag setzen.
* mail._domainkey.%
Damit wird jede Mail signiert, mit mail._domainkey.<Name der Domain>
Will man nun noch postfix mit opendkim verbinden, ist es relativ einfach. Hier werden einfach entsprechende Einträge in der /etc/postfix/main.cf angehängt:
milter_protocol = 6
milter_default_action = accept
smtpd_milters = inet:localhost:10080
non_smtpd_milters = inet:localhost:10080
Danach einfach noch beide Services restarten und schon werden alle Mails entsprechend signiert.
DMARC – Domain-based Message Authentication, Reporting & Conformance
Mit DKIM und SPF haben wir schon zwei Mechanismen, mit denen ich als Absender gewisse Informationen weitergeben kann. Was der Empfänger damit anstellt ist jedoch ihm selbst überlassen. Lehnt Mailserver A eine Mail ab, weil der SPF Check fehlschlägt, lässt Mailserver B die Mail mit höherem Spamscore vielleicht durch. Die Bewertung liegt beim Empfänger, der neben SPF und DKIM noch viele weitere Checks implementiert hat um Spam entsprechend abzuwehren. Die Entscheidung, was nun mit der Mail im besten Fall passieren soll, soll DMARC dem Empfänger erleichtern und dem Sender ein wenig mehr Möglichkeiten geben.
Als Absender hinterlege ich im DNS einen entsprechenden Eintrag. Hier gibt es einige Variablen und zugehörige Optionen, die man setzen kann. Der Empfänger hingegen kann diese Empfehlung, die vom wirklichen Inhaber der Domain kommt nutzen um zu entscheiden was er mit der Mail passieren soll. Der DMARC Eintrag von Google sieht Beispielsweise wie folgt aus:
v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:mailauth-reports@google.com
Dies dient lediglich als Beispiel, wer mehr über die Parameter und Optionen lesen möchte sollte den zugehröigen RFC7489 genauer ansehen
Damit ist auch schon alles getan, was man als Absender machen kann. Wichtig dabei ist der p-Parameter, der auf none (keine Aussage, Entscheidung liegt weiter beim Empfänger), quarantine (Dem Empfänger wird geraten bei einem fehlerhaften Check die Mail als Spam zu betrachten und ggf. in einen Spamordner zu verschieben), oder reject (Die Mail soll auf SMTP Ebene bereits abgelehnt werden) gesetzt werden kann. Es ist schwer hierbei eine Empfehlung oder ähnliches auszusprechen, da es immer auf den Fall an sich ankommt, welche Features man von DMARC im gegebenen Szenario verwenden möchte.
OpenDMARC mit Postfix verbinden
apt-get install opendmarc
Anschließend editieren wir die Datei /etc/default/opendmarc. Hier sind schon einige Beispiele angegeben und sind auch sehr selbsterklärend. Wir tragen folgendes ein:
SOCKET=“inet:12345@localhost“
Nun editieren wir noch die Konfiguration von DMARC, welche unter /etc/opendmarc.conf zu finden ist.
AuthservID mx.domain.tld
PidFile /var/run/opendmarc.pid
RejectFailures false
Syslog true
SyslogFacility mail
TrustedAuthservIDs localhost,mx.domain.tld
IgnoreHosts /etc/opendmarc/ignore.hosts
UMask 002
UserID
FailureReports false
AutoRestart true
HistoryFile /var/log/opendmarc.log
RecordAllMessages true
SoftwareHeader true
Danach editieren wir noch /etc/opendmarc/ignore.hosts
127.0.0.1
Die Option „SoftwareHeader true“ ist eher für eure ersten Tests von Vorteil, da ihr in einem weiteren Header die verwendete Version und verarbeitete E-Mail sehen könnt:
DMARC-Filter: OpenDMARC Filter v1.3.1 mx.domain.tld A3DF6FFB75
Anschließend geht es an die Integration von OpenDMARC in Postfix. Da es sich hierbei um einen Mailfilter handelt, wird er an der bereits bekannten Stelle in der main.cf nach unserem DKIM Milter eingetragen.
smtpd_milters = inet:localhost:10080, inet:localhost:12345
non_smtpd_milters = inet:localhost:10080, inet:localhost:12345
Danach starten wir OpenDMARC und restarten Postfix. Nun sollten E-Mails einen Header enthalten, der in etwa so aussieht, falls der DMARC-Check erfolgreich war:
Authentication-Results: mx.domain.tld; dmarc=pass header.from=sender-domain.tld
Angemerkt sei, dass opemdmarc seit Version 1.3 auch selbst SPF Checks ausführen kann, falls es also bei jemandem Probleme geben sollte mit postfix-policyd-spf, kann auch der eigene SPF Check verwendet werden.
Ist ein key für alle ausgehenden mails mehrerer Domains möglich?
Ich hätte keine Lust das für jede Domain zu machen.
ja, das geht