Beiträge von Dominik.S

Dein Add-on ist trotzdem genial und hilft mir im produktiven Einsatz riesig.

Natürlich ist es langfristig eleganter, wenn eine meiner Ansicht nach so elementare Funktion wie das Abtrennen auf einen nicht als Netzlaufwerk gemappten UNC-Pfad weiterhin bzw. wieder auch ohne Add-on funktioniert.

Ich erwäge, wieder auf den ESR Channel zu wechseln. Es wird ja gemunkelt, dass Version 140 die nächste ESR werden könnte. Deshalb habe ich jetzt mal Auto-Updates abgeschaltet, um auf 138.0 zu verharren und nicht im Release-Channel die ESR zu überholen. Wenn dann eine Version höher als 138.0 die neue ESR werden sollte, müsste es ja ohne Datenverlust mit dem Herunterladen und Drüberinstallieren des entsprechenden ESR-Installations-Packages klappen.

Es gibt Neuigkeiten in Sachen Bearbeitung des Bug-Reports:

Der Betreuer, der sich der Sache angenommen hat, hat folgenden Link gepostet, in dem es darum geht, mittels einer Einstellung zugelassene Hostnamen für abgetrennte Attachments zu definieren:

⚙ D247897 Bug 1964145 - Allow access to attachments at specific UNC hosts. r=#thunderbird-reviewers

Die zugelassenen Hostnamen sollen wohl in der Einstellung "mail.allowed_attachment_hostnames" (mail/app/profile/all-thunderbird.js) hinterlegt werden.

Gemäß mail/modules/AttachmentInfo.sys.mjs soll, so lese ich das als Laie, abgefragt werden, ob in "mail.allowed_attachment_hostnames" eine entsprechende Ausnahme hinterlegt ist. Davon abhängig soll der Zugriff entweder erlaubt werden, oder es wird ausgegeben, dass der Zugriff aufgrund des Umstands, dass es sich um einen UNC-Pfad handelt, blockiert worden ist, jedoch die Möglichkeit besteht, die Blockierung durch Hinzufügen einer Ausnahme in der entsprechenden Einstellung aufzuheben.

Heißt das, dass daran gearbeitet wird, und eine entsprechende Einstellung irgendwann mittels about:config allgemein verfügbar sein wird, oder kann / muss ich jetzt schon irgendetwas unternehmen?

Sorry für mein Unwissen, ich stecke da leider nicht so tief drin.

Das ist ja unglaublich.

Alle Anhänge wieder aus TB heraus zu öffnen... ich bin sprachlos. Heiligsprechen kann ich Dich nicht, dafür "fehlen mir die Berechtigungen".

Aber ich bin mir sicher, tausend andere vom gleichen Problem geplagte Nutzer, die dank deiner Hilfe weiterarbeiten können, als wäre nie etwas gewesen, würden das jetzt ebenso wie ich gerne tun.

TAUSEND DANK .

Das wäre natürlich ein Riesending. Allein für den Versuch und das Bemühen schon einmal ganz lieben Dank.

Ja, leider ist das nicht trivial. Ich habe schon ein paar Artikel zu dem Thema nachträgliches Ändern der in der E-Mail selbst (also auf dem IMAP-Server) verlinkten Attachments überflogen, und möchte mir das aktuell nicht zumuten.

Wenn es wenigstens eine Lösung gäbe, es einzeln - Mail für Mail - zu machen, könnte man es wenigstens für die wichtigsten Mails, die im Büro immer wieder aufgerufen werden, händisch veranlassen.

Nicht anders als durch Löschen der ursprünglichen Mail mit Anhang vom IMAP-Server und anschließenden erneuten Upload ohne Anhang, dafür mit dem Link bzw. Verweis, funktionierts ja auch das ursprüngliche Abtrennen des Anhangs.

Es wäre wünschenswert, wenn noch daran gearbeitet würde, dass UNC-Pfade zumindest in Bezug auf abgetrennte Anhänge weiter bzw. wieder funktionieren würden. Ich habe mich absichtlich dazu entschieden, auf einen UNC-Pfad zu verlinken, und nicht auf ein mittels Laufwerksbuchstaben eingebundenes Netzlaufwerk.

Womöglich gibt es spätestens dann größeren Protest, wenn eines der um UNC-Pfade beschnittenen Releases zum esr-Release erklärt wird, und damit verstärkt Einzug ins geschäftliche bzw. "produktive" Umfeld hält. Ich kann mir vorstellen, dass ich dort nicht der Einzige bin, der auf UNC-Pfade gesetzt hat.

Scheint kein Bug zu sein, sondern ein Feature. Auf Bugzilla habe ich folgende Antwort bekommen:

„Looks like an UNC file:// path. Due to security/privacy concerns there we had to apply some restrictions, so UNC paths are no longer directly allowed. Use a mapped drive instead.“

Ja, es ist ein UNC-Pfad, und ja, in Zukunft kann ich für neu abgetrennte Anhänge einen Pfad auf einem verbundenen Netzlaufwerk verwenden.

Wie kann ich indes die bereits abgetrennten und auf den UNC-Pfad verlinkten Anhänge neu verlinken? Es mag nachvollziehbar erscheinen, dass ein Feature irgendwann einmal entfernt wird.

Aber wenn die abgetrennten Anhänge tausender alter E-Mails jetzt einfach weg sein sollen (bzw. das E-Mail-Programm nicht mehr auf diese zugreifen kann; da sind sie ja noch), und sich daran nichts ändern lässt, wäre das schon sehr selbstbewusst von den Entwicklern.

Der Umstieg vom esr- auf den release-channel war vermutlich eine dumme Idee.

Ich habe einen Bugreport erstellt (Bug 1964145; Titel "TB cannot find detached attachments").

TB 137.0.2 & Win 11 24H2

Umstieg von der ESR-Version (128. ...) auf den "normalen" Release-Kanal (137. ...). Seitdem findet TB abgetrennte und verlinkte Anhänge nicht mehr:

Sowohl Anhänge, die vor Jahren mit früheren Versionen abgetrennt worden sind, als auch Anhänge, die gerade eben mit der aktuellen TB-Version abgetrennt worden sind, werden nicht mehr gefunden.

Es handelt sich um einen Netzwerkpfad (SMB-Freigabe in Windows Netzwerk ohne Domäne). Hat jahrelang so funktioniert.

Der Pfad ist selbstverständlich verfügbar. Das Abtrennen dorthin wird ohne Fehlermeldung vollzogen. Die abgetrennten Anhänge liegen danach auch dort. Rechtsklick "Link-Adresse kopieren" und Einfügen derselben in den Windows Explorer funktioniert ebenfalls.

Das Problem ist identisch auf jedem Rechner, der vom 129er ESR- auf das current 137er Release upgedated worden ist. Keines dieser 137er Thunderbird-Releases findet mehr irgendeinen abgetrennten Anhang.

Naja, dann störe ich mich einfach nicht weiter dran.

Ich dachte nur, dass das Phänomen vielleicht bekannt wäre, und ich vielleicht irgendetwas übersehen habe.

Das Original-HTML der betroffenen E-Mails wird von den verschiedenen Thunderbird-Installationen auf den verschiedenen Rechnern jedenfalls nicht nur in Bezug auf die Bildschirmdarstellung unterschiedlich interpretiert, sondern ebenso in Bezug auf den Druck.

Demnach wird die Mail, wenn ich sie von einem der Rechner aus, bei welchen der Text fett dargestellt wird, drucke oder in PDF konvertiere, ebenso fett gedruckt, bzw. es wird eine PDF mit fetter Schrift erstellt.

Wenn ich von einem der anderen beiden Rechner aus, bei welchen die Darstellung normal (nicht fett) ist, drucke oder in PDF konvertiere, ist auch das Ergebnis (Ausdruck oder PDF) nicht fett, sondern normal (wie es sein sollte).

TB 128.9.0esr mit Windows 11 24H2

Seit Jahren zeigen vier vergleichbare Thunderbird-Installationen mit identischen Einstellungen auf unterschiedlichen Rechnern folgende Merkwürdigkeit:

E-Mails einiger weniger Absender - aufgefallen ist mir dies seit Jahren im Zusammenhang mit E-Mails eines Helpdesk-Systems - werden seit Jahren, also bereits über zahlreiche Thunderbird-Generationen hinweg, und ich glaube, auch bereits zu Zeiten von Windows 10, in der Einstellung "Original HTML" auf zweien der vier Rechner "normal" dargestellt, also mit der Systemschrift in normaler Größe und nicht-fett, und auf zwei weiteren irgendwie "seltsam" (Schriftart sieht irgendwie anders aus und ist vor allem Fett).

Links die Darstellung, wie sie eigentlich sein sollte, rechts die irgendwie "seltsame" Darstellung:

Die Rechner sind relativ ähnlich, wenngleich von unterschiedlichen Herstellern: Unvermurkste Windows-Installationen (W11 24H2), die ansonsten keine Auffälligkeiten zeigen, gleiche Bildschirmauflösungen, gleiche (Standard-)Einstellung von grafischen Effekten etc. in Windows, absolut identische (Standard-)Einstellungen in Thunderbird im Bereich Sprache & Erscheinungsbild - Schriftarten und Farben. Keine Drittanbieter-Virenschutzsoftware. Selbstverständlich auf keinem der Rechner an der Windows-Standardschrifteinstellung (Segoe UI Variable) herumgepfuscht.

Ich bin mit meinem Latein am Ende. Falls jemand noch eine Idee hätte, wo ich noch nachschauen kann - es würde mich freuen.

Viele Grüße

Dominik

Liebe Experten,

nachdem es mir in den letzten Tagen nicht zuletzt auch dank des Studiums zahlreicher Beiträge und Diskussionen aus diesem Forum gelungen ist, TB so einzurichten, dass nunmehr so gut wie alles so funktioniert, wie ich es mir vorgestellt habe - bezüglich eines Punkts komme ich partout nicht weiter. Ich würde mich freuen, wenn jemand einen Tipp für mich hätte:

IMAP, Kalender- und Adressbuch-Sync meines Google-Kontos funktionieren perfekt, bezüglich der Tasks- bzw. Aufgaben-Sync stehe ich jedoch auf dem Schlauch: Weder wird mir beim Abonnieren bzw. Hinzufügen meines Google-Kalenders die Option angeboten, die Rubrik "Tasks", "My Tasks", "Aufgaben" oder wie auch immer diese heißen soll auszuwählen, sondern ich kann nur den Hauptkalender Google-Kontos auswählen sowie die Google-Systemkategorien "Family" (Familienkalender) und "Contacts" (Geburtstage etc. von Kontakten).

Dementsprechend ist Thunderbird (91.10.0 64-Bit für Windows) kein Zugriff auf die Aufgaben bzw. Tasks meines Google-Kontos möglich (Meldung: "Bitte einen Kalender auswählen, der Aufgaben unterstützt").

Was mache ich falsch? Nach dem, was ich bislang auch in diesem Forum zu dem Thema gelesen habe, ist es doch so, dass für die Einbindung eines Google-Kalenders (einschließlich Tasks bzw. Aufgaben) kein Plugin / keine Erweiterung mehr benötigt wird. Testweise habe ich es dennoch auch einmal mit TBSync ausprobiert. Mit dem gleichen Ergebnis: Die Task-Liste wird auch beim Abonnement des Kalenders via TBSync nicht als auswählbare Checkbox angezeigt.

Was mache ich falsch?

Grüße

Dominik