MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Exchange Online SMTP BasicAuth Abschaltung

Ich habe schon mehrere Seiten zur SMTP-Verbindung und Authentifizierung mit Exchange Online geschrieben aber da immer wieder Postings und Meldungen zu der Abschaltung geschrieben werden, möchte ich hier die wichtigsten Punkte zusammenfassen. Wer mag, kann die ausführlichen Artikel immer noch lesen.

Worum geht es?

Wer eine Mail über Exchange Online an externe Empfänger senden will, muss sich natürlich bei Exchange Online anmelden, damit der Cloud Service den Absender und die Legitimation überprüfen kann. Wäre das nicht der Fall, dann wäre Exchange Online ein offenes Relay. Eine Anmeldung per SMTP ist also nicht ungewöhnlich aber natürlich auch eine Angriffsmöglichkeit. Es ist nicht schwer, den Benutzernamen zu erraten (Meist die Mailadresse des Absenders) und dann kann ich einfach viele Kennworte durchprobieren. Exchange Online muss jede Anmeldung prüfen und verwerfen. Eine weitere Absicherung gibt es erst einmal nicht.

Das ist erst möglich, wenn ich eine Anmeldung mit "Benutzername + Kennwort" gar nicht mehr zulassen und dem Client sage, er möge bitte mit einem SAML-Token ankommen. Der Client muss dann zuerst zum SAML/OAUTH-Service (z.B. login.microsoftonline.com) gehen und sich dort authentifizieren. Hier sind zusätzliche Schutzfunktionen, z.B. MFA, Passkey, Anomalie-Erkennung etc.) sowie implementiert. Der Exchange Server kann nicht legitime Verbindungsversuche direkt ablehnen. Exchange Online spart Ressourcen und wird sicherer. Das sollten alle Nutzer von Exchange Online befürworten.

Es können dabei die unterschiedlichsten Systeme betroffen. Hier eine Auswahl

  • Scan2Mail
    Sie haben einen Scanner, der Dokument per Mail an ihre Anwender oder sogar externe Empfänger per Mail sendet
  • Faxserver
    Meist sind die Empfänger in ihrem eigenen Tenant aber eine Anmeldung umgeht elegant die Spamfilter
  • Monitoring-Lösungen
    Wenn ihr PRTG, Icinga, Nagios, CheckMK o.ä. Alarme per Mail an sie oder externe Dienstleister sendet
  • Print as a Service
    Zwar melden sich heute Drucker auch immer häufiger per Cloud, wenn Sie einen Servicebedarf haben, aber ich kenne einige Lösungen, die auch einfach eine Mail "Papier leer" versenden.
  • Veranstaltungsmanagement
    Vielleicht nutzen sie eine eigene Plattform zur Verwaltung von Veranstaltungen, Schulungen, Events, welche mit ihrer Domain entsprechende Mails sendet.
  • ERP/CRM/Helpdesk Produkte
    Denken Sie auch an die Vertriebskommunikation, wenn Bestellbestätigungen, Kundenanfragen u..a per Mail über Funktionspostfächer erfolgen

Es kann je nach Firma als sehr unterschiedliche Lösungen geben, welche sich immer noch per SMTP mit Username/Kennwort ohne OAUTH an Exchange Online anmelden, weil es schon immer funktioniert hat.

Zeitplan

Die Anmeldung per Benutzername/Kennwort ist zwar (Stand Feb 2025) immer noch möglich, aber wird schrittweise abgeschaltet. Zuerst wird es bei neuen Tenants nicht mehr per Default aktiviert aber kann reaktiviert werden. Dann werden nach und nach Tenants deaktiviert und am Ende ist eine einfache Anmeldung per Benutzername/Kennwort gar nicht mehr möglich. Mein letzter Zeitplan (Stand Feb 2026) ist:

Zeitpunkt Veränderung

31. Nov 2026

Keine Änderung. BasicAuth ist weiterhin aktiv. Als Administrator können Sie sehen, wer diese Funktion nutzt und auch selbst deaktivieren

Vielleicht ist jetzt eine gute Gelegenheit eine solche Nutzung zu ermitteln und die Umstellung zu Planen. Neue Systeme sollten gleich zukunftssicher eingerichtet werden.

Ende Dez 2026

BasicAuth wird bei allen Tenants abgeschaltet. Als Administrator können Sie es aber wieder reaktivieren.

Das bedeutet natürlich. dass es ihnen auch auffallen muss, wenn ihre Prozesse keine Mails mehr senden können

ab 1 Jan 2027

Bei danach neu angelegten Tenants ist BasicAuth nicht mehr aktiv, aber kann wohl wieder reaktiviert werden

ca. 2. HJ 2027

Finale Abschaltung auf allen Tenants. Ob Microsoft die Zeit noch mal weiter schiebt, werden wir noch sehen.

Die Abschaltung von BASICAUTH mit SMTP wurde von Microsoft schon vor vielen Jahren angekündigt und die erste Deadline war der 1. Oktober 2022 und wurde danach mehrfach verschoben. Ich habe aber den Eindruck, dass Microsoft es nun ernst meint

Wer nutzt BasicAuth im Tenant?

Betroffen sind nur Systeme, die über Exchange Online Mails mit Authentifizierung einliefern. Nicht betroffen sind Systeme, die Mails "anonym" oder über entsprechende Connectoren einliefern oder über eigene Wege ihre Mails versenden, z.B. Newsletter etc. Nicht betroffen sind Outlook, OWA, ActiveSync. Thunderbird und andere IMAP4-Clients können meist schon OAUTH oder sind einfach umzustellen. Dankenswerterweise stellt Microsoft im Exchange Online einen passenden Report zur "SMTP-Authentifizierung" bereit. In meinem LAB-Tenant gibt es keine Anmeldungen. Daher ist der Bericht bei mir leer.


Quelle: https://admin.cloud.microsoft/exchange#/reports/smtpauthmailflowdetails

Das kann bei ihnen natürlich ganz anders aussehen. Oben erscheinen Kuchendiagramme aber interessanter ist die Tabelle unten mit der Absenderadresse und dem verwendeten Authentifizierungsprotokoll. Auch die TLS-Version ist interessant, wenn TLS1.0/TLS1.1 abgeschaltet wird. Der Reports zeigt als Standard nur die letzten 7 Tage an. Denken Sie daran, den Wert auf die maximalen 90 Tage zu stellen, damit Sie auch frühere Verbindungen sehen

Hier sollten sie möglichst schnell die Verwendung analysieren und umstellen.

Szenarien

Die einen mögen nun "Zeter und Mordio" schreien oder auf Microsoft schimpfen aber wenn wir mit etwas Abstand den Sachverhalt betrachten, dann ist die Abschaltung von BasicAuth nachvollziehbar. Vielleicht hätte Microsoft pro Tenant eine IP-AllowList ermöglichen können, mit der ich dann z.B. die ´Firewall" als NAT-Device zulassen könnte. Aber für wie viele Tenants würde dies helfen? Es gibt genug alternative SMTP-Dienste, die weiterhin das Risiko eingehen, eine Anmeldung per BASICAUTH zu erlauben. Aber überlegen Sie mal, welche Fälle es eigentlich gibt. Wir haben einen automatisierten Dienste, der Mails über einen "Smarthost" an verschiedene Gegenstellen senden könnte. Folgende Szenarien decken aus meiner Sicht alles ab:

 

Ich unterscheide vier Fälle: 

Fall von Intern an  Einsatzfäll bessere Lösung

 

1

Intern 

Automatische Mails aus Skripten und von Diensten

Für den Fall können Sie auf eine Authentifizierung sogar verzichten. Zwar prüft Exchange dann nicht den Absender und klassifiziert ihn nicht nicht als Intern, aber das stört meist nicht. Legen Sie einen "Partner Inbound Connector" an, senden sie mit einer Subdomains o.ä. und vertrauen Sie der Source-IP z.B.: über EXO Enhanced Filtering, Transportregeln und SPF-Einträgen, damit die Mails nicht als Spam klassifiziert werden.

Durch den Wegfall der Authentifizierung haben Sie auch kein Problem mit MFA, App-Registrations u.a.

 

2

Einzelne externe Adresse

Alarme an externe Dienstleister, z.B. Backup, Storage, Toner für Drucker 

In dem Fall würde ich diese eine externe Adresse, z.B. "toner@<dienstleisterdomain>" einfach als MailContact in meinem Active Directory anlegen. Das Objekt hat dann eine interne Mailadresse "toner@msxfaq.net" und kann auch einfach so angeschrieben werden. Sie müssten auf dem Kontakt natürlich noch "anonym" erlauben und vielleicht per Transportregel den Absenderkreis einschränken. Exchange leitet die Mail dann nach extern um.

 

3 

Einzelne externe Domain 

Migrationen und Koexistenz oder Subdomains mit z.B. einer Ticketnummer als Userpart

In Exchange Online können Sie leider keine fremde Domain als "Exchange Accepted Domain" und dann den Status "External Relay" versehen. Sie könnten über einen Org-Connector den Systemen (Siehe auch Linux Exchange Hybrid) dem Sender einen Vertrauensvorschuss geben, aber das ist auch ein Risiko.

Hier müssten Sie dann schon überlegen, ob eine Authentifizierung oder ein anderer Versandweg möglich ist

 

4

Beliebige externe Adresse

ERP/CRM-Systeme und Listserver 

Auch hier könnten Sie per Org-Connector (Siehe Linux Exchange Hybrid) dem System den höchsten Vertrauenslevel geben aber ich geben zu bedenken, dass Exchange noch andere Schutzfunktionen hat, z.B.

TERRL - Tenant External Recipient Rate Limit, Mailbox External Recipient Rate (ERR) Limit, Limit Enforcement System) und daher nur eingeschränkt für diese Funktionen genutzt werden kann. Prüfen Sie hier wirklich auf Alternativen.

 

Fall 1 und 2 sind einfach und problemlos umzusetzen. Kniffliger wird Fall 3, wobei es hier vielleicht ihr Versendeprozess die Mails direkt an den MX-Record der Gegenseite zustellt, mit der Sie ja irgendwie eine Geschäftsbeziehung haben. Es sollte ja auch im Interesse der Empfängerdomain sein.

Ansonsten müssen sie über andere SMTP-Relays, sei es im Eigenbetrieb oder als externe Dienstleistung, versenden. Das ist für größere Mailvolumen sowieso die bessere Option, da einige Exchange Online Message Rate Grenzen auch auf authentifizierte Konten angewendet werden

Lösungen

Sie brauchen aber nicht den Kopf in den Sand zu stecken, denn es gibt jede Menge Optionen, die gewünschte Funktion weiter bereitzustellen. Der optimale Weg hängt natürlich von ihrer Software und der gewünschten Funktion ab. Wer über Exchange Online authentifiziert versendet, benötigt natürlich ein Postfach mit Exchange Plan und unterliegt den normalen Beschränkungen (Exchange Online Message Rate Grenzen) eines authentifizierten Benutzers. Vielleicht müssen Sie sich aber gar nicht anmelden

  • Versand per OAUTH/SAML als User, App oder Service Principal
    Wenn ihre Software dies kann, dann stellen Sie diese doch einfach auf OAUTH um. Thunderbird kann dies schon länger. Wenn Sie sehr viele interne Empfänger erreichen müssen, dann sollten Sie sich HVE - High Volume Email mit Exchange anschauen.
  • Einlieferung per MSGraph
    Prüfen Sie, ob ihre Lösung nicht schon per Graph API auf Postfächer zugreift. Dann kann Sie vielleicht auch über den Weg schon Mails senden Siehe MGGraph Mail). Dann brauchen Sie den SMTP-Weg gar nicht mehr.
  • Org-Connector
    Das ist zwar ein gefährlicher Weg, aber sie können Exchange Online durchaus mitteilen, dass der Service zu ihrer Organisation gehört und anhand der Source-IP oder eines Zertifikats als vertrauenswürdig angesehen wird. Der so zugelassene Server kann natürlich auch viel Unfug treiben, weswegen ich von dieser Konfiguration abrate. Siehe auch Exchange Online als Outbound Relay und Linux Exchange Hybrid
  • Anonymer Versand
    Vielleicht müssen Sie sich gar nicht anmelden. Wenn Sie nur Mails an ihre eigenen Empfänger senden, dann reicht ein Partner Inbound Connector mit SPF-Eintrag und vielleicht eine Regel, EXO Enhanced Filtering, um den Spamfilter zu besänftigen und schon kann ihr System weiter Mails an ihren Tenant senden. Siehe auch  Exchange DirectSend/RejectDirectSend.
  • SMTP-Proxy
    Es gibt mittlerweile einige Skripte, die sich zu ihrer Software hin als Mailserver ausgeben aber die TCP-Verbindung direkt zu Exchange Online weitergeben und die Authentifizierung entsprechend umsetzen. Einfach, trivial aber eine Komponente mehr in ihrem Nachrichtenfluss. Sind sie vorsichtig, dass aus so einem Provisorium dann kein Dauerzustand wird.
  • Eigenes SMTP-Relay
    Anstelle eines Proxy können Sie natürlich einen richtigen Mailserver (Postfix, Exim, SendMail etc.) aufsetzen, der die Mails per OAUTH-Anmeldung an Exchange Online weitergibt. Alternativ könnte er natürlich auch direkt die Mails zustellen. Sie sollten Sich dann aber auch hier um eine passende Domain mit SPF-Eintrag, DKIM-Signatur und Zertifikate kümmern, damit die Mails auch ankommen. Das ist nicht mal schnell gemacht.
  • Fremdes SMTP-Relay
    Es könnte einfacher sein, ein SMTP-Relay eines anderen Providers zu nutzen, den Sie meist schon haben. Ich habe z.B. auch einen Tenant mit meiner Domain "msxfaq.net" aber das Webhosting und DNS liegt bei einem anderen Provider. Dieser Provider bietet mit auch Postfächer an, die ich eigentlich nicht nutze. Mein MX-Record verweist ja direkt zu Exchange Online. Aber das erlaubt mir dennoch, auch dort ein Postfach zum Versand anzulegen, welches weiterhin mit "Username/Kennwort" funktioniert.
  • Massenmail bitte nicht über Exchange Online
    Achten Sie auf die Exchange Online Message Rate Grenzen. Sie sind für "Menschen" kaum erreichbar aber automatisierte Systeme können sehr schnell daran stoßen. Vielleicht ist dies ein willkommener Anlasse über den automatischen Versand nachzudenken. Vielleicht ist aus ihrer damaligen "mal eben schnell"-Lösung mittlerweile ein geschäftskritisches und stärker genutztes System geworden. Dafür sollten Sie dann alternativen SMTP-Dienstleistern suchen. Sendgrid, Mailgun. Mailchimp, Azure Communication Services, AWS,Cloudflare sind sicher die großen Player aber es gibt auch europäische Anbieter, wer Wert auf lokale Dienste legt. Siehe auch Exchange Online und Massenmail. Übrigens ist HVE - High Volume Email mit Exchange keine Lösung, da dies nur für interne Empfänger gilt

Auf der Seite habe ich einige Konfigurationen mit Exchange Online aber auch anderen Diensten beschrieben. Im Grund gibt es jede Menge Optionen:

Einschätzung

Microsoft wird in näherer Zukunft sicher die Anmeldung zur Einlieferung als authentifizierter Benutzer per SMTP an Exchange Online auf OAUTH2 / Modern Authentication umstellen und wer heute noch SMTP mit BASICAUTH nutzt, muss handeln. Allerdings ist dies aus meiner Sicht keine unlösbare Aufgabe sondern sollte auch in ihrem eigenen Interesse sein. Aber es Arbeit damit verbunden, sei es der Rückbau zu alter Systeme, die Änderung der Konfiguration auf OAUTH eventuell verbunden mit einem Update oder die Nutzung alternativer SMTP-Relays im Eigenbetrieb oder anderer Cloud-Dienste.

Microsoft stellt ihnen einen einfach erreichbaren und zu verstehenden Report im Exchange Online Admin Center bereit. Es liegt nun an ihnen, ob sie sich diesen Report anschauen und entsprechende Maßnahmen umsetzen.

Weitere Links