Das Ausstellerzertifikat ist von zscaler. Zscaler ist m.W. ein Konkurrent von Symantec im Unternehmensumfeld und u.a. dafür bekannt, dass sie Unternehmen auf diesem Weg eine SSL-Inspection erlauben. Deren Root ist standardmäßig nicht beim Thunderbird dabei. Das riecht also ein wenig danach, als ob hier doch eine Sicherheitslösung dazwischenfunkt.
Ich würde also zunächst mal erfragen, ob dein Provider tatsächlich Zertifikate von denen ausstellen lässt.
Das hatten wir neulich erst. Eine richtig saubere Lösung ist das nicht. Denn auf Keyservern bleibt der alte SHA-1 in den hochgeladenen Keys erhalten. Ebenso in den Signaturen von dritten. Das sollte man bedenken, denn schließlich sagt Heise gleich zu Beginn des Artikels:
Der eigene PGP-Schlüssel ist Statussymbol und Aushängeschild. Wie peinlich, wenn der dann mit veralteten SHA1-Signaturen beglaubigt ist.
und
Für PGP-Schlüssel, die mit SHA1 beglaubigt wurden, besteht dennoch keine realistische Gefahr. [...] Trotzdem sollte man SHA1 heute nicht mehr einsetzen. Gar nicht! Das soll endlich verschwinden.
Besser also: Ein neues Paar erstellen. Das macht auch weniger Arbeit.
Doch, der stammt vom eM-Client!
Das kann ich mir nicht vorstellen. Weil:
Probiere es einfach mal aus:
Sorry, nein. Ich werde mir gewiss keinen eM installieren, nur um etwas auszuprobieren. Selbst wenn du richtig liegen würdest, hätte ich ja nichts davon. Davon gehen die "Fehler" im Thunderbird ja nicht weg.
Nebenbei, ich habe in meinen Bookmarks einen alten Faden aus dem US-Forum gefunden: http://forums.mozillazine.org/viewtopic.php?f=46&t=623218 . Der ist von 2008 und heute natürlich nicht mehr aussagekräftig. Er zeigt aber, wie alt dieses Thema ist.
es erstellt immer noch ein Profil nicht neben sich selbst, sondern in %appdata% der HDD-Systempartition.
Das Geheimis einer selbstgestrickten portablen Version ist, dass man sie gleich mit dem richtigen Profil aufruft. Man erstellt also ein Profil am gewünchten Ort, z.B. auf dem Stick, und startet dann direkt mit diesem Profil. Aufrufoption -p.
der Syntax ist auch denkbar einfach.
Mir ging es nicht um Syntax, sondern um die Regeln dazu.
während eM-Client zusätzlich die Tags
X-MOZ-LASTACK:20220421T192900Z
X-MOZ stammt gewiss nicht vom eM-Client. Der stammt vom Thunderbird.
Wenn du das tiefer ergründen willst, wirst du wohl einen Blick in die RFC werfen müssen. Ich investiere hier, wie geschrieben, keine Zeit mehr.
Solche ACKs gibt es vielleicht mehrere: Man bestätigt den Termin an sich, d.h. dessen Status ändert sich zu bestätigt, jeder Eingeladene kann eine Einladung bestätigen, ... .
Außerdem hat der Thunderbird mit X- noch sein eigenes Feld dazu.
Sinnvoll kann es auch sein, sich die ics direkt auf dem Server anzuschauen.
ist aus dem LOG file von TB
Das ist mir schon klar. Die Frage ist: Gibt das Log hier eine Zustandsmeldung des Servers wider oder eine des Thunderbird, also wessen Connection Cache wurde überschritten? Ich kann das der Meldung nicht entnehmen.
In einem Fall könnte man die Anzahl der Verbindungen im Thunderbird erhöhen, im anderen Fall wäre die Grenze beim Provider.
Die E-Mail-Adresse ist eine von kabelbw. Der angesprochene Server von unity-mail. Sofern die nicht auch zusammengehören, ist hier schlicht das Konto falsch konfiguriert.
Wie viele IMAP Verbindungen reißt Du den auf?
Falls das eine Meldung vom Server ist, dann geht es wohl allein darum, wie viele Geräte/Programme auf diesen Posteingang zugreifen, und wie viele Freenet erlaubt.
Ein einfacher Test wäre der, alle anderen Geräte/Clients auszuschalten.
Können andere Programme den Kalender importieren?
Das musst du bei Yahoo erfragen. In der Regel haben die Provider mehrere Filter aktiv, darunter auch Bayes'sche Filter, wie das des Thunderbird. Du kannst den Spamschutz dort sicher komplett deaktivieren. Ob das sinnvoll ist, sei dahingestellt.
Ich habe eine der großen Quarantäne-Dateien einmal in das betreffende Verzeichnis zurückkopiert
Ich würde doch annehmen, dass wenn der Defender diese Datei wiederhergestellt hat, dass sie dann auch entschlüsselt ist. Hast du eine dieser Dateien mal mit einem Editor wie Notepad++ geöffnet? Sind sie lesbar? Wenn ja, dann lassen sich daraus auch die E-Mails wieder zurückholen.
So ein Kalender ist etwas recht Komplexes. Viele unterschätzen das sehr.
Den genauen Grund für die unterschiedlichen "Fehler" in Zusammenhang mit den Erinnerungen habe ich nicht herausfinden können. Inzwischen suche ich auch nicht mehr.
Dieser hier trat über die Jahre sporadisch immer wieder auf, sobald man mehrere Clients benutzt. Bei uns sind das schon einige, auf verschiedenen Betriebssystemen. Wir haben es auf eigenen Servern gesehen (Radicale, später dann Nextcloud) wie auch bei Providern wie Posteo. Ein fixes Schema, das man als Testcase nutzen könnte, ist uns nicht aufgefallen. Die Offline-Unterstützung mit dem Cache spielt irgendwie rein, viel mehr war bisher nicht zu erkennen. Die einzige Konstante: Es war stets nur der Thunderbird. Alle anderen Kalenderprogramme zeigen diese "Fehler" nicht.
Bei dem ähnlichen Fehler mit der Meldung, dass sich der Termin angeblich auf dem Server geändert hätte, verstehe ich schon die Meldung im Zusammenhang mit dem Alarm nicht. Welcher Sinn steckt dahinter? Das ist auch so ein Phänomen, das wir nur mit dem Thunderbird und der Offline-Unterstützung beobachten konnten. Aber, das ist ein anderes Thema und gehört nicht unbedingt auch noch rein.
D.h. die Bestätigung eines Termins wird als eine Änderung des Termins betrachtet.
Ja, das war auch meine Theorie. Es gibt diese Änderung im Timestamp. Siehe #10.
Wir müssen aufpassen, dass die Themen nicht vermischt werden. Es gibt da leider einige in Zusammenhang mit der Erinnerungsfunktion.
Wenn die Erinnerung bei Beiden aufpoppt, dann ist es egal bei welchem ich die Erinnerung bestätige oder verschiebe.
Nach der eingestellten Synczeit von 1 Min, verschwindet die Erinnerung von selbst auf dem jeweils anderen PC.
Das ist nicht verwunderlich, denn der Thunderbird hat dazu ja sein eigenes X-MOZ-Flag. Das synchronisiert er. Siehe dazu den in #10 verlinkten Beitrag. Dort am besten zu diesem Aspekt auch weiter schreiben. Hier geht es ja um die Endlosschleife.
Kleine Randnotiz für meinen speziellen Freund schlingo. Wenn du auch inhaltlich etwas beitragen kannst, dann mach das bitte in jenem Thema, vielleicht indem du die dort aufgeworfene Frage zum Teamkalender beantwortest.
Lieber Oldi,
ich weiß ja, dass du gerade beim Kalender mit Herzblut und Engagement dabei bist. Bei allem Verständnis dafür, hier stimmt etwas nicht im Kalender des Thunderbird.
Sicher gibt es eine Reihe verschiedener Faktoren, die zu diesem Fehler beitragen. Der Kalenderserver zum Beispiel oder die Anzahl und Typen der verschiedenen Programme, mit denen man auf die Termine zugreift. Das mag erklären, weshalb einige das Problem öfter haben als andere, warum es oftmals eine Weile gut geht, dann aber plötzlich doch wieder auftritt. Es gibt auch verschiedene Fehlerbilder, die manchmal vermischt werden.
Unstrittig ist doch aber, dass es allein hier im Forum bestimmt 100 solcher Meldungen gibt. Unstrittig sollte auch sein, dass andere Programme dieses Problem nicht haben. Das kann man doch nicht ignorieren.
Bugs gibt es dazu ebenfalls bereits zuhauf. Ich werde dazu ganz sicher keinen weiteren eröffnen. Es gab auch schon vermeintliche Fixes. Auch das zeigt doch, dass irgendwas im Thunderbird nicht stimmt. Zumindest haben die Entwickler jeweils einen Bug gesehen und versucht zu beheben.
Zum Beispiel ganz neu diesen, in Zusammenhang mit OAUTH: https://bugzilla.mozilla.org/show_bug.cgi?id=1763936. Der verweist auf https://bugzilla.mozilla.org/show_bug.cgi?id=1727123#c19 und einen wohl teilweisen Fix in der Version 100. Man darf gespannt sein.
Könntest du Genaueres zu diesem Gesetz mitteilen?
Daraus leite ich ab, dass [...] dass für die Terminbestätigung jeder (Thunderbird)Client seine eigene, nur lokal gültige Buchführung hat,
[...]
Das bedeutet aber, dass die Endlos-Erinnerungsschleife rein gar nichts mit dem Server zu tun hat, sondern ganz lokales ein individuelles Problem ist.
Ja, das ist so. Die Erklärung hast du selbst geliefert. Andernfalls müsste der Server speichern, welcher Teilnehmer, wann und mit welchem Client eine Erinnerung bestätigt hat. Und ja, das Problem tritt nur mit online Kalendern und nur mit dem Thunderbird auf. Ich habe eine ganze Reihe anderer Kalender getestet, Outlook, Evolution, Windows, Linux, Clients auf iOS und Android, ... . Keiner von denen zeigt dieses Problem.
die Datei cache.sqlite umbenennen in alt-cache.sqlite
Das hatten wir oben schon. Das löst das Problem nur temporär. Solange die Offline-Unterstützung aktiv ist, kehrt das Problem irgendwann zurück.
