Beiträge von Lichtmacher

Hier das selbe:

Thunderbird 102.11.0 Linux.

Ursache, wie Veteran beschrieben hat.

Zitat von Veteran

Zusammengefaßt haben wir also bei der 'problematischen' Mail die Header:

[box]Content-Type: multipart/related;

Content-Type: text/plain

Content-Type: application/pdf

Content-Disposition: attachment; filename="*.pdf"[/box]

Bei der Mail ohne Problem:

[box]Content-Type: multipart/mixed

Content-Type: text/plain

Content-Type: application/pdf

Content-Disposition: attachment; filename="*.pdf"[/box]

Letztere werden übrigens auch von TB beim Anhängen einer PDF-Datei erzeugt.

Das Problem ist: 'multipart/related' vs. 'multipart/mixed' in Verbindung mit 'Content-Type: text/plain'!

Dazu gibt es einen 22 (!) Jahre alten Bugreport.[1]

Normalerweise enthält der erste Teil einer Nachricht (in HTML kodiert) bei 'multipart/related' eine Verknüpfung zum Anhang. Fehlt diese, wie in deinen Mails (als Text kodiert), wird der Anhang in TB nicht richtig erkannt. (s. RFC 2387)

Man kann das nachstellen, wenn man den Header manuell ändert. Dazu kann man die betreffende Mail in einen Testordner kopieren, auf Systemebene mit einem Texteditor den Header ändern, die zugehörige *.msf Datei löschen und den Testordner in TB 'Reparieren' lassen.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=76323

Alles anzeigen

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.

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.