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.
Begriff | Bedeutung |
---|---|
SPF |
Jeder Inhaber einer Domain kann per DNS eine Liste seiner ausgehende Mailserver veröffentlichen. Bei Net at Work sieht das wie folgt aus: 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" Wichtig ist das "-all" am Ende, da damit ein Empfänger mit SPF-Filter Mails von anderen Quellen ablehnen kann. SPF hat drei Besonderheiten, die sie kennen sollten
|
DKIM |
Die Einschränkungen von SPF wollte man mit DKIM verbessern. Hier wird per DNS ein "Public Key veröffentlicht und die Quelle signiert die Mail per DKIM. Das ist zwar nicht mit SMIME/PGP zu vergleichen, da nicht verschlüsselt wird aber die Signatur überlebt auch Relays. Hier ein Beispiel einer solchen Signatur 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> Sie sehen den Selector "s=key1", über den ich per DNS dann den dazu passenden Schlüssel erfragen kann. C:\>nslookup -q=TXT key1._domainkey.netatwork.de key1._domainkey.netatwork.de text = "v=DKIM1; k=rsa; t=s; p=<gekürzt>" Jeder Mailserver und Spamfilter kann damit prüfen, ob die Mail authentisch ist. DKIM ist also deutlich besser als SPF, da die IP-Adresse nicht mehr relevant ist, Veränderungen erkannt werden und üblicherweise der Content als auch der "Header-From" einbezogen wird. |
DMARC |
SPF und DKIM helfen dem Empfänger die korrekte Mail zu erkennen aber wie er mit Fehlern umgehen muss, ist nicht vorgegeben. Hier kommt DMARC ins Spiel. Per DNS gib der Administrator des Versenders vor, wie der Empfänger mit der Mail umgeht. Dies betrifft nicht nur ein Fehler bei der DKIM-Signatur sondern insbesondere auch wenn die DKIM-Signatur nicht vorhanden ist. Perfekt ist es, wenn DMARC vorschreibt, dass DKIM vorhande sein muss, denn dann ist Phishing/Spoofing blockiert. Ohne DMARC kann der Empfänger maximal auf die SPF-Prüfung hoffen. 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" Interessant ist hier der Eintrag "p=reject", mit dem der Administrator von Net at Work die Empfänger anweist, alle Mails direkt abzulenken, die nicht per SPF/DKIM verifiziert werden können. |
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
EnvelopeFrom | HeaderFrom | DMARC | SPF | DKIM | Status | Bewertung |
---|---|---|---|---|---|---|
B |
A |
Kein |
OK |
fehlt |
Spam |
Dieser Fall ist der klassische Phishing/Spoofing-Angriff. Der Absender gibt vor, der Initiator zu sein. Ohne DMARC prüft SPF nur die EnvelopeFrom und die passt natürlich und die Mail käme an. Das ist genau der Fall, bei dem DKIM helfen soll. |
B |
A |
Reject |
OK |
A-OK |
OK |
Wenn A die Mail per DKIM signiert hat, dann kann C diese prüfen und erlaubt die Zustellung |
A |
A |
keine |
Fail |
fehlt |
Spam |
So eine Mail sollte jeder SPF-Check umgehend ablehnen, wenn Domain A ein "-all" hat. |
A |
A |
keine |
Fail |
A-OK |
Spam |
Wenn auf dem zweiten Teilstück die Adresse der Domain "A" als EnvelopeFrom genutzt wird, würde ohne entsprechenden DMARC-Eintrag die SPF-Prüfung scheitern und die Mail abgelehnt werden. |
A |
A |
Reject |
Fail |
A-OK |
Gültig |
Wenn Domain A aber per DMARC die DKIM-Prüfung aktiviert, dann kann der SPF-Fail überstimmt werden und der Empfänger die Mail dennoch annehmen. |
Header-From = B
Anders sieht es aus, wenn der Header-From umgeschrieben wird. Diesen Weg finde ich nicht gut, weil die Empfänger nicht mehr den originalen Absender sehen aber wird oft genutzt, z.B. auch bei Weiterleitungen
EnvelopeFrom | HeaderFrom | DMARC | SPF | DKIM | Status | Bewertung |
---|---|---|---|---|---|---|
B |
B |
kein |
OK |
fehlt |
Gültig |
Die Mailingliste kann die "Header-From"-Adresse durch die Liste ersetzen und die Mail neu mit dem eigenen DKIM-Schlüssel signieren. Wenn sie auch die EnvelopeFrom anpasst, dann kommt die Mail an. Der Empfänger sieht aber nicht mehr den echten Absender. Nur wenn B per DMARC eine DKIM Signatur vorschreibt und diese fehlt, dann würde die Mail |
B |
B |
Reject |
OK |
B-OK |
Gültig |
Wenn B per DMARC eine DKIM Signatur vorschreibt, dann muss diese auch vorhanden sein. |
B |
B |
Reject |
Fail |
B-Invalid |
Spam |
Wenn ein fremder Host versucht als B etwas bei C einzuliefern, dann sollte der SPF-Fail dies verhindern |
B |
B |
Reject |
OK |
B-Invalid |
OK |
Beachten Sie, dass ein korrekter SPF-Check durchaus eine fehlerhafte DKIM-Prüfunge überstimmen können. Wenn das Alignment per DMARC (d.h. Header-From = Envelope-From) passt und die einliefernde IP-Adresse zum SPF-Eintrag der Maildomain passt, dann wird die Mail angenommen. Wenn aber Header-From <> Envelope-From, dann wird natürlich abgelehnt |
A |
B |
Kein |
Fail |
B-OK |
Gültig |
Wenn aber die Mailingliste die Mail per DKIM-Signatur zertifiziert, kann die Mail trotz SPF-Fail dennoch ankommen. Der Empfänger sieht aber nicht mehr den echten Absender. |
A |
B |
Reject |
Fail |
B-OK |
Gültig |
Dieser Fall entspricht Fall , nur dass SPF fehlerhaft ist. Wenn aber die Mailingliste die Mail per DKIM-Signatur zertifiziert, kann die Mail dennoch ankommen. Der Empfänger sieht aber nicht mehr den echten Absender. |
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
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