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

    Approved the thread.
  • 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. :|

  • Abends.


    Hä?

    Du hast eine Frage?

    Welche?


    Ggf. ist es zielführender, Dein Anliegen nocheinmal neu zu formulieren.

    Und dann in einem eigenen Thread zu veröffentlichen.

    SCNR ...

    8)

    Gruß

    P.

  • 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.