Thunderbird zerstört Anhänge beim Speichern aus größerer Mail

    Hallo!

    In Thunderbird 91.7.0 (64 bit) kommt es bei bestimmen Mails zu defekten Anhängen nach dem Abspeichern. Soweit ich es bisher nachvollziehen konnte, erst ab bestimmen größen.

    Folgende Anhänge:

    (geschwärzt wg. Datenschutz)

    nach dem Abspeichern (egal ob einzelen oder alle auf einmal) siehts im Explorer so aus:


    Die defekten PDFs enthalten ein paar Bytes Binärdaten, die bei allen Dateien identisch sind.

    Code
    '¬z³Zrâr^ž)áj[pŠ·Z¹ð'~¶ zJ&¦W­¶«º{^®¥iק


    Die Mail selbst ist OK, auch die Base64-Codierten Anhänge sind in den Quelldaten ersichtlich und können manuell über Base64-To-File Konverter extrahiert werden. Auch mit anderen Mailclients funktioniert das Abspeichern der Anhänge problemlos.

    Die Mail liegt auf einem Cyrus-IMAP-Server.


    Wird die größte Datei weggelassen, funktioniert es problemlos.

    Den Sendeweg kann ich auch ausschließen: Wenn eine neue Mail mit genau diesen Anhängen erstellt wird, tritt bereits im Gesendet-Ordner der Fehler auf.

    LG

  • graba 31. März 2022 um 10:57

    Hat das Thema freigeschaltet.

    Ich habe selbes Problem, sowohl auf einem Haufen PCs (>50) bei mir auf Arbeit als auch privat. Anhänge in der Grösse mehrerer MB lassen sich nicht speichern, es kommen nur immer 1kb grosse Dateien raus. Der dahinter hängende MDA ist ein Dovecot.

    Das Problem tritt nur auf, wenn der Kontentyp IMAP ist und die Nachrichten-Synchronisation deaktiviert ist. Aktiviert man das, läuft wieder alles. Leider ist das bei uns keine Option.

    Hi,

    hier das das gleiche Problem. Sogar der inhalt der "Krüppeldateien" ist identisch. Das ist schon ein dicker Otto und es wundert mich, daß sich kaum Leute dran stoßen. Ich nutze TB seit v0.5 und so einen Showstopper hatte ich noch nie.

    Dasselbe Problem hier. Es ist nicht auf PDFs beschränkt. Es ist eine ZIP-Datei 22MB groß.

    IMAP, disaktivierte Nachrichten-Synchronisation.

    Die gespeicherte Datei ist 45Byte lang, so wie oben:

    ghex zeigt als "Inhalt" an:

    0E 27 AC 7A B3 5A 72 1A E2 72 1B 5E 9E 29 E1 6A 5B 70 8A B7 5A B9 F0 27 7E B6 A0 7A 4A 26 A6 57 AD B6 17 AB BA 7B 5E AE 07 A5 69 D7 A7

    .'.z.Zr..r.^.).j[p..Z..'~..zJ&.W.....{^...i..

    thunderbird 91.9.1 (ubuntu)

    Man kann auf die Idee kommen, dass man nur für einen einzelnen Ordner, z.B. Inbox, die Synchronisation aktiviert. Dann kann man aus diesem Ordner das Attachment auch fehlerfrei speichern. Wenn man nachfolgend aber die E-Mail in einen anderen Ordner verschiebt, wird leider die gesamte E-Mail im Profil verschoben. Es liegt die fette E-Mail dann doch in einem Ordner, der eigentlich nicht synchronisiert werden soll.

    Mein Datensicherungsskript könnte die großen Dateien in den Profilen zwar löschen, aber das ist doch Pfusch. :|

    Ich habe diesen Thread eben erst entdeckt, vielleicht habt Ihr ja inzwischen (auch) schon eine hier nicht dokumentierte Lösung gefunden?

    Das Problem entstand mit Thunderbird 78 und liegt am zu geringen Cache für das direkte Speichern von Anhängen aus Mails >24,41MB (Standardwert 200000 Bit) direkt aus IMAP-Ordnern.

    Einen Lösungsansatz habe ich nach langem Probieren und Suchen letztendlich hier gefunden.

    Mit den Zeilen

    Code
    user_pref("browser.cache.memory.capacity", 40000000);
user_pref("browser.cache.memory.max_entry_size", 40000000);
user_pref("mail.imap.mime_parts_on_demand", false);

    in der prefs.js (oder händische Eingabe über "Konfiguration bearbeiten ..." ) ist das Problem verschwunden.

    Meine anfänglichen Bedenken zum dort empfohlenen hohen Bit-Wert von 40.000.000 (4,77GB) und daraus resultierenden Speicherproblemen haben sich nicht bestätigt.

    Ggf. ist es sinnvoll, den Wert an die maximal zugelassene, eingehende Mailgröße anzupassen, was bei uns für 100MB "819200" wären.

    Danke für den Tipp

    Zitat von Bud Cord

    Einen Lösungsansatz habe ich nach langem Probieren und Suchen letztendlich hier gefunden.

    Mit den Zeilen

    Code
    user_pref("browser.cache.memory.capacity", 40000000);
user_pref("browser.cache.memory.max_entry_size", 40000000);
user_pref("mail.imap.mime_parts_on_demand", false);

    in der prefs.js (oder händische Eingabe über "Konfiguration bearbeiten ..." ) ist das Problem verschwunden.

    Meine anfänglichen Bedenken zum dort empfohlenen hohen Bit-Wert von 40.000.000 (4,77GB) und daraus resultierenden Speicherproblemen haben sich nicht bestätigt.

    Ggf. ist es sinnvoll, den Wert an die maximal zugelassene, eingehende Mailgröße anzupassen, was bei uns für 100MB "819200" wären.

    Jetzt funktioniert das Speichern größerer Anhänge bei mir. Meinen User werde ich das durch eine entsprechende user.js in ihrem Profil einstellen.

    Ich habe etwas mit den Zahlen rumprobiert. Laut browser.cache.memory.capacity ist die Einheit in kiB (1024Byte).

    Bei 35840 für browser.cache.memory.capacity ließ sich aus einer 35MB großen E-Mail das Attachment nicht speichern. Erst ab einem ca. 6fach höheren Wert. Gerne würde man etwas genauer wissen, was die Variable macht. Vermutlich ist die Größe des gesamten Cache... .

    browser.cache.memory.max_entry_size scheint die Größe für die einzelne E-Mail zu sein. Zumindest ließ sich damit das Attachment bei einem geringfügig größerem Wert als 35840 speichern, bei einem geringerem Wert nicht.

    Daher meine Empfehlung:

    browser.cache.memory.max_entry_size

    auf den Wert stellen, den auch der IMAP-Server als maximalen Wert trägt. 40960 (kiB) z.B. für 40MiB.

    Für

    browser.cache.memory.capacity

    habe ich 10x größer gewählt. 400000.

    Bei mir hat es gereicht diese beide Werte zu setzen.

  • Community-Bot 3. September 2024 um 20:50

    Hat das Thema geschlossen.