Email Authentication fĂŒr EmpfĂ€nger

Dokumentengeschichte

Titel Datum Verfasst durch KĂŒrzel

Email Authentication fĂŒr EmpfĂ€nger

30.05.2022

Sebastiaan de Vos

SdV

Version Datum Beschreibung KĂŒrzel

0.6

30.05.2022

Migration aus altem Repo nach Review von MW

PBK

0.5

15.04.2022

Termiologien (From-Header / Envelope)

SdV

0.4

14.04.2022

Detailkorrektur

MK, SdV

0.3

31.03.2022

Notizen ausformuliert

PBK

0.2

15.03.2022

Migration auf Asciidoc

PBK

0.1

14.03.2022

Erstes Draft

SdV

Das FĂ€lschen der Absenderadressen und damit das Vorspiegeln einer falschen IdentitĂ€t ist eine der hĂ€ufigsten Formen des Betrugs in Internet E-Mail. Indem Angreifer sich als jemand anderes ausgeben, wollen sie ihrem Opfer Informationen entlocken (z. B. Phishing) oder dieses dazu bewegen, eine fĂŒr die Angreifer nĂŒtzliche Handlung (z. B. CEO-Fraud) zu begehen. Dies fĂŒhrt auf Seiten der Opfer zu Misstrauen in E-Mail im Allgemeinen und es verursacht großen wirtschaftlichen Schaden fĂŒr Privatpersonen wie auch fĂŒr Unternehmen. In den vergangenen Jahren haben E-Mail Experten deshalb mehrere Methoden entwickelt, um diese Form des Missbrauchs einzudĂ€mmen.

Die drei wichtigsten Methoden werden kombiniert eingesetzt, um a) fĂŒr eine Envelope Sender Domain sendende Systeme zu legitimieren (SPF), b) die IdentitĂ€t einer Domain zu verifizieren (DKIM) und c) um eine Richtlinie (DMARC) festzulegen, wie mit Nachrichten verfahren werden soll, welche SPF und DKIM nicht gerecht werden, sowie um Reports ĂŒber den aktuellen Status möglichen IdentitĂ€tsmissbrauchs zu erhalten. Die drei genannten Methoden werden unter dem Begriff „Email Authentication“ zusammengefasst.

Email Authentication

Email Authentication kombiniert die Methoden von SPF, DKIM und DMARC zu einem Mechanismus mit dem eingehende Nachrichten auf ihre AuthentizitĂ€t geprĂŒft werden können. Die Methoden stellen fĂŒr sich genommen die folgenden Möglichkeiten zur VerfĂŒgung:

SPF

SPF gestattet zu erkennen, ob senden wollende Systeme legitimiert sind im Namen einer Envelope Sender Domain zu senden oder nicht und auch wie mit denen, die nicht legitimiert sind, verfahren werden soll.

DKIM

DKIM gestattet zu erkennen, ob eine Nachricht von der im DKIM-Signature:-Header angegebenen Domain signiert wurde und ob der body oder ausgewÀhlte Header der Nachricht verÀndert wurden.

DMARC

DMARC erfordert fĂŒr eine Nachricht eine erfolgreiche Authentifizierung per SPF oder DKIM der From:-Header Domain. DarĂŒber hinaus legt DMARC fest, welche Richtlinie bei Verletzungen von SPF und DKIM angewandt werden soll und ermöglicht durch Hinterlegung einer Kontaktadresse den Empfang von sog. Feedback Reports ĂŒber die Authentifizierungsergebnisse einer Domain.

Dieses Dokument betrachtet Email Authentication aus Sicht eines empfangenden Mailsystems. Es nennt Software und Konfigurationsbeispiele fĂŒr SPF, DKIM und DMARC, damit E-Mail vor der Annahme authentifiziert, IdentitĂ€tsmissbrauch erkannt und die EmpfĂ€ngerInnen vor missbrĂ€uchlichen Nachrichten geschĂŒtzt werden können. Ziel ist, nur Nachrichten zuzustellen, die den senderseitigen Richtlinien fĂŒr SPF, DKIM und DMARC gerecht werden.

Email Authentication fĂŒr Sender?

Es ist ebenso wichtig die eigene(n) Senderdomain(s) mit den Methoden von SPF, DKIM und DMARC zu legitimieren und fĂŒr andere verifizierbar zu machen. Bereits heute, in Zukunft aber noch viel mehr, wird die Zustellbarkeit eigener Nachrichten an fremde Systeme wesentlich von korrekter Email Authentication abhĂ€ngen.

Was dazu getan werden muss, wird aber nicht in diesem Dokument behandelt. Informationen hierzu finden sich z. B. auf https://certified-senders.org oder https://dmarc.org. Sie richten sich besonders an Sender und beschrÀnken sich vor allem darauf, wie DMARC konfiguriert werden sollte.

Die nachfolgenden Abschnitte zeigen, wie Sie mit Hilfe verschiedener Open Source Softwares die Richtlinien von SPF, DKIM und DMARC erkennen, auswerten und anwenden können.

Terminologien
Brief E-Mail Part Bezeichnung laut RFC Bezeichnung in dieses Dokument

Absender am Briefumschlag

Message Envelope

RFC5321.MailFrom

Envelope Sender

EmpfÀnger am Briefumschlag

Message Envelope

RFC5321.RcptTo

EmpfÀnger

Absender auf Brief

Message Header

RFC5322.From

From-Header

1. Risikobetrachtung

Dieser Abschnitt behandelt das Risiko von SPF, DKIM und DMARC fĂŒr eine verzögerte Zustellung sowie den Verlust legitimer Nachrichten.

Alle drei Methoden brauchen etwas Zeit, um ihre Aufgabe zu erfĂŒllen, aber die Verzögerung, die dabei entsteht, bewegt sich im Bereich von Millisekunden. Der grĂ¶ĂŸte Zeitfaktor besteht bei SPF in (potentiell sequentiellen) DNS-Abfragen und bei DKIM in einer DNS-Abfrage sowie einer Signatur-Verifikation. DMARC besteht nur aus einer DNS-Abfrage und wurde so konzipiert, dass der Einfluss auf die Zustellung so gering wie möglich bleibt:

Scalability is a major issue for systems that need to operate in a system as widely deployed as current SMTP email. For this reason, DMARC seeks to avoid the need for third parties or pre-sending agreements between senders and receivers. This preserves the positive aspects of the current email infrastructure.

— RFC 7489
Abschnitt 2.3

FĂŒr das Risiko des Nachrichtenverlusts ist es wichtig, die Grundidee von DMARC zu verstehen: DMARC veröffentlicht Richtlinien fĂŒr den Umgang von VerstĂ¶ĂŸen gegen SPF und DKIM. Hierbei erfordert DMARC, dass eine E-Mail mit mindestens einer der beiden Methoden, SPF oder DMARC, konform ist. Falls beide Methoden fehlschlagen, so gilt eine E-Mail als nicht authentisch.

Wenn ein Angreifer eine fremde Domain fĂŒr einen illegitimen Nachrichtenversand missbraucht, wird dies im Regalfall dazu fĂŒhren, dass bei der Nachricht sowohl die SPF- als auch die DKIM-PrĂŒfung fehlschlĂ€gt. Die Frage auf EmpfĂ€ngerseite ist nun, wie mit diesen „Fehlern“ verfahren werden soll.

An dieser Stelle setzt die Policy an, die DMARC mit Hilfe des p-tags im DMARC-Eintrag im DNS der From-Header Domain veröffentlicht. Drei Werte sind fĂŒr das p-tag zulĂ€ssig:

none

Ist none gesetzt, fordert die im From:-Header angegebene Senderdomain, dass nichts unternommen werden soll, wenn es zu VerstĂ¶ĂŸen gegen SPF und DKIM kommt.

quarantine

Ist quarantine gesetzt, fordert die im From:-Header angegebene Senderdomain, dass die Nachricht zwar angenommen, aber nicht direkt in die Mailbox zugestellt, sondern in QuarantÀne, z. B. den SPAM-Ordner, gelegt werden soll.

reject

Ist reject gesetzt, fordert die im From:-Header angegebene Senderdomain, dass die Annahme der Nachricht verweigert und diese nicht zugestellt werden soll.

Dieser Mechanismus ist einfach und er funktioniert schnell und zuverlĂ€ssig. Er kann aber dazu fĂŒhren, dass auch legitime Nachrichten abgelehnt wĂŒrden, wenn eine Senderdomain (temporĂ€r) selbst ihre DMARC-Richtlinie nicht aufrecht erhĂ€lt.

Friendly fire?
  • Gerade in grĂ¶ĂŸeren Organisation kommt es immer wieder vor, dass Mailsysteme rechtmĂ€ĂŸig E-Mails im Namen der Organisation versenden, diese dazu aber nicht per SPF legitimiert wurden. Dies ist dann der Fall, wenn die IP-Adressen des verwendeten Mailsystem nicht in dem SPF-Eintrag der Envelope Sender Domain vorkommen. [1].

  • Auch kommt es vor, dass das öffentliche DKIM-SchlĂŒsselmaterial im DNS der DKIM-signierenden Domain (entspricht im Regelfall der From:-Header Domain) falsch eingegeben oder ĂŒbertragen wurde und in der Folge, obwohl der private SignierschlĂŒssel valide ist, die Verifizierung der DKIM-Signatur fehlschlĂ€gt.

  • Ihr Mailsystem sendet eine legitime Nachricht an eine Mailingliste, die diese Nachricht auf eine nicht mit DMARC kompatible Weise weiterverteilt. Ein typisches Problem ist es, wenn die Mailingliste den From:-Header unverĂ€ndert beibehĂ€lt, dabei jedoch die DKIM-Signatur entweder entfernt oder durch Modifikation der Nachricht invalidiert.

Diese drei beispielhaft genannten Szenarien zeigen, wie eine DMARC reject-Policy die Zustellung legitimer Nachrichten gefÀhrdet.

In den ersten beiden FĂ€llen wĂ€re es Aufgabe der Senderdomain, die SPF- und DKIM-Konfiguration zu korrigieren und mit DMARC-Montoring darauf zu achten, dass keine eigenen Konfigurationsfehler fĂŒr Zustellprobleme sorgen. FĂŒr den zuletzt genannten Fall ist es Aufgabe der Mailingliste, den Nachrichtenversand DMARC-konform durchzufĂŒhren. Des Weiteren wurde ein Verfahren namens ARC entwickelt, um die AuthentizitĂ€t einer Nachricht ĂŒber mehrere Instanzen hinweg zu transportieren. ARC ist jedoch in einem experimentellen Stadium und hat sich deshalb noch nicht etabliert.

Als EmpfĂ€nger können Sie optional Ausnahmen konfigurieren, um aus Ihrer Sicht legitime und vertrauenswĂŒrdige Mailsysteme von der SPF-, DKIM- und DMARC-PrĂŒfung auszunehmen. Des Weiteren sollten Sie DMARC-Reports versenden, damit Sender, deren Nachrichten gegen ihre eigene DMARC-Richtlinie verstoßen, davon erfahren und dies korrigieren können.

2. Die richtige Software

Um es vorweg zu sagen: Die eine Software, die alles perfekt kann, existiert nicht. Je nach Anwendungsfall passt sich aber die eine oder andere Software besser in Ihre Dienstarchitektur ein.

Wenn Sie eine modulare Architektur bevorzugen oder einen Maildienst betreiben, der auf mehrere Instanzen oder gar Maschinen verteilt ist, eignet sich Software, die auf einen Aspekt beschrĂ€nkt ist wie z. B. SPF verifizieren, DKIM authentifizieren, DMARC-Richtlinien anwenden und Feedback Reports generieren, besser als eine monolitische Anwendung. FĂŒr diesen Anwendungsfall eignen sich die folgenden Software-Produkte:

Modulare Software

Wenn Sie hingegen eine All-in-One-Lösung wĂŒnschen oder einen Maildienst betreiben, der alles in einem Server vereint, eignet sich ein Monolith besser. FĂŒr diesen Anwendungsfall stehen die folgenden Software-Produkte zur VerfĂŒgung:

Monolitische Software

Alle genannten Softwares unterliegen einer Open-Source-Lizenz und setzen ein Linux oder ein anderes Unix-oide Betriebssystem zur AusfĂŒhrung voraus. Die nachfolgenden Abschnitte zeigen, wie sie fĂŒr die verschiedenen Aufgabenstellungen konfiguriert werden.

3. DMARC prĂŒfen

Die PrĂŒfung einer eingehenden Nachricht gegen eine DMARC-Richtlinie besteht aus folgenden PrĂŒfschritten:

  1. Ob das sendende Systeme durch die SPF-Policy der Envelope Sender Domain legitimiert wurde.

  2. Ob die Nachricht eine DKIM-Signatur in sich trÀgt und ob diese erfolgreich verifiziert werden kann.

  3. Ob die From:-Header Domain eine DMARC-Policy veröffentlicht hat und ob die SPF- oder DKIM-PrĂŒfung fĂŒr die From:-Header Domain erfolgreich war.

Ist dies der Fall, steht aus Sicht der DMARC-Policy einer Annahme der Nachricht nichts entgegen. Verletzen das sendende Systeme oder die Nachricht hingegen die DMARC-Policy, so soll das empfangende System die DMARC-Policy-Vorgaben bei Verletzungen umsetzen.

Diese drei Aufgabenkomplexe – SPF, DKIM und DMARC – können nacheinander von Software-Modulen oder innerhalb einer Software bearbeitet werden. UnabhĂ€ngig davon welche Architektur Sie wĂ€hlen, werden die Programme einen Authentication-Results:-Header in die geprĂŒfte Nachricht eintragen – er listet die verschiedenen PrĂŒfergebnisse:

mx.example.com dokumentiert die PrĂŒfergebnisse von sender@example.net
Authentication-Results: mx.example.com;
	dkim=pass header.d=example.net header.s=202203-example.net header.b=dhpvJqM6;
    dmarc=pass (policy=reject) header.from=example.net;
	spf=pass (mx.example.com: domain of sender@example.net designates 192.2.0.1 as permitted sender) smtp.mailfrom=sender@example.net
PrĂŒfungsergebnisse fĂ€lschen

Ein Angreifer, der bewusst E-Mails mit gefĂ€lschten Absender-Adressen in Umlauf bringt, um Betrug zu begehen, wird auch versuchen SPF, DKIM und DMARC zu unterlaufen, indem er selbst in die E-Mails gefĂ€lschte „PrĂŒfergebnisse“, in Form eines Authentication-Results:-Header einschleust.

Diese Betrugsversuche können unterbunden werden, indem fĂŒr die eigenen Programme festgelegt wird, welchen Authentication-Results:-Headern sie trauen und welche sie ignorieren sollen. Dies geschieht indem ein Host oder eine Domain benannt wird, welchen die Programme vertrauen sollen.

In den nachfolgenden Beispielen wird immer example.com bzw. eine Subdomain dieser Domain verwendet. Passen Sie die Domain entsprechend der Domain Ihrer eigenen Mailplattform an.

3.1. Modulare Verarbeitung

Zur modularen Verarbeitung werden die Softwares OpenDKIM und OpenDMARC nacheinander ĂŒber die MILTER-Schnittstelle des MTA in die Verarbeitung eingehender Nachrichten eingebunden. Dabei ĂŒbernimmt OpenDMARC zwei Aufgaben – jene der SPF-Legitimation und jene der DMARC-Policy-PrĂŒfung.

Der DMARC-Standard schreibt nur eine SPF-PrĂŒfung zwingend vor und betrachtet das Anbringen gĂŒltiger DKIM-Signaturen als optional. Deshalb ist es praktisch, beide Aufgaben von einer Applikation (hier: OpenDMARC) abarbeiten zu lassen.

Aber die Bedeutung von IP-Adressen in Reputationssystemen lĂ€sst, nicht zuletzt wegen cloud-basierter Maildienste und deren wechselnden IP-Adressen, stetig nach und so empfiehlt die Kompetenzgruppe „E-Mail“ des eco-Verbandes in jedem Fall immer auch DKIM-Signaturen als „zweites Pfand“ mit anzubringen und auf diese bei der Annahme von Nachrichten, im vorliegenden Fall mit OpenDKIM, zu prĂŒfen.

3.1.1. OpenDKIM

OpenDKIM kann die DKIM-Signaturen eingehender Nachrichten verifizieren und es kann DKIM-Signaturen auf ausgehende Nachrichten anbringen. Das Programm steht in allen gĂ€ngigen Linux-Distributionen zur VerfĂŒgung und sein Verhalten wird fĂŒr gewöhnlich ĂŒber die Datei /etc/opendkim.conf gesteuert.

Das nachfolgende Beispiel konfiguriert OpenDKIM sich mit Hilfe des Socket-Parameters lokal an die IP-Adresse 127.0.0.1 auf dem TCP-Port 8892 zu binden, dort auf eingehende Nachrichten zu warten und deren DKIM-Signaturen - so vorhanden - zu verifizieren.

/etc/opendkim.conf
Syslog        true
Socket        inet:8892@127.0.0.1
AuthservID    mx.example.com         (1)
Mode          v                      (2)
1 Der Parameter AuthservID legt fest, welche IdentitĂ€t OpenDMARC verwendet, wenn es seine PrĂŒfergebnisse in einen Authentication-Results:-Header eintrĂ€gt.
2 Der Parameter Mode legt mit der Option v, dass OpenDKIM E-Mails verifizieren soll.

3.1.2. OpenDMARC

OpenDMARC prĂŒft ob eingehende Nachrichten konform mit der DMARC-Policy der From-Header Domain sind, generiert optional DMARC-Reports und prĂŒft (ebenso optional) ob sendende Server entsprechend der SPF-Policy der Envelope Sender Domain zum Senden im Namen dieser Domain legitimiert sind. Eine detailierte Funktionsbeschreibung stellt das Trusted Domain Project zur VerfĂŒgung, welches OpenDMARC entwickelt und veröffentlicht.

OpenDMARC Milter muss nach OpenDKIM als MILTER in den MTA eingebunden werden. Die DKIM-PrĂŒfung muss abgeschlossen und ein Authentication-Results:-Header eingetragen sein wenn OpenDMARC auf SPF und DMARC zu prĂŒfen beginnt.

Das Verhalten der Applikation wird fĂŒr gewöhnlich mit Hilfe der Konfigurationsdatei /etc/opendmarc.conf gesteuert. Im nachfolgenden Beispiel wird OpenDMARC konfiguriert, sich lokal an die IP-Adresse 127.0.0.1 auf dem TCP-Port 8893 zu binden, dort auf eingehende Nachrichten zu warten, eine SPF-PrĂŒfung vorzunehmen, den Authentication-Results:-Header, welchen das vorangeschaltete OpenDKIM bereits eingefĂŒgt hat, auszuwerten und anschließend die – so vorhanden – DMARC-Policy der From-Header Domain zu prĂŒfen.

/etc/openmarc.conf
Syslog                true
Socket                inet:8893@127.0.0.1          (1)
AuthservID            mx.example.com               (2)
TrustedAuthservIDs    mx.example.com               (3)
SPFSelfValidate       true                         (4)
RejectFailure         yes                          (5)
1 OpenDMARC kann mittels inet- als auch ĂŒber einen local-Socket vom MTA angesprochen werden.
2 Die Option AuthservID legt fest welche IdentitĂ€t OpenDMARC verwendet, wenn es seine PrĂŒfergebnisse in einen Authentication-Results:-Header eintrĂ€gt.
3 Diese Option legt fest, welchen bereits vorhandenen Authentication-Results:-Headern OpenDMARC vertraut und welche es widerum ignoriert. Die IdentitĂ€t des in diesem Abschnitt vorgeschalteten OpenDKIM muss hier gelistet sein, damit OpenDMARC dessen PrĂŒfergebnisse in seine DMARC-Policy-PrĂŒfung mit einbezieht.
4 Mit SPFIgnoreResults true wird die SPF PrĂŒfung immer von OpenDMARC vorgenommen. Mit SPFSelfValidate true wird SPF nur von OpenDMARC geprĂŒft, wenn sonst keine SPF-PrĂŒfung im Authentication-Result:-Header vorhanden ist.
5 Opendmarc lehnt ohne weitere Konfiguration gar keine Mails ab. Dazu muss man explizit RejectFailure yes setzen.

3.2. Monolithische Verarbeitung

Monolithische Verarbeitung bedeutet alle Verarbeitungschritte fĂŒr SPF, DKIM und DMARC finden in einer Applikation statt. Die populĂ€rste Software dafĂŒr stellt das Programm rspamd dar.

3.2.1. rspamd

rspamd ist mehr als nur ein Programm, um E-Mail Authentication durchzufĂŒhren. Begonnen als hochperformanter Ersatz fĂŒr die Software SpamAssassin wurde rspamd mit der Zeit zu einer All-In-One-Lösung erweitert. Es bietet viele Filter-Funktionen und wird laufend aktualisiert und erweitert.

Bereits im Auslieferungszustand prĂŒft rspamd, ob eine From-Header Domain ĂŒber eine DMARC-Policy verfĂŒgt und vermerkt die PrĂŒfergebnisse im Header der entsprechenden E-Mail, aber es fĂŒhrt nicht die mit der DMARC-Policy verbundenen Aktionen aus. Aktivieren Sie diese Aktionen mit folgender Konfiguration:

/etc/rspamd/local.d/dmarc.conf
actions = {
	quarantine = "add_header";
	reject = "reject";
}

4. DMARC Feedback Reports versenden

E-Mail-EmpfĂ€nger tun durch den Versand von DMARC Feedback Reports den Teilnehmern des DMARC-Ökosystems Gutes, indem sie RĂŒckmeldung zur SPF- / DKIM- / DMARC-KonformitĂ€t ihrer Maildomain geben. Feedback Reports melden möglichen IdentitĂ€tsmissbrauch sowie mögliche DMARC-Konfigurationsfehler, wovon die StabilitĂ€t des gesamten Ökosystems profitiert.

Ziel der DMARC-Policy einer From-Header Domain ist letztlich immer, das Policy-Level auf entweder quarantine oder reject zu setzen. Nur dann ist ein Schutzniveau gegeben! Das niedrigste Policylevel none ist der ungefĂ€hrlichen Erprobung der SPF- und DKIM-Einstellungen vorbehalten. Es wird fĂŒr gewöhnlich solange gesetzt bis die From-Header Domain ein „strict alignment“ seiner E-Mails erreicht hat und dann iterativ restriktiver gefasst.

Besonders in dieser Erprobungsphase ist es fĂŒr Versender wichtig, DMARC Feedback Reports zu erhalten. Die Außensicht auf das Sendeverhalten ihrer Domain macht fĂŒr sie sichtbar, ob noch Anpassungen an ihrer SPF-Policy erforderlich sind und / oder ob DKIM-Signaturen sauber validieren.

DMARC Feedback Reports werden von der empfangenden Mailplattform an eine oder mehrere E-Mail-Adressen, die in der DMARC-Policy der From-Header Domain vermerkt sind, versendet. Dabei unterscheidet der DMARC-Standard zwei Arten von DMARC Feedback Reports:

"Forensic" / "Failure" Reports

„Forensic Reports“ sind ausfĂŒhrliche Reports, die je festgestelltem Verstoß gegen eine DMARC-Policy versendet werden. Aus Sicht des Datenschutzes kann es dabei passieren, dass ein solcher Report personenbezogene und damit schĂŒtzenswerte Informationen weitergibt, weswegen Forensic Reports umstritten sind. Diese Art Report ist im sog. AFRF-Format verfasst und wird an die mit dem ruf-Tag im DMARC DNS TXT-Record angegebene(n) Adresse(n) gesendet.

"Aggregated" Reports

Ein „Aggregated Report“ fasst die Ereignisse, welche eine Senderdomain mit DMARC-Policy betreffen, in einem bestimmten Zeitintervall (empfohlenerweise tĂ€glich) in aggregierter Form zusammen. Der Report wird als komprimierte XML-Datei erstellt und an die in dem rua-Tag im DMARC DNS TXT-Record angegebene(n) Adresse(n) versendet.

Das Versenden von Aggregated Reports ist ein zweiteiliger Vorgang: Zuerst werden die DMARC-PrĂŒfergebnisse gesammelt und dann, zu einem bestimmten Zeitpunkt, werden daraus Reports generiert und versendet. Die nachfolgenden „Best Practices“ fĂŒr den Versand basieren auf Empfehlungen und Erfahrungen der KG „E-Mail”.

4.1. Best Practices fĂŒr den Versand

Wenn Ihr Report-Dienst Benachrichtigungen ĂŒber möglichen Missbrauch einer Senderdomain versendet, mĂŒssen EmpfĂ€nger ihm vertrauen können und ihr Dienst muss mit den teils personenbezogenen Daten vertrauensvoll umgehen. Wir empfehlen deshalb die nachfolgenden Maßnahmen:

  1. Vermeiden Sie, Failure Reports zu versenden. Unter UmstĂ€nde kann das Versenden von Failure Reports sogar gesetzlich problematisch sein, da in Failure Reports personenbezogene Daten, wie zum Beispiel die EmpfĂ€nger-E-Mail-Adresse oder der Betreff, genannt werden. Der Report on the compliance of DMARC with the EU GDPR, den die eco Kompetenzgruppe „E-Mail” als Rechtsgutachten in Auftrag gegeben hatte, zeigt im Detail an welchen Stellen Failure Reports DSGVO-konform sind und wo sie diese mit der DSGVO unvereinbar verletzen.

  2. Verwenden Sie als Versanddomain fĂŒr Reports immer eine separate Domain oder Subdomain, damit das Sendeverhalten dieser (Sub)Domain nicht die Reputation Ihrer Hauptdomain negativ beeinflusst (denn Reports enthalten IP-Adressen - oder bei Failure Reports sogar Inhalte - von Spammern/Phishern).

  3. Verwenden Sie eine eigene, dedizierte IP-Adresse fĂŒr den Versand der Reports, denn auch diese IP-Adresse könnte eine schlechte Reputation erhalten.

  4. Versehen Sie die Reports mit einer DKIM-Signatur, damit EmpfĂ€nger zweifelsfrei nachvollziehen können, dass der Report von Ihrem Dienst stammt und dieser so ĂŒber Zeit eine gute Reputation aufbauen kann.

  5. Erstellen Sie eine eigene DMARC-Policy fĂŒr die Report-(Sub)Domain und fordern Sie fĂŒr diese (Sub)domain weder „Failure Reports“ noch „Aggregated Reports“ an, damit zwischen Ihrer Report-Domain und anderen Mailplattformen keine Report-Endlosschleife entstehen kann.

  6. Wenn Ihr Maildienst aus mehreren Mailservern besteht, die alle Reports senden sollen, dann setzen Sie nur einen Report-Dienst fĂŒr alle Server ein. Sammeln Sie die Report-Daten zentral in einer Datenbank und lassen Sie den Report-Dienst die „Aggregated Reports“ auf Grundlage aller dort abgelegten Informationen generieren.

  7. Lassen Sie Ihren Report-Dienst nur einmal tĂ€glich „Aggregated Reports“ versenden. Senden Sie nicht exakt um 00:00 Uhr, denn das weltweit entstehende Report-Aufkommen kommt fĂŒr die empfangende Plattform sonst einer DDoS-Attacke gleich.

  8. Rechnen Sie mit Backscatter! Manche EmpfĂ€nger nehmen Reports an und reagieren auf diese schon wenige Sekunden spĂ€ter mit einer Bounce-Mail oder einer Zustellbenachrichtigung (DSN). Überlegen Sie wo diese vielen Mails landen sollen.

  9. Ein merklicher Anteil an im rua-tag benannten EmpfĂ€ngeradressen benennt Mailboxen fĂŒr die das Zielsystem keine Nachrichten annimmt. Die Reports werden in der Mail-Queue ihres MTA verbleiben bis sie bouncen. Reports, die nicht zugestellt werden können, sollten Sie löschen und die EmpfĂ€ngeradressen möglicherweise von der Zustellung ausnehmen.

  10. Das sendende eigene Postfach sollte genug Ratelimit haben, damit die Reports alle versendet werden können. Oft werden Tausende Reports innerhalb von Sekunden versendet.

4.2. DMARC Feedback Reports mit OpenDMARC

OpenDMARC sammelt Daten, die es fĂŒr Reports nutzen wird, in einer Datei. Der Pfad zu dieser Datei wird mit Hilfe des Parameters HistoryFile spezifiziert. Die Datei selbst muss fĂŒr den User, mit dem OpenDMARC betrieben wird, les- und schreibbar sein.

„Failure Reports“ leiten Sie am besten zu sich selbst um:

/etc/opendmarc.conf
CopyFailuresTo        postmaster@mx.example.com
FailureReportsSentBy  postmaster@mx.example.com
FailureReports        yes
FailureReportsOnNone  true
ReportCommand         /usr/sbin/sendmail userpart@sub.domain.tld    (1)
FailureReportsBcc     localpart@example.net                         (2)
1 Geben Sie hier nicht sendmail -t an
2 Senden Sie (dennoch) „Failure Reports“, können Sie mit FailureReportsBcc diese immer auch an sich selbst senden und so mitverfolgen was berichtet wird.
OpenDMARC Multi-Host Reporting

Wenn Ihre Mailplattform mehrere Server einsetzt, die jeweils separate OpenDMARC-Instanzen einbinden, sollten Sie deren Daten an zentraler Stelle sammeln und die Reports zentral generieren lassen. Dies erleichtert dem Report-EmpfÀnger die Auswertung.

Erstellen Sie dazu einen cronjob / systemd timer und lassen Sie das Programm opendmarc-import die Daten jeder OpenDMARC-Instanz periodisch in eine zentrale Datenbank schreiben:

% opendmarc-import --dbhost=hostname --dbname=name --dbpasswd=password --dbport=port

Erstellen Sie dann einen zweiten cronjob / systemd timer und lassen Sie das Programm opendmarc-reports zentral reports generieren und versenden. Das Intervall, in dem Reports generiert und versendet werden, steuern Sie mit interval=secs. Wenn Sie die Reports nicht lokal, sondern ĂŒber einen bestimmten anderen Server versenden wollen, geben Sie diesen mit den Parametern smtp-host und smtp-port an.

4.3. DMARC Feedback Reports mit rspamd

rspamd sammelt Daten, die es fĂŒr Reports nutzen wird, in einer oder mehreren redis-Datenbanken. Das Generieren und Versenden von Reports mĂŒssen Sie explizit aktivieren, indem Sie den Abschnitt reporting in der Datei /etc/rspamd/local.d/dmarc.conf aktivieren und konfigurieren:

/etc/rspamd/local.d/dmarc.conf
servers = "192.2.0.1:6379";                 (1)
reporting {
    enabled = true;
    email = 'dmarc_reports@sub.example.com';    (2)
    domain = 'example.com';                 (3)
    org_name = 'Example organisation';      (4)
    bcc_addrs = ["postmaster@example.com"]; (5)
    smtp = '127.0.0.1';                     (6)
    smtp_port = 25;                         (7)
    from_name = 'example.com DMARC report'; (8)
    helo = 'example.com';                   (9)
    msgid_from = 'example.com';             (10)
}
1 Hier können Sie bei Bedarf, abweichend von der zenralen redis-Konfiguration fĂŒr rspamd, festlegen in welche redis-DB DMARC-Report-Daten geschrieben werden sollen.
2 Hiermit legen Sie fest mit welcher Envelope Sender Adresse rspamd die Reports versenden wird.
3 Die EmpfÀngerdomain in deren Namen die Reports generiert werden.
4 Geben Sie hier den Namen ihrer Organisation an.
5 Wenn Sie die Reports zusÀtzlich immer auch an andere Adressen versenden wollen, können Sie hier eine Liste von Adressen spezifizieren
6 Dieser Parameter legt den SMTP-Server fest, der fĂŒr den Versand kontaktiert werden soll
7 Dieser Parameter legt den TCP-Port des SMTP-Servers fest, der fĂŒr den Versand kontaktiert werden soll
8 Dieser Parameter legt den Anzeigenamen des Absenders fest (Standard ist: "Rspamd")
9 HELO im SMTP Dialog
10 Message-Id Format

Sobald rspamd DMARC-PrĂŒfergebnisse gesammelt hat, können Sie damit beginnen, diese in Reports zu versenden. Erstellen Sie dazu einen cronjob / systemd timer, welcher periodisch die Daten des Vortags (!) auswertet und als Reports versendet:

% 27 3 * * * rspamadm dmarc_report
rspamd Multi-Host Reporting

Wenn Ihre Mailplattform mehrere Server einsetzt, die jeweils eigene rspamd-Instanzen einbinden, sollten Sie deren Daten an zentraler Stelle sammeln und die Reports zentral generieren. Dies erleichtert dem Report-EmpfÀnger die Auswertung.

Konfigurieren Sie alle rspamd-Instanzen so, dass diese ihre Report-Daten an die zentrale redis-Datenbank senden und lassen Sie nur auf einem Host den cronjob / systemd timer ausfĂŒhren, der periodisch Reports generiert und versendet.


1. Ein fachkundiger E-Mail-Dienstleister wird vor dem Newsletter-Versand prĂŒfen, ob SPF, DKIM und DMARC stimmen, auf mögliche Probleme aufmerksam machen und Lösungswege aufzeigen.