Posts by Poe

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


    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 .... ?

    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?

    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....

    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.

    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ö

    Das ist der richtige Weg. Es funktioniert bei mir auch (eben getestet mit BB91.3.0). Es erfolgt eine Meldung über den erfolgreichen Export. Ich kann dir nicht sagen, weshalb das bei dir nicht kappt.

    Ich habe auf 91.3.0 geupdatet, aber die Situation ist unverändert.

    Allerdings erfolgt bei mir KEINE Meldung über den erfolgreichen Export. Wenn ich nach der Passworteingabe "Ok" klicke schließt sich einfach das Eingabefenster. Ein Fehler beim Export wird da wohl nicht so richtig korrekt abgefangen.


    Das ist jetzt nicht gerade das, was man eine Aussage nennt. Gleich drei Relativierungen in einem kurzen Satz.

    ja, nicht ohne Grund. Ehrlich gesagt sehe ich nichts von einer Verschlüsselung, eine Kollegin bekam letztens eine entsprechende Mail von mir und musste dem Schlüssel vertrauen aussprechen.

    Ich sehe mir das noch mal an, ggf mit einem anderen erzeugten Schlüssel.


    Danke

    Hallo,

    so, wollen wir mal sehen ob das hier passt...


    Ich bin aktuell auf 91.1.1 , die neue Version hab ich noch nicht ausgerollt.


    Ich verwende TB auf mehreren Rechnern unter Windows und Linux. Alles eine Emailadresse.

    Auf einem der PCs habe ich einen OpenPGP Schüssel erstellt, und wie es aussieht funktioniert das soweit irgendwie.


    Für die anderen Geräte treibt mich jetzt die Frage um welchen Weg man einschlägt. Jedes Gerät erzeugt einen Schlüssel, so das ich im Endeffekt 3 oder mehr Schlüssel für die gleiche Emailadresse habe? Scheint mir für die Empfängerseite nicht sinnvoll, gibt bestimmt Probleme. Aber möglicherweise gibt es dafür ja auch sinnvolle Szenarien.


    Vermutlich ist ein Schlüssel pro Emailadresse der vorgesehene Weg .... ?

    Also hab ich den Schlüssel exportiert: "OpenPGP Schlüssel verwalten" - > Schlüssel markiert -> Sicherheitskopie für geheimen Schlüssel erstellen -> Speicherpfad festgelegt -> Passwortfenster zur Absicherung befüllt -> ok. Keine Fehlermeldung.

    Jedoch: Die Datei ist 0kb groß, und wenn ich sie versuche in einer anderen Installation zu importieren gibt es eine Fehlermeldung.

    Für mich scheint es das das Erstellen der Sicherheitskopie nicht funktioniert. Warum ? Unklar. Nur, wenn das erstellen einer Sicherheitskopie nicht funktioniert ist das nicht gerade ein Verfahren was man benutzen möchte....


    Mich würde sowohl interessieren ob mein Vorgehen für das Nutzungsszenario korrekt ist, wie auch wo das Problem mit dem Schlüsselexport liegt.


    Danke

    Ja, diese Zeile.


    Ich verstehe die Frage nach der Version nicht, und im Moment auch nicht die Intention der Versionierung der admx. . Die Fehlermeldung erscheint doch beim öffnen des GPRO auf der Richtlinienverwaltung auf dem Server, was interessiert da die Version.


    Die letzte Frage kann ich nicht beantworten :)


    Als Hinweis mag gelten das bei Windowseigenen GPOs die Richtlinien auch immer alle da sind, und ggf halt einfach nicht funktionieren wenn der Client die Versionshöhe nicht hat.

    Okay, ich hab das Problem.

    Ich muss in der Zertifikatsverwaltung / Stammzertifizierungsstelle das .cert eintragen, dann funktioniert es wieder mit SSL/TLS und STARTTLS. Über die Ausnahmeregelungen geht es scheinbar nicht mehr wie bisher.


    Jetzt verstehe ich auch warum im Enterprise so viel Fragen kamen wie man das Zertifikat global mit einimpft..... naja, bei paar Hänseln schafft man es noch händisch...

    Extras > Einstellungen > Erweitert > Zertifikate > Zertifikate Verwalten

    Wenn es diesen Punkt denn gäbe. Das ist jetzt unter Extras > Einstellungen > Datenschutz &Sicherheit > Zertifikate > Zertifikate Verwalten.


    Die relevanten Zertifikate tauchen dort unter den Serverzertifikaten auf. Sie stehen zwar unter "Unbekannt" und haben keinen Namen, aber sind da. Oder es sind definierte Ausnahmen, ich kann das nicht unterschieden. Ich habe bei den Serverzertifikaten versucht den eigenen MailServer noch mal aus Ausnahme einzutragen : xyzserver:993 bzw. xyzserver:587, aber das wid als Eintrag nicht akzeptiert.


    Ich habe keine Probleme bei anderen Emailkonten großer Provider die ebenfalls über 993 agieren.
    In dem Fall exsistiert auch noch ein Eintrag von GDATA für diesen anderen Mailserver des Providers.


    Wobei ich die Zertifikatsgeschichte auch schwer durchschaue. Habe versucht das Zertifikat unter "Ihre Zertifikate" neu zu importieren, aber das wird verweigert. Ich habe eine .key , .crt und .pem , aber die Zertifikatsverwaltung frisst die nicht.


    Der Kalender wurde bei mir problemlos übernommen, sowohl der lokale als auch der auf dem Netzlaufwerk.

    Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:

    • Thunderbird-Version (konkrete Versionsnummer:( 78.0
    • Wurde gerade auf eine neue Versionsreihe aktualisiert (alte und neue Version angeben): 68.10 auf 78.0
    • Betriebssystem + Version: W10 Prof
    • Kontenart (POP / IMAP): IMAP
    • Postfach-Anbieter (z.B. GMX): lokaler Mailserver
    • Eingesetzte Antiviren-Software: GDATA
    • Firewall (Betriebssystem-intern/Externe Software): intern und extern
    • Router-Modellbezeichnung (bei Sende-Problemen):


    Nach Update auf 78.0 ist Thunderbird nicht mehr in der Lage mit dem lokalen Mailserver zusammenzuarbeiten. Weder im IMAP noch im SMTP. Ursache ist wohl eine Änderung in den Authentifizierungsvorgaben.

    IMAP wird hier abgerufen: Port 993, Verbindungssicherheit SSL/TLS , Passwort normal. Dazu gab es ein internes SSL Client Zertifikat.

    SMTP für den Versand: Port 587, Verbindungssicherheit STARTTLS, Passwort normal. Dazu ebenfalls ein internes SSL Client Zertifikat.


    Seit dem Upgrade funktioniert das so nicht mehr. Ich musste IMAP auf Port 143, Verbindungssicherheit keine , Passwort ungesichert übertragen zurückstufen um überhaupt emails abrufen zu können. Das gleiche bei SMPT, zurück auf Port 25, und PW ungesichert.


    Das ist zwar jetzt erst mal nicht sooo tragisch da der Mailserver ein Zimmer weiter steht, aber gefallen finde ich da nicht dran. Kann mir jemand sagen was da los ist, ich vermute das steht in Zusammenhang mit den neuen Verschlüsselungsoptionen.


    Früher wurde ich bei Erstverbindung mit dem Mailserver von Thunderbird gefragt ob ich das Selbstzertifikat akzeptieren will als Außnahme, aber jetzt wird es scheinbar kommentarlos abgelehnt. An welchen Stellschrauben kann ich da jetzt drehen.


    mfg

    Nein, die Mitarbeiter sollen ihn nur eintragen damit der Rest der Belegschaft Bescheid weiß. Dein rechtliches Argument halte ich für ziemlich wackelig, das Argument deines Chefs ist korrekt meiner Meinung nach. Urlaub ist nur wenn du einen Urlaubtag nimmst. Das dein Urlaub von Wochenenden durchsetzt ist, und wie da die rechtliche Handhabe ist - dazu gab es schon diverse Gerichtsentschiede. ..... aber völlig egal, ist ein anderes Thema.


    Ich formuliere mal einen deutlicheren Fall: Jemand ist 4 Wochen auf Lehrgang im Bundesland nebenan. Mo-Fr. Am Wochenende ist kein Lehrgang. Ergo sollte da auch keiner eingetragen sein.

    Die Lösung oben kann ich auf Grund der Komplexitität leider keinem Mitarbeiter zumuten der mal fix den Urlaub für das verlängerte Wochende eintragen will.

    Na gut, dann halt nicht....ists halt so, lebt man halt damit. Jede 5€ Zeitschaltuhr kann diverse Wochentagseinstellungen aber der Kalender halt nicht.

    Ja, diese Lösung würde funktionieren, ist aber nicht zumutbar.

    Das Problem ist das suggeriert wird das man für Sonnabend und Sonntag Urlaubstage verwendet. Zumindest bei uns ist das nicht der Fall :)

    Was machen denn andere mit Terminen die nur von Montag bis Freitag stattfinden? Außwärte Montage, mehrwöchige Schulungen , was weiß ich was...

    Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:

    • Thunderbird-Version: 68.2.2
    • Lightning-Version:68.2.2
    • Betriebssystem + Version:W10Pro 32b


    Bei uns werden in einem "zentralen" Kalender Urlaubstermine eingetragen. Blöderweise werden diese Termine mit der Kategorie " Urlaub" auch über das Wochenende angezeigt, was etwas irreführend ist.

    Gibt es einen Weg die Anzeige auf Werktage oder Mo-Fr. zu begrenzen? Manuell durch Auswahl, oder indem das eine Eigenschaft der Kategorie "Urlaub" ist?

    Irgendeinen Trick mittels "Benutzerdefiniertes Wiederholen"? Allerdings sollte es auch noch von Lieschen Müller händelbar sein......


    mfg