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 E-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.

Überblick

DMARC baut auf den Techniken Sender Policy Framework (SPF) und DomainKeys Identified Mail (DKIM) auf, indem es für eine Absender-Domain festlegt, wie das Empfänger-Mailsystem die Authentifizierung von E-Mails durchführen soll und wie im Falle eines Fehlers zu verfahren ist. Während die vorgenannten Techniken beschreiben, wer eine Mail versenden darf (SPF), bzw. sicherstellen, dass diese Mail in bestimmter Weise unverändert vom Absender stammt (DKIM), kann der Absender nach der DMARC-Spezifikation zusätzlich eine Richtlinie festlegen, auf welche Art der Empfänger mit einer Mail umgehen soll, die in einem oder beiden Fällen nicht den Anforderungen entspricht. Die DMARC-Richtlinie veröffentlicht die Absender-Domain durch einen Eintrag im Domain Name System (DNS). Sofern das Empfänger-Mailsystem die DMARC-Spezifikation bei E-Mail-Nachrichten anwendet, ist dadurch eine konsistente Überprüfung der Authentizität dieser E-Mails gesichert.

Die DMARC-Spezifikation entstand unter anderem auf Initiative von Google, Yahoo, Microsoft, Facebook, AOL, PayPal und LinkedIn.

Abfragen lässt sich die DMARC-Richtlinie einer Domain via dig _dmarc.domain txt, beispielsweise dig _dmarc.wikipedia.org txt. Ein dig example.org txt ist nicht ausreichend um den DMARC-DNS-Eintrag zu bekommen.

Aufbau einer DMARC-Richtlinie

DMARC verwendet, so wie auch SPF und DKIM, TXT-Records im DNS. Für eine Absender-Domain wird auf der Subdomain _dmarc ein Resource Record angelegt, der die DMARC-Richtlinie für diese Absender-Domain enthält. Folgend ist ein Beispiel dargestellt, wie DMARC im TXT-Record von _dmarc.example.org konfiguriert sein könnte:

v=DMARC1; p=quarantine; pct=100; rua=mailto:postmaster@example.org; ruf=mailto:forensik@example.org; adkim=s; aspf=r

Abkürzung	Bedeutung	Angabe	Erlaubte Werte	Standardwert, wenn Angabe fehlt
v	Protokollversion	notwendig	DMARC1	–
pct	Prozentualer Anteil der zu filternden Mails	optional	ganze Zahl zwischen 0 und 100	100
fo	Fehlerberichtsoptionen	optional	0, 1, d, s	0
ruf	Fehlerbericht wird versandt an:	optional	URIs	–
rua	Aggregierter Bericht wird versandt an:	optional	URIs	–
rf	Format der Fehlerberichte	optional	afrf	afrf
ri	Intervall zwischen den aggregierten Berichten (in Sekunden)	optional	ganze Zahl	86400
p	Anweisung, wie mit Mails der Hauptdomain zu verfahren ist.	notwendig	none, quarantine, reject	–
sp	Anweisung, wie mit Mails der Subdomain zu verfahren ist.	optional	none, quarantine, reject	Anweisung der Hauptdomain
adkim	Abgleichmodus für DKIM	optional	r, s	r
aspf	Abgleichmodus für SPF	optional	r, s	r

Besondere Bedeutung haben die Abgleichmodi: Für SPF fordert die DMARC-Spezifikation, dass erstens die Überprüfung positiv ausfällt und zweitens die From Kopfzeile der Mail dieselbe Domain aufweist wie MAIL FROM im SMTP. Für DKIM wird gefordert, dass die Signatur gültig ist und zusätzlich die dort genannte Domain dieselbe ist, wie in der From Kopfzeile der Mail. Als Abgleichmodi sind s für ‘strict’ bzw. r für ‘relaxed’ vorgesehen. Bei ‘strict’ müssen die Domains exakt übereinstimmen, bei ‘relaxed’ darf die From Kopfzeile auch eine Subdomain enthalten. Der Domain-Abgleich wird in der Spezifikation als „Identifier Alignment“ bezeichnet (deutsch etwa: Übereinstimmung des Identifizierungsmerkmals) und stellt eine wesentliche Schutzfunktion dar, die über die Zusicherung von SPF und DKIM hinausgehen.

fo legt fest wie Fehlerberichte erstellt werden sollen. 0 ist die Voreinstellung und erzeugt einen DMARC-Fehlerbericht, wenn sowohl SPF, als auch DKIM fehlschlagen. 1 erzeugt einen Fehlerbericht, wenn entweder SPF oder DKIM fehlschlägt. d erzeugt einen DKIM-Fehlerbericht, wenn die Nachricht eine Signatur enthält, die nicht ausgewertet werden konnte. s erzeugt einen SPF-Fehlerbericht, wenn die SPF-Prüfung nicht bestanden wurde.

Zum erfolgreichen Bestehen einer DMARC-Prüfung genügt es, wenn einer der beiden Prüfmechanismen SPF oder DKIM positiv ausfällt und die Domain mit der From-Kopfzeile übereinstimmt. Werden beide Prüfmechanismen parallel eingesetzt, erhöht dies die Wahrscheinlichkeit einer erfolgreichen DMARC-Prüfung, falls einer der Mechanismen durch ungünstige Umstände fehlschlägt.

Die Policy (hier abgekürzt als 'p' bzw. 'sp' für Subdomains) legt schließlich fest, wie das Empfänger-Mailsystem mit der Mail verfahren soll, wenn die Überprüfung scheitert. Vorgesehene Modi hierfür sind 'none', 'quarantine' und 'reject'. 'none' (auch als Monitormodus bezeichnet) wird in der Regel zum Testen verwendet und macht dem Empfänger-Mailsystem keine Vorschriften über die Verfahrensweise. 'quarantine' verlangt die Kennzeichnung der Mails als Spam, 'reject' verlangt, die Mail zu verwerfen.

DMARC-Reporting

Ein Bestandteil von DMARC ist die Funktionalität, dass die Empfänger-Domain der Absender-Domain über den DMARC-Status der empfangenen E-Mails automatisch berichten kann. Dies dient dazu, um mögliche Fehlkonfigurationen und somit Zustellprobleme erkennen zu können. Die Übermittlung der Berichte erfolgt per E-Mail an die in der DMARC-Richtlinie angegebene E-Mail-Adresse, wobei zwischen zwei verschiedenen Arten von Berichten unterschieden wird.

Fehlerbericht

Ein Fehlerbericht (englisch failure report), teils auch als forensischer Bericht bezeichnet, wird pro E-Mail mit fehlgeschlagener DMARC-Prüfung erstellt und an die im Parameter ruf angegebene E-Mail-Adresse versandt. Der Fehlerbericht ähnelt einer Bounce Message. Aufgrund von Datenschutzbedenken gibt es im offenen Internet kaum DMARC-Nutzer, die Fehlerberichte versenden. Teilweise treffen E-Mail-Dienstleister individuelle Vereinbarungen, um sich gegenseitig Fehlerberichte zuzusenden und unter Wahrung von Datenschutzvorgaben zu verarbeiten.

Aggregierter Bericht

Ein aggregierter Bericht (englisch aggregate report) wird einmal täglich an die im Parameter rua angegebene E-Mail-Adresse versandt. Der aggregierte Bericht enthält eine zusammengefasste Übersicht über das Ergebnis der SPF-, DKIM- und DMARC-Prüfung von allen E-Mails der Absender-Domain des letzten Tages. Gegenüber einem Fehlerbericht sind erheblich weniger Details enthalten. Das Datenformat eines aggregierten Reports baut auf XML auf und ist standardisiert, was eine automatisierte Auswertung ermöglicht.

Kritik

DMARC steht in der Kritik, da es Zustellungsprobleme von legitimen E-Mails verursachen kann. Dies zeigt sich insbesondere im Zusammenhang mit Mailinglisten. Deswegen zögern viele große E-Mail-Anbieter, DMARC mit einer anderen Policy als ‚none‘ einzusetzen. Yahoo war 2014 der erste große Anbieter, der DMARC mit einer ‚reject‘-Policy aktiviert hatte. In der Folge kam es zu massenhaften, automatischen Abmeldungen von Teilnehmern von Mailinglisten.

Kompatibilität mit Mailinglisten

DMARC überprüft den From-Header der E-Mail und fordert die Übereinstimmung mit der bei SPF oder DKIM überprüften Domain (englisch alignment). Bei Mailinglisten, die Veränderungen an Kopfzeilen wie Absender, Empfänger oder Betreff vornehmen, führt dies zu Zustellproblemen der E-Mails. Die E-Mail muss unverändert weitergeleitet werden. Alternativ muss das Verhalten der Mailingliste geändert werden, was eine Software-Anpassung voraussetzt. Die Absenderangabe im From-Header der E-Mail muss durch eine Adresse der Mailingliste ersetzt werden und die DKIM-Signatur entfernt werden. Beispiel:

From: Nutzer <user@example.org>
Subject: ...
To: wikide-l@lists.wikimedia.org

müsste nach einer Veränderung durch die Mailinglistensoftware folgendermaßen abgeändert werden:

From: Nutzer via wikide-l <wikide-l@lists.wikimedia.org>
Subject: ...
To: wikide-l@lists.wikimedia.org

Die E-Mail-Adresse des wirklichen Absenders wird bei dieser Ersetzung komplett entfernt, so dass es nicht mehr möglich ist, den tatsächlichen Absender zu ermitteln oder mit dem Absender direkt in Kontakt zu treten. Eine Option besteht darin, dass die Mailingliste den ursprünglichen Absender in alternativen Kopfdaten wie den Reply-To-Header einfügt.

Um die Authentizität einer E-Mail nachzuweisen, die bei der Weiterleitung verändert wurde, beispielsweise durch eine Mailingliste, wurde das Verfahren Authenticated Received Chain (ARC) entwickelt. ARC ist speziell für die Anwendungsszenarien gedacht, wo DMARC fehlschlägt.

Normen und Standards

• RFC 7489 – Domain-based Message Authentication, Reporting, and Conformance (DMARC). März 2015 (englisch).

Weblinks

• dmarc.org – Offizielle Website
• Überblick. (PDF; 856 kB) dmarc.org (englisch).
• Geschichte Spezifikationserstellungsprozess. datatracker.ietf.org (englisch).