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 sendet und empfängt, muss sich mit dem Thema Spam und Spoofing herumschlagen, 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:

Verfahren Relevante Felder Beschreibung

SPF

Envelope-From

Der Absender A veröffentlicht per DNS eine Liste der "erlaubten Absender-Adressen". Mit einer SPF-Richtlinie "-all" sind alle anderen Systeme nicht mehr zugelassen und jeder Empfänger B, der SPF konsequent prüft, sollte solche Mails direkt ablehnen.

SPF schaut dabei auf den Absender A des Briefumschlags aber nicht im darinliegenden Anschreiben. Dieser Schutz funktioniert nur, wenn der Absender alle Server kennt und eingetragen hat. Aber es gibt Probleme, wenn ein Empfänger die Mails an ein drittes System C umleitet und der Umleiter B als "Versender" erscheint. Das finale Ziel prüft die erste Absenderadresse, die nicht im SPF-Eintrag von A passt und lehnt ab.

DKIM

Header-From

Hier kommt DKIM ins Spiel. Der Absender A signiert die Mail und ausgewählte Kopfzeilen (z.B. Absender, Empfänger, Betreff, Datum des Anschreiben) und addiert die Information zur Mail. Passende dazu hat der Absender auch die Informationen zur Prüfung im Internet per DNS-Eintrag bekannt gegeben. Ein Empfänger kann nun beim Empfang prüfen, ob die Mail unverändert ist. Das erfolgt unabhängig vom einliefernden Server und SPF. Eine per DKIM vom Absender signierte Mail sollte idealweise auch nach einer Umleitung unverändert sein. Ein Angreifer kann die DKIM-Signatur nicht fälschen aber er kann eine Mail ohne DKIM Signatur senden.

DMARC

Envelope-From-Domain zu HeaderFrom-Domain

Es gibt einen Unterschied zwischen dem Absender auf dem Umschlag und dem Absender im darin liegenden Anschreiben. Der Umschlag ist nur für den Postboten wichtig. Sie kennen es auch vom Briefdienst, dass z.B. ein Dienstleiter Briefe als Kunde versendet. Mittels DMARC kann ein Absender vorgeben, wie ein Empfänger auf ein DKIM=FAIL bzw. SPF=FAIL reagieren und wohin er einen Bericht senden soll. Viel wichtiger ist aber, dass DMARC eine "Ausrichtung" (Engl. Alignment) der beiden Absender steuert. Damit kann erschwert werden, dass jemand sich auf dem Anschreiben als falscher Absender ausgibt.

SRS

 

Der sendende Mailserver schreibt die Envelope-From-Domain um, damit beim Ziel eine SPF-Prüfung erfolgreich ist. Der Envelope-From ist für den Empfänger nicht zu sehen.

ARC

 

Diesen Weg nutzen große Firmen, die viele Anwender mit Umleitungen haben, um gegenüber anderen Firmen ihre Legitimation zu beweisen. Quais ein "Trust" zwischen Providern wie Hotmail, GMail und Yahoo und klammere ich auf dieser Seite aus. ARC kann aber auch im Innenverhältnis genutzt, werden, z.B. wenn ein vorgelagerter Spamfilter eine SPF/DKIM/DMARC-Prüfung durchgeführt hat und die Ergebnisse einem nachgeschalteten System sicher mitteilen will.

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 (EnvelopeFrom, P1 oder RFC5321) und dem darin liegenden Anschreiben mit einem eigenen Absender und Empfänger (HeaderFrom, 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.

Header Originalbrief Weiterleitung PMF
PlainTextForward		 MFED
MailfromEqualFrom		 REM
Remailing		 REM+MOD
Remail+Modify		 SRS

EnvelopeFrom

NoReply@A

UserA@B

UserA@A

UserA@A

UserB@B

Listserver@B

SRS_A_UserA@B

EnvelopeTo

UserB@B

UserC@C

UserC@C

UserC@C

UserC@C

UserC@C

UserC@C

HeaderFrom

UserA@A

UserB@B

UserA@A

UserA@A

UserA@A

Listserver@B

UserA@A

HeaderTo

UserB@B

UserC@C

UserA@A

UserA@A

UserA@A

Listserver@B

UserA@A
SPF
DKIM
DMARCAlign		 -
-
-		 PASS
PASS
PASS		 FAIL
PASS
PASS		 FAIL
PASS
PASS		 PASS
PASS
FAIL		 PASS
FAILA, PASSB
PASS		 PASS
PASSA
FAIL

Spamergebnis

-

PASS

FAIL

FAIL

FAIL

PASS

FAIL

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.

Absender A sendet eine Mail an B und alle drei Checks 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.

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 Mails an Postfächer auf anderen Servern weitergeben. Das ist dann meist ein serverseitiges Umleiten, z.B. in Exchange über das Feld TargetAddress, Forwardingsmtpaddress.
  • Mailinglisten und Listserver
    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 an ein anderes Postfach kopieren 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 um die Funktion kümmern, damit die legitimen Umleitungen möglich sind während verbotene Umleitungen unterbunden werden. Die Verbote könnten 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 weder sicher noch 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 (Envelope) aber nicht die "To:-Zeile" im Header und behalten auch den Absender bei. 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 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 kann als legitime Mail von Absender A bei Server C erkannt und zugestellt werden.

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. Genau dazu wurde SRS entwickelt. Die MAILFROM-Domain im SMTP-Handshake passt zum Mailserver und dem SPF-Eintrag. Dass der "Userpart" davor anders aussieht, interessiert einen einfachen SPF-Checker nicht.

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 SPF-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.

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