EXO SRS - Sender Rewriting Scheme (SRS)

Sender Rewriting Scheme ist ein Verfahren zum Umschreiben der Absenderadresse im Envelope einer Mail, damit die Empfänger den SPF-Check durchführen kann. Mitte 2018 hat Microsoft diese Funktion für bestimmte Umleitungen/Weiterleitungen auch in Exchange Online eingeführt. 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.

Weiterführende Informationen habe ich auf Umleitung/Weiterleitung mit SPF/DKIM/DMARC/SRS bereitgestellt

Warum SRS?

Seit dem Menschen per Mail Informationen austauschen, gibt es auch den Bedarf Mails von einem Absender A einen primären Empfänger B von dort an einen Empfänger C weiterzuleiten. Szenarien sind:

• Empfänger B möchte die Mail auch in einem zweiten Postfach C lesen
• Empfänger B ist eine Verteilergruppe, die alle Nachrichten an die Mitglieder verteilt
• Empfänger B wird zum Zielsystem C migriert und für eine Übergangszeit

Solange Empfänger B und Empfänger C in einem vertrauenswürdigen System liegen, funktioniert dies problemlos. Sobald aber Empfänger C wieder außerhalb von Empfänger B ist, wird es kompliziert, wenn der Absender A beibehalten werden soll. Denn heute schützen Absender A ihren guten Namen der Domain durch SPF, DKIM, DMARC und auch Empfänger C schaut genau hin, mit welchen Adressen hier "System B" Mails einliefern will.

Bei SRS wird der "MAIL FROM", d.h. die Absenderadresse im SMTP-Envelope, auf eine Domain des Servers gesetzt, für die er zuständig ist. Der Server C sieht nun eine eingehende Verbindung von Server B mit einer SMTP-Domain als Absender im Envelope, für die auch der Administrator B verantwortlich ist. Hinsichtlich SPF bedeutet dies:

• Server C sieht nicht die Domain A als "Absender"
  Damit ist die SPF-Veröffentlichung von Server A nicht zu berücksichtigen. Ein "SPF=-all" der Domain A stört damit nicht den Empfang
• Server C sieht die Domain B als "Absender"
  Damit ist die SPF-Veröffentlichung von Server B maßgeblich

In einer reinen SPF-Umgebung kann so eine Weiterleitung und Umleitung erfolgreich konfiguriert werden und auch der Empfänger C ist zufrieden, da der Anwender sich nicht um den Envelope kümmert, sondern den Absender aus dem Header der Mail anzeigt.

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:

• Umleitung/Weiterleitung mit SPF/DKIM/DMARC/SRS
• Verteiler und SPF/DKIM/DMARC
• SPF ?all und Umleitungen

Bildungsregel und Rückmeldungen

Der Envelope-Absender hat aber noch eine zweite wichtige Funktion. Wenn die Mail im Zielsystem nicht zugestellt werden kann und der Mailserver im Ziel nicht schon bei der Übertragung dies durch einen Fehler dem Absender sagt, dann ist es die Aufgabe des Zielservers eine Unzustellbarkeit zu erzeugen. Nun könnte man natürlich einfach eine Absenderadresse generieren, die den AbsenderA als Userpart enthält. Schon früher gab es solche Adressen.

SRS=<MailboxA>=<DomainA>@DomainB

Das wurde so aber dann doch nicht spezifiziert, denn es wäre schon sehr einfach, eine Mail an Domain A über Server B zu routen. Daher wurden bei SRS noch zwei weitere Komponenten addiert, die ein "Erraten" der Rückadresse durch fremde Personen unmöglich macht. Ansonsten könnte jemand ja die Dienste von Server B missbrauchen, um eine Nachricht indirekt zu einem Server A zu senden.

• Timestamp
  Wenn die Rückadresse nur eine gewisse Zeit gültig ist, dann reduziert das dies das Risiko eines Missbrauchs.
• Hash
  Die Server der Zwischenstation B haben einen geheimen "Salt" und erstellen aus der weiterleitenden Mailbox und die Absenderadresse A, einem Zeitstempel und dem Geheimnis einen Hashwert. Den kann ein Angreifer eigentlich nicht ermitteln.

Exchange orientiert sich an folgender Regel.

<MailboxB>+SRS=<Hash>=<Timestamp>=<DomainA>=<MailboxA>@DomainB

Dies ist aber nicht vorgeschrieben und andere Mailserver können andere Regeln nutzen, denn es betrifft den "Userpart" einer Mail, z.B.

SRS0=<Hash>=<timestamp>=example.org=alice@example.com

In SRS V1 gab es den Timestamp noch nicht.

Das gleiche Schema kann ein Mailserver auch nutzen, um z.B. "Bounces" eigene Adresse generieren. Exchange nutzt z.B. folgendes Schema:

bounces+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Customer's Default Accepted Domain>

Damit es keine "Loops" gibt, sollte natürlich "Server B" die weitergeleitete Mail mit einem "<>"-Absender weiterreichen.

Wann macht Exchange Online SRS?

Wenn sie eine Mail an einen Exchange Empfänger senden, gibt es mehrere Möglichkeiten diese Mail an einen Empfänger C umzuleiten.

Exchange OnPremises hat keine SRS-Funktion. Die Funktion gibt es nur in der Cloud.

In Exchange Online muss der Administrator auf dem Tenant die automatischen Weiterleitungen über Remote-Domains und die ausgehenden AntiSpam für Um/Weiterleitungen erst erlauben.

Allerdings werden bereits per SRS umgeschriebene Mails nicht erneut umgeschrieben.

Auch wenn es eine Wiederholung ist: SRS schreibt die Envelope (P1)-Adresse um aber nicht die "From"-Adresse in im Header, die der Anwender sieht. Ein DMARC-Eintrag erzwingt aber, dass die Domains beider Adressen gleich sind und ist damit immer "Fail".

• Sender Rewriting Scheme (SRS) in Microsoft 365 -
  https://learn.microsoft.com/en-us/microsoft-365/troubleshoot/antispam/sender-rewriting-scheme#summary

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.

• Sender Rewriting Scheme (SRS) coming to Office 365
  https://blogs.technet.microsoft.com/exchange/2018/06/15/sender-rewriting-scheme-srs-coming-to-office-365/
• Sender rewriting scheme for forwarded emails from Office 365
  https://www.microsoft.com/en-us/microsoft-365/roadmap?filters=&searchterms=Sender%2CRewriting%2CScheme
• MC649482 – (Updated) Sender Rewriting Scheme (SRS) Expanding to SMTP/Mailbox Forwarding
  https://app.cloudscout.one/evergreen-item/mc649482/

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.

• Sender Rewriting Scheme Upcoming Changes
  https://techcommunity.microsoft.com/t5/change-team-blog/sender-rewriting-scheme-upcoming-changes/ba-p/2632829
• Sender Rewriting Scheme (SRS) in Microsoft 365
  https://learn.microsoft.com/en-us/exchange/reference/sender-rewriting-scheme
• Sender Rewriting Scheme (SRS) coming to Office 365 (2018)
  https://techcommunity.microsoft.com/t5/exchange-team-blog/sender-rewriting-scheme-srs-coming-to-office-365/ba-p/607932

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.

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

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

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

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

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

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

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.

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

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

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.

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.

• RFC2821 Simple Mail Transfer Protocol
  https://www.ietf.org/rfc/rfc2821.txt
• What is the maximum length of a valid email address?
  https://blog.moonmail.io/what-is-the-maximum-length-of-a-valid-email-address-f712c6c4bc93

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

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?

• 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?view=o365-worldwide#relay-pool 
• Schutz vor ausgehenden Spam in EOP
  https://learn.microsoft.com/de-de/microsoft-365/security/office-365-security/outbound-spam-protection-about?view=o365-worldwide  

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.

• EXO mit NoSpamProxy
• Partner Inbound Connector
• Enhanced Filtering
• Erweiterte Filterung für Connectors in Exchange Online
  https://learn.microsoft.com/de-de/Exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/enhanced-filtering-for-connectors
• Microsoft 365: Basics - Anleitung zu Pflegen von DNS-Domains in Office 365
  https://learn.microsoft.com/en-US/microsoft-365/admin/get-help-with-domains/dns-basics?view=o365-worldwide&WT.mc_id=365AdminCSH_inproduct

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.

Solange die Spamfilter und "guten Absender" einfach nur SPF-Einträge veröffentlicht und geprüft haben, ist eine Fälschung der Absenderdomain für mit "SPF:-all" kaum möglich. Leider hat man bei der Definition von SPF eher die Verhinderung von DDoS-Attacken auf Mailserver im Hinterkopf gehabt, die NDR-Meldungen (Siehe NDR-Backscatter) an unbeteiligte Absender verhindern wollten. Das ist heute immer weniger relevant, da viele Spamfilter die Mails z.B. anhand anderer Überlegungen gar nicht erst annehmen und daher auch keinen NDR erstellen müssen. Für die Anwender hilft SPF aber nicht, denn Sie sehen gar nicht den Absender auf dem Umschlag sondern den Header-From-Absender, der bei einfachen SPF-Prüfungen nicht einbezogen wird.

Erst durch die Veröffentlichung eines DMARC-Eintrags der "Domain A" wird auch der "Header-From" in die Bewertung einbezogen. Ein entsprechend konfigurierter Empfänger wird den DMARC-Eintrag zur  beiden Header-Domain ermitteln und dann prüfen, ob die Envelope-Domain entsprechend der DMARC-Richtlinien (strict oder relaxed) dazu passt.

Sollte die Domain nicht passen, dann ist das DMARC-Ergebnis immer ein FAIL, selbst wenn der SPF-Test eigentlich ein PASS liefert. Es hilft dann nicht einmal, wenn DKIM ein "Pass" liefert.

Weitere Details zu diesen zusätzlichen Herausforderungen finden Sie auf Umleitung/Weiterleitung mit SPF/DKIM/DMARC/SRS.

Wenn sie für ihre Domain eine Weiterleitung durch andere Firmen erlauben wollen, dann müssen Sie auf DMARC verzichten. Besser ist es, wenn Sie die Weiterleitungen ihrer Empfänger "erkennen" und besser gleich den richtigen Empfänger anzuschreiben.

Nutzen von SRS?

Es ist schon komisch, dass die ersten Entwürfe von SRS im Jahr 2003 (http://www.open-spf.org/svn/project/specs/drafts/draft-mengwong-sender-rewrite-01.txt) entstanden und die RFC4408 dann 2006 veröffentlicht wurde. Es dann aber über 12 Jahre gedauert, bis auch Exchange Online die SRS-Funktion bekommen hat. Das ist zwar spät und wird in Anbetracht der Zunahmen von DMARC auch immer weniger nützlich, da damit nur Weiterleitungen möglich sind, wenn der "Absender A" und/oder der "Empfänger C" kein DMARC nutzen. Zudem ist es suspekt, wenn Microsoft nicht alle von Administratoren oder Benutzern automatisch konfigurierbare Umleitungen mit SRS umschreibt.

SRS ist in Exchange Online da und kann aktuell nicht konfiguriert werden. Sie werden damit leben müssen, dass eine umgeleitete Mail nur bei Zielen ankommt. die entweder Microsoft vertrauen, keine DMARC-Prüfung machen oder Absender keine DMARC-Einträge publiziert.

Ich hätte mir gewünscht, dass Microsoft nur dann SRS einsetze, wenn die "Absenderdomain A" keinen DMARC-Eintrag hat oder "Absender A" eine gültige DKIM-Signatur angebracht hat. Dann würde mich bei Server C auch der SPF-Fail nicht stören, solange das "DMARC-Alignment" gültig ist und die Mail dank DKIM verifiziert werden kann.

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

• Spam und UCE - Filter: SRS, HashCash
• SPF, DKIM und DMARC jetzt!
• Google blockt Domain ct.de wegen Microsoft?
• Umleitung/Weiterleitung mit SPF/DKIM/DMARC/SRS
• Verteiler und SPF/DKIM/DMARC
• SPF ?SPSPF ?all und Umleitungen
• MOERA - Microsoft Online Email Routing Address
• SMTP P1/P2-Felder
• Envelope und Header
• DMARC bricht SPF mit SRS
• Exchange Online als Nebeneingang für Mailempfang
• NDR-Backscatter
• Partner Connector
• Enhanced Filtering
• Message Center Post MC649482: SRS
  https://admin.microsoft.com/minportal/Home#/MessageCenter/:/messages/MC649482
• Sender Rewriting Scheme
  https://de.wikipedia.org/Sender_Rewriting_Scheme
  https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme
• Sender Rewriting Scheme (SRS) coming to Office 365
  https://blogs.technet.microsoft.com/exchange/2018/06/15/sender-rewriting-scheme-srs-coming-to-office-365/
• Sender rewriting scheme for forwarded emails from Office 365
  https://www.microsoft.com/en-us/microsoft-365/roadmap?filters=&searchterms=Sender%2CRewriting%2CScheme
• Set-OutboundConnector
  https://learn.microsoft.com/en-us/powershell/module/exchange/set-outboundconnector
• MC649482 – (Updated) Sender Rewriting Scheme (SRS) Expanding to SMTP/Mailbox Forwarding
  https://app.cloudscout.one/evergreen-item/mc649482/
• Sender Rewriting Scheme
  https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme
• Sender Rewriting Scheme (SRS) in Exchange Online
  https://blog.icewolf.ch/archive/2021/04/06/sender-rewriting-scheme-srs-in-exchange-online/
• RFC4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
  https://datatracker.ietf.org/doc/html/rfc4408
• Sender Rewriting Scheme (SRS) in Microsoft 365
  https://learn.microsoft.com/en-us/microsoft-365/troubleshoot/antispam/sender-rewriting-scheme
• Sender Rewriting Scheme (SRS) coming to Office 365
  https://techcommunity.microsoft.com/t5/exchange-team-blog/sender-rewriting-scheme-srs-coming-to-office-365/bc-p/2237609
• Sender Rewriting Scheme
  https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme
• Sender Rewriting Scheme (SRS) in Exchange Online
  https://blog.icewolf.ch/archive/2021/04/06/sender-rewriting-scheme-srs-in-exchange-online/
• Sender Rewriting Scheme
  https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme
• Sender Rewriting Scheme - For Forwarders and Remailers To Rewrite Sender Addresses
  http://www.open-spf.org/svn/project/specs/drafts/draft-mengwong-sender-rewrite-01.txt
• libsrs2 is the next generation SRS library
  https://www.libsrs2.org/
• meta:span - Mail-SRS-0.31 /Mail::SRS
  https://metacpan.org/pod/Mail::SRS
• Exim Internet Mailer - Chapter 58 - DKIM, SPF, SRS and DMARC
  https://www.exim.org/exim-html-current/doc/html/spec_html/ch-dkim_spf_srs_and_dmarc.html