X-MS-Exchange-SenderADCheck und DKIM

Bei der Analyse gebrochener DKIM-Signaturen bin ich auf den SMTP-Header "X-MS-Exchange-SenderADCheck" aufmerksam geworden, den ich hier beschreiben möchte. Aktuell kann dieses Feld eine Ursache sein, wenn ein Mailserver eine Nachricht nicht annimmt. Dies gilt insbesondere beim Einsatz von Mailinglisten mit DMARC, DKIM, SPF, ARC oder Weiterleitungen.

Update:
Bei einer Verifikation im Mai 2023 konnte ich nicht mehr nachstellen, dass ExchangeOnline das Feld "X-MS-Exchange-SenderADCheck" von 1 auf 0 setzt und damit die DKIM-Signatur des initialen Senders ungültig macht. Das würde viele Probleme lösen. Das muss ich aber noch genauer untersuchen.

Exchange Online und DKIM

Microsoft hat im 2019/2020 für alle Tenants die Funktion DKIM verfügbar gemacht. Als Administrator müssen Sie nur einen CNAME in ihrem DNS eintragen, der auf einen passenden DNS-Eintrag bei Microsoft verweist. Auf der Seite DKIM mit Office 365 habe ich die Einrichtung beschrieben. Im Jahr 2017 habe ich eine Test-Mail gesendet, in der folgende DKIM-Signatur (gekürzt) enthalten war.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=msxfaq.com;
 s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
 bh=S+iXvEFDj3f6JXKMaDNWb/kRKVwXxM9dDGz/COkegK4=;
 b=B6E0wUV+X.......x8UBY=

Der Trick bei DKIM ist ja, dass der Absender einige Bestandteile der Mail nutzt, daraus einen Hash-Wert bildet und den dann mit einem geheimen Schlüsselteil digital signiert. Den öffentlichen Schlüssel zur Prüfung der Signatur kann der Empfänger per DNS erhalten. In dem Beispiel ist das der "Selector1", mit dem der Empfänger sich den Key per DNS holt.

Maßgeblich ist die Domäne der "Header.From"-Adresse der Mail.

PS C:\> Resolve-DnsName selector2._domainkey.msxfaq.com  -Type txt

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
selector2._domainkey.msxfaq.co CNAME  86386 Answer     selector2-msxfaq-com._domainkey.msxfaq.onmicrosoft.com
m

Name      : selector2-msxfaq-com._domainkey.msxfaq.onmicrosoft.com
QueryType : TXT
TTL       : 3600
Section   : Answer
Strings   : {v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0e7DgMLe2m6HSNU5TQInvrVj+l5zIvryubyD0t4JdYCpfilov
            ArC1f0sIHZH6TOeD3YgDE91N3yCJFJNZm/O0iVbORHo4+my4OLNr8VpKe3Cwa8ktZ2NvyMpS2hke+7vEsqnMImsM2BgQK1fSmJFkM3+Dwcr
            qqohYaRIUQWCLWQIDAQAB;}

Der CNAME verweist auf einen TXT-Eintrag bei Microsoft mit dem öffentlichen Schlüssel. So kann der Empfänger prüfen, ob die eingeschlossenen Inhalte der Mail unverändert sind. Ein Mailserver dann die Nachricht selbst dann noch annehmen, wenn andere Prüfungen wie z.B. SPF, SenderID ein Fail liefern. Das passiert z.B. wenn eine Mailingliste die Mail weiter verteilt. Es ist unwahrscheinlich, dass die IP-Adresse des ListServers das Recht zum Versand im Namen der Teilnehmer hat.

Wenn der Listserver aber die Mail noch z.B. durch Werbung "verschönert", dann bricht recht sicher die DKIM-Signatur. Damit solche Mails nicht im Spamfilter hängen bleiben, gibt es noch ARC - Authenticated Received Chain.

A über B nach C

Längere Zeit hat DKIM auch mit Office 365 sauber funktioniert, bis NoSpamProxy sich über korrupte DKIM-Signaturen beschwert hat. Interessanterweise waren es Mails von Firmen, die Exchange Online nutzen und die Mail über eine Mailingliste bei mir landen sollte. Normalerweise sollte das funktionieren, da der Absender A seine Mail korrekt per DKIM signiert und die Zwischenstation B zwar gerne auch eine weitere Signatur anfügen kann, die aber niemandem nutzt. Empfänger C sieht ja, dass die Mail ursprünglich von einem Absender der Domain A kommt und da muss die DKIM-Signatur von Domain A gelten.

B ändert X-MS-Exchange-SenderADCheck

Da hier die Signatur bricht, muss Station B etwas an der Mail verändert. Ich habe mir als von A eine Mail senden lassen, die sowohl über B nach C als auch direkt an C gegangen ist. So habe ich als Empfänger C den Header beider Mails gehabt und mit die Signaturen angeschaut.

 

Pfad Header DKIM Statu

A direkt zu C

 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=msxfaq.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=NjTaeifgl/+yoNcYqg9P5qSlFgduYzLpQbjZ89kpR7A=;
 b=dye2zv3M1H.......7Ds=
From: Testuser <testuser1@msxfaq.com>
To: "DLTest" <dlist@uclabor.de>
CC: "Carius, Frank (NAW)" <Frank.Carius@Netatwork.de>
Subject: DMARC test - please ignore
Date: Mon, 17 Aug 2020 23:02:01 +0000
Message-ID:
 <VE1PR02MB55823C1C491DBB461FB0081AF25F0@VE1PR02MB5582.eurprd02.prod.outlook.com>
X-MS-Exchange-SenderADCheck: 1
Content-Type: multipart/alternative;
 boundary="_000_VE1PR02MB55823C1C491DBB461FB0081AF25F0VE1PR02MB5582eurp_"
MIME-Version: 1.0

OK

A via B zu C

 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=msxfaq.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=NjTaeifgl/+yoNcYqg9P5qSlFgduYzLpQbjZ89kpR7A=;
 b=dye2zv3M1H.......7Ds=
From: Testuser <testuser1@msxfaq.com>
To: "DLTest" <dlist@uclabor.de>
CC: "Carius, Frank (NAW)" <Frank.Carius@Netatwork.de>
Subject: DMARC test - please ignore
Date: Mon, 17 Aug 2020 23:02:01 +0000
Message-ID:
 <VE1PR02MB55823C1C491DBB461FB0081AF25F0@VE1PR02MB5582.eurprd02.prod.outlook.com>
X-MS-Exchange-SenderADCheck: 0
Content-Type: multipart/alternative;
 boundary="_000_VE1PR02MB55823C1C491DBB461FB0081AF25F0VE1PR02MB5582eurp_"
MIME-Version: 1.0

FAIL

Wenn Sie genau hinschauen, dann sehen Sie genau eine Änderung: Das Feld "X-MS-Exchange-SenderADCheck" wurde durch B von 1 auf 0 gesetzt. Das Feld hatte ich lange nicht bemerkt und auch in einer früheren Mail von 2017 war es noch nicht relevant. Aber im August 2020 nutzt Exchange Online eine andere Definition für ihre DKIM-Definition. Maßgeblich ist der "h="Teil in der DKIM Signatur

h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;

Microsoft gibt damit vor, dass der ermittelte Hash-Wert neben dem Body auch die Inhalte der Felder "From", "Date", "Subject", "Message-ID", "Content-Type", "MIME-Version" und eben "X-MS-Exchange-SenderADCheck" einbeziehen soll. Allerdings ändert Microsoft das Feld bei einer Weiterleitung in einem Office 365 Tenant.

Als Gegenprobe habe ich die von NoSpamProxy abgelehnte Mail an genau der Stelle wieder verändert und noch trotz SPF-Fail mit DKIM PASS einliefern können.

Damit war klar, dass diese kleine und aus meiner Sinn überflüssige Änderung der Mail die Idee hinter DKIM-System bricht.

Allerdings frage ich mir dann schon:

  • Warum addiert Microsoft das Feld "X-MS-Exchange-SenderADCheck" überhaupt im Header?
    Sicher ist es interessant bei der Fehlersuche über den Weg die Authentizität des Absenders zu prüfen aber ich wüsste keinen Client, der diese Information aktuell auswertet
  • Warum addiert Microsoft das Feld in die DKIM-Signatur?
    Wenn es niemand auswertet, könnte man es auch weglassen. Die Absicherung durch die DKIM-Signatur macht natürlich Sinn, wenn Microsoft zukünftig diese Feld für bestimmte neue Funktionen auch übergreifend zwischen Tenants verwenden sollte.
  • Warum ändert B diese Feld?
    Sicher ist B nicht autoritativ für die Absenderdomain A aber wenn B schon prüft, dass die Mail nicht verändert wurde und die DKIM-Signatur bei B noch in Ordnung ist, dann könnte B doch einfach der gesicherten Information von A vertrauen und das Feld unverändert weiter geben. Oder Exchange Online sich selbst hier nicht?

Leider weiß ich nicht, wann Microsoft diese Verhalten ändern. Sicher könnte ich NoSpamProxy so anpassen lassen, dass er eine Mail mit einem "X-MS-Exchange-SenderADCheck:0" und DKIM=FAIL einfach noch mal mit "X-MS-Exchange-SenderADCheck:1" prüft. Wenn dann ein DKIM=PASS kommt, könnte man dies akzeptieren.

Ich bin gespannt, wenn Microsoft ihre DKIM-Signatur so anbringt, dass die originale Signatur nicht bricht. Vielleicht fixt Microsoft in dem Zuge auch die fehlende Absicherung gegen Replay-Attacken (Siehe DKIM doppelte Header=

Sonderfall SPF ohne DKIM

Ich habe dann natürlich eine Alternative gesucht und eine Absenderdomain genutzt, die kein DKIM macht. Ich habe eine Mail mit einen Absender der "carius.de"-Domain versendet. Die Domain liegt bei 1&1/IONOS, die im Sep 2020 noch keine DKIM-Signatur aufgebracht haben. Insofern konnte ich per DMARC nur den SFP-Check vorgeben:

v=DMARC1; 
p=reject; 
rua=mailto:p1myzbnv@ag.DMARCian-eu.com,mailto:dmarc@carius.de,mailto:dmarc_agg@vali.email; 
ruf=mailto:dmarc@carius.de

Die Mail wurde an die Zwischenstation (Office 365) gesendet und dort weiter geleitet.

Absender Zwischenstation Office 365 Ziel

EnvelopeFrom  (P1-From)

testuser@carius.de

SRS-Adresse testuser_carius.de@<zwischenstation>

EnvelopeTo (P1-To)

dl@<zwischenstation>

ziel@<zieldomain>

SourceIP

carius.de-Host

<zwischenstation>-Server

Header-From  (P2-From)

testuser@carius.de

testuser@carius.de

Header-To (P2-To)

dl@<zwischenstation>

dl@<zwischenstation>

SPFStatus

PASS, da die Source-IP zu P1-From und P2-From passt.

FAIL, da die SourceIP zu P1-From passt aber nicht zur P2-From. DMARC erwartet aber ein "matching" (aspf=relaxed als Default)

DKIM

 NA - keine Signatur vorhanden.

FAIL. Office 365 als Zwischenstation addiert eine DKIM-Signatur, deren Domain aber nicht zum P2-From passt.

Ergebnis

PASS - Die Mail kommt an, da SPF passt und andere Spamfilter hier nichts gefunden haben.

 REJECT, Die Mail wird abgelehnt da SPF nicht passt und DKIM nicht vorhanden ist.

Es gibt nun mehrere Optionen zur Lösung:

  1. Zwischenstation schreibt P2-FROM um
    Würde die Mailingliste auch diese Adresse auf ihre Domain per SRS umschreiben, würde die aufgebrachte DKIM-Signatur passen und die Mail würde vom Ziel vermutlich nicht abgelehnt. Allerdings bricht das natürlich eine eventuell vorhandenen DKIM-Signatur des Absenders. Das Rewriting sollte daher nur passieren, wenn es keine gültige DKIM-Signatur der empfangenen Mail gibt.
  2. Absender addiert DKIM
    Dann könnte das Ziel die DKIM-Signatur prüfen und die Mail annehmen, wenn die Zwischenstation die Signatur nicht ungültig macht
  3. ARC Umsetzung
    Würde das Ziel im Rahmen von ARC der Zwischenstation "Office 365" vertrauen, dann könnte die Mail auch als authentisch angekommen werden
  4. Verzicht auf DMARC
    Ich könnte natürlich einfach nichts per DNS zu DMARC veröffentlichen. Der Empfänger entscheidet dann selbst, ob er die Mail trotz falscher SPF-Prüfung annimmt. Und ich würde nicht verhindern, dass jemand mit meiner From-Domain als P2-From eine Spoofing-Attacke fährt.
  5. Der Empfänger legt eine Ausnahmen an
    Er könnte Mails von der "vertrauenswürdigen Zwischenstation Office365" trotz DMARC-FAIL annehmen.

Leider gibt es bei DMARC keine Option, mit der ich dem Ziel z.B.: mitteilen kann, dass er nicht den "P2-FROM" sondern nur den P1-FROM samt SRS für die bewertet. Die Option "aspf", kennt nur die beiden Zustände "Relaxed" und "Strict". Ich habe "aspf" nicht angegeben und damit kommt Relaxed zum Einsatz.

In relaxed SPF Alignment, the MailFROM domain and the Header From domain must be an exact match or a parent/child match (i.e. example.com and child.example.com)
https://mxtoolbox.com/dmarc/details/dmarc-tags/aspf

Leider reicht das nicht aus, da durch die Umschreibung von Microsoft nur der P1-From geändert wird und damit P1-From und P2-From nicht mehr passen. Genau der Fall wird von Microsoft auch dokumentiert.

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: Sender Rewriting Scheme (SRS) in Office 365 https://docs.microsoft.com/en-us/office365/troubleshoot/antispam/sender-rewriting-scheme

Ich würde Microsoft hier nicht alleine den schwarzen Peter zuweisen. Könnte ich bei IONOS meine Mails per DKIM signieren, wäre das Problem deutlich reduziert. ARC könnte helfen, wenn alle Ziele einfach Office 365 vertrauen, was aber noch lange dauern könnte.

Eventuell hilft hier aber irgendwann auch eine weitere RFC weiter, die noch im Entwurf ist

Weitere Links