DMARC bricht SPF mit SRS

Seit Jahren kennen wir SPF (Sender Policy Framework), damit Mailversender eine Liste der "gültigen Sender" per DNS veröffentlichen und Empfänger dies prüfen können. Dann kam mit DKIM ein zweiter Weg die Authentizität einer Mail sicher zustellen und zuletzt DMARC, um Richtlinien anzubieten. Idealerweise nutzen Sie als Versender aber auch Empfänger alle angebotenen Mittel. Allerdings gibt es einen Fall, wo ein DMARC-Eintrag die SPF-Prüfung stört.

Mehr Details

Mir ist das auch nur bei einer Troubleshooting-Session aufgefallen, und ich habe einige Zeit daran geknabbert, bis ich die Ursache gefunden haben. Es war wieder mal der Versand einer Mail an einen Verteiler, der dann diese Mails an die Mitglieder der Mailingliste versendet hat. Also wieder die drei Stationen:

  • Station1: Benutzer aus Firma-A sendet an einen Verteiler bei Firma-B
    Firma B kann (und sollte) die Mail gerne prüfen und sicherstellen, dass der Absender authentisch ist. Am einfachsten geht das, wenn Firma A eine Liste der erlaubten Versender-IP-Adresse per DNS veröffentlicht und alle anderen mit einem "-all" verbietet.
  • Station2: Firma-B verteilt die Mail an die Mitglieder
    Nachdem die Listserver bei Firma B den Absender legitimiert hat, kann er die Mail nun an alle Mitglieder versenden. Allerdings kann er ja nun nicht als Benutzer der Firma-A die Mail weiterleiten, da er nicht in der SPF-Liste von Firma A enthalten ist. Also muss er die Absenderadresse (Envelope-MailFrom, RFC5321-From) mittels SRS umschreiben.
  • Station3: Firma-C empfängt
    Der empfangende Server bei Firma-C hat auch einen Spamfilter und sieht nun eine Mail von Firma B mit der IP-Adresse von Firma-B. Der SPF-Check ist also "PASS". Aber das stimmt leider nicht immer

In meinem Fall hat der Spamfilter von Firma C die Mail mit einem Fehler abgelehnt und Domain-B war ein Exchange Online Tenant, der DKIM und SRS macht.

Fehlermeldung

Die Meldung war eine klassische 550-Ablehnung:

550 5.7.23 The message was rejected because of Sender Policy Framework violation -> 
550 DMARC Sender Invalid - envelope rejected - https://community.mimecast.com/docs/DOC-1369#550

Leider liefert die Meldung keine weiteren Details. Nur die Begriffe DMARC und "envelope rejected" könnte ein Hinweis sein. Dankenswerterweise hat das Exchange Online von Firma B mit dem Verteiler auch noch mitgeteilt, wie die Absender-Adresse ausgesehen hat. (Beispiel)

Verteilername+SRS=y1OwP=BF=firma-A.tld=user@firma-B.tld

Exchange Online schreibt vor das "+SRS+" den Namen des Verteilers und danach wie gehabt einen Zeit-Tag und Hashwert, ehe dann die Domain des Absenders (Firma-A) und der Userpart kommt. Erst dann kommt das "@" und die Domain von Firma-B. Eine Kontrolle des SPF-Records von Firma-B zeigte auch, dass dort ein "-all" stand aber auch über ein Include die Microsoft-Server eingeschlossen wurden. Damit bin ich davon ausgegangen, dass Firma-C beim SPF-Check erst mal ein "Pass" liefert und damit auch DMARC erfüllt wäre.

Nur aus Gewohnheit habe ich aber noch mal die DKIM-Signatur prüfen wollen aber keine entsprechende Signatur von Firma-A gefunden. Es war wohl eine Signatur von Firma-B vorhanden aber die ist nicht sinnvoll, da die FROM-Adresse im Header, also der RFRC5322-From weiterhin die "user@firma-a.tld" enthalten hat. Eine korrekte DKIM-Prüfung sucht daher eine Signatur mit einem "d=firma-A.tld"-Eintrag. Also konnte der Spamfilter bei Firma-C sich nur an der SPF-Prüfung stören. Die schien aber korrekt zu sein. Also habe ich mir noch mal die Grundprinzipien angeschaut:

Schutz und Prüfung

Nun hat natürlich der Inhaber der Domain A ein vitales Interesse daran, dass niemand sonst mit seinem Namen etwas versendet und auch B und C haben Filter im Einsatz, die Fälschungen erkennen. Damit kommen folgende vier Begriffe in den Fokus. Es gibt noch weiter wie MTA-STS, DANE etc., die ich hier aber nicht weiter betrachten will.

  • SPF - Sender Policy Framework (Spam und UCE - Filter: SPF, SenderID)
    Jeder Domaininhaber kann und sollte per TXT-Record im DNS die Server veröffentlichen, die für die Domain autorisiert sind. Idealerweise ist das eine Liste von IP-Adresse, Namen oder Include-Anweisungen, die mit einem "-all" abgeschlossen wird. Dann können Empfänger die einliefernde IP-Adresse zu einem "Envelope-From"-Wert prüfen und Phishing sehr gut verhindern. Das gleiche gilt natürlich für die Domain B als Versender und den Server S4 als Empfänger. Sie sehen aber schon, dass die umgeleitete Mail von C vermutlich abgewiesen wird, das der Server S3 von Domain-B nicht in der "SPF-AllowList" von Domain-A steht.

Hier ist der erste Sonderfall, der gar nicht so selten ist. Wenn Domain-A und Domain-B beide einen Microsoft 365 Tenant mitnutzen, dann haben Sie vermutlich beide per "Include"-Direktive auch die Exchange Online Server eingebunden und der SPF-Check kann dann doch fehlerfrei sein.

Bitte pflegen Sie ihren SPF-Record am besten mit einem "-all" am Ende, wenn Sie alle legitimen Sender kennen.

  • SRS
    Damit nun Domain-B dennoch eine Mail an Domain-C senden kann, wurde "Sender Rewriting Scheme" entwickelt. Domain-B ändert den Absender im Envelope derart, dass dort auch Domain-B auftaucht. Exchange Online  nutzt dazu folgendes Pattern, damit Der Server S4 in Domain C dann als Absenderdomain die "Domain-B" zur IP-Adressprüfung nutzt.

<Forwarding Mailbox Username>+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Forwarding Mailbox Domain>
Quelle: https://learn.microsoft.com/en-us/exchange/reference/sender-rewriting-scheme

  • DKIM
    SPF und SRS können aber nicht sicherstellen, das die Mail nicht auf dem Transport verändert wurde. Der Absender kann dies per SMIME/PGP absichern aber bei SMTP wurde mit DKIM eine Funktion entwickelt, über die Mailserver gewissen Inhalte einer Mail und des Headers auf dem Server signieren. Im DNS der Domain des Absenders wird dazu der Schlüssel zur Verifizierung hinterlegt. Der Empfänger nutzt dazu nun den FROM-Header, such tim Header die dazu passende Signatur kann damit prüfen, ob die Mail des ersten Absenders unverändert ist. Wenn der Server S4 in Domain-C auch DKIM versteht, dann kann er die Mail annehmen, obwohl der SPF-Eintrag vieleicht nicht passt.

SPF und DKIM sind wichtig und sollte jede Firma sowohl veröffentlichen als auch einrichten. In Exchange Online sind dies ein paar TXT-Einträge in der jeweiligen DNS-Zone und eine Checkbox zum Aktivieren des DKIM-Versands. Exchange Online Protection prüft eingehend sowohl SPF als auch DKIM.

  • DMARC
    Sie haben aber schon gelesen dass SPF auf den "Envelope-From" geht während DKIM den Header-From nutzt. Die Werte können sogar abweichend sein und DKIM selbst schreibt dem Empfänger nicht vor, wie er sich bei einem Fehler verhalten soll. Hier kommt DMARC ins Spiel. Der TXT-Eintrag informiert den Empfänger, wie der Sender gerne die Auswertung hätte. Über die Einstellung "Alignment" kann ich als Sender fordern, dass Mailfrom und HeaderFrom identisch sein müssen, was eine Absenderumschreibung mittels SRS verhindert. Ich kann mitteilen, ob Mails mit fehlerhafter Prüfung abgelehnt oder in der Quarantäne landen sollen. Der wichtigste Punkt ist aber die Bitte, die Ergebnisse der Überprüfung an den Absender zurück zu senden. So können Sie z.B. bei der Einführung von SPF/DKIM feststellen, welcher Server in ihrem Namen sendet und die Einträge anpassen.

Nun haben wir zwei Validierungsoptionen und eine Konfigurationsinformation, die den Mailfluss erlauben oder blockieren können. Wo ist nun das Problem mit Exchange Online?

Fehleranalyse

Leider bekomme ich beim Versand über die Mailingliste dann einen NDR von Server S3 in Domain-B, der die Mails nicht an Domain-C übertragen kann. Die Fehlermeldung und den Absender und Empfänger der Mail hatte ich ja schon (Auszüge):

550 5.7.23 The message was rejected because of Sender Policy Framework violation -
550 DMARC Sender Invalid - envelope rejected - https://community.mimecast.com/docs/DOC-1369#550

Sender: Verteilername+SRS=y1OwP=BF=domaina.tld=userA@domainB.tld
Recipient UserC@domainC.tld

Das System von Domain-B hat also eine SRS-Umschreibung des Absenders gemacht. Der empfangende Server S4 in Domain-C wertet also nicht den SPF-Eintrag von "Domain-A" aus sondern von "Domain-B". Das ist gut und sinnvoll. Nun muss ich mir natürlich noch die DKIM-Signaturen anschauen, denn der Administrator von "Firma-A" hat einen DMARC-Eintrag

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=FirmaB.onmicrosoft.com;
 s=selector2-FirmaB-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xxxxx;
 b=xxxxx
X-MS-Exchange-SenderADCheck: 0
From: "UserA" <userA@DomainA.tld>
To: "Mailinglist" <Mailinglist@domainB.tld>

Wer genau hinschaut, erkennt hier zwar eine DMARC-Signatur von Firma-B aber nicht von Firma-A. Hier hat der Mailserver von Firma-A wohl kein DKIM-Support. Leider bringt die Signatur von Firma-B aber nichts, denn die Domain "FirmaB.onmicrosoft.com" könnte zwar mit SRS zum Envelope-MailFrom passen aber für DKIM maßgeblich ist die Domain im Header-From, welches nicht durch die Mailingliste geändert wurde.

DMARC Alignment

Aber ich habe auch feststellen können, dass Firma-A sehr wohl einen DMARC-Eintrag per DNS veröffentlicht hat. Da wollte Firma-A wohl per RUF und RUA schauen, wie gut sie schon SPF und DKIM implementiert haben um später eine Policy vorzugeben. Ich habe mir dann noch einmal die DMARC-Spezifikationen genauer angeschaut und auch Microsoft hat dazu eine nette Folie veröffentlicht, von der ich nur einen Auszug hier wiedergeben.


Auszug aus https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-dmarc-configure?view=o365-worldwide#troubleshooting-your-dmarc-implementation

Hinweis: Das Ablaufdiagramm hat an mehreren Stellen Unstimmigkeiten und Fehler. Auf DMARC-Validation habe ich ein eigenes Flussdiagramm erstellt

Die SPF-Prüfung beginnt links oben mit der Ermittlung der Absenderdomain aus dem RC5321.Mailfrom (Envelope) bzw. dem HELO/EHLO-String des Mailservers, zu der dann der SPF-Record gesucht wird. Die erste Raute ist die Prüfung "is Client-IP authorized". Wenn dies nicht der Fall ist, endet die SPF-Prüfung hier mit einem FAIL. Wenn die Client-IP aber im SPF-Record aufgeführt ist, dann führt das nicht automatisch zu einem SPF=PASS!. Sobald der Empfänger zu einer Domain auch einen DMARC-Record findet, prüft er drei Dinge weiter ab, von denen mindestens eine zutreffen muss.

Bedingung Ergebniss im einem Fall

Sind Envelope-Mailfrom und Header-From gleich?

Das ist hier nicht der Fall, denn die Domain "firma-A.tld" im Header entspricht sicher nicht der per SRS umgeschriebenen Adresse im MailFrom des SMTP-Envelope. Das muss aber nur erfüllt sein, wenn die DMARC-Richtlinie auf "Strict" steht. Im Falle "Relaxed" können noch zwei andere Bedingungen auf "True" gehen, damit SPF einen Pass bekommt.

Ist Envelope-Mailfrom Subdomain von Header-From?

Da sich die Domains im Header-From und "Envelope-MailFrom komplett unterscheiden ist dies "False"

Ist DKIM-Domain eine Subdomain von Header-From?

Hier bin ich nicht sicher, wie DMARC genau die "DKIM-Domain" ermittelt, wenn es DKIM-Signaturen von anderen Mailservern gibt. Theoretisch könnte ja die DKIM-Signatur von Firma-B mit dem Envelope passen aber ich habe immer gelernt, dass DKIM sich nur auf den Header-From konzentriert und dann das hier auch nicht passt.

Da hier nun alle drei zusätzlichen SPF-Prüfungen negativ sind, muss die abschließende SPF-Antwort ein "FAIL" sein

Damit ist dann auch klar, dass der Spamfilter die Mail als "SPF-Fail" ansieht, da der Envelope MailFrom und der Header-From zwar gleich sind aber DMARC weitere Prüfungen vorsieht. Eine DMARC-Richtlinie von Firma-B konnte hier nichts verändern, da Firma-B gar keinen _dmarc-Record veröffentlicht hat. Das bedeutet aber, dass ein beliebiger DMARC-Record der Firma-A dafür sorgt, dass jeder Spamfilter mit aktiver DMARC-Prüfung, der eine Mail mit einem "header-From:*@firma-A.tld" erhält, diese den erweiterten SPF-Prüfungen unterwerfen sollte.

SRS rewriting does not fix the issue of DMARC passing for forwarded messages. Although an SPF check will now pass by using a rewritten P1 From address, DMARC also requires an alignment check for the message to pass. For forwarded messages, DKIM always fails because the signed DKIM domain does not match the From header domain. If an original sender sets their DMARC policy to reject forwarded messages, the forwarded messages are rejected by Message Transfer Agents (MTAs) that honor DMARC policies.
Quelle: https://learn.microsoft.com/en-us/microsoft-365/troubleshoot/antispam/sender-rewriting-scheme

Leider sind solche Tests und Ergebnisse aber nicht allgemeingültig, denn letztlich entscheidet der Entwickler eines Spamfilters mit SPF, DKIM und DMARC-Logik selbst über die Details der Implementierung und der Betreiber kann durch Konfigurationen auch noch ein abweichendes Verhalten festlegen. SPF, DKIM und DMARC sind auch nur "RFCs", was übersetzt ein "Request for Comments" bedeutet. Man sollte sich dran halten aber es gibt keine Verpflichtung.

Ergebnis

Seit Jahren ist mir die Funktion von SPF, DKIM und DMARC eigentlich geläufig und ich erkläre in Workshops immer wieder gestandenen MailAdmins, was diese drei Dinge tun und vor allem was sie nicht tun und was bei einer unsauberen Konfiguration alles schiefe gehen kann. Ich muss sogar immer wieder überzeugen, weil Sie damit ihren eigenen Spamschutz fast gar nicht verbessern sondern nur einen Teil dazu beitragen, dass andere die Mails von ihnen zuverlässiger annehmen und sie ihre Domains gegen Phishing besser schützen. Aber anscheinend gibt es gar nicht mehr so viele Mails, die über mehrere Stationen weiter geleitet werden und die Absender schon mit DMARC ohne DKIM arbeiten. So ist mir lange auch nicht aufgefallen, dass SRS zwar bei SPF hilft, aber eben nur solange die "Header-From-Domain" keinen DMARC-Eintrag hat.

Es hat den Anschein, dass dieser Sonderfall einfach nicht berücksichtig wurde. Wobei ein Spamfilter sehr wohl aus der SRS-Adresse ja den originalen Absender ermitteln und dessen Domain mit der From-Adresse vergleichen könnte.

Nutzen Sie das wissen und aktivieren sie DMARC nur, wenn sie alle Mails auch per DKIM versenden, ansonsten werden über Verteiler oder Umleitungen weiter versendete Mails trotz SRS entweder sichtbar abgelehnt oder landen beim Ziel in einer Quarantäne. Allerdings scheinen bei weitem nicht alle Empfänger dies so streng zu sehen oder machen einfach noch gar kein DMARC. Aber die Anzahl wird sicher zunehmen.

Weitere Links