Datenhaufen zu IT und Elektronik.

Schlagwort: SPF

SPF-Record erklärt: Schutz vor gefälschten E-Mails

Ich bin in der letzten Zeit immer mal wieder zu meinem SPF Record Beispiel gefragt worden. Ihr wisst schon… Diese beiden:

kernel-error.de.    IN  TXT "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"
kernel-error.de.    IN  SPF "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"

Ich versuche das ganze noch einmal etwas aufzuschlüsseln. Die genannten Beispiele sollen die Möglichkeiten zeigen, welche man hat um den SPF-RECORD zu erstellen. Der echte SPF-RECORD sollte aber so schlank wie irgendwie möglich sein. Denn er wird ja theoretisch bei jeder eingehenden E-Mail geprüft. Um so länger er ist und umso mehr geprüft werden muss umso mehr DNS Lookups müssen gemacht werden. Man hat nach RFC nur maximal 10 DNS Abfragen, eine davon hat man schon verbrannt um den eigentlichen SPF RECORD zu holen. Es bleiben also noch 9 🙂 Kommt man über diese 10 Abfragen stirbt alles mit der Meldung:
Results – PermError SPF Permanent Error: Too many DNS lookups

Ist auch OK so, denn wenn der empfangende Mailserver für jede eingehende E-Mail hunderte DNS lookups durchführen muss, tut er ja nichts anders mehr!

Gut, nun zu meinem Beispielrecord.

v=spf1 ==> Ist die Protokollversion
ip4:212.23.142.146 ==> Von dieser IPv4 Adressen dürfen E-Mails kommen.
ip6:2001:7d8:8001:100::2 ==> Von dieser IPv6 Adresse dürfen E-Mails kommen.
ptr:smtp.kernel-error.de ==> Es dürfen E-Mails von den PTR Adresse“n“ des Hosts smtp.kernel-error.de kommen.
mx ==> Es dürfen E-Mails vom MX (Mail Exchange) der Domäne kernel-error.de kommen.
a:smtp.kernel-error.de ==> Es dürfen E-Mails von den IPv4 / IPv6 Adressen des Hosts smtp.kernel-error.de kommen.
==> Kommt die E-Mail von einem -nicht zutreffenden- System gilt der SPF-Test immer als Fehlschlag
all ==> Das ganze passiert immer.

Bei den IP-Adressen kann ebenfalls ein ganzes Netz angegeben werden. Zum Beispiel: 212.23.142.146/24

Beim mx könnte eine andere Domäne oder Subdomäne stehen. Zum Beispiel: mx:smtp.kernel-error.de damit dürften dann E-Mails vom MX der Domäne smtp.kernel-error.de kommen. Natürlich muss es diesen MX auch geben!!! Es geht noch mehr… Zum Beispiel habe ich in einer weiteren Domain von mir nur folgendes stehen:
v=spf1 include:kernel-error.de -all

include:kernel-error.de ==> Gibt an das bitte der SPF RECORD von der Domain kernel-error.de abgefragt und angewandt werden soll. Damit gilt die SPF-Policy der Domain kernel-error.de. Ich muss also nur eine Policy pflegen und lasse alle anderen Domains nur auf diese verweisen 🙂

Die Abfrage würde dann so aussehen:

DNS record(s):
    vandemeer.de. 86400 IN SPF "v=spf1 include:kernel-error.de -all"
    kernel-error.de. 86400 IN SPF "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 -all"

Würde man nun den oben stehenden RECORD in die Zone kernel-error.de. werfen und ihn aktiv nutzen; Dann wird er funktionieren und absolut gültig sein. Das empfangende E-Mail System wird aber eine ganz Hand voll DNS Abfragen machen müssen um diese SPF Policy zu prüfen. Jetzt beantwortet sich sicher die Frage, warum ich einen anderen SPF-RECORD einsetzte als hier aufgeführt 😀 Denn die aufgeführten RECORDS sind schlicht ein Beispiel und keine Copy & Paste Vorlagen. Ok ok… Ich hätte das direkt genauer beschreiben sollen, hm?

Weniger ist im SPF RECORD also mehr. Man darf sich also überlegen welcher RECORD für seine Domain und sein System gerade der beste ist. Wenn es wechselnde IP Adresse gibt ist sicher ein A/AAAA RECORD besser, wenn sich dieser oft ändert dann ggf. ein MX der Domain oder ein ganzes Netz oder oder…

Mehr zum Lesen:

SPF
SPF-RECORD
SPF-RECORD erkärt

DMARC (Domain-based Message Authentication, Reporting & Conformance)

Habt ihr eigentlich schon etwas von DMARC (Domain-based Message Authentication, Reporting & Conformance) gehört? Nein… Dann dann haben wir das ja nun aufgeholt 😛

Im Grunde „erweitert“ DMARC die beiden Systeme SPF (Sender Policy Framework) und DKIM (DomainKeys Identified Mail). Warum und wie?!? Nun ja, beide Techniken sind erstmal ~nicht schlecht~. Setzt man sie ausgehend ein, fehlen dem Admin denn noch etwas die „Rückmeldungen“. OK, wenn etwas schief geht, jammern die User. Setzt man sie eingehend ein, würde es hin und wieder helfen wenn der „Absender“ einem etwas genauer sagen würde wie denn nun mit seinen Nachrichten umgegangen werden soll.

Hier springt nun DMAC -in die Bresche- (woher kommt eigentlich diese Redensart?). DMARC wird, wie bei SPF oder DKMI möglich, einfach als TXT-RECORD in der DNS Zone versenkt. Dort finden sich nun Informationen für den empfangenden Mailserver. Zum Beispiel kann angegeben werden wie viel Prozent der eingehenden E-Mails überhaupt gefiltert werden soll (pct), wie hart bei Fehlern im SPF (aspf) und DKIM (adkim) umgegangen werden soll, wie mit E-Mails der Haupt- (p) oder Subdomänen (sp) umgegangen werden soll und was tierisch geil für den Admin des Absendenden E-Mail Systems ist…. An welche E-Mail Adresse ein forensischer (das Wort trifft es, ich finde es aber doof :-P) Bericht (ruf) und wohin eine tägliche Zusammenfassung (rua) gesendet werden soll.

Diese Berichte schlagen normalerweise als E-Mail mit einem komprimierten ZIP-File im Gebäck auf. In diesem ZIP-File steckt dann ein XML-File (*würk* XML.. für die Auswertung denn noch geil). Diese kann man nun auswerten. So kann der Admin des absendenden E-Mail Systems sehen wie gut oder schlecht seine Bemühungen greifen. Er wird schnell über Probleme informiert und kann erkennen ob und wie stark seine Domain gerade -missbraucht- wird.

Eine E-Mail mit ZIP-File lässt sich sehr einfach automatisch auspacken und die XML Datei wird dann von irgendeinem Stück Software gefressen. Heraus kommt ein täglicher Bericht für den Admin. Ok, man könnte es schön bunt machen, dann kann man es auch einer Krawatte zum klicken geben 🙂

Klar muss der Empfänger es unterstützen, sonst bringt das alles nix. Aber jeder Absender, der bereits SPF und DKIM einsetzt, kann seinen DMARC Record schon mal erstellen, hm?

Ich probiere eine kurze Erklärung des DMARC TXT RECORDS an meinem…

_dmarc.kernel-error.de  IN TXT  "v=DMARC1; pct=100; rua=mailto:postmaster@kernel-error.de; ruf=mailto:postmaster@kernel-error.de; adkim=s; aspf=s; p=quarantine; sp=quarantine"

_dmarc. ==> ist halt der „Bezeichner“
kernel-error.de ==> japp die Domain
IN TXT ==> Internet und Text
„“ ==> Dazwischen ist der Text
; ==> Trennt die Optionen
v=DMARC1 ==> Protokollversion, hier also 1
pct=100 ==> 100% meiner vermeintlichen Nachrichten sollen gefiltert werden
rua=mailto:postmaster@kernel-error.de ==> Zusammenfassung geht an postmaster@kernel-error.de
ruf=… ==> der forensiche Bericht geht ebenfalls an den Postmaster
adkim=s ==> DKIM soll nicht relaxed (r) sondern strict (s) ausgewertet werden
aspf=s ==> auch strict
p=quarantine ==> Fehlgeschlagenes der Hauptdomäne sollen als SPAM markiert werden.
sp=quarantine ==> bei der Subdomäne auch.

Noch eine Kleinigkeit. Wenn man mehrere Domains betreut und die Berichte an eine zentrale E-Mail Adresse senden möchte dann muss man noch etwas beachten. Denn sollen die Berichte an eine E-Mail Adresse außerhalb der Domain des DMARC RECORDS gesendet werden, dann muss dieses in der Empfängerdomäne „erlaubt“ werden. Dieses geht über einen gesonderten TXT RECORD.

kernel-error.com._report._dmarc.kernel-error.de TXT "v=DMARC1"

Wenn man diesen RECORD als Beispiel nimmt, würde er in der Zone kernel-error.DE stehen. Damit würden die Berichte aus der Zone kernel-error.COM an die Adresse xyz@kernel-error.de zugestellt werden können.

Noch Fragen? Na dann fragen 😀


UPDATE 12.12.2013

Ok ok… da die Frage jetzt ein paar mal aufgekommen ist, wie ein solcher Report aussieht…. Hier ein Beispiel: >> klick <<

Zur besseren Ansicht kann ich auch hier nur wieder auf dmarcian.com verlinken. Hier gibt es einen XML du Human Konverter 🙂 

Frage beantwortet?

SPF Records

Es gibt seit einiger Zeit einen dedizierten SPF-Record. Dieser wird auch bereits von vielen SPF-Filtern sowie Bind seit Version 9.4 unterstützt. Dieses entlastet etwas die TXT Anfragen und sorgt für mehr Ordnung 🙂 Wird dieser SPF Record vom jeweiligen SPF Filter unterstützt, fragt dieser meist zuerst nach dem SPF-Record und wenn es keine Antwort gibt als nächstes nach einem TXT-SPF Record.

Um diesen Filtern etwas Arbeit zu ersparen, das DNS etwas aufzuräumen und auf lange Sicht RFC konform zu bleiben (es würde mich nicht wundern wenn der TXT-SPF Record bald ausstirbt). Sollte man ebenfalls bei seiner SPF geschützten Domain einen solchen Record erstellen.

Für meinen Bind und die Domain kernel-error.de würde ein Beispiel wie folgt aussehen:

kernel-error.de.    IN    SPF    "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"

 

Geprüft werden kann alles schnell und einfach mit DIG:

# dig kernel-error.de IN SPF +short
"v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"

 

Sobald alle gängigen Filter die SPF-Records implementiert haben und alle Postmaster ihre Einführungszeit hatten, kann man dann sicher seinen TXT-SPF-Record entfernen. Dieses dauert sicher wieder ein paar Jahre! Ach ja, mein TXT SPF Record schaut so aus:

kernel-error.de.    IN    TXT    "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"

 

 

Mehr zum Lesen:

SPF
SPF-RECORD
SPF-RECORD erkärt

© 2024 -=Kernel-Error=-

Theme von Anders NorénHoch ↑