Strato ist auch dabei und stellt stellt den Service Basic Authentication für SMTP ein.
Bedeutet also, dass alle Kunden die u.a. Joomla bei Strato hosten ab 01.10.2025 ein Problem haben?
Könnte man hier vielleicht einmal konkrete Beispiele auflisten, was dann im Zusammenhang mit Joomla nicht mehr funktioniert?
Anmeldung in Joomla (nicht mehr möglich?)
Nutzung von Kontaktformularen (nicht mehr möglich?)
Anforderung neues Passwort in Joomla (...)
Benutzerdaten vergessen in Joomla (...)
usw.
Strato ist auch dabei und stellt stellt den Service Basic Authentication für SMTP ein.
Wo finde ich diese Info?
Google Suche
Das ist meiner Meinung nach wohl offensichtlich eine "KI-Gespensteranwort" vom "Geist der KI-Maschine".
Siehe auch die zugehörigen Links und am Ende des diesbezüglichen KI-Abschnitts der Google-Suchantwort:
KI-Antworten können Fehler enthalten
Ich hänge bei Strato seit 15 Minuten in der WS aber kläre das jetzt und berichte dann "ohne KI in my brain" 
Ergebnis Telefonat mit Hotline und Nachfrage im Fachbereich:
Strato weiß noch nicht was Sie tun werden.
Eine Entscheidung wird in den nächsten WOCHEN fallen und dann wird dies allen Kunden mit Kundenaccount final mitgeteilt.
Meine Frage danach, ob man bei Strato den Ernst der Lage richtig erkannt hat und warum hier nicht schon viel früher reagiert wurde hat man mir leider nicht beantwortet.
Ich nutze und habe keine Mailhoster/Webhoster die OAuth 2.0 zwingend erfordern.
Wenn ich es aber richtig verstehe, auch wenn es dann irgendwann ein diesbezügliches Joomla-Core Plugin gibt wird man um zusätzlichen regelmäßigen Konfigurationsaufwand nicht herum kommen. Weil das Microsoft Azure "client secret" nach 3 bis spätestens 24 Monaten ungültig wird und die Joomla-Website danach wieder keine Mails versenden kann wenn man dieses "client secret" im Microsoft-Azure Portal nicht zuvor neu erstellt und in der Joomla-Konfiguration dann wieder neu einträgt und speichert.
Important part 2
Microsoft Azure client secrets expires after a maximum of between 3 and 24 months (you can select the length yourself).
If your authentication suddenly doesn't work anymore, please check the if the Client Secret has expired.
aus:
github.com/PHPMailer/PHPMailer/wiki/Microsoft-Azure-and-XOAUTH2-setup-guide
In diesem Wiki ist auch schön beschrieben wie man in Microsoft Azure das OAuth2 konfiguriert und wie man das client secret usw. erstellt.
Dieser zusätzlichen regelmäßigen Konfigurationsaufwand dürfte wohl auch für das bereits diesbezüglich kommerziell angebotene Plugin gelten.
Welche zusätzlichen möglichen Parameter an ein entsprechendes Joomla-Core-Plugin übergeben werden würden sieht man ja wohl z.B. dort:
github.com/PHPMailer/PHPMailer/blob/master/examples/sendoauth2.phps#L60-L82
Workaround um den diesbezüglichen Problemen aus dem wege zu gehen wäre z.B. eine zusätzliche seperate Domain bzw. email-Adresse für die Joomla-Website zu benutzen bei einem Maihoster/Webhoster der kein OAuth 2.0 zwingend erfordert und SMTP ermöglicht. Ähnliches ist ja auch in Linkziel in #12 zu lesen. Dort ist übrigens auch nachfolgendes von Brianteeman zu lesen vom 11.+18.12.2024 wohl nützlich für entsprechende Entwickler eines Joomla-Core-Plugins:
Can we not utilise https://github.com/decomplexity/SendOauth2
phpmailer has builtin support for using 0auth2 with the decomplexity wrapper. There is an example here https://github.com/PHPMailer/PHPM…sendoauth2.phps so surely we just need to add configuration options to Joomla to support this.
Or am I missing something here that means everyone is running and hiding?
SPF ist kein Problem wenn man die andere Domäne auch als Absenderadresse in der Joomla-Website verwendet.
Bei diesbezüglich korrekter Joomla-Konfiguration mit SMTP ist der sendene Mailserver von der anderen Domäne und dort muß SPF natürlich korrekt konfiguriert sein.
siehe z.B. auch #4 und #6 dort:
Es ist natürlich richtig das dann:
...die Absendeadresse nicht der Domäne der Webseite entsprechen würde.
Meine Frage danach, ob man bei Strato den Ernst der Lage richtig erkannt hat und warum hier nicht schon viel früher reagiert wurde hat man mir leider nicht beantwortet.
Welche "Ernst der Lage"? Wo ist denn das Problem?
Welche "Ernst der Lage"? Wo ist denn das Problem?
Mögliche Wechsel von Strato Kunden zu anderen Hostern habe ich damit gemeint. Wenn mann als Hoster 2 Monate vor dem Dday noch nicht weiß, wie die IT-Planung aussieht... naja, was soll ich dazu noch sagen.
Ich sehe das Problem immer noch nicht ... es ist nur eine andere Art der Authentifizierung - ich hoffe diese Änderungen bringen mehr Sicherheit im Mailversand und weniger Spams - für Joomla gibt es ein (oder sogar zwei) Plugins und es wird schon an einer Core Lösung gearbeitet.
Ich sehe das Problem immer noch nicht ... es ist nur eine andere Art der Authentifizierung - ich hoffe diese Änderungen bringen mehr Sicherheit im Mailversand und weniger Spams - für Joomla gibt es ein (oder sogar zwei) Plugins und es wird schon an einer Core Lösung gearbeitet.
Nicht jedes kleinere Unternehmen; Dienstleister oder Handwerksbetriebe haben das Geld, sich ab dann von nicht mehr funktionierenden älteren Geräten und Anwendungen zu verabschieden aber das hat ja mit Joomla nichts zu tun und daher beende ich meinerseits die eigenen Bedenken hier im Forum. Kann man ja sowieso nichts dran ändern.
Ich denke falls STRATO oder andere Webhoster/Mailhoster die Service Basic Authentication für SMTP beenden und nur noch OAuth 2.0 zwingend erfordern wollen dann werden sie dies mit einer erheblichen Übergangszeit von über 6 oder gar 24 Monaten vorher ankündigen so wie es z.B. Microsoft getan hat und sicherlich nicht schon in 2 Monaten! Es gibt meiner Meinung nach keinen Grund warum z.B. STRATO bereits zum gleichen Termin wie Microsoft nur noch OAuth 2.0 zwingend erfordern müßte oder sollte.
Könnte man hier vielleicht einmal konkrete Beispiele auflisten, was dann im Zusammenhang mit Joomla nicht mehr funktioniert?
Wie schon richtig in #21 von dir gennant funktioniert bei den tatsächlich betroffenen "O365-Joomla-Websites" dann bezüglich der Funktionalitäten keinerlei email-Versand vom Joomla-Core- und Joomla-Erweiterungen mehr.
Es sind also alle Funktionalitäten der betroffenen "O365-Joomla-Websites" nicht mehr nutzbar die auf den email-Versand angewiesen sind.
Die Anmeldung(Login) in Joomla funktioniert aber weiterhin sofern man nicht eine Erweiterung installiert hat die diesbezüglich eine Funktionalität besitzt die auf den email-Versand angewiesen ist(Ich kenne keine derartige Erweiterung).
Ich denke, man sollte da erstmal abwarten. Ich bin mir ziemlich sicher, dass es entweder eine geeignete Lösung seitens Joomla geben wird bzw. eine entsprechende Übergangsfrist der Hoster. Schließlich ist Joomla nicht das einzige CMS/Webanwendung, das OAuth2.0 nicht unterstützt.
Weil das Microsoft Azure "client secret" nach 3 bis spätestens 24 Monaten ungültig wird und die Joomla-Website danach wieder keine Mails versenden kann wenn man dieses "client secret" im Microsoft-Azure Portal nicht zuvor neu erstellt und in der Joomla-Konfiguration dann wieder neu einträgt und speichert.
Sieger66damit ist die Authentifizierung beim Zugang zu Virtuellen Maschinen von MS gemeint (Azure) und hat nichts mit der Authentifizierung bei Mailservern zu tun.
Das Problem ist, dass man nicht einfach ein POP3-Postfach einer anderen Domäne verwenden kann, weil das einige Probleme mit sich bringen würde (SPF...), abgesehen davon, dass die Absendeadresse nicht der Domäne der Webseite entsprechen würde.
zero POP3 hat generell keinen Einfluss auf SPF. Das Sender Policy Framework legt nur fest, welche IP's oder welche Domain's E-Mails von Server X versenden dürfen bzw. was mit empfangenen Mails passieren soll, die keine oder eine fehlerhafte Implementierung von DMARC, DKIM oder SPF haben. POP3 ist nur ein Protokoll, das dazu dient, dass Du Deine E-Mails beim Server Deines E-Mail-Anbieters abholen kannst. Man sollte in der Zwischenzeit auch IMAP statt POP3 verwenden.
Ich denke, man sollte da erstmal abwarten. Ich bin mir ziemlich sicher, dass es entweder eine geeignete Lösung seitens Joomla geben wird bzw. eine entsprechende Übergangsfrist der Hoster. Schließlich ist Joomla nicht das einzige CMS/Webanwendung, das OAuth2.0 nicht unterstützt.
Wenn Joomla bereits über ein O365 Postfach sendet und das ab September nur mehr über OAuth 2.0 funktionieren wird, dann ist die Zeit schon etwas knapp. Es muss ja nicht immer zwingend ein Hoster eingebunden sein, einige Kunden von uns haben O365 direkt bei MS, aber zum Glück gibt es nur bei wenigen eine Webseite mit Formular, wo die Mailfunktion zwingend benötigt wird.
Sieger66damit ist die Authentifizierung beim Zugang zu Virtuellen Maschinen von MS gemeint (Azure) und hat nichts mit der Authentifizierung bei Mailservern zu tun.
Ich denke du hast das Wiki dort:
github.com/PHPMailer/PHPMailer/wiki/Microsoft-Azure-and-XOAUTH2-setup-guide
und meine sonstigen Links und Erläuterungen in #27 nicht vollständig gelesen oder verstanden.
Sieger66 Mein Fehler - und ich bitte um Entschuldigung! Wir werden sehen, ob es ein adäquater Workaround ist.
Ergänze mal vom 24.August 2025:
Good news on this: The guys in Web357 have developed the plugin for both GMail and Microsoft:
https://www.web357.com/gmail-smtp-connect-joomla-plugin
https://www.web357.com/microsoft-outlook-365-mail-connect-plugin-for-joomlaaus:
github.com/joomla/joomla-cms/issues/43403
sind halt kostenpflichtige Plugins. Aber wer auf Microsoft oder Gmail angewiesen ist zahlt ja ohnehin...