-
Beiträge
-
-
Guten Tag,
seit etwa 3 Tagen ist unsere Otobo Instanz nicht mehr im Stande eine Verbindung zu M365 auf zu bauen. Den genauen Zeitpunkt kann ich zwar nicht mehr bestimmen, das verhalten ist jedoch unverändert das selbe.
Im Communication Log sammeln sich versuche Mail per Imap abzurufen
Die einzelnen Prozesse werden dann nach 600 Sekunden gekillt und eine entsprechende Mail vom Scheduler versendet
Error: Timeout of 600 seconds reached, killing child process!
Die Prozesse scheinen laut Logs schon beim Verbindungsaufbau zu 365 zu scheitern. Auch ein manuelles FetchMail mit Debug über die Console zeigt leider nicht mehr
Folgendes konnte ich am Wochenende bereits testen
- Imap Verbindung zu einem anderen System mit Basic Auth funktioniert!
- Login in die M365 Accounts via Webseite (getestet von meinem Notebook, sprich andere IP) -> Funktioniert
- Login in die M365 Accounts via Thunderbird (getestet von meinem Notebook, sprich andere IP) -> Funktioniert
- TCP Verbindung zu outlook.office365.com -> Funktioniert
- Eine andere Public IP (um eine eventuelle Sperrung der IP zu umgehen)
Eingesetzt werden:
Otobo 10.1.7
Mail::IMAPClient 3.42
Debian 11
openssl 1.1.1n-0+deb11u5
MailAccount-OAuth2 10.1.1
Auf Grund meiner Tests würde ich die Ursache für das Problem bei dem Otobo Plugin oder dem IMAPClient vermuten, hat sonst noch jemand aktuell Probleme mit der Verbindung zu 365 bzw. noch eine Idee an was es liegen kann?
Grüße und danke,
Steven
-
Hallo Steven,
wir haben das identische Verhalten bei einem anderen Kunden, auch vom Zeitpunkt passt es sehr gut.
Ich habe das Problem schon gedebugged und festgestellt, dass OTOBO eine Verbindung aufbaut und dann aber nichts mehr zurückkommt von MS:
Wir bekommen auch keinen Fehler. Nach dieser Ausgabe sollte es eigentlich weiter gehen, es kommt aber nichts mehr:otobo@ff0367fe9f14:~$ bin/otobo.Console.pl Maint::PostMaster::MailAccountFetch –force-pid –debug
Spawning child process to fetch incoming messages from mail accounts…
outlook.office365.com (IMAPOAuth2)…
Started at Sun Jun 25 12:05:38 2023
Using Mail::IMAPClient version 3.43 on perl 5.036000
Connecting with IO::Socket::IP PeerAddr outlook.office365.com PeerPort 143 Proto tcp Timeout 600 Debug 1
Connected to outlook.office365.com
Read: * OK The Microsoft Exchange IMAP4 service is ready. [RgBSADAAUAAyADgAMQBDDDKHAAEEAMAAxADIANQAuAEQARQBKLSLDLSKVAFAAMgA4ADEALgBQAFIATwBEAC4ATwBVAFQATABPAE8ASwAuAEMATwBNAA==]
Sending: 1 STARTTLS
Sent 12 bytesDas Verhalten kenne ich so überhaupt nicht, oder nur von Fail2Ban oder ähnlichen Diensten die dann einschreiten. Wir senden 12 bytes hin und es kommt einfach nichts zurück.
Ich denke daher nicht, dass das Problem bei OTOBO liegt, weiter bin ich aber leider auch noch nicht. Sieht man nichts in den Logdateien vom MS365 Exchange?
Neue Erkenntnisse werde ich hier teilen.
Schöne Grüße,
Stefan
-
Hallo Stefan,
AFAIK gibt es keine Möglichkeit auf die Connection Logs von Exchange zuzugreifen. Ich vermute den Fehler irgendwo im IMAP / SSL.
Anbei noch ein Screenshot welcher zeigt, dass der Login problemlos durchläuft.
Was ich noch nicht getestet habe, vielleicht hat das jemand von euch. Funktioniert das abrufen via POP?
@Thomas, das wäre auch mein Workaround
Grüße,
Steven
-
-
Hallo Steven,
ich kann das Problem bestätigen.
Wir haben seit Samstagmorgen genau den gleichen Zustand. Verbindung bricht mit timeout ab. Zugänge selbst funktionieren aber.Aktueller Workaround: Mails an anderen Provider weitergeleitet und diesen dann per IMAP angebunden.
Über Hilfe und Neuigkeiten zu dem Thema sind wir dankbar!
VG Thomas
-
-
Hallo nochmal,
Genau bei den TLS Geschichten geht es nicht weiter, sind eventuell irgendwelche Zertifikate abgelaufen oder ungültig?
Schöne Grüße,
Stefan
-
Hallo Stefan,
möglich, allerdings müsste dieser Vertrauensbruch dann irgendwo aus Perl kommen womit ich mich leider nicht auskenne. Sollte Perl, wie ich annehme auf Openssl zurückgreifen dürfte mMn. kein Zertifikatsproblem vorliegen. Ich komme mit openssl bis zum IMAP Service von 365
openssl s_client -connect outlook.office365.com:993 -crlf -quiet
depth=2 C = US, O = DigiCert Inc, OU = http://www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert Cloud Services CA-1
verify return:1
depth=0 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = outlook.com
verify return:1
* OK The Microsoft Exchange IMAP4 service is ready. [RgBSADMAUAAyADgAMQBDAEEAMAAwADUAMAAuAEQARQBVAFAAMgA4ADEALgBQAFIATwBEAC4ATwBVAFQATABPAE8ASwAuAEMATwBNAA==]Grüße,
Steven
-
-
Guten Morgen,
wir haben seit Sonntag früh (~4.20 Uhr Morgens) die selben Probleme.
Sollte das Problem wirklich von den TLS Zertifikaten kommen, gibt es überhaupt eine Möglichkeit das selbst zu beheben, oder muss hier auf ein Update des MailAccount-OAuth2 Plugins gewartet werden?
Update:
Wir haben eben noch eine Meldung von Microsoft gefunden, welche auf Probleme mit Exchange Online Services hinweist, unter anderem IMAP und POP3 Connections.
-
-
-
Guten Tag zusammen,
anbei die Meldung aus dem Admin Portal von MS.
Some users may experience intermittent performance issues with various Microsoft 365 services 26. Juni 2023 um 07:24 MESZ .... - Users may be unable to access the Exchange Online service from Internet Message Access Protocol (IMAP) and Post Office Protocol (POP3) connection methods. Grüße, Steven
-
-
-
Hi,
ah danke, das klingt wirklich so:
Denn die Abschaltung von TLS 1 und 1.1 soll eigentlich erst nächsten Samstag erfolgen, das hatte ich überlesen. Und nach unseren ersten Tests sollte jede aktuelle OTOBO Version eine passende TLS Version selbsttätig aushandeln.
Wir bleiben aber dran.
Schöne Grüße,
Stefan
-
Liebe OTOBO Community,
Emin hat einen Workaround erstellt für das Problem, wir werden das Thema aber weiter untersuchen und nicht sofort ein neues Paket veröffentlichen, denn eigentlich sollte diese Änderungen nicht notwendig sein.
Das einzige was geändert wurde ist, dass der Socket separat aufgebaut wird, deswegen warten wir jetzt nochmal einen Tag ab, was sich bei MS tut.
Ihr könnt diese Datei aber austauschen, danach funktioniert die Mailabholung via OAuth und O365 wieder:
Wir bleiben dran….
Schöne Grüße,
Team OTOBO
-
Hallo Stefan,
vielen Dank für Dein schnelles Teilen in diesem Topic. Für alle, die das Problem gerne sofort lösen würden, habe ich zwei Zeilen vorbereitet:
sed -i 's/use MIME::Base64;/use MIME::Base64;\nuse IO::Socket::SSL;/' /opt/otobo/Kernel/System/MailAccount/IMAPOAuth2.pmsed -i 's/Starttls => \[ SSL_verify_mode => 0 \],/Socket => IO::Socket::SSL->new( PeerAddr => $Param{Host}, PeerPort => 993, SSL_verify_mode => SSL_VERIFY_NONE ),/' /opt/otobo/Kernel/System/MailAccount/IMAPOAuth2.pmViele Grüße
EminEdit: Es wäre toll, wenn Betroffene Ihr Feedback teilen würde (ganz besonders, wenn es nicht funktionieren sollte).
-
-
Danke Stefan, der Fix funktioniert!
Ich musste allerdings nach dem Austausch der Datei das Abrufen manuell via CLI starten. Ich vermute aber, dass es im Anschluss normal funktionieren sollte.
Danke auch an zzz für die sed Befehle, das wird bei den weiteren Ticketsystemen, bei welchen wir das umstellen müssen, ordentlich Zeit sparen.
-
-
Hi zusammen,
bei uns funktioniert es auch wieder.
Lassen sich die mit Stauts „wird verarbeitet“ Connection Einträge im Kommunikationslog irgendwie canceln?
Grüße
Robert
-
Je nachdem wie alt die Einträge sind bekommst du diese Recht einfach raus in dem du alles löschst was älter als eine Stunde ist
bin/otobo.Console.pl Maint::Log::CommunicationLog –delete-by-hours-old 1 –force-delete
ansonsten kannst du die Einträge auch einzeln löschen, XXXXX steht für die ID und steht in der URL in den Detail der Vorgänge.
bin/otobo.Console.pl Maint::Log::CommunicationLog –delete-by-id XXXXX–force-delete
grüße,
Steven
-
-
-
-
-
-
-
-
-
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.