EXO SRS - Sender Rewriting Scheme (SRS)

Sender Rewriting Scheme ist ein Verfahren, um den beim MAILFROM genutzten Absender so umzuschreiben, dass ein einfacher SPF-Check gültig sein kann, auch wenn damit das DMARC-Alignment bricht. Diese Seite beschreibt die Funktion bei Exchange Online, welche 2021 und 2023 verändert wurde und ihre Auswirkungen.

Exchange OnPremises kann keine Absenderadresse mittels SRS umschreiben. Weiterleitungen zu Systemen mit SPF-Check und Quell-Domains mit "spf: -all" funktionieren daher nicht. Dieses Problem möchte Exchange Online lösen.

Umleitungen und SRS

Wenn eine Mail von AbsenderA@DomainA an EmpfängerB@DomainB geht, dann kann der Mailserver von Domain-B anhand der IP-Adresse des einliefernden ServerA und der Absenderadresse von A anhand der SPF-Einträgen prüfen, ob der ServerA dafür freigeschaltet ist. Knifflig wird es nun, wenn EmpfängerB diese Mail nun an EmpfängerC@DomainC anhand einer Umleitung weiterreicht.

  • Umleitung
    Bei Umleitungen soll die beim EmpfängerC sichtbare Absenderadresse weiterhin der AbsenderA sein und sind wichtig, wenn Sie z.B. bei Migrationen alle Mails an ein altes Postfach schon an das neue Postfach umleiten oder Mails an Verteilern an die Mitglieder verteilt werden sollen. In dem Fall sendet aber ServerB als AbsenderA@DomainA und das bricht einen strengen SPF-Eintrag.
  • Weiterleitung
    Bei Weiterleitungen wird der AbsenderA durch den AbsenderB ersetzt. Einsatzzweck sind hier z.B. Mailinglisten oder durch Anwender per Regel konfigurierte Weiterleitungen. Hierbei kommt SRS nicht zur Anwendung, da der AbsenderB@DomainB auch zu versendenden ServerB passt und damit auch ein SPF-Eintrag.

Die ganze Problematik ist nur relevant, wenn EmpfängerB und EmpfängerC in unterschiedlichen Mailsystemen betrieben werden und dazwischen eine Übertragung per SMTP ohne Sonderkonfigurationen erfolgt. Bei einer Hybrid-Bereitstellung zwischen Exchange Online und Exchange OnPremises ist dies nicht relevant, da die empfangende Exchange-Umgebung der anderen Seite vertraut und daher auch den Absender ohne SPF-Check o.ä. akzeptiert.

Wenn ihr Mailserver eine Mail an einen ServerC umleitet, den Absender aber nicht umschreibt, der ServerC einen SPF-Check macht und DomainA einen "spf:-all" hat, dann wird ServerC die Mails ablehnen. Sie verhindern als Betreiber von B so die Nutzung der Funktion "Umleitung"

Persönlich bin ich kein Freund von Umleitungen, da Sie auch das Risiko einer Datenverlusts haben, wenn z.B. eine unautorisierte Um/Weiterleitung unbemerkt eingerichtet wird. Für Migrationen kann ich bei ServerC ja temporär konfigurieren, dass er ServerB vertraut.

Weitere Informationen zu dieser Problematik finden Sie auf:

Exchange Online und SRS

Die Thematik betrifft Exchange Online in mehreren Szenarien:

  • Umleitungen durch "TargetAddress"
    Eine Administrator kann durch Setzen des AD-Felds "TargetAddress" eine Mail an einen Empfänger direkt an einen anderen Empfänger anhand der MOERA - Microsoft Online Email Routing Address umleiten. Dieser Fall kommt bei CrossTenant oder CrossOrg-Migrationen fast immer vor. Dazu zählen aber auch MailUser/MailContact-Objekte .
  • Verteilerlisten
    Durch den Exchange Admin verwaltete Verteiler können auch genau diese MailUser/MailContact-Objekte als externe Empfänger enthalten.
  • Umleitungen durch Benutzer
    Anwender selbst können über Regeln ebenfalls sowohl eine Umleitung als auch eine Weiterleitung konfigurieren.
  • Umleitungen durch Regeln
    Über eine Transportregel können Sie als Administrator den Empfänger einer Mail umschreiben,

Damit eine Exchange Umgebung Mails überhaupt automatisch weiterleitet/Umleitet, spielen auch die Einstellungen von RemoteDOmains eine Rolle. Bei einer Hybrid-Bereitstellung sind beide Server bei korrekter Konfiguration des Organization Connectors als "intern" anzusehen. Allerdings gibt es noch den Sonderfall, dass eine Mail z.B. über einen MX-Record von extern zum OnPremises Exchange eingeliefert wird, der diese dann an an Exchange Online Postfach zum Versand ins Internet weiterleitet.

Microsoft Quellen

Auf der Exchange Dokumentation von Microsoft finden sich viele Beschreibungen zu SRS und den Änderungen. Interessant ist hier ein Message Center Post MC649482 SRS (https://admin.microsoft.com/Adminportal/Home#/MessageCenter/:/messages/MC649482), der eine Kurzfassung liefert:

All messages that are forwarded externally from Exchange Online to the internet will be subject to SRS rewriting.
Messages that will see a change in behaviour include those forwarded externally by SMTP or mailbox forwarding, or by Mail Contacts or Mail Users with external addresses

Microsoft unterwirft also generell erst einmal alle Mails, die von Exchange Online ins Internet übertragen werden. Das macht Sinn, denn wenn die Absenderadresse im Envelope (SMTP P1/P2-Felder und Envelope und Header) eh zu ihrer Domain gehört und auch der Empfänger der Umleitung wieder intern ist, dann muss nichts umgeschrieben werden.

SRS is not always used to rewrite all forwarded messages. As mentioned in the SRS documentation, the new Relay Pool feature decides whether a message should be rewritten or not.
One scenario this applies to is when the incoming message did not pass our SPF check in the first place. The list of conditions that skip SRS rewriting can be found in the Relay Pool documentation: Outbound delivery pools (Pools für die Zustellung ausgehender Nachrichten https://learn.microsoft.com/de-de/microsoft-365/security/office-365-security/outbound-spam-high-risk-delivery-pool-about)

Im Juli 2021 hat Microsoft angefangen, Mails über zwei unterschiedliche Wege zu senden. Mails über den Hauptweg sind in dem SPF-Eintrag von Exchange Online enthalten. Wenn Sie als Kunde für ihre Domain daher einen "include:spf.protection.outlook.com " eingebunden haben, sind andere Adressen unterbunden. Wenn die eingehende Mail den SPF-Check schon nicht besteht, dann sollte Microsoft durch das Umschreiben der Mail keinen Vorteil verschaffen, sondern verzichtet auf das Umleiten und sendet Sie über IP-Adressen, die nicht in "include:spf.protection.outlook.com" enthalten sind.

SRS does not act on traffic leaving Exchange Online using an on-premises mail flow connector.

Das Verhalten ist erklärbar, da hier die Mail von extern zum lokalen Exchange Server ja eine regulärer Fall ist, d.h. der MX-Record verweist auf Exchange Online Protection und das Postfach ist weiterhin auf dem OnPremises Server. Die Mail wird dann von Exchange Online angenommen und anhand der "TargetAddress" zum lokalen Server weiter geleitet. Das ist kein Routing nach Extern sondern Intern und unterliegt daher nicht einem SRS Rewriting

Before this change takes effect, customers who route traffic to the internet from their on-premises environment should enable the new parameter SenderRewritingEnabled on their outbound on-premises mail flow connector to avoid any disruptions.


Quelle: Set-OutboundConnector https://learn.microsoft.com/en-us/powershell/module/exchange/set-outboundconnector

Ich habe aber keinen vergleichbaren Eintrag auf dem OnPremises Send-Connector gefunden. Das wäre dann wohl eher auf dem Inbound-Connector von Exchange Online zu prüfen.

Testserie

Es wird also Zeit für eine Testserie. Die Testserie gibt den Stand vom Dezember 2023 wieder. Da Microsoft auch in der Vergangenheit die SRS-Funktion immer wieder angepasst hat, sollten sie die Funktion immer wieder selbst prüfen. Von Microsoft ist ist folgendes beschrieben:


Quelle: https://learn.microsoft.com/en-us/exchange/reference/sender-rewriting-scheme  15 Dez 2023

Leider konnte ich das bislang noch nicht so nachvollziehen. Für meine Testumgebung haben ich einige Vorarbeiten getätigt:

Vorarbeite Erledgit

AbsenderA

Ich nutze als AbsenderA ein Testpostfach der Domain "carius.info", die nicht aktiv genutzt wird. Sie hat aber folgenden "strengen" SPF-Record. Der SPF-Eintrag erlaubt nur den Mailservern von IONOS mit dieser Domain zusenden und Exchange Online ist nicht eingeschlossen und alle anderen Server sind "-all" ausgeschlossen. Jeder Empfänger, der SRS ernst nimmt, sollte daher die Mails ablehnen, wenn Sie mit dieser Adresse von einem Exchange Online Server aufschlägt.

"v=spf1 include:_spf.perfora.net include:_spf.kundenserver.de -all"

keine DMARC-Policy. Ich habe aber in der Auswertung so getan, als gäbe es eine eine DMARCPolicy mit p=reject

EmpfängerC

Als EmpfängerC nutze ich den Service von learndmarc.com, der mit eine temporäre Mailadresse (ld-7865d2b584@learndmarc.com) anbietet, die ich zur Auswertung nutzen kann.

Tipp: Auf der Webseite "LearnDMARC.com" können sie problemlos eine temporär Adresse erhalten und eingehende Mails direkt auf den MAIL-FROM im Envelope analysieren. Damit können Sie im Test-Tenant dann Umleitungen anlegen und von einem anderen Tenants Mails dorthin senden.

Exchange Online "msxfaqlab.onmicrosoft.com

Hier habe ich noch mehrere Dinge angepasst:

  • Automatische Weiterleitung
    Normalerweise verhindert Exchange Online mittlerweile eine automatische Um/Weiterleitung durch Anwender.  Damit die Weiterleitungen durch den Benutzer selbst funktionieren, muss ich die "Anti-Spam Outbound Policy" auf https://security.microsoft.com/antispam anpassen. Die Weiterleitung über Kontakte und Gruppenmitgliedschaften funktionieren auch ohne die Freigabe.
  • SPF
    Die Domain "msxfaqlab.onmicrosoft.com hat einen ein einen strengen SPF-Record und DKIM ist aktiviert. So kann ich gleich sehen, ob Exchange Online auch solcher Um-/Weitergeleitete Mails mit einer DKIM-Signatur versieht und diese gültig sein kann. Aber Exchange Online nutzt wohl nur SPF als Kriterium für SRS.
msxfaqlab.onmicrosoft.com text = "v=spf1 include:spf.protection.outlook.com -all" 

selector1-msxfaqlab-onmicrosoft-com._domainkey.msxfaqlab.onmicrosoft.com text =  "v=DKIM1; k=rsa; p=MIIBIjANk...IDAQAB;"

Dann muss ich nur noch die verschiedenen Empfänger und Umleitungen in Exchange Online einrichten:

 

 

Das linke Postfach hat dann Mails an die Empfänger im Exchange Online-Tenant versendet, die dann zum Ziel umgeleitet wurden.

Umleitung SRS SPF DKIM DMARC
SPFAlign
DMARC
DKIMAlign
DMARC
SPF
DMARC
DKIM
DMARC
Total
Beschreibung

Direkter Versand A->C

Nein

Pass

Nein

Ja

Ja

Pass

Pass

Pass

Die direkte Mail ist angekommen. SPF hat wie erwartet gepasst und IONOS addiert leider keine DKIM-Signatur. DMARC war aber dennoch happy, da das Alignment gepasst hat und SPF war ja OK.

Direkter Versand B->C

Nein

Pass

Ja

Ja

Ja

Pass

Pass

Pass

Hier war nun alles Grün, denn SPF, DKIM und DMARC haben alle Anforderungen erfüllt.

Postfach mit Weiterleitung zu C

Nein

Pass

Pass

Pass

Pass

Pass

Pass

Pass

Mein MSXFAQLAB-Postfach ist nun der Absender der Mail und nicht mehr das Testpostfach in carius.info Damit funktioniert quasi alles. Allerdings sieht der EmpfängerC nicht mehr AbsenderA.

MailFrom    : srstest@msxfaqlab.onmicrosoft.com
HeaderFrom  : SRSMailbox (srstest@msxfaqlab.onmicrosoft.com)
DKIM-Domain : .msxfaqlab.onmicrosoft.com

Postfach mit Umleitung zu C

Nein

Ja

Ja

Fail

Fail

Fail

Fail

Fail

Eine Umleitung im Postfach belässt den HeaderFrom auf dem AbsenderA aber den EnvelopeFrom auf das Postfach. Es findet keine SRS-Umschreibung statt. Da Aber auch DMARC Alignment fehlschlagen, wird es nicht viel besser.

MailFrom    : srstest@msxfaqlab.onmicrosoft.com
HeaderFrom  : SRSTest Carius (srstest@carius.info) 
DKIM-Domain : .msxfaqlab.onmicrosoft.com

MailContact/MailUser mit externer Adresse

Ja

Pass

Pass

Fail

Fail

Fail

Fail

Fail

Dem Kontakte muss ich noch eine msxfaqlab.onmicrosoft.com-Proxyaddresse geben.

set-MailContact ld-7865d2b584@learndmarc.com `
   -EmailAddresses "smtp:srscontact@msxfaqlab.de","SMTP:ld-7865d2b584@learndmarc.com"

Die Mail kam mit SRS Umschreibung von der Domain msxfaqlab.de.

Mailfrom   : srscontact+SRS=c5NHa=H2=carius.info=srstest@msxfaqlab.de
HeaderFrom : SRSTest Carius (srstest@carius.info) 
DKIM-Domain: d=msxfaqlab.onmicrosoft.com

Es war sogar eine DKIM-Signatur mit "", die aber nicht zur From-Domain "carius.info" gepasst hat.

Verteiler mit MailContact als Mitglied

Ja

Pass

Pass

Fail

Fail

Fail

Fail

Fail

Der Versand an einen Verteiler hat nicht viel geändert.

MailFrom   : SRSgroup+SRS=c5NHa=H2=carius.info=srstest@msxfaqlab.de 
HeaderFrom : SRSTest Carius (srstest@carius.info) 
DKIM-Domain: d=msxfaqlab.onmicrosoft.com 

SPF und DKIM funktionieren aber mit einer DMARC-Policy wäre das Alignment gebrochen und damit alles andere auch.

Transportregel

Nein

Pass

Pass

Fail

Fail

Fail

Fail

Fail

Über eine "Redirect"-Transportregel habe ich alle Mails an ein Postfach an den Mailcontact umgeleitet.

MailFrom   : bounces+SRS=qE70O=H2@msxfaqlab.de 
HeaderFrom : SRSTest Carius (srstest@carius.info)
DKIM-Domain: d=msxfaqlab.onmicrosoft.com 

Auch hier sind SPF und DKIM erst einmal korrekt aber würde es eine DMARC-Policy geben, dann bricht das fehlende Alignment die nachfolgenden Checks.

Entgegen der Aussagen der Dokumentation konnte ich nicht bestätigen, dass auch Mails durch eine Weiterleitung/Umleitung im Postfach oder bei einer Transportregel umgeschrieben ist. Mein Test zeigt, dass im Dezember 2023 die SRS-Funktion von Exchange nur zum Einsatz kommt, wenn eine Mail über einen MailContact oder einen Verteiler mit externen Empfängern zum Einsatz kommt, wenn die Mails selbst von extern kommt. Hier gibt es von Microsoft aber noch eine Bedingung:

One scenario this applies to is when the incoming message did not pass our SPF check in the first place.
Quelle: MC649482 – (Updated) Sender Rewriting Scheme (SRS) Expanding to SMTP/Mailbox Forwarding

Daher habe ich die Testserie nur für die beiden Fälle mit SRS-Umschreibung wiederholt und dabei bei der Absenderdomain den SPF-Record entfernt.

carius.info hat keinen SPF-Record mehr.

Nun kann Exchange Online nicht mehr sicher sein, dass der einliefernde Server auch authentisch ist.

Umleitung SRS SPF DKIM DMARC
SPFAlign
DMARC
DKIMAlign
DMARC
SPF
DMARC
DKIM
DMARC
Total
Beschreibung

MailContact/MailUser mit externer Adresse

Nein

None

Pass?

NA

Fail

Fail

Fail

Fail

Da Exchange Online nicht prüfen konnte, ob die Mail von einem legitimen Server gekommen ist, hat Exchange auch keine SRS-Umschreibung vorgenommen. Auch der Zielserver konnte kein SPF prüfen und damit wäre auch ein DMARC-Alignmentcheck hinfällig.

Mailfrom   : srstest@carius.info. 
HeaderFrom : SRSTest Carius (srstest@carius.info) 
DKIM-Domain: d=msxfaqlab.onmicrosoft.com

Exchange Online hat die Mail per DKIM signiert und da es keine DMARC-Policy mit Alignment gibt. Interessanterweise liefert Learndmarc hier ein pass, obwohl die DKIM-Domain nicht zur HeaderFrom-Domain passt. Ich hätte da auch ein "Not Available" gemacht, da keine Signatur für carius.info dabei ist.

Verteiler mit MailContact als Mitglied

Nein

None

Pass

NA

Fail

Fail

Fail

Fail

Der Versand an einen Verteiler hat nicht viel geändert.

MailFrom   : SRSgroup+SRS=c5NHa=H2=carius.info=srstest@msxfaqlab.de 
HeaderFrom : SRSTest Carius (srstest@carius.info) 
DKIM-Domain: d=msxfaqlab.onmicrosoft.com 

SPF und DKIM funktionieren aber mit einer DMARC-Policy wäre das Alignment gebrochen und damit alles andere auch.

Ohne Sicherung des einliefernden Absenders per SPF findet keine SRS-Umschreibung des MAIL-FROM statt. So wird sichergestellt, dass EmpfängerC eine eingehende Mail von Exchange online bekommt die aufgrund der Umschreibung bei einer Domain ein SPF-Pass erhalten würde.

SRS-Domainauswahl

Eine Fragestellung wollte ich noch klären, denn bei der Umschreibung per SRS ersetzt Exchange Online die originale Absenderdomain durch eine Domain aus seinem Bereich. Ein Tenant hat aber in der Regel mehrere Domains. Ich habe dem Kontakt daher einfach Mailadressen aus beiden Domains gegeben:

Set-MailContact `
   -Identity       ld-7865d2b584@learndmarc.com `
   -EmailAddresses "SMTP:ld-7865d2b584@learndmarc.com",`
                   "smtp:srscontact@msxfaqlab.de", `
                   "smtp:srscontact@uclabor.de"

Zur Bestätigung hier noch einmal die Ausgabe eines "Get-MailContact"

Danach habe ich Mails an beide zusätzlichen Adresse von einem per "SPF=-all" abgesicherten Mailkonto gesendet, so dass SRS auch aktiv werden kann.

Zieladresse SRS-Absender

 

srscontact@uclabor.de

srscontact+SRS=a5fpx=H3=carius.de=srstest@uclabor.de

 

srscontact@msxfaqlab.de

srscontact+SRS=a5fpx=H3=carius.de=srstest@msxfaqlab.de

 

Es ist gut zu sehen, dass Exchange Online die Domäne der angeschriebenen Adresse verwendet, um die SRS-Adresse zu bilden.

SRS Überlänge

Eine Absender und Empfänger-Adresse müssen gemäß RFC822 einen gewissen Format folgen und eine Grenze dabei ist die Länge des "Local part", d.h. des String vor dem "@".

local-part The maximum total length of a user name or other local-part is 64 characters.
Domain:   The maximum total length of a domain name or number is 255 characters.
Path:        The maximum total length of a reverse-path or forward-path is 256 characters, including the punctuation and element separators”
Quelle: RFC2821 Simple Mail Transfer Protocol https://www.ietf.org/rfc/rfc2821.txt

Wobei an der gleichen Stelle auch noch steht:

... Every implementation MUST be able to receive objects of at least these sizes. Objects larger than these sizes SHOULD be avoided when possible. However, some Internet mail constructs such as encoded X.400 addresses [16] will often require larger objects: clients MAY attempt to transmit these, but MUST be prepared for a server to reject them if they cannot be handled by it. To the maximum extent possible, implementation techniques which impose no limits on the length of these objects should be used.
Quelle: RFC2821 Simple Mail Transfer Protocol https://www.ietf.org/rfc/rfc2821.txt

Alles längere kann gehen aber muss nicht gehen. Mit Outlook konnte ich Mailadressen bis 128 Zeichen als "Local part" zumindest per SMTP auf die Reise senden und IONOS hat diese auch angenommen. Auch Exchange Online erlaubt mir einen UserPart bis 316 Zeichen!. Also habe ich folgende Adresse addiert und angeschrieben: (Umbruch)

"smtp:123456789012345678901234567890123456789012345678901234567890
123456789012345678901234567890123456789012345678901234567890
123456789012345678901234567890123456789012345678901234567890
123456789012345678901234567890123456789012345678901234567890
123456789012345678901234567890123456789012345678901234567890
12345 67890123456@msxfaqlab.onmicrosoft.com"

Die war dann aber für IONOS schon mal zu lange. Ich habe mich dann auf weniger Zeichen beschränkt und wieder mit carius.de  (SPF=-all) gesendet

Ziel:  a12345678901234567890@msxfaqlab.onmicrosoft.com 
Absender srstest@carius.de
a12345678901234567890+SRS=a5fpx=H3=carius.de=srstest@msxfaqlab.onmicrosoft.com

Im nächsten Versuch habe ich dann 62 Zeichen verwendet.

Ziel: a123456789012345678901234567890123456789012345678901234567890@msxfaqlab.onmicrosoft.com 
Absender srstest@carius.info
MAIL FROM bounces+SRS=oaVL2=H3@msxfaqlab.de

Wenn die Obergrenze bei 64 Zeichen für das "Return"-Feld ist, dann musste Exchange irgendwie etwas abschneiden. Exchange hat sich dann aber wohl dazu entschieden, die generische "bounces+SRS=oaVL2=H3"-Adresse zu verwenden und keinen Rückschluss auf den originalen Absender einzubauen.

Alternative Pools

Beim Versand von Nachrichten von extern über Exchange Online nach extern hat Microsoft mittlerweile unterschiedliche Pools an Servern konfiguriert. Es gibt Server, die für den Versand von Mails aus dem Tenant oder authentifizierten Absendern zuständig sind und damit eine gewisses Vertrauen genießen. Werden aber Mails schon "unsicher" an Exchange Online eingeliefert und dann wieder in die Welt versendet, dann nutze Exchange Online alternative ausgehende Server. Diese Relay-Server sind z.B. nicht im SPF-Record von "include:protection.outlook.com" enthalten und profitieren daher nicht von einem SPF-Pass. Auch hier schauen wir uns eine Tabelle an

In bestimmten Szenarien werden Nachrichten, die über Microsoft 365 weitergeleitet oder weitergeleitet werden, mithilfe eines speziellen Relaypools gesendet, da das Ziel Microsoft 365 nicht als tatsächlichen Absender betrachten sollte. Es ist wichtig für uns, diesen E-Mail-Datenverkehr zu isolieren, da es legitime und ungültige Szenarien für die automatische Weiterleitung oder Weiterleitung von E-Mails aus Microsoft 365 gibt. Ähnlich wie beim Übermittlungspool mit hohem Risiko wird für Relay-E-Mails ein separater IP-Adresspool verwendet. Dieser Adresspool wird nicht veröffentlicht, da er sich häufig ändern kann und nicht Teil des veröffentlichten SPF-Eintrags für Microsoft 365 ist.
Relaypools https://learn.microsoft.com/de-de/microsoft-365/security/office-365-security/outbound-spam-high-risk-delivery-pool-about?view=o365-worldwide#relay-pool

Der Relay-Pools wird zwar nicht im  SPF-Record veröffentlicht aber er ist durchaus "bekannt".

Sie können erkennen, dass eine Nachricht über den Relaypool gesendet wurde, indem Sie sich die IP-Adresse des ausgehenden Servers ansehen (der Relaypool befindet sich im Bereich 40.95.0.0/16).
Relaypools https://learn.microsoft.com/de-de/microsoft-365/security/office-365-security/outbound-spam-high-risk-delivery-pool-about?view=o365-worldwide#relay-pool

Entsprechend routet Exchange die Mails

SPF Absenderdomain  SPF Beschreibung SRS Sendepool SPF im Ziel

-All 

Pass 

Die Mails vom Absender ist vom richtigen Host gekommen. Auch eine gültige DKIM-Signatur beweist, dass der Absender zur Domain korrekt und sogar die Mail unverändert ist. Für SRS ist DKIM aber nicht wichtig. Die Mail-From-Adresse wird bei einer Umleitung mittels SRS auf eine Domain des Tenants umgeschrieben, so dass auch beim Ziel ein SPF-Check ein PASS ergibt.

Ja

Regulär

Pass

-All

Fail 

Die Mails vom Absender ist vom falschen Host gekommen.

EOP filtert die Mail

Entfällt 

Entfällt 

?all
~all
nicht da 

Pass

Wenn die Mails vom Absender vom einem Host kommt. der im SPF-Record aufgeführt ist, dann ist dies ein PASS. Auch ein DKIM-Pass ist ein legitimer Beweis, der aber nicht für SRS genutzt wird.

Ja 

Regulär

Pass 

?all
~all
nicht da 

Fail

Die Mails vom Absender ist vom falschen Host gekommen aber SPF verbietet es nicht. Auch eine DKIM-Signatur fehlt oder passt sind. Damit kann Exchange nicht sicher sein, dass die Mail authentisch ist. Sie wird nicht per SRS umgeschrieben.

Nein

Relaypool
40.95.0.0/16

Nicht prüfbar

Wenn Exchange Online nicht prüfen kann, ob der Absender durch SPF verifiziert wurde, dann bekommt die Mail keinen Bonus und wird nicht umgeschrieben. Sie wird aber nach einer Umleitung über den Relay-Pool versendet, der nicht im SPF-Record von Office 365 enthalten ist.


Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/sender-rewriting-scheme-upcoming-changes/ba-p/2632829

Das macht Sinn, denn ein Spammer könnte ja eine Mail mit einer Domain senden, die in einem Office 365 Tenant verwendet wird und einen "include protection.outlook.com" in ihrem SPF-Record hat. Würden dann die Mail über den regulären Pool verwendet. dann würde das Ziel (EmpfängerC) eine Mail von AbsenderA über die regulären Mailserver von Exchange Online bekommen und der SPF-Check wäre fälschlicherweise ein PASS. Ein Spammer könnte sich so einen Bonus erschleichen. Das Verhalten konnte ich bei meinem Tests nachweisen:

SPF-Station    SourceIP                   Hostname
Kein SPF       40.95.79.58                mail-be0deu01rlnn2058.outbound.protection.outlook.com
SPFPass        2a01:111:f403:2622::701..  mail-be0deu01on20701.outbound.protection.outlook.com

Wurde die Mail nicht mit einem SPF=PASS vorne eingeliefert, wurde sie hinten über den Relay-Pool versendet.

Ich wäre gerne mal Mäuschen bei der Designphase gewesen. Die Liste aller Fälle und deren Reaktion muss ganz schön lang sein und wie stellt man sicher, dass man alle Sonderfälle erwischt hat?

SRS und 3rd Party

Kommen wir nun zu einer Konstellation, die mit SRS das Leben für 3rd Party Spamfilter nicht einfacher macht. Das folgende Bild zeigt ein Routing aus dem Internet über NoSpamProxy zu Exchange Online. Exchange Online leitet die Mail dann wieder nach Extern weiter, wobei der Versand auch wieder über das vorgelagerte Spamgateway laufen soll.

Klassisch wird dazu in Exchange Online ein Partner Inbound Connector angelegt, um Mails an den Tenant nur noch über das Gateway zuzulassen und ein Partnerconnetor für den Adressraum "*" stellt sicher, dass alle Mails zum Internet nicht über den Standardroute von Exchange Online sondern ebenfalls über das Gateway gehen. Hier gibt es dann zwei Aufgabe zu lösen:

  • Eingehend: SPF und SRS
    Damit SRS überhaupt von Exchange Online angewendet wird, muss Exchange Online ein "SPF=PASS" ermitteln können. Exchange Online sieht technisch eine einliefernde IP-Adresse von NoSpamProxy, die eher nicht im SPF-Record der Absenderdomain enthalten ist. Als Exchange Online Admin müssen Sie daher nicht nur einen "Inbound Partner-Connector" für den Empfang vom Spamfilter anlegen, sondern zusätzlich "Enhanced Filtering" auf https://security.microsoft.com/skiplisting beibringen, dass er nicht die letzte, sondern vorherige IP-Adressen aus dem "Received By"-Header auswertet:

    Sie sollten nach der Einstellung eine Mail aus dem Internet über das Gateway an Exchange Online senden und im Header ein "Authentication-Results spf=pass" sehen. Hier ein exemplarischer Header einer Mail der Domain rimscout.com über NoSpamProxy an mein Exchange Online Postfach

    Sie sehen in der vorletzten Zeile die 40.107.135.72 als einliefernde IP an NoSpamProxy, die aber auch weiter oben von Exchange Online wiedererkannt wurde. Exchange Online braucht ein SPF=PASS, damit SRS bei Umleitungen aktiviert wird.
  • Ausgehende Domains
    Die zweite Herausforderung ist der Versand über den Spamfilter in die Welt. Im Regelfall kommen ja nur Mails von Domains, die dem Kunden gehören und im Gateway auch als "Allowed Domains" angelegt wurde. Wenn Exchange Online die HeaderFrom-Adresse nun per SRS umschreibt, dann kommt beim Gateway auch eine Mail aus der Kundendomain an. Eventuell sollten prüfen, dass auch die "<tenantname>.onmicrosoft.com" und "<tenantname>.mail.onmicrosoft.com" mit auf der Liste sind.
    Was machen Sie aber, wenn Exchange Online kein SRS macht, weil die einliefernde Domain weder SPF noch DKIM macht? Dann wird Exchange Online die Absenderadresse nicht umschreiben und ihr vorgelagertes Gateway lehnt die Mail natürlich ab. Sie kommt ja vielleicht von einem anderen Tenant und sollte als "eingehend aus dem Internet betrachtet werden.
    Hier gibt es dann drei Lösungswege:
    - Das Gateway erkennt die Mail, weil sie ein paar Sekunden vorher schon eingehend versarbeitet wurde. Hoffentlich ist es keine Loop
    - Das Gateway nutz Felder wie "X-MS-Exchange-CrossTenant-Id", um den Source-Tenant zu erkennen und ignoriert die MailFrom-Header
    - Exchange Online bekommt einen Connector, der Mails mit fremden Domain nicht über das Gateway sondern anhand der Exchange Online Route und die RelayServer sendet.
  • SRS mit <tenantname>.onmicrosoft.com
    Eine dritte Thematik ist zu beachten, wenn Exchange Online die Tenantdomain für SRS verwendet. Auch für <tenantname>.onmicrosoft.com gibt es einen vordefinierten SPF-Record, den sie nicht ändern können.

    Das führt zu dem Problem, dass so umgeschriebene Mail nie über ein 3rdParty-Gateway gesendet werden können, da Sie dessen IP-Adressen nicht über ein "include" auf die "Allowed Hosts"-Liste eintragen können. In dem Fall bleibt nur der direkte Versand der Mails mit dieser Domain am eigenen Gateway vorbei.

Besser finde ich hier natürlich den kompletten Verzicht, eingehende Mails an eine "<tenant>.onmicrosoft.com"-Adresse zu senden. Diese Domain könnten Sie bei einem Umzug zu einem anderen Service nie mitnehmen. Aus dem gleichen Grund kann ich nur mit dem Kopf schütteln, wenn auf dem Handwerkerbulli eine "<firmenname>@t-online.de" steht, nur weil das damals als Telekom-Monopolkunde die erste Mailadresse war.

Übrigens ist die "<tenantname>.onmicrosoft.com"-Adresse auch nicht aus dem Internet erreichbar, wenn Sie z.B. über einen Partner Connector eingehende Mails nur über ihr vorgelagertes Gateway zulassen um Exchange Online als Nebeneingang für Mailempfang zu unterbinden.

DMARC verhindert Umleitungen

Wenn Sie sich die erste Testreihe anschauen, dann sehen Sie bei allen Weiterleitungen fast alle DMARC-Optionen auf ROT gehen. Wenn AbsenderA auch nur eine DMARC-Policy anlegt, dann scheitert es immer am Alignment der Domains und Weiterleitungen werden auch mit gültiger DKIM-Signatur eigentlich abgewiesen. Zum Glück scheinen nicht alle Mailserver mit DMAC-Support das so streng zu sehen, wie es der Standard definiert hat und nehmen die Mails auch an, wenn das Alignment nicht passt. Sie werden dann einfach den SPF-Record auf den MailFrom und die DKIM-Prüfung auf den Header-From aus.

Ich würde heute fast empfehlen, auf DMARC zu verzichten, wenn Sie eine Weiterleitung ihrer Mails durch einen Empfänger erlauben wollen

Umleitung auf Umleitung?

Dass ich generell gegen Umleitungen bin, wenn Sie nicht durch einen Administrator im Rahmen einer Migration oder Koexistenz verwaltet wird, sollte sich herumgesprochen haben. Sobald DMARC genutzt wird, hilft weder der durch SRS ermöglichte SPF=PASS noch eine durch den ersten Absender ggfls. angebrachte DKIM-Signatur weiter, da das Alignment von "Envelope FROM" und "Header FROM" nicht mehr passt. Aber auch dem EmpfängerC ist es ja nicht verboten, die Mail erneut auf einen EmpfängerD umzuleiten.

Wenn Empfänger C nur einen einfachen SPF-Check oder DKIM-Check macht, weil er DMARC nicht kann oder der AbsenderA keinen DMARC-Eintrag veröffentlicht, dann könnte auch dieser Server die Absenderadresse erneut umschreiben.

Zusammenfassung

Erste Überlegungen zu SRS starteten 2005 und auch wenn sich das Verfahren weiterentwickelt hat, ist es dennoch ein Versuch ein Problem zu lösen, welches Sie ohne Weiterleitungen und Umleitungen gar nicht hätten. SRS mit Exchange Online hilft, wenn der Absender einen SPF-Eintrag veröffentlicht hat und auch der EmpfängerB mit SPF für die umgeschriebene Domain dem Spamfilter bei EmpfängerC hilft, die Absenderdomain zu validieren. Fehlt einer der beiden SPF-Einträge, dann steigt die Wahrscheinlichkeit, dass die Mails als Spam endet.

Sobald aber AbsenderA noch einen DMARC-Eintrag veröffentlicht, wird durch die Umleitung mit SRS bei EmpfängerB das DMARC Alignment brechen. Wenn das der Spamfilter bei EmpfängerC dann DMARC auswertet, hilft auch ein SPF=PASS nicht mehr weiter.

Egal wie sie es drehen und wenden. Es sind drei Server involviert die für SPF, DKIM und DMAR unterschiedliche Einstellungen veröffentlichen können und es gibt immer einen Fall, dass die Überprüfung die Mail als nicht legitim bewertet und ablehnt oder ein eine Quarantäne verschiebt.  Umleitungen können Sie "sicher" nur nutzen, wenn der Betreiber von EmpfängerC bei sich dem ServerB eine Ausnahme einrichtet und ihm vertraut. Das ist bei Migrationen, bei denen sich B und C "kennen", kein Problem. Allerdings sollte natürlich der Spamfilter von EmpfängerB nicht schlechter sein, als von EmpfängerC.

Weitere Links