Serververbindungen funktionieren nicht mehr nach Update auf TB 102 und höher

    Hallo,

    ich habe die Tage in einer Windows Umgebung das Update auf 102.1. ausgerollt. Bisher standen wir auf 91.8.1 . Das Update erfolgt bei uns durch Überinstallation.

    In Folge des Update funktionierten bei keiner Installation die Verbindungen zum Mailserver mehr. Anschließende Aktualisierung auf 102.1.2 ohne Effekt.

    diese laufen über

    Port 993, SSL/TLS, Passwort normal

    Das Zertifkat ist hausintern und muss einmal als Ausnahme bestätigt werden.

    Ich musste auf

    Port 143, Sicherheit:keine, Passwort ungesichert

    herabstufen.

    Außerdem habe ich auf Grund eines Posts an anderer Stelle in den Sicherheitseinstellungen auf "automatische Zertifikatswahl" gewechselt.


    Das Symptom ist das die Clients unterunterbrochen mit dem Punkt oben links hin und her rödeln und eine Verbindung zum Server versuchen, aber es wird nix, es gibt aber auch keine Fehlermeldung. Nachrichten werden in Folge natürlich nicht abgerufen.

    Irgendetwas hat sich in TB am Handling der Verbindungssicherheit geändert.

    Da der Mailserver hier hausintern steht ist das jetzt erst mal nicht ganz so tragisch, trotzdem würde ich mir eine sicherere Alternative wünschen.

    Haben wir hier einen Bug oder ist das gewollt und welche Optionen stehen alternativ zur Verfügung.

    Danke,

    mfg Pö

    Hilf mir kurz auf die Sprünge: IMAP oder POP?

    Bei POP gab es intern ja grundlegende Änderungen, da man die komplette Implementierung für POP auf Javascript statt C++ umgestellt hat. Dies war auch schon für SMTP im 91er der Fall und findet gerade schrittweise auch für IMAP statt. Bei der internen Umstellung gibt es leider alle Möglichen Fallstricke - beispielsweise mit der Kodierung der Passwörter usw.

    Sorry, hatte ich vergessen, es ist alle IMAP.

    Ach ja, jene, welche das Passwort nicht merken lassen, bekommen nciht mal das Passwortfenster zum Mailabruf zu sehen. Dh es scheitert ganz grundlegend am Aufbau der gesicherten Verbindung zum Mailserver.

    Du könntest ein Log erstellen und nach dem Problem darin schauen. Dies wäre letztlich auch für eine Bug-Meldung hilfreich:

    Protokoll (Log-Datei) der Server-Verbindung mit IMAP, POP und SMTP erstellen - Thunderbird Mail DE

    Hm.Guter Ansatz.

    Der Mailserver hat folgende Versionen aktiviert: TLS v.1.1 , 1.2, 1.3

    Ich hätte erwartet das das keine Probleme verursacht, aber ich kappe mal die Option für 1.1, mal sehen...

    TLS 1.1. am Mailserver abgeschaltet, aber kein Verbesserung. Sobald ich auf SSL/TLS wechsel gibt es kein Verbindungsaufbau.

    Ich kann mir aber gut vorstellen das das Problem aus diesem Dunstkreis kommt.

    Weitere Checks ergaben das es eher ein Problem bei der Authentifizierung des Benutzers am Server ist ( wo aber nichts verändert wurde.) . Gas es da Änderungen auf TB Ebene? Oben wurden Probleme bei der Codierung der Passwörter angesprochen, was bei "Passwort, normal" gegenüber "Passwort, unverschlüsselt" ja eine Fehlerquelle sein könnte.

    Gesendete Nachrichten laufen im RECEIVED Header mit: ...from [192.168.42.xx] (xx.xx.xx [192.168.42.xx]) by xxxxxserver with ESMTPSA (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128) , also soweit sogut mit dem TLS....

    Also irgendetwas ist da ganz schön geschlampt....

    Einmal editiert, zuletzt von Poe (12. August 2022 um 12:48)

    Zitat von Poe

    Weitere Checks ergaben das es eher ein Problem bei der Authentifizierung des Benutzers am Server ist

    Die Logs sollten das evtl. genauer zeigen.

    Zitat von Poe

    Gas es da Änderungen auf TB Ebene?

    Weiß ich nicht. Aber du bist nicht der einzige, der über ein Problem dieser Art mit einer 102 berichtet. Könnte also sein.

    Zitat von Poe

    Ich habe leider nie begriffen was "Passwort,normal" gegenüber "Passwort, ungesichert" und "Passwort, verschlüsselt" differenziert.

    Es geht dabei nicht um die Verschlüsselung der Verbindung, sondern um die Art, wie authentifiziert wird. Passwort, normal gibt es nur bei verschlüsselten Verbindungen. Zur Authentifizierung wird ein Passwort über die verschlüsselte Verbindung gesendet. Passwort verschlüsselt wäre eine andere Methode. Hier wird zusätzlich zu der verschlüsselten Verbindung das Passwort selbst ebenfalls verschlüsselt, mit einem anderen Schlüssel. Eine weitere Methode zu Authentifizierung wäre z.B. die, kein Passwort zu verwenden, sondern ein Zertifikat. Oder Kerberos, oder ... .

    Passwort ungesichert gibt es nur in Zusammenhang mit einer unverschlüsselten Verbindung. Die Methode zur Authentifizierung ist die Verwendung eines unverschlüsselten Passwortes, das hier sogar lesbar übertragen.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

    Ich lese hier parallel Meldungen das nach dem Update das Passwort nicht erkannt wird. Das scheint mir irgendwie in die gleiche Richtung zu gehen.

    Im SMPT, also beim Versand zum Mailserver, ist übrigens alles unverändert und funktioniert (StartTLS, Passwort normal). Merkwürdigerweise musste allerdings das hauseigene Zertifikat erneut als Sicherheitsausnahme bestätigt werden.

    Mich beschleicht der Verdacht das das auch beim IMAP so passieren sollte (bei einer kompletten Neuinstallation eines Clients wird das nämlich immer nötig hier) die 102. es aber nicht schafft das Warnfenster mit der Bestätigung für die Sicherheitsausnahme einzublenden. Und dann gehts halt nicht weiter.

    Das IMAP Log... ist..... ausufernd. Wonach such ich da?

    Zitat von Poe

    Das IMAP Log... ist..... ausufernd. Wonach such ich da?

    Tja, das Lesen dieser Logs ist nicht ganz einfach, weil die ja keine genormte Form haben, sondern es sich dabei im Grunde um mozillaspezifische Debug-Informationen handelt.

    Nichtsdestotrotz erschließen sich viele Dinge auch Außenstehenden wie uns. Du kannst darin z.B. den Anmeldevorgang nachvollziehen. Wenn deine Theorie stimmt, müsstest du einen Fehler bei der Authentifizierung sehen.

    Mich wundert ein wenig, dass das Log so groß wird, wenn doch bereits die Anmeldung scheitert. Die vielen typischen Einträge, die entstehen, wenn die E-Mails abgerufen werden, dürften ja gar nicht auftauchen.

    Um die Logs klein zu halten, rufe nur ein einziges Konto ab, das betroffen ist. Da der Anmeldevorgang sehr früh im Prozess stattfindet, sollten dir auch time stamps helfen.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

    Hallo, auch ich habe mit einen hauseigenen Mailserver die Fehlersituation wie User Poe oben.

    Fehler: Port 993, SSL/TLS, Passwort normal

    OK mit: Port 143, Sicherheit:keine, Passwort ungesichert

    hier mal ein anonymisierter LOG:

    Das Bestätigen einer Zertifikatsausname kommt nicht. Es half auch die Umstellung auf

    Einstellungen/Zertifikate/Automatisch eins auswählen nicht.

    Kann jemand was mit den LOGs anfangen?

    2 Mal editiert, zuletzt von WarpRider (13. August 2022 um 16:55) aus folgendem Grund: Code-Tags gesetzt

    Das ist merkwürdig, denn ohne Login kann es ja nicht funktionieren. Der Schnipsel oben deutet auch darauf hin, dass die Anmeldung bereits erfolgt ist, weil es ja schon den Select auf INBOX gibt. Das kann ich aber nicht genauer sagen, weil das thunderbird-spezifischer Debug-Text ist.

    Wenn du einen Bug dazu eröffnest, dann gelangst du an Leute, die diesen Code zu 100% verstehen. Das wäre daher meine Empfehlung.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

    Mein Log sieht auch so aus wie von WarpRider, insbesondere Zeile 11 -14. Falls das was zu sagen hat.

    Zitat von Susi to visit

    er Schnipsel oben deutet auch darauf hin, dass die Anmeldung bereits erfolgt ist, weil es ja schon den Select auf INBOX gibt.

    Das sehe ich etwas anders, aber bin nicht tief genug in der Materie. Die Ordnerstruktur zu sehen und den Inhalt einzelner Nachrichten abzurufen ...... hmm.
    Ich glaube insbesondere das "Nachrichten- abrufen" ist das Problem. Ordner und bestehende Mails können ggf je nach Konfiguration auch durch lokale Offline Verfügbarkeit da sein, ohne das es einer Server- Anmeldung bedarf .... ?

    Zitat von Poe

    Ordner und bestehende Mails können ggf je nach Konfiguration auch durch lokale Offline Verfügbarkeit da sein, ohne das es einer Server- Anmeldung bedarf .... ?

    Das ließe sich leicht herausfinden, indem du den Cache deaktivierst. Müßig bleibt es trotzdem irgendwie, deshalb der Hinweis, das Problem den Entwicklern zu melden. Die wissen wann das Programm welche Aktion ausführen sollte und können den Debug Output verstehen.

    Welchen Log Level hattet ihr eigentlich eingestellt? Ist der Anmeldevorgang vielleicht deshalb nicht zu sehen?

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

    Auch mit Version 102.2.2 ist der Fehler noch vorhanden.

  • Community-Bot 3. September 2024 um 20:50

    Hat das Thema geschlossen.