DMARC

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

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.[1]

Überblick[Bearbeiten | Quelltext bearbeiten]

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 Empfehlungen geben, auf welche Art der Empfänger mit einer Mail umgeht, die in einem oder beiden Fällen nicht den Anforderungen entspricht. 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-Richtlinie für eine Absender-Domain kann das Empfänger-Mailsystem einem Eintrag im Domain Name System (DNS) entnehmen.

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

Aufbau einer DMARC-Richtlinie[Bearbeiten | Quelltext bearbeiten]

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 Forensischer Report wird versandt an: optional URIs
rua Aggregierter Report 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 Hauptdomäne zu verfahren ist. notwendig "none", "quarantine", "reject"
sp Anweisung, wie mit Mails der Subdomäne zu verfahren ist. optional "none", "quarantine", "reject" Anweisung der Hauptdomäne
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 Domäne aufweist, wie im SPF-Record hinterlegt. Für DKIM wird gefordert, dass die Signatur gültig ist und zusätzlich die dort genannte Domäne 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 Domänen exakt übereinstimmen, bei 'relaxed' darf die From Kopfzeile auch eine Subdomäne enthalten. Über die Auswertung erhält der Sender einen täglichen Report an die genannte Adresse.

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.

Kritik[Bearbeiten | Quelltext bearbeiten]

DMARC überprüft den From-Header der E-Mails und stellt an diesen strenge Anforderungen (sog. „alignment“). Mailinglisten ist es dadurch nicht mehr möglich, Veränderungen an Kopfzeilen, wie Absender, Empfänger oder Betreff vorzunehmen. Die E-Mail muss unverändert weitergeleitet werden.[4] Alternativ muss die Absenderangabe im From-Header der E-Mail durch die Adresse der Mailingliste oder die eigene Adresse ersetzt, und die DKIM-Signatur entfernt werden.[5] 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, was aber ebenfalls zu Problemen führen kann. Eine Lösung für dieses Problem existiert nicht.

DMARC fordert Änderungen an jeder Mailinglisten- und Weiterleitungssoftware. Das Konzept von DMARC hat dementsprechend auch zu Problemen bei Mailinglisten geführt.[6]

Normen und Standards[Bearbeiten | Quelltext bearbeiten]

  • RFC 7489 – Domain-based Message Authentication, Reporting, and Conformance (DMARC), 2015

Weblinks[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. Draft Stand: 15. Juli 2013 im IETF Datatracker
  2. Golem-Artikel vom 30. Januar 2012
  3. Focus-Artikel vom 30. Januar 2012
  4. Mailinglisten DKIM-konform betreiben
  5. Nachrichten DMARC-konform mit Mailman verteilen
  6. Heise Newsletter: DMARC-Policy: Yahoo killt Mailinglisten-Mitgliedschaften