Umleitung/Weiterleitung mit SPF/DKIM/DMARC/SRS

Diese Seite entstand als Ergänzung zu Google blockt Domain ct.de wegen Microsoft? zur Erläuterung der technischen Hintergründe.

Vorabinformation

Wer heute Mails sende und empfängt, muss ich mit dem Thema Spam und Spoofing rumschlagen, d.h. Absender geben vor jemand zu sein, der Sie nicht sind um den Empfänger zu überrumpeln. Damit dies erschwert wird, setzen Empfänger Filter ein, die Informationen der Absender auswerten. Dazu gibt es mehrere Bausteine:

Das hilft natürlich alles nichts gegen "ähnlich klingende Domains". Aber das kenne wir auch schon von Werbung für Einträge in angeblich offiziellen Branchentelefonbüchern.

Für die folgende Beschreibungen gehen wir davon aus, dass Absender A und Um/Weiterleiter B ihre Domains mit "SPF=-all" abgesichert, die Mails mit DKIM Signieren und einen DMARC-Eintrag mit p=reject haben. Zudem prüfen die empfangenden Server B und C sowohl SPF und DKIM und folgen den DMARC-Vorgaben.

Weiter-/Umleitung

Eine Mail besteht aus einem Umschlag mit Absender und Empfänger (Envelope, P1 oder RFC5321) und dem darin liegenden Anschreiben mit einem eigenen Absender und Empfänger (Header, P2, RFC5322. Diese müssen nicht identisch sein und das Transportsystem interessiert sich nur für dem Umschlag (Envelope). Wenn Sie einen Brief bekommen, dann kann diese umgeleitet werden, d.h. der Empfänger sieht auch noch den Absender oder er kann "weitergeleitet" werden, d.h. die Zwischenstation schreibt etwas um. Dazu gibt es nicht nur eine sondern gleich mehrere Möglichkeiten. Die Domain habe ich verkürzt mit A, B, und C bezeichnet.

In folgendem PDF haben sich im April 2023 einige Universitäten mit dem Thema Forwarding beschäftigt, insbesondere mit abweichenden EnvelopeFrom und der Nutzung von Listservern/Mailinglisten. Eine häufig noch genutzte Technik zur Kollaboration von Teams über Institutionen hinweg. Ich nutze deren "Abkürzungen" in der Überschrift

Forward Pass: On the Security Implications of Email Forwarding Mechanism and Policy
https://arxiv.org/pdf/2302.07287.pdf

Beim EnvelopeFrom bei einer Spamprüfung nur die Domain wichtig. Es gibt aber Fälle, an denen Der EnvelopeFrom geändert wird. Der HeaderTo ist hinsichtlich Spamfilterung in allen Fällen irrelevant. Für alle Domains wird ein "SPF =-all" mit unterschiedlichen Servern, gültige DKIM-Signaturen und DMARC-Eintrag P=Reject angenommen.

Betrachtet wird die Verbindung von Host B zu Host C.

Wenn Domain A und Domain B beide mit SPF, DKIM und DMARC arbeiten, dann kann ein Benutzer in Domain B keine Mails an sein Postfach automatisiert an ein Postfach in Domain C umleiten. Es geht nur, wenn es eine Weiterleitung ist, d.h. der Empfänger in B die Mails als ls Zitat oder Anlage an den Empfänger C weiterleitet. Der Empfänger C "sieht" dann natürlich die Weiterleitung und den Benutzer B als Absender. Bei Migrationen und Koexistenz ist dies natürlich keine Lösung.

Denkbar wäre natürlich, dass der Server C dem Server B "vertraut". Das macht z.B: die Exchange Hybrid Konfiguration oder große Provider über ARC. Würde Domain A keinen DMARC-Record veröffentlichen, dann würden auch alle Fälle mit einem DMARC-Alignment-Fehler wieder funktionieren. Aber darauf haben weder B noch C Einfluss und warum sollte der Domaininhaber A auf DMARC verzichten. Er möchte ja seine Maildomain gerade gegen Missbrauch sichern.

Weiterleitung

Da ich die späteren Kapitel um das Thema "Umleiten" kümmern, nehme ich den einfachen Fall einer "Weiterleitungen" vorweg. Bei Weiterleitungen wird die originale Mail in eine neue weitergeleitete Mails eingebettet.

A sendet eine Mail an B und alle drei Check sind erfolgreich. B packt dann die Mails in eine neue Mail, die von B an C gesendet wird. Das funktioniert eigentlich immer problemlos aber ist für den Anwender unschön, da er in einem Posteingang bei den so weitergeleiteten Mails immer den Absender "B" sieht. Wenn er wissen will, von dem die Mail ursprünglich gesendet wurde, muss er die Mail öffnen. Auch ein "Antworten" funktioniert in der Regel nicht, da er damit nur eine Mail an das Postfach "B" sendet und im schlimmsten Fall seine eigene Mail wieder bekommen.

Wenn er nun von Hand den Empfänger der Antwort auf "A" umstellt oder B freundlicherweise ein "Reply-To:A" addiert hätte, sind dennoch manuelle Schritte erforderlich um die zitierte Mail zu bereinigen.

Das ist dann der Moment, wo eine Umleitung gefordert wird, d.h. im Postfach von C soll eine Mail ankommen, als wäre sie direkt von A gekommen. Da der physikalische Transportweg aber über den Server B geht, stellt dies neue Herausforderungen an Spamfilter und Definitionen.

Dennoch funktioniert so eine Weiterleitung in der Regel problemlos, wenn der Administrator die Verwendung von automatischen Regeln diesbezüglich nicht unterbunden hat.

• ReplyTo
  https://de.wikipedia.org/wiki/Header_(E-Mail)

Warum überhaupt umleiten?

Es gibt durchaus berechtigte Gründe für legitime Umleitungen. Aber es gibt auch Umleitungen, die sie als Firma nicht zulassen sollten und entsprechend können Sie Umleitungen bei einigen Systemen wie z.B. Exchange Online serverseitig pauschal unterbinden und zur für bestimmte Ziel-Domänen zu lassen.

• Merger&Aquisition
  Umstrukturierungen gehören zum Tagesgeschäft von Firmen und Dienstleistern. Postfächer auf einem System sollen auf einem neuen System bereitgestellt werden. Allerdings können Sie die Mails an einen Empfänger anhand des MX-Record nicht nach einzelnen Postfach-Adressen zu unterschiedlichen Servern leiten. Das empfangende System muss also Mails an Postfächer auf anderen Servern weitergeben. Das ist dann meist eine serverseitiger Umleiten, z.B. in Exchange über das Feld TargetAddress, Forwardingsmtpaddress.
• MailinglistenListserver
  Viele Arbeitsgruppen (IETF, RFC etc.) kommunizieren immer noch Mailinglisten, in denen man sich einschreiben kann und dann jede Mail an die Liste bekommt. Je nach Einstellung sehe ich als Absender dann den "echten" Absender" oder die Adresse der Liste. Im ersten Fall sendet der Listserver dann natürlich mit der Adresse und Domain des Teilnehmers, obwohl er dafür eigentlich nicht berechtigt ist.
  Der Anteil wird immer geringer, da Alternativen wie Teams, Discord, etc. bereitstehen aber Mail ist immer noch ein generisches Kommunikationsmittel
• Verteiler und SPF/DKIM/DMARC
  Eine "Lite-Version einer Mailingliste ist ein Verteiler mit externen Teilnehmern. Ein Administrator pflegt die Mitglieder als Kontakte und Exchange sende eine Mail an den Verteiler an alles Teilnehmer. Sobald die externen Teilnehmer auch die Liste erreichen, werden ihre Mails ggfls. mit der fremden Domain des Teilnehmers weiter verteilt.
• Individuelle Weiterleitungen
  Ein dritter Fall sind Mitarbeiter, die Mails an ihre Postfach auch noch einem anderen Postfach zuleiten wollen, z.B. an die Urlaubsvertretung oder als "Backup" an ein Archivsystem. Innerhalb einer Firma kann das legitim sein aber wenn Mitarbeiter eingehende Mails direkt an z.B. ein GMX-Postfach zustellen, damit sie diese unerlaubt auch von zuhause lesen können, dann ist das anders zu bewerten. Es ist aber technisch entweder eine Weiterleitung oder Umleitung, die der Anwender einrichtet.

Wir müssen uns also um die Funktion kümmern, damit die legitimen Umleitungen möglich sind und verbotene Umleitungen unterbunden werden. Die Verbote können und sollten Sie immer auf ihrem Mailserver oder Spamfilter umsetzen und nicht darauf hoffen, dass die Gegenseite C eine umgeleitete Mails aufgrund von Spambewertungen ablehnt. Das ist nicht weder sicher und stabil. Die legitimen Umleitungen müssen aber immer funktionieren und dazu müssen wir auch die Spamfilter im Ziel C betrachten.

Umleitungen dank DKIM

Im ersten Fall ändert der Server B einfach Zieladresse im Umschlag. Einige Server, z.B. Exchange Online, addieren sogar eine DKIM-Signatur, obwohl dies unsinnig ist. Der Server B hat ja nicht das Schüsselmaterial für Domain A und eine Signatur mir Domain B-Schlüsseln wird vom Ziel nicht ausgewertet, dass Domain B nicht zum Absender A passt.

Wenn Server B eine Mail mit der Domain A sendet aber nicht nicht auf der Allow-List von Domain A steht, dann schlägt der SPF-Check fehl. Da allerdings weder in der Mail noch im Umschlag der Absender geändert wurde, passt das DMARC-Alignment der Domains und wenn der Server B auch nichts an den Feldern geändert hat, die von Server A bei der DKIM-Signatur einbezogen wurden, dann ist die DKIM-Signatur von Server A weiterhin gültig. Die Mail wird als legitime Mail bei Server C erkannt und zugestellt.

Umleitungen mit SRS und SPFOnly

Leider addieren nicht alle Server DKIM-Signaturen oder prüfen diese und wenn nur SPF genutzt wird, dann funktioniert die Umleitung nicht mehr. Aber dazu wurde SRS "erfunden", d.h. der Server B ändert einfach die Absenderadresse es Umschlags, damit Server C wieder ein SPF=Pass erreicht. So eine Absenderadresse endet auf die Domain B aber vor dem @ steht die Information über den Absender

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

So kann eine Unzustellbarkeitsmeldung o.ä. an die Adresse der Domain B wieder an den Ausgangssender A übertragen werden. Diese generierte Adresse ist immer nur eine kurze Zeit gültig und Anwender sehen diese eigentlich nie. Für die Übertragung der Mail von Server B nach Server C ändert sich dann der Envelope-From.

Das funktioniert wunderbar, wenn der Empfänger "nur" mit SPF arbeitet. Aus der Zeit stammt aus SRS.

Keine Umleitung mit SRS und DMARC

Bei den Voraussetzungen haben wir aber geschrieben dass alle Server auch DKIM und DMARC machen und dann sieht das Bild etwas anders aus, weil DMARC auch ein "Alignment" der Absenderdomains aus dem dem Envelope und dem Header erzwingt.

MIt SRS wird der PSF-Check gültig, weil die Domain B im Umschlag mit dem SPF-Eintrag der Domain B den Server legitimiert. Allerdings bricht es das DMARC-Alignment. Daher sollte ein Server B auf das Rewriting des Envelope-Absenders verzichten, wenn die Mail durch Absender A per DKIM gültig signiert ist und daher der Server C die Mail anhand der DKIMA=PASS-Prüfung annimmt.

• DMARC bricht SPF mit SRS

Umleitung mit ARC oder Trust

Wenn Sie eine Umleitung von Mails von B nach C brauchen, weil Sie z.B. eine Firma umstellen (M&A-Szenarien, Verkauf, Zukauf o.ä.) und während der Koexistenz eine Umleitung ermöglichen wollen, dann können Sie natürlich immer noch als Administrator des Spamfilters bei Server C eine Einlieferung von dem bisherigen Besitzer der Postfächer auf Server B statisch erlauben.

So ein "Vertrauen" können Sie natürlich nicht konfigurieren, wenn die Zieladressen z.B. bei Google, Hotmail oder anderen Providern liegen. Sie können auch nicht der Domain A vorgeben, wie möge bitte ihren DMARC-Record entfernen, damit der Server C nur noch einen SPF-Check macht oder vielleicht der von Server B angebrachten DKIMB-Signatur vertraut, obwohl sie eigentlich nicht zutreffend ist. Für Merger&Aquisitions von Firmen sind solche Konfigurationen denkbar.

Sie könnte aber als Admin von Server C natürlich den DMARC-Check für Mails von Server B abschalten oder temporär deaktivieren. Aber das schwächt dann auch den direkten Empfang von Mails an Domain C und keine Lösung. Die großen Provider haben dafür mit ARC eine Lösung entwickelt. In dem Fall signiert der Server B die Mail von A und das Zielsystem C vertraut diesen Signaturen.

Der Server B addiert eine ARC-Signatur, die einer DKIM-Signatur ähnlich ist. Wenn nun Server C auch ARC versteht und Server B vertraut, dann vertraut Server C darauf, dass Server B einen gleichwertigen Spamfilter hat und daher keine weiteren Prüfungen mehr erforderlich sind.

Andere Umleitungsfälle

Am Beispiel von "U3: Keine Umleitung mit SRS und DMARC" haben Sie gesehen, dass selbst mit korrekten SPF, DKIM, DMARC -Einstellungen auch legitime Umleitungen beim Empfänger blockiert werden. SRS für Umgebungen mit SPF gedacht aber mit DMARC-Alignment wieder kontraproduktiv. So können Sie sich noch ganz viele andere Kombinationen mit SPF, DKIM, DMARC vorstellen, die entweder nicht gehen oder vielleicht gehen, weil nichts verboten wird.

Ein SPF "-all" verhindert, dass ein Mail mit einem SPF-Fail zugestellt wird. Aber ein "?all" oder gar kein SPF-Eintrag überlässt es eben dem Empfänger, was seine Hausordnung vorschreibt. Es kann gelingen aber es muss nicht. Eine DKIM-Signatur kann die Authentizität einer Mail sicherstellen aber wenn Sie mit DMARC bei Zustellfehlern informiert werden wollen, dann ist das Alignment der Absenderdomain auch aktiv und blockiert SRS-Umschreibungen

Damit kommen wir wieder an den Anfang: Weiterleitungen sind i.O. auch wenn der Empfänger C dann nur Mails von B bekommt und nicht mehr sieht, das A der erste Sender war. Umleitungen werden immer mehr unmöglich, da Spamfilter und Domainschutz immer häufiger streng umgesetzt werden. Wer als Betreiber von A aber seinen Empfängern in B eine Umleitung zu C erlauben will, kann den DKIM-Eintrag entfernen, damit das Aligment nicht stattfindet und einige Varianten der Umleitungen funktionieren können. Dann mit dem Risiko, dass auch andere Personen ihre Domain missbrauchen.

Ich kann mir nur vorstellen, dass die Möglichkeit zur Umleitung von Mails auch ein Grund bei einigen Domains ist, die ein "SPF=~all" oder/und ein "DMARC p=none" verwenden. Dann kann es halt auch passieren, dass Server C solche Domains abstrafen, insbesondere wenn Sie zum Spamversand durch Dritte missbraucht werden.

Insofern sehe ich es eher als Risiko an, eine Domain mit "SPF=~all / ?all" zu veröffentlichen. Damit sind Umleitungen leichter aber wollen Sie das?

Weitere Links

• Google blockt Domain ct.de wegen Microsoft?
• SPF, DKIM und DMARC jetzt!
• DMARC-Validation
  Wie eine DMARC-Eintrag die SPF und DIM-Ergebnisse steuert
• Umleitung/Weiterleitung mit SPF/
  Wenn Server B als User A an Server C senden möchte
• Mailingliste mit DMARC, DKIM, SPF, ARC
  Die Tücken bei Verteilung von Informationen über Listserver u.a.
• Verteiler und SPF/DKIM/DMARC
  Warum sich Exchange Verteiler nicht als Drehscheibe mit externen Absendern und Empfängern eignen
• DMARC bricht SPF mit SRS
• ARC - Authenticated Received Chain
  DKIM verifiziert die Quelle, ARC die Zwischenstationen und ermöglicht so Vertrauen für Weiterleitungen/Umleitungen
• Weiterleitungen
• TargetAddress
• Forward Pass: On the Security Implications of Email Forwarding Mechanism and Policy
  https://arxiv.org/pdf/2302.07287.pdf