Mailingliste mit DMARC, DKIM, SPF, ARC

Auf dieser Seite beschreibe ich die Besonderheiten beim Einsatz von DMARC, DKIM und SPF in Verbindung mit drei oder mehr Stationen, wie Sie bei der Verwendung von Mailinglisten und Verteilern gerne passieren. Leider gibt es viele Produkte aber auch Konfigurationen, die Probleme machen.

SPF, DKIM und DMARC funktionieren im Grunde schon und ich möchte hier eine Lanze für "DMARC:p=reject" und "SPF:-all" brechen. Siehe dazu auch DMARC bricht SPF mit SRS

Ausgangssituation

Wenn zwei Firmen miteinander kommunizieren, dann möchte man sicher sein, dass der Absender wirklich authentisch ist. Ein sicherer Weg wäre natürlich eine Signierung der Mail per SMIME/PGP, aber leider setzt sich diese Option nicht wirklich durch. Aber die Administratoren von Mailservern haben sich natürlich auch überlegt, wie so eine Prüfung besser gelingen kann und in dem Zuge haben sich drei Begriffe und RFCs entwickelt, die ich hier nur kurz zusammenfasse.

C:\>nslookup -q=TXT _spf.netatwork.de 
Antwort: _spf.netatwork.de text = "v=spf1 
                                   +mx:netatwork.de 
                                   +ip4:80.66.20.18 +ip4:80.82.206.0/26 
                                   include:spf.protection.outlook.com 
                                   -all" 

DKIM-Signature: v=1; c=relaxed/relaxed; d=Netatwork.de; s=key1; t=1597183513; 
 bh=<gekürzt>; h=  "Subject:Subject:From:From:Date:Date:ReplyTo:ReplyTo:Cc:Cc:Message-Id:Message-Id"; 
 a=rsa-sha256;b=<gekürzt>

C:\>nslookup -q=TXT key1._domainkey.netatwork.de

key1._domainkey.netatwork.de    text =
        "v=DKIM1; k=rsa; t=s; p=<gekürzt>"

C:\>nslookup -q=TXT _dmarc.netatwork.de
_dmarc.netatwork.de     text = "v=DMARC1; p=reject; rua=mailto:be750dfe@mxtoolbox.dmarc-report.com; fo=1; adkim=s; aspf=s; rf=afrf; sp=none"

Alle Systeme sind natürlich angreifbar, da z.B. DNS-Einträge erst mit DNSSEC gegen Spoofing und Fälschungen abgesichert werden und das ganze System natürlich kein Schutz gegen "ähnlich klingende Domains". Als Betreiber von "netatwork.de" kann ich ich keinen Schutz gegen "metatwork.de" vorgeben. Auch gibt es immer noch Firmen, die DKIM nicht nutzen und DMARC nicht als "reject" konfigurieren. Zudem gibt es Empfänger wie Exchange Online Protection, die ein "Reject" durch ein "Quarantine" uminterpretieren. Spamfilter haben also weiterhin ihre Berechtigung.

Solange ein Absender direkt den Empfänger anschreibt, funktioniert sogar SPF aber sobald die Mail erneut gesendet wird, wird es knifflig. Mehrere Fälle sind hier zu berücksichtigen.

Die weiteren Fälle betrachte ich unter der Prämisse, dass der Empfänger DMARC respektiert und der Absender eine strenge Prüfung mit "p=reject" vorgibt.

Mailingliste/Verteiler/Umleitung

Der erste Fall stellt die Nutzung einer Verteilerliste oder Mailingliste dar. Dieser Fall ist gar nicht so selten, auch wenn es mittlerweile mit Microsoft Teams, Web-Foren, Facebook-Gruppen, LinkedIn-Gruppen u.a. ganz neue Möglichkeiten der Kommunikation in Gruppen gibt. Speziell ist "alten Hasen" mit langem Internet-Background nutzen immer noch intensiv solche Mailverteiler zur Diskussion.

• SecLists.Org Security Mailing List Archive
  https://seclists.org/
• Linux kernel mailing list
  https://en.wikipedia.org/wiki/Linux_kernel_mailing_list

Das Grundprinzip ist dabei immer gleich: Der Absender sendet die Mail an die Adresse der Mailingliste und die Liste verteilt die Mails dann weiter. Für das Mail-Routing wird die "RCT-TO-Adresse im "Envelope" genutzt. Der Absender auf Host A sendet an Host B, welcher dann die Mail an einen Teilnehmer auf Host C weiterleitet. Host A und B haben beide eine strenge SPF-Policy.

Es gibt zwei häufig verwendete Varianten, wie die Zwischenstation die Mails ans Ziel verändert. Interessant sind hier immer die "Absender", d.h. der Envelope-From und der "Header-From". Der "gelbe" Teil des Envelope bekommen Anwender nie zu sehen und daher ist diese Änderung zwar wichtig, damit z.B. SPF korrekt ermittelt werden kann, aber für den Anwender nicht relevant. Nicht extra aufgeführt habe ich weitere Felder wie "ReplyTo", womit eine "Antwort" auf die Mail gesteuert werden kann. Hier die Tabelle, wen eine Mail vom Server B mit der IP-Adresse IP2 an den Server C zugestellt wird.

Header-From = A

Wenn der für den Empfänger sichtbare Absender der Mail der originale Autor ist, dann ergibt sich folgende Tabelle

Die Tabelle enthält nicht alle möglichen Permutationen.

Weiterleitung

Ein andere Szenario ist die "Weiterleitung" einer Mail von B nach C. Dieser Fall ist bei Migrationen und Umzügen recht häufig. Das kann sie im privaten  Bereich betreffen, wenn Sie ihren Mailprovider oder Domäne wechseln und z.B.: jede Mail an ihr GMX-Postfach an ihr neues Postfach weiterleiten wollen. All diese Fälle bedeuten aber, dass die Mail erst einmal im Postfach "B" abgelegt wird und dann Regeln oder Agenten aktiv werden, welche die Mail dann wieder weiter senden.

In all diesen Fällen wird aber "B" der Absender sein und die Information über A maximal im Body der Mail erscheinen. Es ist also eine neue Mail mit einer neuen MessageID und entspricht der Tabelle "HeaderFrom=B" mit dem EnvelopeFrom = B.

Backup-MX

Früher gehörte die Bereitstellung eines Backup-MX zum guten Ton. Internet-Leitungen waren langsam und weniger stabil. Daher hat der Provider die Mail für den Kunden schon mal angenommen und dann an den Kunden weiter geleitet. Der Backup-MX verändert hier natürlich weder den Header-From noch den Envelope-From oder sonst was in der Mail. Er addiert allerdings einen "Received"-Eintrag, der aber bei SPF nicht von Belang ist und bei DKIM nicht einbezogen werden sollte.

Der Absender kennt  natürlich nicht die IP-Adresse mit welcher der Backup-MX-Server die Mails an das Zielsystem weiter gibt, so dass ein "SPF:-all" hier die Zustellung blockieren könnte. Als Empfänger sollten Sie also sicherstellen, dass Sie ihrem Provider vertrauen und für Mail von diesem System keine SPF-Prüfung erzwingen, selbst wenn DMARC dies fordert.

Unglücklicherweise kann ihr eigener Spamfilter dann nicht mehr viel tun als auf Viren zu scannen. Der Spamfilter beim Provider sollte also identisch zu ihren Einstellungen konfiguriert sein.

Heute wird diese Konfiguration mit einem Backup-MX beim Provider nicht mehr neu eingerichtet aber ich bin sicher, dass es noch sehr viele Bestandinstallationen gibt, die dann über "Probleme" beim Empfang von Absendern mit einer "SPF:-all"-Policy klagen

Wenn der Empfänger hier DKIM prüft und DMARC korrekt beachtet, dann löst sich das Problem auch indirekt, da eine gültige DKIM-Signatur durch den Absender mit der "Header-From"-Adresse in der Regel einen SPF-Fail überstimmt.

Web-Formular u.a.

Zuletzt sollten Sie ihre eigenen Lösungen prüfen, die vielleicht "im Namen eines Benutzers" senden. Beliebt sind Formulare auf eigenen Webseiten, in die Besucher ihre Mailadresse eintragen. Wenn das Formular dann die Daten per Mail an ein internes System sendet und dabei den Absender aus dem Formularfeld als "Mail-From"-Adresse verwendet, dann sollte ihr Mailserver dem Webserver vertrauen. Steht der Webserver bei einem Hoster und die Mail geht an ihr Mailsystem an einem anderen Standort, dann könnte ein Spamfilter dieser gewünschte Kundenmail ansonsten verwerfen.

Das Problem dabei ist, dass es wieder nur die Domains betrifft, die ein "p=reject" hinterlegt haben und ihr Spamfilter dies berücksichtigt. Da aber die überwiegende Anzahl an Domains dies noch nicht hat, ist das Fehlerbild diffus. Nur Mails einiger Domänen kommen nicht an und Sie merken davon auch nichts. Der Fehler liegt aber beim Betreiber bzw. Entwickler des Formulars, der die notwendigen Freischaltungen nicht beantragt hat.

Was machen viele falsch

Der erste Fehler ist, SPF, DKIM und DMARC nicht einzusetzen. Wenn sie sich den Luxus erlauben, einen eigenen Mailserver zu betreiben und diese Basisfunktion nicht Microsoft, Google oder einem anderen Provider überlassen, dann müssen Sie sich auch seriös mit den Themen beschäftigen. Die einzigen, die es schwerer haben, sind Spammer, Phisher etc.

SPF, DKIM, DMARC ist kein Allheilmittel gegen Spam. Auch böse Personen können eigene "Vertipper"-Domains entsprechend absichern. Aber es hilft sehr gut.

• Absender
  Als Versender können Sie durch korrekte Konfiguration von SPF, DKIM und DMARC dafür sorgen, dass ihre Mails besser und zuverlässiger zugestellt werden. Die Empfängerseite kann so viel besser eingehende Mails bewerten und verifizieren
• Empfänger
  Wenn ihr System SPF, DKIM und DMARC auswertet, kann es sehr zuverlässig Phishing erschweren.

Aber wie mit jeder Lösung gibt es auch Probleme. Es kann tatsächlich vorkommen, dass eine Mail nicht zugestellt wird, weil die Empfängerseite meint, dass die Mail weder eine gültige DKIM-Signatur hat noch SPF korrekt ist. Es kann ein Konfigurationsfehler beim Absender, insbesondere DNS-Einträge sein. Aber auch der Empfänger kann aufgrund eines Softwarefehlers irrtümlich eine Mail blocken. Wenn ein Absender per DMARC die Überprüfung von SPF/DKIM anordnet, dann sollte der Empfänger eine Mail annehmen, wenn folgende Bedingungen erfüllt sind.

• SPF-Check Einliefernde IP ist im DNS-Eintrag zur Domäne des "Header-From" als "erlaubt gelistet
  Normal nutzt SPF den "Envelope-From aber per DMARC kann der Sender die Überprüfung des Header-From vorschreiben. Dieses Feld sieht der Benutzer. Der Envelope-From hingegen ist nur für das Routing zwischen den MTAs relevant.

Wenn SPF kein "PASS" erzeugt, dann muss DKIM herhalten.

• DKIM: Dazu nimmt der Empfänger wieder den "Header-From", sucht eine DKIM-Signatur, die von diese Domain erstellt wurde und verifiziert dies anhand der er DNS veröffentlichten Schlüssel.
  Wenn das passt, dann ist der Empfänger sicher, dass die Mail von einer authentifizierten Quelle kommt, selbst wenn Sie über ein Relay, Backup-MX oder Listserver gelaufen ist.

Aber gerade beim Betrieb über einen Listserver kann einiges schief gehen, z.B.

• Ein mit DKIM gesicherter Header wird verändert
  Das macht z.B. Exchange Online, welches ein Feld "X-MS-Exchange-SenderADCheck" mit in die DKIM-Signatur aufnimmt. Es hat den Wert 1, wenn der Benutzer etwas versendet, aber wenn ein anderer Tenant die Mail umleitet oder per Verteiler oder Mailingliste neu sendet, wird der Wert auf "0" gesetzt und die DKIM Signatur des ersten Servers ist ungültig
• Der Body wird verändert
  Viele Listserver aber auch Relays etc. addieren Werbung oder Disclaimer an eine Mail an eine Mailingliste. Es gibt aber auch Produkte, die den Body einfach im Rahmen der Verarbeitung parsen, speichern und später mit zusätzlichen Werten neu erstellen. Auch wenn DKIM die "Whitespace"-Zeichen ignoriert, kann allein die Umformung die Signatur brechen

Die Lösung erscheint einfach: Das verändernde System sollte eine eigene DKIM-Signatur mit den neuen geänderten Werten anbringen. Allerdings is es eher selten, das ein System in der Mitte sich als "System-A" ausgehen kann. Wenn das System aber nicht für die Absenderdomain autoritativ ist, dann kann es auch keine DKIM-Signatur für die Domain des System-A anbringen.

Die einzige Lösung ist dann, dass das System auch die "Header-From"-Adresse auf eine eigene Adresse umschreibt und dann signiert. Bei einer Mailingliste bedeutet das dann, dass die Empfänger nicht mehr den Namen des eigentlichen Absenders sondern eine generische Adresse der Mailingliste sehen. Das ist unschön.

Mehrere DKIM-Signaturen

Wenn eine Mail mehrere Stationen durchläuft, steht es jeder Station natürlich frei, eine eigene DKIM-Signatur anzubringen. Auch das ist per RFC dokumentiert:

Of course, a message might also have multiple signatures because it passed through multiple Signers. A common case is expected to be that of a signed message that passes through a mailing list that also signs all messages. Assuming both of those signatures verify, a recipient might choose to accept the message if either of those signatures were known to come from trusted sources.
Quelle: https://tools.ietf.org/html/rfc6376#section-4

Diese zusätzlichen Signaturen können auch andere Felder einbeziehen. Ein Empfänger sollte auch immer alle DKIM-Signaturen prüfen. Für seine Entscheidung, ob die Mail aber tatsächlich "sauber" ist, ist nur die Domain des Absenders aus dem Header der Mail ("Header.From") maßgeblich. Das Flussdiagramm von Microsoft zeigt das auch

Auszug aus https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dmarc-to-validate-email?view=o365-worldwide#troubleshooting-your-dmarc-implementation

Zuerst wird jede DKIM-Signatur erst mal geprüft. Ganz rechts sehen sie bei Station (1) die Prüfung, ob DKIM PASS ist. Wenn dies der Fall ist, dann liest der Validator an Station (2) die Domain aus dem Feld "d=" der DKIM-Signatur und vergleich sie an Station (3) mit der Domain der Mailadresse, die er aus dem Header.From bezogen hat.

Die Einstellungen von DMARC können hier auch das Verhalten für Subdomains steuern aber nicht die eigentliche SMTP-Domain.

Insofern erscheint es auf den ersten Blick unlogisch, wenn Zwischenstationen auch DKIM-Signaturen für andere Domains als die des Header-From anfühgen.

Diese zusätzliche DKIM-Signaturen können aber in Verbindung mit ARC - Authenticated Received Chain wieder von Belang sein. Mittels ARC können Sie ausgewählten Providern ein Vertrauen aussprechen. Wenn dann eine Mail ankommt, die von diesen Providern per DKIM signiert wurde, dann können Sie ausnahmsweise der Mail vertrauen. Das müssen Sie aber Einstellen und ich habe den Anscheint, dass es es hierbei eher darum geht, dass sehr große Provider sich gegenseitig vertrauen.

• Troubleshooting your DMARC implementation
  https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dmarc-to-validate-email?view=o365-worldwide#troubleshooting-your-dmarc-implementation
  Mit nettem Ablaufdiagramm zur Auswertung von DMARC

Zwischenstand

Die erste Version den Missbrauch von Domains für Spoofing/Phishing über SPF zu steuern, war zwar gut gemeint, schnell umzusetzen aber greift immer dann zu kurz, wenn Mails weiter gegeben werden. Aber selbst heute gibt es noch viel zu viele Firmen, die SPF ignorieren und ihre ausgehenden IP-Adressen gar nicht oder nicht mit einem strengen "-all" veröffentlichen. So macht man es Spammern natürlich einfach, die eigne Domain zu missbrauchen. Aber zumindest einige große Provider können durch einen SPF-Check Mails ablehnen.

DKIM könnte aber SPF komplett ersetzen, wenn denn endlich genug Firmen ihre Mails per DKIM korrekt signieren und die DNS-Einträge pflegen. Dann können auch die Empfänger die Mails auf ihre Authentizität prüfen.

Dann fehlt aber immer noch der DMARC-Eintrag, mit dem der Absender auch tatsächlich vorschreibt, dass nicht verifizierbare Mails abgelehnt werden dürfen. Denn solange dies nicht durch den Absender vorgegeben wird, wird kaum ein Empfänger voreilig solche Mails ablehnen.

Also fangen Sie bitte an DKIM und DMARC einzuführen. Per DMARC sollten sie erst einmal "p=none" machen aber per RUA die Rückmeldungen einsammeln, wer die Mails bei einem "p=reject" verwerfen würde. Nach einigen Wochen und entsprechenden Korrekturen können Sie dann per DMARC mit "p=reject" den Zwang einer DKIM-Signatur aktivieren. Zudem sollten sie natürlich weiterhin SPF mit "-all" einsetzen, damit zumindest ein Basisschutz vorhanden ist.

Weitere Links

• DKIM mit Office 365
• DMARC bricht SPF mit SRS
• X-MS-Exchange-SenderADCheck und DKIM
• DKIM doppelte Header
• Spam und UCE - Filter und deren Bedeutung
• Spam und UCE - Filter: DKIM
• Spam und UCE - Filter: SPF, SenderID
• DMARC
• UnifiedGroups Mailrouting
• Site Replication Service - SRS
  Die Abkürzung hat NICHTS mit dem Exchange SRS zu tun, der damals bei Exchange 5.5/2000/2003 relevant war