Google blockt Domain ct.de wegen Microsoft?

In der c't 21/2023 auf Seite 38 wird berichtet, dass ein Mailversand von der Domain "ct.de" an Google-Konten einige Wochen gestört war, weil ein Angreifer über Microsoft sehr viele Mails an Google gesendet hat. Ich war in dem Thread nicht involviert und kann nur anhand der Aussagen im Artikel analysieren, was hier schief gelaufen sein könnte, ehe ich mich am "Microsoft Bashing" beteilige.

Als Vorablektüre zum besseren Verständnis dient die Seite Umleitung/Weiterleitung mit SPF/DKIM/DMARC/SRS und SPF, DKIM und DMARC jetzt!

Nach meiner Einschätzung ist weder Microsoft noch Google schuld, sondern die SPF/DMARC-Konfiguration der Domain "ct.de". Exchange Online ist kein offenes Relay.

Der Artikel

Der Aufmacher des Artikels startet mit:


Auszug aus https://www.heise.de/select/ct/2023/21/2323709370896340290

.. Mitte Juni nahm Google plötzlich keine Mails mehr von ct.de mehr an, die Reputation der Domain sei zu gering..."

Und im Fließtext steht dann, dass Mitarbeiter der ct.de-Domain Emails weder an "gmail.de" noch an Firmen schreiben konnten, die von Google gehostet wurden, d.h. deren MX-Record auch auf Google verweist. Am 12. August 2023 hat das c't-Magazin unter der folgenden URL das Thema noch mal aufgegriffen.

Google meinte also, dass die "Domain" irgendwie suspekt ist. Die Fehlermeldung an die Absender bei ct.de deutet auch darauf hin:

Our system has detected that this message is likely suspicious 
due to the very low reputation of the sending domain.
To best protect our users from spam, the message has been blocked

Google hat die Mail aber nicht aufgrund von Spamverdacht der individuellen Mail oder einer falschen IP-Adresse mitsamt SPF-Record abgelehnt, sondern etwas "schwammig" von einer Reputation geschrieben. Als Betreiber eines Mailservice möchte ich für meine Kunden natürlich eine optimale Leistung erbringen und auch meine Ressourcen schonen. Gemäß einem "Mein Haus, Meine Hausordnung", hat Google weitere Module zur Klassifizierung von Mails, Domains, IP-Adressen etc. Sie können die Einstufung ihrer eigenen Domain über die "Postmaster-Tools" einfach einsehen.

Dort können Sie ihre Domain eintragen und per DNS-Eintrag beweisen, dass Sie die Hoheit über die Domain haben um dann den Status anzuzeigen. Ich kann zwar nicht die Domain-Reputation einer anderen Domain anschauen aber zu meiner msxfaq.de liegen bei Google keine Daten vor.

Laut dem Artikel in der c't würde die Aussage aber bei wenig Mails nur eingeschränkt sein. Für ihre "normale Firmendomain" dürfe Google sich gar nicht die Mühe machen, ein Rating zu speichern. Wenn ihre Domain aber durch ein offenes Relay oder Missbrauch mangels SPF/DKIM/DMARC bei Google-Empfänger mit vielen Mails auffällig wird, dann sollten Sie hier etwas sehen.

Vielleicht sollten Sie schon vorab ihre Domain mit einem Google Konto der Firma verbinden, um im Falle eines Falles nicht erst einen DNS-Eintrag vornehmen zu lassen. Bei einigen Firmen dauert das aus meiner Erfahrung auch mal länger.

Das Problem der Umleitungen

Ich habe schon auf mehreren Seiten das Thema "Umleitung" und "Weiterleitung und die Herausforderungen beschrieben. Bei einer Umleitung wird die Absenderadresse nicht geändert, damit Sie im Zielpostfach noch den originalen Absender sehen. Dies ist insbesondere bei Migrationen sehr wichtig, damit der Anwender schon im neuen Postfach z.B. noch Mails erhält die an die alte Adresse gehen.

Heute müssen sie aber Spamfilter im Blick haben, denn wenn A an B sendet und B an C umleitet, dann erscheint B als Absender der Domain "A". Der Admin von Domain A kann natürlich z.B. per SPF die legitimen Server vorgeben, so dass die Umleitung nur funktioniert, wenn Ziel C entweder B vertraut oder keinen SPF-Check macht oder A auch B als legitimen Absender eingetragen hat.

Die c't hat in ihrem Artikel nun sogar geschrieben, dass Sie Microsoft Teams nutzen und auch die Microsoft Server als legitime Absender im SPF-Record für ct.de hatten und sie am Ende als "Schutz" diesen Include von "protection.outlook.com" doch lieber weg gemacht haben. Solange der Eintrag drin war, konnte wirklich Microsoft Mails mit der Domain "ct.de" versenden.

Das würde aber bedeuten, dass Microsoft ein Relay beliebige Absender ist, die sich als "ct.de" ausgeben.

Ich dränge meine Kunden immer darauf, dass sie KEINE Umleitungen nach extern erlauben. Weiterleitungen können nicht verhindert werden

Bei Exchange Online ist eine automatische Umleitung allerdings per Default eingeschaltet, allerdings ist diese Einstellung nicht alleine maßgeblich.

PS C:\ > Get-RemoteDomain | fl identity,auto*
Identity : Default
AutoReplyEnabled : True
AutoForwardEnabled : True

Daher rate ich immer dazu, dies ausschalten um den eigenen Tenant abzusichern.
-> Checkliste Tenant Einrichtung

Die ist aber nicht die einige Einstellung. Microsoft hat auch noch im Security Center bei den AntiSpam-Richtlinien eine Einstellung, die ein Weiterleiten steuert.


Quelle: Control automatic external email forwarding in Microsoft 36
https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/outbound-spam-policies-external-email-forwarding

Ein Spammer kann das in seinem Tenant allerdings abschalten. Mit den richtigen Einstellungen bekommt ein Admin aber auch eine Information, wenn ein Postfach eine unbedingte Weiterleitung von Mails einträgt, weil dies auch von Hackern gerne genutzt wird, um Mails eines gekaperten Postfachs (z.B. Kennwortrücksetzlinks) zu erhalten.


Quelle: https://security.microsoft.com/alertpoliciesv2

Aber auch das wird einen Spammer nicht interessieren. Sollte die ct.de-Domain aufgrund eines anderen missbrauchten Tenants gelitten haben, dann helfen diese Einstellungen im eigenen Tenant nicht weiter.

Was könnte passiert sein?

Eigentlich gehe ich davon aus, dass ein Mail-Admin bei der c't durchaus weiß, wie man einen Mailserver betreibt und daher war ich neugierig, ob Microsoft wirklich was falsch macht. Dazu musste ich mir aus dem Artikel erst einmal ein paar Daten sammeln: Vor allem schreibt der Autor über ein spezielles „Open Forwarding“, was bei Microsoft möglich wäre aber wohl kein "Open Relay" ist. Folgendes könnte passiert sein

Phase Beschreibung

Vor Exchange Online

Die Computerzeitschrift und die Domain "ct.de" gibt es definitiv länger als Microsoft 365 und Exchange Online. Also gab es eine Zeit, als die Mailserver der ct.de ihre Mails auch problemlos zu Google senden konnten. Ich nehme nun mal an, dass der SFP-Record die Server der ct.de und ein "?all" hatte, wie es auch nach dem Vorfall der Stand ist.

Google bekam als Mails von Servern der ct.de, die per SPF auch als autoritativ geführt wurden. Also vermutlich kein Spam und wenn jemand anderes eine Mail senden wollte, dann hatte er zumindest nicht die Erlaubnis. Allerdings sagt das "SPF:?all" schon, dass GMail den SPF-Eintrag ignorieren solle. Google konnte natürlich selbst entscheiden, ob es das tut. Ein Content-Filter wird GMail immer noch nutzen.

Office 365 Nutzung

Ich weiß natürlich nicht, wie genau die Domain ct.de in einem Microsoft 365 Tenant genutzt wird, aber Sie ist eingetragen und damit jemand aus Microsoft 365 eine Mails in die Welt senden könnte, sollte der Administrator auch die Mailserver von Microsoft 365 in den SPF-Eintrag als "Include" aufnehmen. Das hat der Administrator auch getan.

Im Prinzip ist das auch in Ordnung, denn nun kann auch Gmail prüfen, dass die Mails vom Tenant authentisch ist. Das gilt natürlich nur, wenn Sie Microsoft dahingehend vertrauen, dass die Absenderadresse nicht gefälscht werden kann.

Das sichert Microsoft auch zu, dass authentifizierte Benutzer immer nur mit einer Mailadresse senden können, die in Exchange Online in dem Tenant hinterlegt ist.

Ich kann also als in meinem Tenant nicht einfach eine Adresse mit der Domain "ct.de" anlegen und damit Mails senden.

Missbrauch durch Weiterleitung

An einen Fall hat hier aber wohl niemand gedacht: Mails an Microsoft Exchange Postfächer können durch den Anwender oder den Administrator weitergeleitet und umgeleitet werden. Während bei einer Weiterleitung der Absender durch das weiterleitende Postfach ersetzt wird, wird bei einer Umleitung die Absenderadresse beibehalten.

Und hier kommt nun der böse Spammer ins Bild, der sich entweder selbst einen Tenant kaufen kann oder eines der vielen Exchange Online Postfächer missbraucht, die nicht ausreichend gesichert waren, deren Zugangsdaten abgephished wurden und kein Multi Faktor aktiv haben.

Der Spammer gibt sich nun als "ct.de" aus und wenn die Werbemail relativ gut gemacht ist, dann kommt sie auch im Postfach an. Spamfilter sind nie 100% und wenn der Tenant unter Kontrolle des Spammers ist, kann er die Spamfilter auch abschalten.

Allerdings hat auch die Domain "ct.de" mit dem schwachen SPF-Eintrag ja niemandem verboten, als "ct.de" zu senden. Mit einem "SPF:-all" statt einem SPF:?all" wüsste jeder Mailserver, dass eine Zulieferung von fremden Servern unterbunden ist.

Nachdem die Mail aber im Postfach von Exchange Online gelandet ist, konnte Sie mittels Umleitung zu einem GMail-Konto gesendet werden.

Bei GMail kam damit eine Mail von einem Microsoft 365 Server an, der im SPF-Record der Domain ct.de sogar als "autorisiert" geführt wurde. Da reichten dann wohl ein paar Empfänger, die diese Mails als Spam gemeldet haben, damit GMAIL die Domain ct.de als nicht mehr vertrauenswürdig eingestuft hat. Erschwerend kam ja dazu, dass die Mails von im SPF aufgeführten Systemen gekommen ist. Als wenn der Mailadmin von ct.de seine Server nicht unter Kontrolle hat.

Nun könnte man natürlich doch Microsoft 365 die Schuld geben, warum der Spamfilter von Exchange Online die Spam-Nachricht nicht als solche gefunden hat. Dem spricht aber entgegen, dass ein Spamfilter nie 100% erkennen können und der Spammer ja auch darauf Einfluss nehmen kann, wenn er das Exchange Postfach oder den Tenant kontrolliert.

Kann ich Absender in Exchange Online fälschen?

Dazu müssen wir natürlich zwei Fälle unterscheiden:

  1. Authentifizierte Anwender
    Sie können davon ausgehen, dass authentifizierte Anwender nicht mit einer Domain versenden können, die nicht im Tenant registriert ist. Das habe ich mehrfach per Graph, Outlook, SMTP, IMAP versucht und jedes Mal hat Microsoft die Absenderadresse durch die Adresse des authentifizierten Kontos ersetzt. Alles andere wäre auch verwunderlich. Diese Verhalten kann bei Migrationen etwas aufgeweicht werden, indem eine SMTP-Domain auch noch in einem anderen Tenant registriert werden kann. Das ist im Sep 2023 aber noch Preview und dann auf die Tenants beschränkt.
  2. Anonyme Absender
    In dem Fall gibt sich jemand als <username>@ct.de aus und sendet massenhaft Mails an das Postfach, welches eine Weiterleitung zu einem Google-Konto eingerichtet hat. In dem Fall muss ich mich natürlich fragen, warum diese Mail an einen Tenant von extern überhaupt angenommen wurde. Exchange Online Protection prüft SPF/DKIM/DMARC und sollte zumindest viele Mails erkennen.
    Es könnte aber sein, dass der Spammer auch die Hoheit über das Postfach oder den Tenant hat und über eine Allow-List den einliefernden Server einfach zugelassen hat.

Damit gibt es hier durchaus einige Kombinationen, die zu betrachten wären.

Schutz von ct.de

Damit ist natürlich interessant, wie die Domain ct.de überhaupt geschützt ist. Kann vielleicht jeder als "ct.de" senden? Exchange Online Protection prüft mittlerweile jede Mail per SPF und DKIM und beachtet seit Sommer 2023 endlich auch die DMARC vorgaben. Leider habe ich keinen Schnappschuss der DNS-Einträge zum damaligen Zeitpunkt sondern kann nur den Stand vom 16. Sep 2023 widergeben. Der SPF Eintrag enthält nicht mehr den Microsoft Eintrag, einige ipv4 und ipv6-Adresen und endet auf ein "?All".

ct.de text = "v=spf1……….. ?all"

Ein “?all” im SPF-Eintrag bedeutet, dass alle anderen Server auch gültig sein könnten. Ob da nun per Include noch die Microsoft Server drin sind oder nicht, ist dann ziemlich egal. Ein „-all“ würde einen Versand von nicht aufgeführten Servern unterbinden, wenn die Empfängerseite reines SPF macht und nur den Envelope-From anschaut.

Hinweis an c't. Warum habe ihr kein "-all"? Kennt ihr eure eigenen Mailserver nicht? Mit einem "-all" wäre es zumindest nicht möglich, mit einer falschen IP-Adresse bei Microsoft eine Mail einzuliefern.

Im Artikel steht aber, das damals auch der "include:protection.outlook.com" in der Zone enthalten war und das für die Nutzung von Microsoft 365 ja auch korrekt ist. Damit würde aber Microsoft sich auch selbst vertrauen. Mit einem "-all" im SPF-Eintrag wäre es theoretisch doch möglich, eine Mail von einem anderen Tenant als "ct.de" zu senden.

Schauen wir und nun noch den DMARC-Eintrag an.

DMARC: _dmarc.ct.de text = "v=DMARC1; p=none; sp=none; rua=mailto:dmarc.report@ct.de"

Allein die Existenz des DMARC-Eintrags allein weist Mailserver an, nicht nur den „Envelope-From“ sondern auch den „Header-From“ anschauen und die Domain prüfen. DMARC ist aus meiner Sicht sehr wichtig, weil damit auch die Mailadresse, die der Empfänger letztlich sieht, gegen SPF geprüft wird. Mit einem NONE macht der DMARC-kompatibler Empfänger das schon aber er wird die Mail halt nicht ablehnen oder in Quarantäne stecken, weil der Domaininhaber von „ct.de“ das nicht will.

Frage an c't. Warum setzt ihr "p=none; sp=none"?

Ich weiß von einigen Providern, die hier Wunsch der Absenderdomain allerdings ignorieren und SPF:Fail bzw. DKIM:Fail dennoch als Spam abwehren. Quasi „Meine Haus, meine Regeln“. Wer DMARC setzt, sollte es richtig machen.

Testfälle

Soweit ich die Beschreibung analysiert und verstanden habe, ergeben sich für erst einmal vier Szenarien, die man aber anhand von SPF/DKIM/DMARC-Einstellungen noch locker potenzieren könnte.

Szenario Beschreibung Missbrauch möglich

1

Direkte Zustellung

Es kann natürlich immer passieren, dass sich jemand als "ct.de" ausgibt und mit dem Absender Mails an Google sendet. Wenn die Domain "ct.de" dies nicht durch strenge SFP/DKIM/DMARC-Einstellungen unterbindet, dann kann die Empfängerseite nur eigene Spamregeln anwenden und die Mails "bewerten". Der Absender sollte nicht mit einer IP-Adresse senden können, die im SPF-Eintrag vorhanden ist.

Als Inhaber der Domain kann ich diesen Missbrauch erschweren, indem ich SPF und DMARC korrekt setze. Google prüft und folgt SPF/DMARC-Anweisungen.

Ja, wenn ct.de ein SPF erzwingt oder das Ziel kein SPF prüft.

2

Missbrauch eines Office 365 Konto

Ein Spammer kann sich natürlich auch ein Microsoft 365 Konto kaufen und Mails versenden. Allerdings ist er da auf die im Tenant angelegten Domains  beschränkt. Er kann sich also nicht als "ct.de" ausgeben. Da hilft ihm auch kein SPF-Eintrag mit einem "include:protection.outlook.com". Ich kann dem Benutzer erst gar keine Mailadresse aus der "ct.de"-Domain geben. Und der Versuch eine Mails per SMTP-AUTH mit falscher Absenderadresse unterzujubeln, hat schon das einliefern per Thunderbird nicht funktioniert.

Senden der Nachricht fehlgeschlagen.
Fehler beim Senden der Nachricht. Der Mail-Server antwortete:  SendAsDenied; 
relaymissbrauchtest@msxfaqdev.onmicrosoft.com not allowed to send as relayuser@carius.de; 
  STOREDRV.Submission.Exception:SendAsDeniedException.MapiExceptionSendAsDenied; 
  Failed to process message due to a permanent exception with message 
  [BeginDiagnosticData]Cannot submit message. .....[EndDiagnosticData] 
  [Hostname=FR0P281MB2847.DEUP281.PROD.OUTLOOK.COM]. 
Bitte überprüfen Sie die Nachricht und wiederholen Sie den Vorgang.

HIer ist also kein Missbrauch von Exchange Online möglich

Nein

3

Weiterleitung über Hybrid

Sie können mit Exchange Online als Firma den einen lokalen Exchange Server hinter Exchange Online verstecken. In dem Fall sendet der lokale Server per TLS gesichert Mails über Exchange Online als "Relay" ins Internet. Ich habe meinen lokalen Server einfach die "ct.de"-Adresse als Accepted Domain gegeben, ein Postfach angelegt und versucht eine solche Mail ins Internet zu senden. in dem Fall ist das "Inbound Routing" von Exchange Online relevant, da viele Kunden alle die gleichen Server nutzen.

Exchange Online versuch den Absender anhand des TLS-Zertifikats oder einer IP-Adresse+Mailfrom an einen Tenant zu binden. Ein Spammer sollte beides nicht für "ct.de" fälschen können. Damit ist die Mail immer "Inbound" zu behandeln. Die Domain "google.com" ist einem Microsoft Tenant "google0.onmicrosoft.com" zugewiesen und würde nie bei den Mailservern von Google landen. "Google-de" hat keinen zugewiesenen Tenant und "google.onmicrosoft.com" hat keine Domain.

Ein Spammer kann über diesen Weg kein Mails an "google.de/google.com" über Exchange Online als Relay routen

Nein

4

Weiterleitung an Google

Nun kann es aber passieren, dass ein Benutzer (Spammer oder regulär) mit einem Postfach in Exchange Online eine Weiterleitung zu einem Google-Konto einrichtet. Das muss nicht mal boshaft sein. Wenn eine Firma z.B. das Lesen der Firmenmails auf dem Privatgerät unterbindet aber dann die Möglichkeit einer vom Anwender einstellbaren Weiterleitung übersehen hat, dann kann der Mitarbeiter die Firmenmails an sein privates Postfach bei Google umleiten lassen.

Dazu schauen wir uns diesen Fall einmal genauer an.

Möglich

Wir brauchen uns nur das letzte Szenario in diesem Fall genauer anzuschauen.

Exchange Online Weiterleitung funktioniert

Da Fall 1-3 nicht zutreffen, kann das Problem nur durch eine "Weiterleitung" in Exchange Online erfolgen. Ich habe daher in einem Tenant beim Konto eine Weiterleitung per OWA an mein Postfach angelegt, bei dem ich selbst den Spamfilter prüfen kann:


https://outlook.office.com/mail/options/mail/forwarding

Natürlich musste ich im MSXFAQDEV-Tenant temporär die automatische Weiterleitung erlauben. Bei den "Remote Domains" ist die Checkbox schon bei den Standardeinstellungen aktiv aber in Exchange Online Protection habe ich die Weiterleitung von "System controlled" auf "ON" gestellt. Ich habe dann eine Mail von meinem IONOS-Postfach an den MSXFAQDEV-Tenant geschickt, dessen Postfach die Mails an mein Net at Work Konto zugestellt hat.

Anhand der ARC-Validierung der bei Net at Work angekommen Mails im Header sehen wir folgendes:

  • Absendersystem-> MSXFAQDEV
    Leider bringt IONOS keine DKIM-Signatur an, so dass der MSXFAQDEV-Tenant nur SPF prüfen kann. Diese Prüfung erreicht ein "Pass", da die IP-Adresse 212.227.126.131 zur Domain "carius.de passt. Beachten Sie auch das Feld "smtp.mailfrom=carius.de", welches die Envelope-Absenderdomain liefert, die Basis des SPF-Tests ist.
Authentication-Results-Original: spf=pass (sender IP is 212.227.126.131)
smtp.mailfrom=carius.de; dkim=none (message not signed)
header.d=none;dmarc=pass action=none header.from=carius.de;

Received-SPF: Pass (protection.outlook.com: domain of carius.de designates
212.227.126.131 as permitted sender) receiver=protection.outlook.com;
client-ip=212.227.126.131; helo=mout.kundenserver.de; pr=C

ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
212.227.126.131) smtp.rcpttodomain=msxfaqdev.onmicrosoft.com
smtp.mailfrom=carius.de; dmarc=pass (p=reject sp=reject pct=100) action=none
header.from=carius.de; dkim=none (message not signed); arc=none (0)

Received: from mout.kundenserver.de (212.227.126.131) ...

From: "Frank Carius" <relaytest@carius.de>
To: "'Frank Carius DEV'" <relaytest@msxfaqdev.onmicrosoft.com>
Subject: Carius->MSXFAQDEV->Netatwork
  • Weiterleitung durch MSXFAQDEV
    Dass der MSXFAQDEV-Tenant die Mail weitergeleitet,  genau genommen ja umgeleitet hat, sieht man den den beiden Headern. Die Mail geht nun zum Zieltenant
Resent-From: <relaytest@msxfaqdev.onmicrosoft.com>
Return-Path: adminfc@msxfaqdev.onmicrosoft.com
  • Empfang bei Net at Work
    Die Mail wurde nun weiterleitet an mein Net at Work-Konto. Das sehen Sie erst einmal am "smtp.rcpttodomain=netatwork.de". Achten Sie aber auch auf den Eintrag "smtp.mailfrom=msxfaqdev.onmicrosoft.com". Das ist ein sicheres Zeichen, das Exchange Online hier die Absender-Adresse im Envelope nach den SRS-Regeln umgeschrieben hat. Nur damit bekommen wir ein SPF-Pass auf eine IP-Adresse, die definitiv nicht zu "carius.de" passt.
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
40.107.127.130) smtp.rcpttodomain=netatwork.de
smtp.mailfrom=msxfaqdev.onmicrosoft.com; dmarc=fail (p=reject sp=reject
pct=100) action=oreject header.from=carius.de; dkim=none (message not
signed); arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=carius.de]
dmarc=[1,1,header.from=carius.de])

Authentication-Results: spf=pass (sender IP is 40.107.127.130)
smtp.mailfrom=msxfaqdev.onmicrosoft.com; dkim=none (message not signed)
header.d=none;dmarc=fail action=oreject header.from=carius.de;compauth=pass
reason=130
Received-SPF: Pass (protection.outlook.com: domain of
msxfaqdev.onmicrosoft.com designates 40.107.127.130 as permitted sender)
receiver=protection.outlook.com; client-ip=40.107.127.130;
helo=40.107.127.130; pr=C

Damit haben wir nun bewiesen, dass ein unbekannter Absender mit einer SMTP-Domain eine Mail an ein Exchange Online Postfach senden kann, indem dann eine Weiterleitung diese Mail an ein anderes Konto, als auch ein Google-Konto weiterleitet.

Umleitung nur mit Kontrolle des Domaininhabers

Der Störfall mit der Domain "ct.de" bezieht sich aber nun darauf, dass genau so eine Umleitung in einem beliebigen Microsoft 365 Tenant zu einem Google Konto nun Ursache dafür gewesen sein, soll, dass Google die Domain ct.de abstraft und in der Zeitschrift c't nun behauptet wird, dass Google dafür mit dem Finger auf Microsoft zeigt.

Kennen Sie den Spruch ihrer Eltern, dass jemand, der auf einen anderen mit einem Finger zeigt, zugleich mit drei Fingern auf sich selbst zeigt?

Bei dem Problem gibt es einige Fragen, die ich nicht beantworten kann

  • Google Rating
    Ich weiß nicht, wie Google genau Domains bewertet und vor allem gibt es ja einen Unterschied zwischen der Domain im Envelope und im Header. Die Domain im Envelope kann man mit SPF schützen, die Header durch DMARC. Wenn Absender diese Hilfsmittel nicht nutzen, dann kann der Mail-Admin der Zieldomain nur irgendwie sich etwas ausdenken, um seine Kunden zu schützen. Ich hoffe und erwarte aber, dass Google hier nicht die Envelope.From-Domain nutzt sondern die Header.From-Domain"

Wäre das Problem auch passiert, wenn die Domain "ct.de" einen "-all"-Eintrag im SPF-Record hätte? Ich denke nein, denn dann hätte der erste Microsoft 365 Tenant die Mail schon gar nicht angenommen, wenn der dortige Admin nicht gelockert hätte. Ein Angreifer könnte aber den Schutz lockern.

  • Also hilft es ja doch nichts, oder?
    Das stimmt so nicht, wenn würde Exchange die Mail mit der originalen Absender Domain einfach weiterschicken, würde ein strenger SPF-Check vermutlich die Zustellung unterbinden. Es gibt hier Schwächen, wenn der Domaininhaber auch Microsoft -Server addiert oder kein "-all" hinterlegt. Aber das ist gar nicht erforderlich, da Exchange Online die Absenderadresse im Envelope einer weitergeleiteten Mail mittels SRS umschreibt. Vielleicht ist das damit gemeint, wenn im Artikel steht.

..weil Microsoft Server eine extrem ungewöhnliche Art der direkten Weiterleitung einsetzen…“
Quelle: c't 21/2023 auf Seite 38

  • Dann hilft der SPF-Record für sich alleine gar nicht!
    Korrekt. Wenn ein Mailsystem eine weitergeleitet Mails mittels SRS umschreibt, dann prüft die nächste Station diese Domain gegen SPF. Wenn ich
    SPF hilft aber alleine ist er keine Absicherung, da das reine SPF nur den Envelope sichert. Sind sie eher froh, dass Exchange mit SRS arbeitet, da ansonsten auch erwünschte Weiterleitungen nur mit viel manueller Konfiguration möglich wären
  • DMARC ist ein Schlüssel
    Wir wissen nun, dass ein Tenant-Admin eine Weiterleitung zulassen kann und damit Mails einer Domain über eine Weiterleitung zu Google gehen könnten Der Anwender sieht dabei die "Header.From"-Adresse, die vermutlich Google auch bewertet. Wie kann ich mich da besser schützen? Dazu brauchen wir einen DMARC-Eintrag, damit die kompatiblen Empfänger (wozu Google gehört) auch die Absenderdomain im Header in die Prüfung einbezieht. Damit ist so eine Weiterleitung mit ihrer Domain erst einmal verhindert, da die Domain im Envelope und im Header nicht übereinstimmen.

Jetzt ist ihre Domain ziemlich gut geschützt. Leider auch gegen erwünschte Umleitungen bei Empfängern, der der umleitende Host kein SRS einsetzt oder das Ziel eine von der Quelle angebrachte DKIM-Signatur prüfen kann.

  • Wie kann ich dennoch weiterleiten?
    Wenn Sie als Domaininhaber Mails versenden wollen und Empfänger die Mail weiterleiten dürfen, dann geht das mit aktivem DMARC nicht mehr per DKIM. Was ist die Signatur der Mail noch korrekt aber DMARC erzwingt auch ein Alignment ud das ist durch SRS unbrauchbar geworden. Hier gewinnt dann aber die SPF-Prüfung. Natürlich kann ein Empfänger abweichend vom DMARC-Standard dennoch eine DKIM-Prüfung machen und die Mail damit besser bewerten. Darauf verlassen können Sie sich aber nicht. Weiterleitungen müssen also mit SRS umgeschrieben werden, damit SPF ein PASS liefert.
  • Ist Exchange nun ein offenes Relay?
    Ganz klares NEIN und ich habe insbesondere zu DKIM/SRS einige Mails und Chats mit den Entwicklern in Redmond ausgetauscht denn das Thema ist nun mal nicht trivial. (Siehe auch Verteiler und SPF/DKIM/DMARC, Mailingliste mit DMARC, DKIM, SPF, ARC, ARC - Authenticated Received Chain) Hier aber auf Microsoft zu zeigen ist falsch, denn Microsoft macht hier nichts falsch, wenn man mal von einer überflüssig angebrachten DKIM-Signatur absieht.

Als Besitzer eine Domain haben Sie eine sehr umfangreiche Kontrolle über den Versand von Mails mit ihrem "guten Namen". Allerdings sollten Sie die Werkzeuge und Einstellungen auch nutzen. viel große Provider setzen ein "-all" als Default und raten einen DMARC-Eintrag zu setzen. Jeder seriöse Mailanbieter nutzt dieses Wissen um Missbrauch ihrer Domain zu verhindern. Wenn sie aber qualifizierte Weiterleitungen bei einer so abgesicherten Domain weiter erlauben wollen, dann müssen Sie ihren Mailserver dazu bringen, alle Mails per DKIM zu signieren. Dann funktionieren zumindest die Weiterleitungen an Empfänger, die DKIM auswerten.

Wie sieht die Lösung aus?

Wenn ich mir die aktuellen Einstellungen zur Domain "ct.de" anschaue, dann ist dies ein Negativbeispiel, wie man es nicht machen sollte. SPF sagt der Welt, welche Server auf jeden Fall mit der Domain "ct.de" senden dürfen aber andere Server sind nicht verboten. Der DMARC-Eintrag sagt aus ,dass keine Mail abgelehnt oder in Quarantäne gesteckt werden darf. Da darf man sich dann auch nicht wundern, dass Google dann seine eigene Hausordnung anlegt. Lösungen sind sehr schnell möglich:

  • SPF auf -All
    Dann würde schon auf der ersten Teilstrecke Microsoft die Mail gar nicht annehmen und die Weiterleitung gar nicht zum Zuge kommen.
  • DMARC auf p=reject
    Wenn SPF schon nicht streng konfiguriert werden kann, dann sollte zumindest DMARC auf "reject" stehen, denn nach der Weiterleitung mit SRS ist die "Envelope.from"-Domain und "Header.from"-Domain unterschiedlich und SPF bekommt ein Fail. Allerdings sollte man dann DKIM in Betracht ziehen. Siehe auch SPF, DKIM und DMARC jetzt!

Ich wollte erst eine Tabelle zu den Fällen erstellen aberes gibt einfach zu viele Kombinationen aus SourceIP, AbsenderSPF (-all oder nicht -all), AbsenderDKIM (an/aus), AbsenderDMARC (Kein,none, reject/quarantine), WeiterleitungSRS An/Aus), Empfängerprüfungen u.a.

Better together?

Der Artikel macht mir einen recht oberflächlichen Eindruckt und lässt viel Potential brach liegen. Was hier der Domain ct.de passiert ist, kann theoretisch jeder Domain passieren, die nicht entsprechend abgesichert wurde. Allerdings wurde versäumt, die Zusammenhänge etwas detaillierter beschreiben und konkrete Handlungsanweisungen zu ergänzen. Es gehört natürlich zum Handwerk von Presse, über entsprechende Überschriften um Aufmerksamkeit zu buhlen aber Microsoft Bashing ist hier fehl am Platz. Mit der Reichweite und dem Anspruch der Zeitschrift c't hätte man hier doch besser ein Plädoyer für eine strenge SPF und DMARC-Policy halten können. Wer dann wirklich noch Umleitungen unterstützen will, muss dann DKIM umsetzen oder das Ziel dazu bringen, den Mailservern zu vertrauen. Zum Glück scheint Google hier den Microsoft Servern schon derart zu vertrauen, dass Sie diese nicht auf eine Blockliste setzen, nur weil eine Domain nicht beim Spamschutz mithilft. Das ist wohl auch ein Grund dafür, dass die großen Provider mit ARC - Authenticated Received Chain sich gegenseitig authentifizieren können, damit nicht ein einzelner Kunde einen Provider beschädigen kann.

@c't: Vielleicht überdenkt ihr eure SPF/DKIM/DMARC-Konfiguration noch einmal. Wir helfen euch gerne auch dabei die Welt ein bisschen sicherer zu machen. Meine Kollegen von NoSpamProxy und ich stehen euch und euren Lesern, zu denen ich auch gehöre, ´mit Rat und Tat zur Seite.

Weitere Links