Donnerstag, 19. Juli 2018
Da ich mich auf der Arbeit gerade mit dem Thema E-Mail-Sicherheit und -Authentizität befasse, war es nun an der höchsten Zeit, auch meinen privaten Mailverkehr sicherer zu machen.
Begonnen habe ich mit der Konfiguration des sogenannten Sender Policy Frameworks SPF. Der Besitzer einer Domain gibt mit einem TXT-Eintrag in einem bestimmten Format auf dem Nameserver der Domain bekannt, von welchen IPs aus überall legitime E-Mails versendet werden können.
Mailserver, welche von einer mit SPF ausgerüsteten Domain E-Mails erhalten, können — müssen aber nicht — diese Information abfragen und mit den Informationen im Header des E-Mails vergleichen. Basierend auf dem Resultat dieser Auswertung kann der Mail-Server oder der Mail-Client des Empfänger Aktionen ergreifen. Beispielsweise E-Mails markieren oder in einen Unterordner verschieben, welche von keiner der freigegebenen IP versendet wurden. Oder E-Mails von einer offiziellen Mail-Server-IP eine höhere Authentizitätspunktzahl geben und so von der Spam-Score abziehen.
Mein Hoster der Wahl, Cyon, hat im Support-Artikel Was ist ein SPF-Record? festgehalten, wie ein solcher SPF-Record aussehen könnte und wie man diesen über das Controlpanel my.cyon einrichtet. Obwohl der Autor des Support-Artikels festhält, dass alle Kundendomains bereits einen Eintrag besitzen …
Der Standardeintrag bei cyon sieht folgendermassen aus: […] Sie können diesen im my.cyon unter «Webhosting» > «DNS-Editor» mit dem DNS-Editor anpassen. Wichtig ist, dass man den bestehenden Eintrag ergänzt, da nur jeweils ein SPF-Eintrag gültig ist.
… hatten meine Domains keinen solchen Eintrag. Wahrscheinlich, weil ich bereits langjähriger Kunde bin und nur neue Hostingkunden diesen Eintrag automatisch erhalten.
Cyon schlägt folgenden Eintrag vor:
v=spf1 +a +mx +ip4:194.126.200.0/24 +ip4:149.126.0.0/21 -all
Ich empfand diese zwei Ranges viel zu weitläufig und habe mich entschieden, stattdessen folgende Konfiguration einzuspeisen:
v=spf1 +a +mx +ip4:194.126.200.18 +ip4:194.126.200.19 +ip4:194.126.200.20 +ip4:194.126.200.22 +ip4:149.126.4.65 -all
Die IPs fand ich folgendermassen heraus:
$ host mail.cyon.ch
mail.cyon.ch has address 194.126.200.18
mail.cyon.ch has address 194.126.200.22
mail.cyon.ch has address 194.126.200.20
mail.cyon.ch has address 194.126.200.19
$ host s056.cyon.net
s056.cyon.net has address 149.126.4.65
Dahinter verstecken sich einerseits alle vier Server, auf welche mail.cyon.ch auflöst, andererseits der physische Server, auf welchem meine Web-Site gehostet wird: s056.cyon.net.
Die TTL habe ich auf 15 Minuten gesetzt, damit ich in Notfällen Anpassungen vornehmen kann und diese sich dann rasch propagieren.
Existenz des Eintrags verifizieren
$ dig @ns1.cyon.ch emeidi.com txt
...
;; ANSWER SECTION:
emeidi.com. 900 IN TXT "v=spf1 +a +mx +ip4:194.126.200.18 +ip4:194.126.200.19 +ip4:194.126.200.20 +ip4:194.126.200.22 +ip4:149.126.4.65 -all"
...
Via: Using dig to search for SPF records
und Force dig to resolve without using cache
Warnung
Auf der Arbeit musste ich realisieren, dass man als Besitzer einer Domain den SPF-Record stets aktuell halten muss. Bisher sah ich folgende Probleme:
- E-Mails werden im Namen des Dienstleister über den Services eines Dritten versendet (bspw. SaaS), der Dienstleister vergisst aber, die IP(s) resp. die Domain mit den SPF-Einträgen des Mail-Servers in die Konfiguration aufzunehmen.
- Man macht einen Flüchtigkeitsfehler und schreibt bspw. Anstelle +ip4:1.2.3.4 folgende syntaktisch falsche Konfiguration: +ipv4:1.2.3.4
Validität prüfen
Es empfiehlt sich deshalb, zumindest die Validität eines SPF-Records zu testen. Hierfür hat sich bei mir das Tool MxToolbox Supertool bewährt:
Wird der SPF-Record grün hinterlegt, ist alles bestens. Erscheint er rot, ist etwas an der Syntax nicht korrekt. Übrigens: Bei mit +include: verschachtelten Einträgen empfiehlt es sich, die Domains im Include-Statement auch noch gleich abzufragen, indem man in der Resultate-Tabelle darauf klickt. In einem Fall fand sich die Fehlkonfiguration dort.
Zusätzlich gibt es noch eine andere Variante — lasst uns doch einfach ein Mail senden! Und zwar an diese Mail-Adresse: check-auth@verifier.port25.com. Man erhält automatisch eine Antwort zurück, die sich etwa so liest:
==========================================================
Summary of Results
==========================================================
SPF check: pass
"iprev" check: pass
DKIM check: permerror
SpamAssassin check: ham
==========================================================
Details:
==========================================================
HELO hostname: s056.cyon.net
Source IP: 149.126.4.65
mail-from: xyz@eMeidi.com
----------------------------------------------------------
SPF check details:
----------------------------------------------------------
Result: pass
ID(s) verified: smtp.mailfrom=xyz@eMeidi.com
DNS record(s):
eMeidi.com. 60 IN TXT "v=spf1 +a +mx +ip4:194.126.200.18 +ip4:194.126.200.19 +ip4:194.126.200.20 +ip4:194.126.200.22 +ip4:149.126.4.65 -all"
eMeidi.com. 60 IN A 149.126.4.65
----------------------------------------------------------
"iprev" check details:
----------------------------------------------------------
Result: pass (matches s056.cyon.net)
ID(s) verified: policy.iprev=149.126.4.65
DNS record(s):
65.4.126.149.in-addr.arpa. 60 IN PTR s056.cyon.net.
s056.cyon.net. 60 IN A 149.126.4.65
Produktiver Test
Um das funktionieren des SPF-Records vollends zu testen, sendete ich mir ein Mail an eine Gmail-Adresse und guckte mir dann den Mail-Header an, wie er bei Google ankommt:
...
Received-SPF: pass (google.com: domain of xyz@emeidi.com designates 149.126.4.65 as permitted sender) client-ip=149.126.4.65;
Authentication-Results: mx.google.com;
dkim=temperror (no key for signature) header.i=@emeidi.com header.s=default header.b=LchLhMBS;
spf=pass (google.com: domain of xyz@emeidi.com designates 149.126.4.65 as permitted sender) smtp.mailfrom=xyz@emeidi.com
...
Ist SPF gar nicht konfiguriert, sieht der E-Mail-Header stattdessen folgendermassen aus:
...
Received-SPF: neutral (google.com: 149.126.4.65 is neither permitted nor denied by best guess record for domain of xyz@emeidi.com) client-ip=149.126.4.65;
Authentication-Results: mx.google.com;
dkim=temperror (no key for signature) header.i=@emeidi.com header.s=default header.b=cbFM4Bn7;
spf=neutral (google.com: 149.126.4.65 is neither permitted nor denied by best guess record for domain of xyz@emeidi.com) smtp.mailfrom=xyz@emeidi.com
...
