Verwendest Du klassisch Mbox als Speicherformat für die Konten in Thunderbird auf Deinem PC? Oder verwendest Du Maildir als Speicherformat (wenn JA, dann hast Du dies bewusst ausgewählt und müsstest es wissen)?
Beiträge von Thunder
-
-
ich würde dann einfach das Bereithalten deaktivieren, evtl. den Cache löschen und das Bereithalten wieder aktivieren. Was spricht dagegen? Was verlöre ich dabei?
Dies ist ja im Prinzip genau das, was durch das Löschen der Mbox-Dateien "im Bulk" gemacht wird. Wenn Du dies aus Thunderbird selbst heraus machen wolltest, hast Du bei mehreren Konten und vielen Ordnern viel zu tun. Bei meinem kurzen Test gerade habe ich Thunderbird nicht dazu bewegen können die Dateien zu löschen. Wobei ich die Optionen in den Konten-Einstellungen → Synchronisation & Speicherplatz noch nicht alle ausgenutzt hatte. Vermutlich hätte ich dort zumindest noch einstellen müssen, dass alles älter als 1 Tag (oder ähnlich) gelöscht werden soll.
Die "unwichtigen Dinge" könnten beispielsweise
... Die Einstellung, ob extene Inhalte zur jeweiligen E-Mail geladen werden geht wohl auch verloren. Man muss dann halt beim Anzeigen der Mails wieder anklicken, dass man die externen Inhalte sehen will.
-
Verstehe ich es richtig, dass man Google Kontakte über die Option "LDAP-Adressbuch hinzufügen" synchronisiert?
Nein, es wird automatisch CardDAV für Kontakte und CalDAV für die Kalender verwendet. Wie gesagt wird beim Adressbuch aber pauschal nur das Google-Adressbuch mit allen Adressen ohne die differenzierten Kontakte-Gruppen verbunden:
-
Was nutzt ein Backup, wenn man beim Arbeiten im Fall von IMAP korrupte Offline-Cache-Dateien in Form der Mbox-Dateien hat? Nichts, weil man den Cache nicht sinnvoll aus einem Backup wiederherstellen kann.
Insofern redet ihr aneinander vorbei.
-
Google Kontakte funktionieren in 102 nativ mit Thunderbird. Allerdings werden nicht alle Features unterstützt - Kontaktgruppen gehen meines Wissens nicht.
-
Zu 1)
Dies muss jeder für sich selbst bewerten. Updates bringen immer auch Risiken mit sich und neue Probleme sind nicht immer sofort erkennbar. Für Thunderbird lasse ich Updates immer nur halbautomatisch installieren - installiert wird das Update dann erst, wenn ich es per Klick initiiere.
Zu 2)
Unter allen Betriebssystemen handelt es sich bei dem beschriebenen Vorgehen um den /ImapMail/-Ordner. Das Vorgehen macht nur dort Sinn, wo das klassische Mbox-Format verwendet wird. Falls Maildir verwendet wird, ist dies nicht notwendig bzw. sollte gar nicht ausgeführt werden, soweit ich dies technisch überblicke. Wie man unter macOS am einfachsten rekursiv in dem ImapMail-Ordner nach allen Dateien ohne Endung sucht, weiß ich nicht.
Zu 3)
Genau: Es klingt alles sehr vage. Es ist ja auch vage, weil es viele Eventualitäten und unterschiedlichste Szenarien gibt, die man gar nicht alle überblicken kann. Außerdem gibt es auch ganz andere Ursachen für zumindest scheinbar ähnliche Symptome. Die "unwichtigen Dinge" könnten beispielsweise nur lokal gespeicherte "Tags" sein. Ich bin da leider kein Experte, was alles (nur) in den MSF-Dateien gespeichert wird.
Auf Seiten der Thunderbird-Programmierer möchte man meines Wissens am liebsten gar keine pauschale Handlungsempfehlung geben, sondern auf die individuellen Fehlermeldungen bzw. Support-Anfragen der User auf SuMo warten. Aus deren Sicht sind die zugrunde liegenden Bugs repariert und damit ist erstmal gut. Ein Teil der Symptome verschwindet auch tatsächlich von alleine - dies gilt meines Erachtens aber nicht für potentiell bereits beschädigte Mbox-Dateien, wenn es diese gibt. Und da kommen wir wieder zu "vage". Diese können vereinzelt oder auch in großem Stil beschädigt sein - sie müssen es aber nicht sein.
-
Es ist halt ein "smarter" Workaround für das "Problem", dass an eine noreply-Adresse gesendet wird. Ich denke, dass Tanger eigentlich ein Feature bräuchte und sucht(?), womit die noreply-Adresse einfach aus den Empfängern heraus gelöscht werden könnte. Das wäre doch viel smarter als pur die Warnung zu deaktivieren. Sowas ließe sich bestimmt als Add-on programmieren. Das kann man ja durchaus auch mal als Auftragsarbeit von einem Entwickler machen lassen, wenn man sich das manuelle Löschen der noreply-Adresse sparen möchte.
-
eine API, die man sich bspw. mit Chrome teilt
Dies ist halt leider eine Einschränkung, die meiner Meinung nach bei Software abseits von Browsern teilweise zu Problemen führt. Die MailExtension-API in Thunderbird hat deshalb ja auch einige Erweiterungen gegenüber der reinen WebExtension-API. Software-übergreifend standardisiert ist die MailExtension-API aber halt noch lange nicht und wird es meiner Vermutung nach auch nie werden.
Theoretisch müsste sich jemand bei MZLA finden, der sich um eine Erweiterung der storage-API bemüht. Ich glaube aber weder an den Willen noch an die Akzeptanz seitens Google oder des Chromium-Projekts(?) für solch eine Erweiterung.
-
an diese Adresse nicht möglich ist
...oder nicht gewünscht ist
Die Absender der noreply@example.com Adressen haben die Möglichkeit einen Reply-To Header anzugeben, in dem eine passende erreichbare Adresse ist. Jedoch ist es häufig so, dass eine Rückmeldung auf die gesendeten Mails in dem Kontext überhaupt nicht erwünscht ist. Wer trotz noreply-Adresse eine Rückantwort "öffentlich" und regelmäßig akzeptiert, macht meiner Meinung nach etwas Konzeptionelles falsch. Ein Bouncing muss deshalb aber nicht unbedingt erfolgen, finde ich.
-
Dieses Add-on speicherte seine Optionen früher als prefs, jetzt aber als "reguläre" Add-on storage. D.h., einmal (aus Versehen) entfernt, alles Optionen weg (danke Mozilla
).Das ist ja keine Erfindung von Mozilla, sondern eine API, die man sich bspw. mit Chrome teilt, denke ich. Die Add-on-Entwickler könnten statt storage.local auch storage.sync verwenden. Dieses speichert nämlich (auch ohne den Sync-Service) die Einstellungen persistent - auch über eine Deinstallation des Add-ons hinaus, wenn ich nicht irre. Es gibt aber halt leider auch eine Menge Anwender, die bei der Deinstallation und anschließenden Neuinstallation von Software (egal ob Thunderbird selbst oder Add-ons) denken, dass alles wieder "neu" und "sauber" sein müsste. Diesem "Verlangen" hat man vermutlich mit storage.local bei dessen Umsetzung nachgegeben. Meiner Vorstellung nach müsste es eine offizielle Variante geben, die zwischen storage.local und storage.sync angesiedelt ist - letztlich sowas wie storage.local.persistent oder ähnlich.
-
Es ist zumindest nichts erkennbar, dass bereits an einer 91.12.1 oder ähnlichem gearbeitet würde. Es gibt im 91er Branch keine Änderungen seit dem 91.12.0 Release.
-
Und was ist oberhalb von "Profiles" so alles?
-
Leute, was soll die Diskussion um die Anzahl der Zeilen oder um die KByte des Codes? Wenn ich im CSS alle möglichen Regeln drin habe, dann erwarte ich zumindest von jemandem wie Boersenfeger, dass er genauer Beschreibt was nicht funktioniert und um welche CSS Rule es sich dabei handelt, die nicht funktioniert. Es kann natürlich theoretisch auch sein, dass alle Rules aus dem gezeigten CSS nicht mehr funktionieren. Aber auch dies könnte man vielleicht etwas differenzierter als Problem beschreiben.
-
Letztlich entscheidend bei der Diskussion hier und im parallelen Thema ist, dass Boersenfeger wohl dafür kritisiert wird, dass er zu viel CSS-Code zur Diskussion stellt, bei dem man gar nicht überblicken kann was nun funktioniert und was nicht. Es wäre also nett, wenn man jeweils "nur" den relevanten Teil des CSS zur Diskussion stellt.
-
Vielleicht ist dies dieser Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1777913
-
Am einfachsten wäre es, den ImapMail-Ordner komplett zu löschen.
Dies könnte demnächst (wieder) funktionieren. Ab dem heutigen Daily-Build wird der komplette ImapMail-Ordner von Thunderbird wieder neu erstellt, wenn man diesen gelöscht oder verloren hatte. Dass dies zuvor nicht funktioniert hat, war eine Regression durch einen anderen Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1777937
-
Bei Deinem ursprünglichen (ersten) Beitrag habe ich die toten Links heraus gelöscht. Für die Bilder in Deinem weiteren Beitrag bis Du alleine verantwortlich. Falls Du zuvor die Bilder noch im ersten Beitrag sehen konntest, dann lag dies an dem von mir genannten Cache, auf den nur Du zugriff hattest und somit die Bilder dort noch sehen konntest. Das ist ein (eigentlich behobenes) Problem der Foren-Software, wenn man einen Reload beim Erstellen des Beitrags macht, bevor dieser wirklich final abgesendet wurde. Die Bild-Dateien (Dateianhänge) werden dann nämlich in Wahrheit gar nicht an den Server übertragen, sondern sind nur in einem Cache auf Deinem PC / Mac vorhanden.
-
Ich würde wetten, dass Du eine userChrome.css verwendest, in der es Anpassungen gibt, oder?
-
Kleine technische Rückfrage: Hast Du beim Erstellen des Foren-Themas bzw. Beitrags einen "Reload" im Browser gemacht, nachdem Du den Dateianhang (das Bild) hochgeladen hast, aber noch bevor Du den Beitrag final abgesendet hast? Das hat nämlich vermutlich zum Verlust des Dateianhangs geführt (den Du dennoch zunächst noch in Deinem Browser aus einem Cache heraus sehen konntest).
-
Der von mir genannte Ordner liegt in der Regel trotz ausgelagertem Profil genau dort, wo ich ihn gezeigt habe.
Hat denn irgendwer von den inzwischen 3 beteiligten Hilfesuchenden meinen Tipp ausprobiert, statt nur zu sagen, dass er/sie auch das Problem hat?!
%LocalAppData%\Thunderbird\
Danke Dir für den passenden Shortcut, den man per Windows-Suche bzw. "Ausführen"-Funktion unter Windows aufrufen kann. Das ist genau das Verzeichnis, welches man guten Gewissens einfach löschen kann, weil es (trotz eines Unterordners mit dem Namen "Profiles") eben nicht die relevanten persönlichen Profil-Daten enthält, sondern nur bestimmte quasi Cache-Daten.
