[English]Aktuell scheint es, dass Nutzer von Multifunktionsdruckern mit Scan-Funktion, die eine Verbindung zu einem Microsoft Office 365 SMTP-Server verwenden, bei bestimmten Geräten in Probleme laufen. Nutzer von Ricoh Geräten bekommen beim Scannen auf Microsoft Office 365-Konten Verbindungsfehler "Cannot connect to SMTP server" gemeldet und es kommt zu einer "SSL negotiation failed"-Meldung. Betroffen sind zum Beispiel verschiedene Ricoh-Modelle, aber auch Xerox Versalink C7030 oder Kyocera- und Sharp-Geräte wurden als betroffen gemeldet. Ursache dürfte eine Änderung bei TLS 1.2 durch Microsoft sein. Aktuell ist unklar, ob Microsoft das bereits behoben hat.
Anzeige
Scan-Problem beim Senden zu MS Office 365-Konto
Ein Blog-Leser hat mich auf Facebook in einer privaten Nachricht auf ein Problem mit Multifunktionsgeräten hingewiesen, wenn diese versuchen, Scans per SMTP an Microsoft Office 365-Konten zu übertragen. Das Problem ist seit dem 2. Februar 2025 bei Microsoft Learn unter office 365 "Cannot connect to SMTP server" "SSL negotiation failed" beschrieben und wird dort von Betroffenen diskutiert.
Ricoh Scan-Fehler "Cannot connect to SMTP server"
Jemand, der für den Hersteller Ricoh arbeitet, hat den Thread gestartet und schreibt, dass er mehrere Kunden habe, die plötzlich den Fehler "Verbindung zum SMTP-Server kann nicht hergestellt werden", "SSL-Aushandlung fehlgeschlagen" (oder "Cannot connect to SMTP server", "SSL negotiation failed" in Englisch) angezeigt bekämen.
Soweit ich es interpretiere, trat der Fehler beim Scannen mit Rico-Geräten auf. Betroffen sind die MFP-Modelle MP C307, MP 6055, IM C3000 und MP C3004ex. Es sieht so aus, als ob deren Scan-Funktion die Scan-Ergebnisse nicht an den eingerichteten SMTP-Server übertragen können, sofern die Geräte die älteren Controller 16S oder 17S verwenden.
Fehlerbild eingekreist auf Office 365-Nutzer
Mehre Nutzer bestätigten den Fehler beim Scannen, wobei manche die Fehlermeldung nur beim zweiten oder dritten Scan hatten. Bei der Überprüfung der Nutzerk-Konfigurationen wurde festgestellt, dass alle Betroffenen Microsoft Office365-Konten für die SMTP-Authentifizierung (smtp.office365.com) verwenden. Und diese SMTP-Authentifizierung funktionierte plötzlich nicht mehr.
Anzeige
Ursache: Deaktivierte TLS 1.2 Cipher-Suite
Im Thread, der bereits drei Seiten und viele Meldungen von Betroffenen umfasst, meldete sich frühzeitig ein Betroffener und berichtete, dass es wohl Probleme mit der TLS 1.2-Verschlüsselung gebe. Die SMTP-Verbindung klappt, wenn die zur Kommunikation verwendeten Server noch TLS_RSA unterstützen. Werden nur Elliptic Curves unterstützt, scheitert die Kommunikation.
Später bestätigte ein Nutzer, dass das Problem mit der TLS 1.2 Cipher-Suite zu tun habe. Ein Ricoh-Techniker habe ihm geschrieben: "Es sieht für mich so aus, als ob Microsoft die Cipher Suites ohne elliptische Kurven für TLS1.2 deaktiviert hat. ECDHE ist nur bei neueren Controllern ab 18S möglich."
Das bedeutet, dass betroffene Geräte mit den älteren Controllern u.U. keine Scans mehr ausführen können, wenn diese das Ergebnis an ein Microsoft Office 365-Konto über smtp.office365.com übertragen.
Betroffene können prüfen, ob die Multifunktionsgeräte ggf. eine andere SMTP-Konfiguration einstellen können. Im Verlauf der Diskussion schreibt jemand, dass er bei seinem Kyocera-Multifunktionsdrucker als Hash SHA2(256/384) aktiviert habe, worauf die Scan-Funktion wieder funktionierte und die Ergebnisse per SMTP an das Microsoft Office 365-Konto übertragen konnte.
Zum 5. Februar 2025 hat sich ein Betroffener allerdings gemeldet und berichtet, dass das Scannen plötzlich (ohne Eingriff) wieder funktioniere. Er vermutet, dass Microsoft die Probleme mit dem TLS 1.2 Cipher intern behoben habe.
Ein anderer Betroffener schrieb, dass sie das Problem nun per Workaround gelöst haben. Sie haben mit hMailServer einen internen Server als SMTP-Relay eingerichtet, und alle Scans von den betroffenen Geräten über diesen Server an Microsoft weiterleiten. War bzw. ist jemand aus der Leserschaft betroffen?
Anzeige
Vermutlich ist das die Ursache, dass mein Brother ADS-2800W keine Scans über den SMTP-Server von Microsoft 365 mehr verschicken kann (ich hatte zunächst 2FA/MFA in Verdacht, weil beim Scanversuch eine kryptische Nachricht, die auf eine Webseite verwies, auf dem Display des Scanners erschien). Übergangsweise verwende ich ein Mail-Konto bei einem kostenlosen E-Mail-Anbieter (auch, um festzustellen, ob es am TLS zwischen Scanner und Provider liegt).
Drucker, Scanner und Mufucs sind leider was TLS und Chiphers angeht meist Jahre (oder sogar Jahrzehnte) hinterher.
Wir haben meistens einen hMailserver irgendwo bei den Kunden stehen. Die MFC mailen dann über diesen zu Office 365.
Grüße
Bastian
Hatte ich auch überlegt einzurichten, aber dann funktioniert es ab September 2025 eh nicht mehr, da hMailserver kein OAuth2 kann und wenn ich dann einen Proxy benötige (z.B. https://github.com/oauth2-proxy/oauth2-proxy), kann ich hMailserver auch direkt weglassen. Oder übersehe ich da etwas?
Ich habe für unsere Scanner Anfang der Woche als das Problem auftrat E-Mail-Konten bei unserem Webhoster eingerichtet (sind ja meist kostenlos mit dabei). Die landen auch nicht im Junk-Ordner oder in der Quarantäne, wenn Sie an Microsoft 365 geschickt werden.
@poiuz:
Wenn Du die Option 3 von
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
benutzt, genügt eine statische public IP oder ein Certificate, um per SMTP-Protokoll Port 25 Emails bei ExchangeOnline einzuliefern.
Dazu braucht es kein OAUTH2.
für M365 soll für normale Konten SMTP ganz deaktiviert werden und man soll sich einen speziellen Versand-Account einrichten, der auch für Massenmails geeignet ist. Für die Geräte und Programme, die schon kein TLS können, habe ich stunnel im Einsatz, ein einfacher Proxy. Muss mal sehen, ob der schon mit dem neueren Zeug zurechtkommt
Ricoh sagte uns, das dies seitens Microsoft erwartete Verhalten sei. Es gibt wohl bestimmte IPs wo die alten Cipber noch funktionieren ansonsten müssten die Geräte endweder aktualisiert oder ersetzt werden. Ich als Microsoft 365 Administrator empfehle den Versuch den HVE Dienst von Exchange Online mal zu testen. Kann nur sagen das ich den für ein paar Kunden nutze und da keine Probleme habe.
Haben wir auch ausprobiert und funktioniert ganz wunderbar.
Hab ich auch so im Einsatz. Dort wo MFA aktiviert ist, kann man ja ein Appkennwort erstellen lassen, klappt einwandfrei. Mal sehen wie das weitergeht wenn sie HVE kostenpflichtig machen und den kostenlosen Versand einstellen.
Haben einen Ricoh MP C3004 mit exakt dem beschriebenen Fehlerbild. Aktuell funktioniert es wieder…. mal sehen wie lange.
Wenn ich es richtig interpretiere, wird "das Funktionieren" wohl zum Lotto-Spiel – sprich: Es hängt davon ab, über welche Server die SMTP-Anfrage an Microsoft bzw. smtp.office365.com geht. Ist ein Server mit geändertem TLS 1.2 Cipher dabei, tritt der Fehler auf.
Ein Betroffener hatte ja ein SMTP-Relais aufgesetzt (ist ja im Beitrag erwähnt) – dürfte als Workaround von Interesse sein.
Kleiner Hinweis: Der Hersteller heißt Ricoh, nicht Rico. Im Beitrag ist es mal so, mal so geschrieben.
Dasselbe habe ich mit Geräten von OKI (MC883/MC8773/MC853) auch festgestellt.
Ab der Firmware A07.96 kann die Anbindung va OAuth2 gebaut werden, welche gemäss OKI-Support ohne Einschränkung funktionieren sollte.
Wir haben aktuell noch viele Sharp Geräte der MX Serie mit diesem Fehler.
Wir haben das gleiche Problem bei mehreren Kunden. Ich bin jetzt auf der Suche nach einem Programm was die Mails entgegennehmen könnte und an Office365 weiterleiten kann.
Leider hat es in unserer Umgebung keine Selbstheilung gegeben.
Wir haben seit Ende der Woche nach wie vor das Problem mit den Ricoh MFPs.