Ich darf im Namen von Peter_Lehmann den besten Dank dafür ausrichten
Das freut mich, da ich ihn nicht vergessen habe.
Ich darf im Namen von Peter_Lehmann den besten Dank dafür ausrichten
Das freut mich, da ich ihn nicht vergessen habe.
Theoretisch sollte das mit der Einstellung im untersten Abschnitt bei Konten-Einstellungen → Synchronisation & Speicherplatz funktionieren:
https://www.thunderbird-mail.de/lexicon/entry/…p-Speicherplatz
Edit: Sorry, da wir ja auch auf dem IMAP-Server gelöscht.
Das Thema ist hiermit geschlossen.
Der Inhalt ist seit heute wieder da.
Ich vermute, dies liegt daran, dass dieses Add-on bei Dir genutzt wurde und nun als Update für den 78er zur Verfügung steht: Provider for Google Calendar
Ist die SMTP-Angabe "Verschlüsseltes Passwort" anstatt "Passwort normal" denn nicht sicherer?
Ich würde sagen: Ein klares Jein.
Das "Passwort, normal" wird bei STARTTLS bzw. bei SSL/TLS ja innerhalb der verschlüsselten Verbindung mit übertragen. Es braucht also theoretisch nicht zusätzlich verschlüsselt werden. Zum Problem könnte dies werden, wenn der Server die verschlüsselte Verbindung verweigert und der E-Mail-Client dann auf eine unverschlüsselte Verbindung "zurück fällt". Dann würde das unverschlüsselte Passwort "lesbar" übertragen. Meines Wissens passiert dies in Thunderbird aber seit längerer Zeit nicht mehr. Er gibt statt dessen dann den Verbindungsversuch auf und meldet einen Fehler.
Letztlich kann man nicht beliebig die Kombinationen wählen, weil dies nicht jede Kombination von jedem Server akzeptiert bzw. unterstützt wird. Es würde zu Fehlern führen.
Wenn Du bspw. einen Dovecot-IMAP-Server mit LetsEncrypt-Zertifikat betreibst, dann könnte (je nach Konfiguration) tatsächlich die Kombination von STARLTLS und "Verschlüsseltes Passwort" funktionieren - jedenfalls geht dies bei mir. Für den SMTP-Server geht bei mir mit dem Postfix-SMTP die Kombination von "SSL/TLS" mit "Verschlüsseltes Passwort". Das würde ja Deinem gewünschten "Optimum" entsprechen.
Da im 78.2.1 weiterhin die Übersetzung fehlt, habe ich den Thementitel nochmals auf 78.2.2 "verschoben". Ich hoffe, dass Sebastian die Übersetzung bis dahin tatsächlich komplett drin hat. Momentan scheitert die Übersetzung noch an technischen Dingen, sodass ich den Übersetzungsstand von Sebastian nicht vor Augen habe.
Wird es automatische Updates von 68 auf 78 geben - ja oder nein?
Ja, sobald man seitens der Entwickler mit der Qualität und Integration von Enigmail OpenPGP zufrieden ist.
Falls nein: Kann ich dann nur über diesen Link > https://www.thunderbird-mail.de/herunterladen/ < updaten?
Ja, man kann die neuen Versionen einfach drüber bügeln. Danach sollte man aber nicht mehr zurück gehen, da inzwischen wirklich viele Dinge (Adressbücher, Zertifikate etc.) aus der neuen Version nicht mehr in der alten Version ankommen. Das gibt beim Hin und Her dann Kuddelmuddel
Da die Übersetzungen wieder nicht korrekt in 78.2.1 drin sind, wird es dafür auch wieder keine automatischen Updates von der alten ESR-Reihe geben.
Ich könnte heulen und mich fremdschämen, da in 78.2.1 weiterhin das Problem mit der Übersetzung besteht und somit eine ganze Reihe (unnötig viele) von Englischen Begriffen im Programm auftaucht, obwohl es eine Übersetzung dafür gibt. Es ist eine Mischung aus technischem Versagen der neuen "Mechanik" und Sebastian kommt scheinbar nicht hinterher, um die rund 500 OpenPGP-Strings zu übersetzen.
Du musst mir bitte noch mal sagen: Was ist "besser", wenn AHT 6.0 installiert ist? Und was ist "defekt", wenn AHT 6.0 installiert ist?
Mein Eindruck ist, dass sich verschiedene Add-ons gegenseitig stören, ohne, dass es einen konkreten schuldigen gibt. Ich könnte mir vorstellen, dass in Thunderbird 78 mit den aufgepimpten Add-ons per WindowListener-API neuer Ärger entsteht.
Ich wollte nur zeigen, daß Thunders neues AllowHtml etwas triggert in punkto Symbolleisten-Icons.
Sonst nichts!
Das glaube ich schlichtweg nicht.
nach der Installation von AllowHTML 6.0 ist auf einmal das Icon für Ublock Origin in der oberste Leiste rechts neben dem "Zum Aufgaben-Tab wechseln" vorhanden!
Und zwar dauerhaft!
Das war bisher nie der Fall bei den vorhergehenden 68er-Thunderbirds und den 5er-AllowHTML-Addons!
Du vergleichst Äpfel mit Birnen oder sogar mit einem Steak.
Thunderbird 68 ist eben nicht Thunderbird 78. Und AHT 6.0 gibt es ja auch nur für Thunderbird 78. Bei dem Wechsel von 68 zu 78 muss sich ja auch deutlich der Code in uBlock geändert haben. Bitte bleibt bei Vergleichen oder Problemen innerhalb einer Versionsreihe des Thunderbird - am besten innerhalb von der 78er-Reihe zur Zeit. Sonst platzt mir der Schädel.
Ich fürchte das wird ein Fall für jobisoft , denn der Fehler wird von einem ganz simplen per Inject eingefügten Codeblock erzeugt:
<!-- Thunderbird & SeaMonkey -->
<toolbarpalette id="MailToolbarPalette">
<toolbarbutton id="QuickFolders-toolbar-button"
class="toolbarbutton-1 chromeclass-toolbar-additional"
label="&qf.toolbar.quickfolders.toolbar;"
tooltiptext="&qf.toolbar.quickfolders.toolbar;"
oncommand="QuickFolders.Interface.toggleToolbar(this);"
checked="true"
/>
<toolbarbutton id="QuickFolders-createfolder"
class="toolbarbutton-1 chromeclass-toolbar-additional"
label="&quickfolders.toolbar.newsubfolder;"
tooltiptext="&quickfolders.toolbar.newsubfolder;"
oncommand="QuickFolders.Interface.onCreateInstantFolder();"
/>
<toolbarbutton id="QuickFolders-skipfolder"
class="toolbarbutton-1 chromeclass-toolbar-additional"
label="&quickfolders.toolbar.skip;"
tooltiptext="&qf.tooltip.skipUnreadFolder;"
oncommand="QuickFolders.Interface.onSkipFolder(null);"
/>
</toolbarpalette>
Alles anzeigen
Es langt sogar schon für das Problem, wenn ich den Code in QuickFolders so kürze, dass dort nur noch das steht:
Sobald ich diese beiden Zeilen auch noch aus dem Inject von QuickFolders Code entferne, taucht mein Buttonn im Anpassen-Dialog wieder auf (man muss allerdings mein Add-on einmal (nach Re-Installation von dem "gekürzten" QuickFolders-Addon) deaktivieren und wieder aktivieren, wenn man die ganzen Versuche macht.
Übrigens kann ich die 3 Buttons aus dem Code von QuickFolders auch überhaupt nicht finden (natürlich bei noch vorhandenem Code dieser Buttons)
Könnte es sein, dass es Probleme gibt, wenn mehrere Add-ons mit dem Listener den Code injizieren?
Wenn man aus dem Issue dort heraus geht, kann man sehen, dass vor 2-3 Tagen eine Reihe von Schritten im Source gemacht wurden, um es mit WindowListener-API umzusetzen.
Also ist er (nach Deaktivieren von QuickFolders) im Auswahl-Dialog erschienen, wo er scheinbar zuvor "verloren" war. Dies habe ich jetzt reproduzieren können. Dafür war es notwendig, dass AHT deinstalliert war und erst installiert wurde, wenn QuickFolders schon vorhanden war.
Zum Vergleich könnte ich ein Add-on brauche, welches ebenfalls einen Toolbar-Button hinzufügt, ohne dies über die WebExtension-Methode zu machen. Es müsste weiterhin per Overlay mit Hilfe der WindowListener-API erfolgen - so wie bei mir. Solch ein Add-on finde ich momentan überhaupt nicht.