bis ein Anwender sich vielleicht entscheidet, doch lieber zurück zu wechseln
In gewissem Sinne ist das Wort "zurück" womöglich falsch bzw. führt zu falschen Erwartungen. Man wechselt bei jedem Wechsel zwischen Maildir und Mbox immer "vorwärts" zum anderen Format. Deshalb trifft ja auch folgendes zu:
Dann ist abermals ein Konvertieren nötig.
Die jeweils zurückbleibenden "alten" Ordner sind zwar noch vorhanden, werden aber beim Hin und Her letztlich ignoriert.
1) Local Folders
2) Local Folders-Mbox
3) Local Folders-MailDir
Und hier müsste die Reihenfolge der Logik nach vermutlich so sein:
1. Local Folders
2. Local Folders-MailDir
3. Local Folders-Mbox
Ist es so, jenachdem, welchen Modus ich einstelle, dass der aktive Ordner dann auch jeweils wechselt?
Wenn ich nicht irre, ist es so, dass er nicht "wechselt", sondern jeweils immer wieder neu erstellt wird (mit fortlaufender Nummerierung).
Man kann theoretisch beliebig oft zwischen Mbox und Maildir hin und her konvertieren, wenn man dies über die Option in den Konten-Einstellungen umschaltet. Empfehlen würde ich dies aber zur Sicherheit dennoch nicht.
Erst als ich in den TB Einstellungen: Datenschutz --> Emailinhalte das Kreuz gemacht für:
"externe Inhalte in Nachrichten erlauben" da war es auch Ok, wenn ich es mit TB empfangen ahbe.
Also somit ist das Problem (hoffentlich) gelöst, ich hoffe dass es so bleibt, wenn ich wieder solche Formulare bekomme.
Der Zusammenhang scheint mir aber nicht plausibel zu sein - zumindest nicht, wenn die Attachments auf der Festplatte gespeichert und dann mit Acrobat aufgemacht werden. Ich würde mir Probleme vielleicht noch gefallen lassen, wenn die PDFs direkt innerhalb von Thunderbird betrachtet werden.
Womit wurde in den verschiedenen Szenarios jeweils das PDF angezeigt?
Um es komplett zu machen, muss noch folgende Pref der Textfarbe ebenfalls entfernt werden, um den Standard wieder komplett zu haben:
user_pref("browser.display.foreground_color", "#000000");
Ich habe nun aber doch in der prefs.js die entscheidende Zeile für den Hintergrund gefunden, die von der hier diskutierten Hintergrund-Farbeinstellung gesetzt wird:
user_pref("browser.display.background_color", "#000000");
Diese Zeile löscht man einfach komplett, dann wird wieder der Standardwert verwendet.
Die oben genannte Option "Immer" führt zu folgendem Eintrag in der prefs.js, welchen man ebenfalls wieder löschen kann/sollte: user_pref("browser.display.document_color_use", 2); Solange dieser Wert nicht wieder auf Standard steht, werden beispielsweise die Buttons in den Content-Seiten/-Tabs nicht korrekt (kontrastierend) angezeigt.
nach "theme" suchen und in der im folgenden Screenshot markierten Zeile bezüglich des aktiven Themas darauf achten, dass "light" aktiv ist :
Das nutzt nichts. Dies ist bei mir im Testprofil aktiv und dennoch wird das von mir definierte schwarz auf schwarz verwendet, was zu unbenutzbaren Content-Bereichen führt, wozu eben auch die Konten-Einstellungen, Einstellungen, Tab mit Infos zur Problembehebung, Add-on-Manager und Konfig-Editor gehören.
werden bestimmt in der prefs.js gespeichert
Ich kann in der prefs.js meines zerschossenen Test-Profils dazu leider keine Zeile finden. In dieser Hinsicht kann sich rächen, dass in Zukunft immer mehr in den SQLite-Dateien gespeichert wird, die man nicht mehr im Klartext einfach lesen und bearbeiten kann.
Ich habe mal einen Bug daraus gemacht, da man ja eigentlich keine Chance hat, um das Problem wieder zu beheben. Der Abgesicherte Modus hilft auch nicht.
Bei meinem Test liegt der "Knackpunkt" bei der Option "Immer". Dann wird auch der Einstellungen-Tab entsprechend eingefärbt. Das ist also die tolle neue HTML-Welt in den Dialogen 
Wenn Mails per IMAP nicht mehr fett angezeigt werden, dann wurden diese vermutlich bereits vorher in einem anderen Client (per Web-Oberfläche oder vom Smartphone, Tablet etc.) als gelesen markiert. In diesem Fall werden "neue" Mails von Thunderbird nur noch als "neu" gekennzeichnet, da sie innerhalb von Thunderbird eben noch neu sind.
Als moderativer Hinweis:
Könntest Du das nächste mal bitte auch den Inhalt des Foren-Themas bearbeiten und dort Dein Problem genauer beschreiben?! Ansonsten werde ich das nächste Thema direkt in den Müll entsorgen.
Zu Deinem Problem/Wunsch:
In welcher Form genau wurden die Bilder denn mit der Mail gesendet? Kannst Du dies beschreiben?
Das ist aber ungünstig mit Schwarz auf Schwarz... Da ist der Darkmode ein wenig zu perfekt geworden 
.
Wo bzw. wie genau hast Du die schwarzen Farben definiert? Wenn die Definitionen innerhalb von Thunderbird gemacht wurden, könnte man vermutlich mit dessen abgesicherten Modus das Problem umgehen, um die Einstellung wieder zu ändern. Allerdings wüsste ich gerade gar nicht, wo man dies innerhalb von Thunderbird gemacht haben könnte.
Aber nur, wenn bei den Adressbuch-Eigenschaften "read-only" deaktiviert ist.
Wie ich jetzt sehen konnte, ist es standardmäßig deaktiviert, wenn man ein neues CardDAV-Adressbuch angelegt hat, was ich für den experimentellen Status widersinnig finde.
Danke für Eure Infos + Hilfe.
Dass die Release Notes explizit von Google sprechen,
Dies liegt daran, dass man jetzt OAuth für CardDAV eingebaut hat. Yahoo soll dann demnächst evtl. auch unterstützt werden.
Kontakt auch nach manueller Synchronisation gar nicht übernommen wurde
Es wird bisher weiterhin nur lesend CardDAV unterstützt, wenn ich nicht irre.
In welcher Form kann man jetzt mit 78.7.1 genau CardDAV für Google Kontakte verwenden? Ich verstehe es bisher nämlich nicht und kann somit auch keine brauchbare Übersetzung der Versionshinweise erstellen.
Parallel schaue bitte mal per Rechter-Maustaste auf dem Ordner 'Posteingang' des betroffenen Kontos in die 'Eigenschaften' und da auf den Reiter 'Kontingent'.
Dort findet man kein SMTP-Kontingent, sondern nur die IMAP-Kontingente. Das heißt, dass man dort überhaupt keine Angabe zu einem Sende-Limit finden kann. Dies kann man nur mit dem Admin des Firmen-Mailservers abklären, wenn der SMTP denn von der Firma betrieben wird.
