[English]Ich nehme mal ein Thema in den Blog auf, welches bereits im April 2024 durch Microsoft kund getan wurde, aber noch nicht allzu viel Aufmerksamkeit erfahren hat. Ein Leser hatte mich bereits vor einiger Zeit auf das Thema hingewiesen. Microsoft wird in Exchange Online die Unterstützung für die Basisauthentifizierung mit Client Submission (SMTP AUTH) im September 2025 endgültig einstellen. Wer dieses Feature verwendet, hat also noch ein Jahr Zeit, zu reagieren.
Anzeige
Blog-Leser Florian R. hatte mich bereits Mitte April 2024 in einer E-Mail mit dem Betreff "smtp auth / office 365" kontaktiert und angemerkt "mich wundert dass es hier von keinen Artikel gibt". Gleichzeitig schickte er mir einen Link auf den Techcommunity-Beitrag Exchange Online to retire Basic auth for Client Submission (SMTP AUTH) vom 15. April 2024, in dem Microsoft das Ende der Basisauthentifizierung für Client-Übermittlung (SMTP AUTH) ankündigt.
Ende der Unterstützung im Sept. 2025
Microsoft wird in Exchange Online die Unterstützung für die Basisauthentifizierung mit Clientübermittlung (SMTP AUTH) im September 2025 dauerhaft entfernen. Nach diesem Zeitpunkt werden Anwendungen und Geräte nicht mehr in der Lage sein, Basic Auth als Authentifizierungsmethode zu verwenden. Die Anwendungen und Geräte müssen spätestens ab diesem Zeitpunkt OAuth verwenden, wenn sie SMTP AUTH zum Senden von E-Mails benutzen.
Microsoft schreibt, dass man bereits im Jahr 2019 mit einem mehrjährigen Prozess zur Deaktivierung von Basic Auth in Exchange Online begonnen habe. Dieser Prozess wurde Ende 2022 abgeschlossen, wobei Client Submission (SMTP AUTH) die einzige Ausnahme darstellt. Microsoft wird jetzt Basic Auth aus Client Submission entfernen.
Der Hintergrund für diesen Schritt: Basic Auth ist eine veraltete Authentifizierungsmethode, die Benutzernamen und Kennwörter im Klartext über das Netzwerk sendet. Dies macht sie anfällig für den Diebstahl von Zugangsdaten, Phishing und Brute-Force-Angriffe. Um den Schutz unserer Kunden und ihrer Daten zu verbessern, werden wir Basic auth von Client Submission (SMTP AUTH) abschaffen und unsere Kunden dazu ermutigen, moderne und sicherere Authentifizierungsmethoden zu verwenden.
Anzeige
Fahrplan zur Umstellung
Microsoft bereitet die Abschaltung in mehreren Schritten vor, so dass Administratoren auf diese Änderung reagieren können. Hier der Fahrplan zur Umstellung.
- Im September 2024 wird der SMTP AUTH-Bericht zur Clientübermittlung im Exchange-Administrationszentrum aktualisiert. Dann wird angezeigt, ob Basic Auth oder OAuth zur Übermittlung von E-Mails an Exchange Online verwendet wird.
- Im Januar 2025 will Microsoft einen Message Center-Post an Tenants senden, die Basic Auth mit Client Submission (SMTP AUTH) verwenden. Im Post wird auf die bevorstehende Änderung hingewiesen.
- Im August 2025, etwa 30 Tage vor der Deaktivierung der Basisauthentifizierung, wird Microsoft einen weiteren Message Center-Post an Tentants senden, die noch die Basisauthentifizierung mit Clientübermittlung (SMTP AUTH) verwenden.
Im September 2025 endet dann die Unterstützung für Basic Auth mit den Client Submission (SMTP AUTH)-Endpunkten:
- smtp.office365.com
- smtp-legacy.office365.com
Sobald Basic auth dauerhaft deaktiviert ist, erhalten alle Clients oder Anwendungen, die eine Verbindung über Basic auth mit Client Submission (SMTP AUTH) herstellen, diese Antwort:
550 5.7.30 Basic authentication is not supported for Client Submission.
Microsoft gibt im Support-Dokument den Hinweis auf das Dokument Authenticate an IMAP, POP or SMTP connection using OAuth, um Clients, die OAuth unterstützen, umzustellen. Kunden, die weiterhin Basic Auth mit Client Submission (SMTP AUTH) verwenden müssen, finden im Beitrag Exchange Online to retire Basic auth for Client Submission (SMTP AUTH) Hinweise auf Alternativen. Das Support-Dokument enthält weitere Details, u.a. für Kunden, die ein hohe E-Mail-Aufkommen haben.
Anzeige
Naja April 2024 kommuniziert, Spetember 2025 endgültig umgesetzt, wer das nicht gebacken kriegt…sollte für solche Systeme nicht verantwortlich sein!
Da muss ich dir zumindest teilweise widersprechen. Das ist kein Problem der Admins, sondern der verwendeten Branchensoftware und der dortigen Entwickler und Verantwortlichen. Unsere Branchensoftware kann gegenwärtig m. W. auch kein OAuth – und da die seitens des Herstellers bereits abgekündigt ist (allerdings eigentlich mit einer längeren Frist als 2025), wird sich das vermutlich auch nicht mehr ändern. Wechsel auf die Nachfolgelösung ist für Anfang bis Mitte 2025 geplant – aber wie das bei solchen Projekten üblich ist, ist das halt der Bestcase, wenn alles nach Plan läuft. Kann klappe, aber wenn nicht bleibt da nicht mehr so ganz viel Puffer.
„Toll". Na, HVE scheint das zu sein was wir brauchen. Ist schon bekannt ob das nach der Preview was kosten wird oder wird es wie die shared-Mailboxen einfach ohne Lizenz genutzt?
@Stefan (AT): HVE wird nach dem Preview kostenpflichtig sein:
"HVE uses a transactional model based on the number of emails sent. For the public preview, the cost will be free but limited to 100,000 recipients per day per tenant."
Hi MaxM,
Danke für die Antwort, sowas dachte ich mir schon 🫤
Als Alternativen werden im MS-Artikel aufgezählt:
1) HVE (kostenpflichtig und limitiert für externe Emails)
2) ACS (kostenpflichtig)
3) "If you have an Exchange Server on-premises in a hybrid configuration, you can use Basic auth to authenticate with the Exchange Server on-premises or configure the Exchange Server on-premises with a Receive connector that Allow anonymous relay on Exchange servers".
IMHO hat MS vergessen, dass es noch die Option 3 gibt:
https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365#option-3-configure-a-connector-to-send-emails-using-microsoft-365-or-office-365-smtp-relay
Damit kann ein beliebiger SMTP-Relay-Host (hMailServer, Postfix, Windows server SMTP daemon …) über einen Inbound Organization Connector Emails für interne UND externe Empfänger an ExchangeOnline einliefern.
Wohl dem der eine statische IP hat und nocht hinter CGnat sitzt, leider gerade bei kleinen Kunden keine Seltenheit. Bin mal auf die Preise gespannt. Für Scans wird es halt sonst smb-scan-to-folder.
@Stefan (AT): In der Tat setzt Option 3 eine statische public IP voraus. IPs aus Dialup-Netzwerken werden wohl gleich beim Verbindungsaufbau geblockt. Da hilft dann auch kein Zertifikat.
Eine Alternative wäre auch der email-oauth2-proxy:
https://github.com/simonrob/email-oauth2-proxy
Wird die Option 3 bleiben?
Ich habe einen Kunden der eine ERP Software nutzt, wo man keine TLS Verschlüsselung aktivieren kann.
Da wird der Exchange Online Connector genutzt und verschickt über Port25 und nutzt als smtp server **mail.protection.outlook.com
@8ball: Da man bei einem ExO INBOUND connector gar nicht angibt, ob TLS verwendet wird oder nicht – das macht ja der sendende Host – glaube ich, dass man auch weiterhin ohne TLS Emails an seinen ExO-Tenant übergeben kann.
Ich behaupte mal, dass viele dies nun umstellen müssen. Auch ich muss an zwei Stellen daran arbeiten (zumindest ein wenig was).
Das WordPress-Plugin WP Mail SMTP unterstützt dies nur in der Pro-Variante, da die kostenfreie Version nur SMTP per Kennwort und Mail anbietet.
Typo3, welches m. E. viel zu umständlich ist, braucht hierfür auch wieder eine Extension…
Ein paar weitere Systeme, fernab von Webservern, kommen sicherlich auch dazu.
Etwas Arbeit kommt da auf, wenn auch nicht besonders viel.
Oder werfe ich hier was gewaltig durcheinander?
Gibt es eigentlich freie Mailserver die man als Relay einsetzen kann welche oauth2 unterstützen? Hmailserver kanns mal nicht, der abgekündigte SMTP-Server in Windows Server 2019/2022 auch nicht 🤔
@Stefan (AT): Warum muss der Relay-Mailserver OAUTH können? Dieser Server relayed über Port 25 mit einer statischen public IP und/oder einem Zertifikat an ExchangeOnline (via Connector). Die einlieferenden Hosts können mit Benutzer/Kennwort oder anonym beim Relay-Mailserver ihre Emails abgeben. Wozu also OAUTH?
Ohne statische IP geht der Connector ja nicht und so hätte man ein Relay das intern einfaches Relay ohne Verschlüsselung und auth macht )für alte MFP) und nach extern outh2 nutzt. Warum gibts sowas nicht? SynologY verschickt seine Statusmails per oauth2, Veeam zb auch.
@Stefan (AT): Ohne statische public IP hast Du natürlich Recht. Da braucht es OAUTH am Ausgang (= Versenden nach ExO).
Ich denke Postfix + XOAUTH2 sollte das möglich sein. Hab es praktisch aber bisher noch nicht eingerichtet.
Hi, klingt nicht schlecht, muss ich mal testen.
Soweit ich das verstanden habe, geht es um OAuth2. Und damit bekommen wir dann zusätzlich Spass, da die Konzerne ihre OAuth2-Implementationen gerne 'optimieren', d.h. vom RFC abweichen. Klassische Verschlimmbesserung! :(
Ich regle das bei mir gerne so, dass ich entweder auf der primären Domain im Webhosting des Kunden Postfächer anlege und dann den SPF entsprechend ergänze (insgesamt nicht so super wegen DKIM und so, geht aber auch) oder dass ich eine Subdomain fürs Mailing via SMTP nutze. Also bspw. scanner@devices.kunde.tld . Die ist dann komplett unabhängig vom M365 und für Benachrichtigungen, Mails vom Scanner etc. reicht das voll aus. Für Mails von einer Warenwirtschaft ist das in der Regel natürlich nicht so passend.
Mach ich auch so.
@yoyobo: Wenn die Domain @devices.kunde.tld von M365 unabhängig ist, wie sendet dann der Scanner seine Emails? Schlägt er den MX record des externen Empfänger nach und versendet dann direkt mit einer statischen public IP an den Email-Host des externen Empfängers?
@MaxM:
Ich nutze einfach den Mailing-Dienst des Webhosters. Meistens bezahlt man den sowieso. Die Mails gehen dann einen längeren Weg, aber es funktioniert in der Regel problemlos.
Hab ich auch mal versucht, jedoch werdwn die Mails wenn sie bei 365 ankommen immer als Spam erkannt (Hoster schickt als office@domain.tld mit korrektem SPF an das office-365-Konto und landet im Junk).
Dass man derzeit komplett unverschlüsselte Sendeconnectoren/Smarthosts benutzen kann, bleibt dagegen?
@Jan:
Du spielst darauf an, dass man bei einem Sende-Connector die Security Restrictions "Always use TLS to secure the connection (recommended)" bis heute abwählen kann?