Aus der Erinnerung heraus, weil wir unsere NC kürzlich in Rente geschickt haben, nachdem der Pi abgeraucht war: Du kannst das in der NC einstellen. Das hat nebenbei den Vorteil, dass die E-Mails auch dann gesendet werden, wenn der Thunderbird gerade nicht läuft.
Beiträge von Susi to visit
-
-
Durch diese "next"-Funktion kann ich aber z.B. mehrere Datensätze zum gleichen Empfänger senden, ohne dass diese in getrennten Mails verschickt werden.
Erkläre doch mal, was das genau für eine Funktion ist und vor allem, was genau du erreichen möchtest. Was meinst du genau mit Datensatz? Deine Beschreibung klingt als würdest du mit Datensatz nicht einen Datensatz für Mailmerge meinen (Name, Vorname, E-Mailadresse), sondern einen Datensatz aus einem anderen Programm, von denen du mehrere in eine E-Mail einfügen möchtest.
-
Sollte es ein selbst erstelltes Filter sein, poste das mal hier.
-
Und ist was passiert?
Bei denen, die voher schon OAuth/App-Passwort/2FA verwendet haben, vermutlich nichts.
2FA hat damit nix zu tun,
Genau
Das sind zwei Paar Schuhe, auch wenn sie häufig kombiniert werden. So auch bei Google. Nach eigener Aussage verlangen sie mindestens bei der Variante App-Passwort zusätzlich auch die 2FA. Siehe https://support.google.com/accounts/answer/185833
ZitatApp-Passwörter können nur für Konten verwendet werden, bei denen die Bestätigung in zwei Schritten aktiviert ist.
Meines Wissens gilt das auch für die Authentifizierung bei Autorisierung über OAuth. Gelöst über ein Cookie.
Ließe sich leicht testen: Neues Profil, Cookies verbieten, Google per OAuth2 einbinden. Das wird vermutlich nicht funktionieren.
... ohne das man seine telefonummer oder eine Emailadresse hinterlegen muss.
Wenn gar nichts hinterlegt ist, wie lösen sie dann das Problem "Passwort vergessen"? Über eine weitere Sicherheitsabfrage, z.B. "Wie hieß dein erstes Haustier?"
-
allerdings ist mir nicht klar geworden wie ich zum nächsten Datensatz springen kann.
Was meinst du damit? Mailmerge verwendet eine Tabelle m csv-Format, in der eine Zeile einem Datensatz enstspricht. Gesendet wird dann an alle.
-
Ein virtueller Ordner vielleicht?
-
Damit beendete ich sofort die Absicht der Ablage von Profilen über bestimmte Jahre und schleppe halt weiterhin alles in meinem einen Profil mit, auch was uralt ist, nach dem Motto "Man könnte ja mal . . . .".
Dann kannst du natürlich für alle Zeiten so weiter machen. Theoretisch gibt es keine Obergrenze für die Größe eines Profils. Performanter wird der Thunderbird dadurch aber nicht. Ich fürchte deshalb, irgendwann wird dich das wieder einholen.
Wir archivieren unsere Mails ein Mal pro Jahr auf die oben geschilderte Weise, also indem wir entweder ein komplettes Profil archivieren und das aktuelle bereinigen, oder indem wir einfach nur manche Ordner dem Archiv/Profil aus dem letzten Jahr hinzufügen. Da wir keine Jäger und Sammler sind, hält sich der Aufwand in Grenzen.
Ganz wichtige Dinge archivieren wir als PDF/A, signiert. Das kommt aber nur sehr selten vor. Die archivierten Profile sollte man hin und wieder mit einer neuen Version anfassen, damit sie ggf. migriert werden. Oder man archiviert jeweils eine portable Version des Thunderbird mit.Probleme hatten wir noch nie. Deshalb vermute ich, dass bei dir noch etwas anderes schiefgelaufen ist.
Andererseits speichere ich gelegentlich technische Konversationen als PDFs ab, bei denen tatsächlich der Dateinamen aus dem Betreff der E-Mail verwendet wird. Diese wiederum sind dann in einer Dokumentenverwaltung abgelegt, die teils viele Unterordner besitzt.
Diese PDFs würde ich grundsätzlich außerhalb des Profils speichern. Vielleicht steckt hier schon ein Problem. Je nachdem, ob die PDFs von der Dokumentenverwaltung in eine eigene Datenbank kopiert oder nur verlinkt werden, müsste sie auf das Profil zugreifen. Das ist nicht schön.
-
Was mich eher sorgt, ist, dass ich einige Termine nicht mehr ändern kann, der erwähnte 404 in der Fehler-Konsole.
Lassen die sich über das Web editieren? Exportiere doch mal den Kalender und schau, ob diese Termine im *.ics eine Besonderheit aufweisen.
-
Richtig. Deshalb würde ich auch die Finger von dieser Einstellung lassen. Normalerweise wird das Verschlüsselungsverfahren automatisch zwischen Server und Thunderbird ausgehandelt. Und da Thunderbird TLS 1.2 und 1.3 unterstützt, wird das funktionieren, sofern man nicht selbst etwas verstellt hat.
Komisch nur, das web.de einen hier in die Irre führen will mit deren Mail...
Sie führen dich nicht in die Irre. Sie schreiben ja, dass eines deiner Programme/Geräte derzeit noch über TLS 1.1 kommuniziert. Das ist eine Tatsache. Das kann völlig in Ordnung sein, weil sie es derzeit ja selbst noch unterstützen. Da wurde halt beim Handshake 1.1 ausgemacht. Ab dem Stichtag wird dann automatisch 1.2 oder 1.3 ausgehandelt. Es sein denn, eines deiner Programme/Apps kann das nicht. Dann wird die Verbindung mit diesem Programm scheitern. Deshalb weisen sie vorab darauf hin.
Den Thunderbird kannst du getrost in seiner Standardeinstellung belassen.
-
Ja!
. Das ist genau die Meldung, um die es geht. Jetzt haben wir mit dir einen weiteren "Augenzeugen".Es passiert relativ häufig, wenn man einen Termin in der Vergangenheit erstellt, ohne dass man auf Ablauf warten oder eine zweites Profil bemühen müsste.
Diese Variante hatte ich noch nie ausprobiert. Das würde das Testszenario natürlich nochmal vereinfachen. Ich habe es eben mit jeweils 5 Terminen bei GMX und Posteo versucht, ohne dass der Fehler auftrat. Das besagt aber nichts. Die Krux ist, dass der Fehler so sporadisch auftritt.
Womit ich sehr hadere, ist, dass ich den Sinn und die Motivation hinter der Meldung nicht verstehe. Wie Altstadt oben schon erwähnt hat, widerspricht sie sich gewissermaßen selbst.
Es hat gar keine inhaltliche Änderung des eigentlich Termins gegeben, weder auf dem Server noch beim Client. Die einzige Änderung, die ich im *.ics finden kann, ist lediglich die, dass der Termin über X-MOZ-LAST-ACK bereits bestätigt wurde und damit auch einen neuen Timestamp bekommen hat. In deinem Fall vielleicht nicht einmal das. Der Termin selbst hat sich jedenfalls nicht verändert.
Das wiederum führt mich zu der hier bereits früher erwähnten Überlegung, welchen Grund es wohl dafür geben könnte, überhaupt eine Bestätigung der Erinnerung auf dem Server zu speichern. Natürlich muss man sich irgendwo merken, dass man eine Erinnerung bestätigt hat. Sonst würde die wieder und wieder hochkommen.
Meine Meinung nach sollte das ausschließlich lokal erfolgen. Warum? Weil CaldDAV dafür gedacht ist, dass mehrere Benutzer auf demselben Kalender arbeiten. Wenn ich eine Erinnerung bestätige, heißt das ja nicht, dass mein Kollege keine mehr bekommen soll. Im Gegenteil, jeder Benutzer soll eine bekommen und zwar genau ein Mal. Sinnvollerweise merkt sich also jeder Benutzer selbst, ob er einen Termin bereits bestätigt hat. Ansonsten müsste sich der Server das für jeden einzelnen Benutzer merken, genau genommen sogar für jedes einzelne Gerät. Das ist aber, soweit ich das sehen konnte, nicht der Fall. Ich habe in der zugehörigen Datei auf dem Server stets nur diesen einen einzigen Eintrag für die Bestätigung gesehen. Und das ist auch noch ein X-MOZ-Eintrag, also einer, der speziell für Mozilla ist und von anderen Programmen nicht beachtet werden muss.
Andere Kalenderprogramme, z.B. der auf meinem Smartphone, hinterlassen erst gar keinen solchen Eintrag. Was dafür spricht, dass die sich das selbst (also lokal) merken. Warum also macht der Thunderbird das? Notwendig scheint es ja nicht zu sein. Eine Erklärung, die mir in den Sinn kommt: Thunderbird bietet als einziges mir bekanntes Programm die Option, die Off-Line-Unterstützung abzuschalten. In diesem Fall bleibt dann nur noch der Server als Speicherort. Daraus ergibt sich sofort die Frage, warum sollte jemand die Offline-Unterstützung abschalten? Welchen Nutzen hat das? (Außer, dass man damit diesen Bug umgehen kann.
)Wenn das mal jemand erklären könnte oder vielleicht auch hinterfragen, wäre schon viel gewonnen. Und sei es nur, dass man die Thematik dann besser verstehen würde.
-
Ist dir bei deiner Recherche kein Beitrag untergekommen, der die Sache mit den Zertifikaten erklärt? Im Grunde ist es ganz einfach: Wenn es wirklich so ist
Es ist für mich kein Drama, dass der Haken jetzt deaktiviert ist,
dann lass alles so, wie es ist. Wenn es dir wichtig ist, dass Avast deine E-Mails untersucht, noch bevor sie in den Thunderbird kommen, dann musst du dazu die entsprechenden Zertifikate von Avast in den Thunderbird importieren. Ohne diese Zertifikate kann Avast die TLS-verschlüsselte Verbindung nicht "belauschen".
-
Urlaub, was für Urlaub?
Naja, auf Reisen, fern jeglicher Entwicklung und dann noch eine Testadresse aus Spanien, das klang für mich sehr nach Urlaub. Hätte ich dir glatt gegönnt.
Wo? GMX? TB/BB?
Das kannst du im TB/BB einstellen. Um den Fehler mit der Meldung zu reproduzieren, ist das unbedingt notwendig, siehe #16. Wenn man die Offline-Unterstützung abschaltet, tritt der Fehler nicht auf. Ob das auch bei dem Fehler, dass sich ein Termin nicht mehr bearbeiten lässt, eine Rolle spielt, kann ich nicht sagen. Diesen Fehler habe ich noch nie gesehen.
Was hast Du als Endung bei GMX? Ich habe "gmx.net"
Ist allerdings GMX.es.
-
bin im Moment auf Reisen fern jeglicher Entwicklung.
Ist allerdings GMX.es.
Ich würde sagen, genieße erst mal den Urlaub. Die Welt kann warten, bis du wieder in .de bist.
-
Anlegen ja, nachträgliches Bearbeiten führt zu dem erwähnten 404.
Ich habe das gerade ebenfalls probiert. Uhrzeit des Termins verändert und einen Kommentar hinzugefügt. Das klappt bei mir mit 91.9.1-bb32.
Bei mir taucht diese Meldung nur auf wenn ich wieder einmal zu schnell war und beim starten von Thunderbird zu für die Terminerinnerung bestätigt habe.
Diese Situation hatte ich auch schon. Die Erinnerung kommt hoch und verschwindet gleich darauf von allein. Auch das könnte eine Folge einer Race Condition sein. Der Teil, der die Erinnerung bringt, war schneller als der, der prüft, ob der Termin nicht bereits bestätigt wurde. Leider ist das nicht immer so. Manchmal bleibt die Erinnerung stehen bis man sie bestätigt. In der Folge tritt dann die besagte Meldung auf.
Ich habe eben versucht, sie zu provozieren. Ohne Erfolg. Ich bin aber sicher, irgendwann käme sie wieder, würden wir den TB/BB wieder für den Kalender benutzen. Je mehr Termine und Clients, desto größer die Chance.
Die Kalender Funktion ist sehr überarbeitet worden,
Gibt es Indizien, dass damit auch dieser Fehler weg ist? Wenn das gelöst ist, würde ich vielleicht wieder zurück zum TB/BB-Kalender wechseln, um es in Linux und Windows einheitlich zu haben. Beim Rest der Familie besteht die Chance eher nicht mehr. Da ist der Kalenderzug abgefahren.
-
Ich den Profilen habe ich immer die an die Ordnernamen fehlerhaft angefügten Zeichen entfernt, da sich diese über Umbennen nicht entfernen ließen.
Zu angefügten Zeichen gab es neulich schon mal was. Ich meine, das hing mit Sonderzeichen im Ordnernamen zusammen. Von Hand entfernen würde ich da jedenfalls nichts.
-
Für die direkt bei GMX erzeugten Termine, die heute alle abliefen, habe ich keine Erinnerung bekommen,
Termine direkt bei GMX im Browser zu erstellen, das hatte ich bisher nie gemacht. Hab's eben mal ausprobiert. Dabei ist mir aufgefallen, dass dort die Methode zur Benachrichtigung standardmäßig auf E-Mail steht. Ein solcher Termin erscheint in TB/BB dann auch ohne das Glockensymbol. Die E-Mail kommt, eine Benachrichtigung erfolgt nicht. Stellt man die Methode auf der Webseite auf Benachrichtigung um, klappt alles. Die Glocke wird angezeigt, die Benachrichtigung poppt auf.
[...] für den lokal erzeugten bekomme ich jetzt eine Erinnerung. Wenn ich auf dem panel "Schließen" klicken will, passiert absolut gar nichts,
Das Anlegen und Speichern von Terminen über TB/BB bei GMX klappt bei mir tadellos. Frage in die Runde: Mein Konto dort ist schon sehr alt. Muss man dort vielleicht inzwischen etwas freischalten, um *DAV benutzen zu können? Das sollte dann doch aber in der Anleitung stehen. Oder hatten die gestern vielleicht nur einen Schluckauf?
-
Zumindest scheint ja der Vorgang des Verschiebens ein normaler Betriebsvorgang bei Thunderbird zu sein, denn er wird im Profilmanager ohne besondere Hinweise ermöglicht.
Das war der Grund meiner Frage. Solange ganze Profile verschoben werden, sind mir überhaupt keine Probleme gekannt. Außer, dass man sich für's Backup natürlich merken sollte, wo das Profil liegt.
Besonders durch Vorgänge mit Antworten/Weiterleitungen hin und her werden teils extrem lange Dateinamen erzeugt (aus dem Betreff), die dann manuell angepasst werden müssen.
Das Problem scheint mir hausgemacht. Beim normalen Speichern, gleich ob mbox oder maildir, spielt der Betreff beim Dateinamen keine Rolle. Vermutlich speicherst du die E-Mails also "anders", z.B. als *.eml.
-
Kannst Du die Instruktionen noch einmal umschreiben für jemanden, der noch nie CalDAV benutzt hat.
Kein Problem. Die schlechte Nachricht aber gleich vorweg: Ich kenne keine Methode, die den Fehler sicher auf Knopfdruck reproduziert. Es werden vermutlich mehrere Versuche nötig sein. Irgendwann wird der Fehler sich aber zeigen. Fairerweise möchte ich erwähnen, dass ich den Fehler bei normaler Benutzung manchmal wochenlang nicht gesehen habe, bis er dann plötzlich doch wieder auftrat.
Das spricht für die Diagnose Race Condition, zu deren Wesen es gehört, dass der Ausgang des Rennens nicht immer vorhersagbar ist. Ein Biest ist er also schon, dieser Bug.
Ich habe die Versuche mit mehreren Rechnern gemacht. Das ist aber gewiss nicht nötig. Getrennte Profile sollten genügen.
Was braucht es?
Zunächst einen CalDAV-Kalender. Der Provider sollte egal sein. Der Fehler wurde rund um die Welt beobachtet. Ich selbst habe ihn in der eigenen NC, mit Kalendern bei Posteo und auch bei GMX gesehen. Ein kostenloser Kalender bei GMX genügt also. Eine Anleitung zur Einrichtung gibt es hier: https://hilfe.gmx.net/kalender/synch…hunderbird.html
Diesen Kalender nun in zwei Thunderbird-Profilen einrichten. Nennen wir sie Profil A und Profil B. Wichtig ist, dass die Häkchen für "Erinnerungen anzeigen" und "Offline-Unterstützung" gesetzt sind. Außerdem muss bei Kalender aktualisieren eine Zeit gewählt werden, weil er sonst nicht automatisch beim Start synchronisiert wird. Dort sollte also nicht "manuell" stehen.
In beiden Profilen den Kalender nun ein Mal benutzen, d.h. jeweils einen Termin anlegen. Dadurch bekommt der jeweilige Cache einen Inhalt. Damit wären die Vorbereitungen abgeschlossen.
Dann der Prozedur gemäß #13 folgen. Ich ergänze dort gleich noch einen Schritt 5.
Auch folgende Variante hat den Fehler schon provoziert, gefühlt aber nicht ganz so oft:
In Profil A Termine mit Erinnerung anlegen. Profil A beenden, Profil B starten, noch bevor der Alarm kommt. Auf Alarm warten und in Profil B bestätigen. Ein paar Minuten warten. Profil B beenden und Profil A starten.
-
Ja, das TB-Adressbuch unterstützt weniger Features als Cardbook. Dahinter steckt ein allgemeines Problem: Der vCard-Standard (4.0) wird vom Umfang her von den verschiedenen Apps nicht einheitlich umgesetzt. Auch andere Adressbücher, z.B. für das Smartphone, unterstützen nur bestimmte Features und Felder. Das heißt, eine Eigenschaft die du mit Programm A einträgst wird u.U. von Programm B gar nicht angezeigt. Programm C wiederum zeigt sie an, dafür fehlt etwas anderes.
Cardbook scheint mir ziemlich vollständig zu sein. -
Falls es jemand nachstellen möchte, ich habe den Fehler bei meinen Tests früher oder später mit folgender Prozedur reproduzieren können.
- Auf Rechner A ² mit dem Thunderbird mehrere kurzfristige Termine mit Erinnerung anlegen. Mehrere deshalb, weil der Fehler nicht immer auftritt.
- Nun den Thunderbird vorerst nicht mehr benutzen, an keinem Rechner. ¹
- Warten, bis die Termine verstrichen sind.
- An einem zweiten Rechner B den Thunderbird starten. Dort kommen dann gleich die Alarme für die verpassten Termine hoch. Die Chance ist gut, dass in einigen Fällen (nicht in allen) dann diese Meldung erscheint:
"Dieser Eintrag wurde kürzlich auf dem Server geändert. Das Übertragen der Änderungen wird die Änderungen, die auf dem Server gemacht wurden, überschreiben."
Button: Änderungen verwerfen und neu laden
Button: Änderungen trotzdem übertragen - Wenn sich die Meldung nach 4. nicht erscheint, zurück an Rechner A. Evtl. kommt sie dort beim nächsten Start des Thunderbird.
Man beachte den Wortlaut der Meldung. Sie besagt, der Termin sei auf dem Server verändert worden. Gleichzeitig spricht die Meldung von Änderungen im Thunderbird, die an den Server übertragen werden sollen. So, als ob man den Termin gerade eben zu editieren versuchte.
Diese Änderung hat es aber gar nicht gegeben. Der Termin ist inhaltlich völlig unverändert. Er wurde vom Benutzer nicht mehr angefasst. Die Meldung an sich ist also bereits irreführend.
Ich habe die Meldung gelegentlich auch für aktuelle Alarme gesehen, also für Erinnerungen, die nicht die Vergangenheit betrafen.
Auch unabhängig von der Erinnerungsfunktion trat der Fehler schon auf, einfach beim Hinzufügen zusätzlicher Wiederholungen zu einem Serientermin.
¹: Nicht benutzen meint hier, nicht mit dem Thunderbird auf den Kalender zugreifen bis die Termine verstrichen sind.
²: Statt zweier Rechner A und B können auch zwei Profile A und B verwendet werden.
