Viele Betreiber von kleineren Email-Servern kennen das Problem, dass die großen Anbieter die Mails von ihren Servern gerne mal als Spam einsortieren. t-online.de geht sogar soweit, dass sie Mails von kleinen Servern direkt abweisen und man muss erst durch Email an die angegebene Email-Adresse seinen Mailserver freischalten lassen. Mit einer neuen IP-Adresse beginnt das Spiel dann von neuem.
Daher ist es sinnvoll seine Mails mit allem Möglichen und möglichst fehlerfrei auszustatten was als state-of-the-art auf dem Gebiet der Email-Sicherheit betrifft gilt. Die Sinnhaftigkeit und Wirkung dieser Maßnahme was das Identifizieren von potentiellen Spam betrifft braucht man da nicht in Frage zu stellen denn oft macht es wenig sinn denn niemand verhindert, dass Spammer die gleichen Methoden benutzen. Gängig auf dem Gebiet ist DKIM, SPF und DMARC. Interessanterweise haben viele größere Email-Provider Probleme mit ihrer eigenen korrekten Implementierung oder verzichten ganz darauf.
Wikipedia definiert folgendes:
- DKIM: DomainKeys, auch bekannt unter DomainKeys Identified Mail (DKIM), ist ein Identifikationsprotokoll zur Sicherstellung der Authentizität von E-Mail-Absendern. Es wurde konzipiert, um bei der Eindämmung von unerwünschter E-Mail wie Spam oder Phishing zu helfen.
- SPF: Das Sender Policy Framework (SPF; früher Sender Permitted From) ist ein Verfahren, mit dem das Fälschen der Absenderadresse einer E-Mail verhindert werden soll, genauer das Versenden von E-Mail über nicht legitimierte Mail Transfer Agents (MTAs) unterbindet. Es entstand als Verfahren zur Abwehr von Spam. Bei SPF trägt der Inhaber einer Domain in das Domain Name System ein, welche Adressen von MTAs zum Versand von E-Mails für diese Domain berechtigt sind.
- DMARC: Domain-based Message Authentication, Reporting and Conformance (DMARC) ist eine Spezifikation, die entwickelt wurde, um den Missbrauch von E-Mails zu reduzieren, wie er etwa bei Mail-Spoofing vorkommt. DMARC versucht einige seit langem bestehende Unzulänglichkeiten im Zusammenhang mit der Authentifizierung von E-Mails zu beheben und wurde bei der IETF zur Standardisierung eingereicht.
DKIM
Für DKIM existiert mit OpenDKIM eine Open-Source-Implementierung und kann auf dem Server sowohl eigene versendete Mails signieren als auch empfangene Mails anhand der Signatur überprüfen. Zunächst muss man OpenDKIM installieren:
apt-get install opendkim opendkim-tools
und die Verzeichnisse erstellen und die richtigen Rechte setzen:
mkdir /etc/opendkim /etc/opendkim/keys chmod 700 /etc/opendkim/keys chown -R opendkim:opendkim /etc/opendkim
Das Verzeichnis mit den Schlüsseln ist nun für fremde Blicke geschützt.
Die Konfigurationsdatei /etc/dkim.conf und /etc/default/opendkim sind bei Debian bereits vernünftig eingestellt und müssen nicht verändert werden.
In der Datei /etc/opendkim/trusted wird definiert welchen Mails auch ohne Signatur vertraut wird. Das sind in der Regel interne Mails. Ein allgemeines Beispiel für die Domain example.com wäre:
# Datei /etc/opendkim/trusted 127.0.0.1 ::1 localhost example example.com host.example.com
Nun haben wir eine Menge Kleinkram gemacht aber uns noch nicht um Schlüssel gekümmert. Zunächst muss einmal dem System mitgeteilt werden wie sie verwendet werden und wo die Schlüssel im Dateisystem liegen.
In der Datei /etc/opendkim/signing.table wird definiert welcher Schlüsselname zu welcher Domain gehört:
# Datei /etc/opendkim/signing.table *@example.com example
Die Datei /etc/opendkim/key.table weist opendkim an unter welchem Pfad die Schlüssl zu finden sind:
# Datei /etc/opendkim/key.table example example.com:202103:/etc/opendkim/keys/example.private
Die entscheidende Zeile besteht aus dem Hostnamen (example.com), einem Selektor (202103) der Jahr bzw. Monat enthält – März 2021 – in dem der Schlüssel erstellt wurde und schließlich dem Pfad des Schlüssels example.private. Sollte der Mail-Server für mehrere Domains zuständig sein müssen key.table und signing.table durch entsprechende Einträge ergänzt werden.
Nun haben wir aber immer noch keine Schlüssel. Diese muss man nun mit opendkim-genkey generieren. Dazu wechselt man ins Verzeichnis /etc/opendkim/ und generiert die Schlüssel:
cd /etc/opendkim opendkim-genkey -d example.com -b 2048 -r -s 202103
Dabei werden beiden Dateien, 202103.private und 202103.txt, angelegt. Die .private-Datei enthält den privaten Schlüssel und die .txt-Datei die TXT-Anweisung für den DNS. Beide Dateien müssen nun gemäß der Definition in der Datei key.table im Keys-Verzeichnis verschoben werden:
cd /etc/opendkim mv 202103.private keys/example.private mv 202103.txt keys/example.txt chmod 600 /etc/opendkim/keys/* chown -R opendkim:opendkim /etc/opendkim
Nun muss man dem DNS der die Domain verwaltet, normalerweise seinem Registrar der Domain, einen entsprechenden TXT-Eintrag mit geben. Der Inhalt befindet sich in der Datei example.txt im keys-Verzeichnis. Dafür wird eine TXT-Eintrag mit dem Hostname 202103._domainkey und dem Inhalt „v=DKIM1; h=sha256; k=rsa; s=email; p=MIIBIjANBgkqhkiG9w0BAQ[…]“ angelegt der sich in der Datei example.txt befindet.
Den neuen Eintrag kann man nun mit dem Befehl host überprüfen:
$ host -t TXT 202103._domainkey.example.com 201908._domainkey.example.com descriptive text "v=DKIM1; h=sha256; k=rsa; s=email; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCA[…]
OpenDKIM muss nun mit neu gestartet werden:
service opendkim restart
Die Konfiguration kann nun überprüft werden:
$ opendkim-testkey -d example.com -s 202103 -vvv opendkim-testkey: using default configfile /etc/opendkim.conf opendkim-testkey: checking key '202103._domainkey.example.com' opendkim-testkey: key not secure opendkim-testkey: key OK
Die Zeile die „key not secure“ enthält braucht nicht zu verunsichern denn die bedeutet nur, dass kein DNSSEC benutzt wird.
Nun muss noch die Konfigurationsdatei von Postfix /etc/postfix/main.cf angepasst werden und die vier Zeilen:
milter_default_action = accept milter_protocol = 6 smtpd_milters = inet:localhost:12345 non_smtpd_milters = inet:localhost:12345
ergänzt werden.
Wenn man sich selber nun eine Email sendet und dort in den Mailheader schaut so wird man, eine erfolgreiche Konfiguration vorausgesetzt, einen Eintrag finden der in etwas so aussieht:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cexample.eu; s=201908; t=1616713034; bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=; h=To:From:Subject:Date:From; b=qBMqEEELwVeLgu0uIVQOV1AfB4ImSYW+lfW7kiyk2jNd50cgp2IIOzrdRVbSZZztn q+Tmdft5jAmzr/buF9UlAOXljO2vPQh[…]
SPF
Für SPF ist die Konfiguration ziemlich simple und dazu öffnet man wieder die DNS-Einstellungen bei seinem Registrar und trägt einen SPF-TXT-Eintrag mit dem Hostname @ und dem Inhalt „v=spf1 mx -all“ an.
DMARC
Ebenfalls sehr einfach ist DMARC und es bedarf auch nur einen TXT-Eintrag im DNS des Registrars. Dazu wird dieser mit dem Hostname _dmarc und dem Inhalt „v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@example.com“ angelegt. Überprüfen kann man das wieder über den host-Befehl:
$ host -t TXT _dmarc.example.com _dmarc.example.com descriptive text "v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@example.com"
Als letzten Test kann man nun die Seite itsnotspam.com aufrufen und man erhält eine zufällige Email-Adresse. Wenn man an diese nun eine Email schickt wird diese auf ihre DKIM-, SPF- und DMARC-Tauglichkeit aber auch auf andere Eigenschaften überprüft.
