Moin,

ich hab nun zum 2. mal mit bekommen, das Thunderbird große Dateianhänge nicht speichern konnte. So scanne ich meine Dokument mit einem Dokumentenscanner
und sende Sie mir selber als EMail zu. Das funktionierte bisher auch immer
bis ca. 100 MB große EMail.
Heute versuchte ich mit TB eine ca. 25 MB große Datei in der 33 MB großen EMail zu speichern, aber es wurden immer nur 45 Byte abgelegt.
Diese sind weder mit den ersten 45 Byte noch mit den letzten der korrekt gespeicherten Datei identisch. Ich habe jetzt nicht wirklich gut prüfen können ob diese 45 Byte überhaupt in der korrekten Datei vorkommen. Vielleicht hat mal jemand einen für mich einen grep der den Inhalt
der kaputten Datei in der korrekten Datei sucht um heraus zu finden ob
das unsinniger Müll ist oder tatsächlich aus der Datei kommt.

Da ein fuser auf die Datei keinen Prozess zeigte hatte TB den Vorgang wohl abgebrochen.
Um zu prüfen das nicht mein IMAP-Server das Problem ist habe ich die Datei
per IMAP-Mutt auf dem gleichen Rechner ohne Probleme in das Zielverzeichnis speichern können.
Es scheint nur große Mails zu betreffen.

Mein System:

user@host:~$ cat /etc/debian_version
10.12
user@host:~$ uname -a
Linux host 4.19.0-20-amd64 #1 SMP Debian 4.19.235-1 (2022-03-17) x86_64 GNU/Linux
user@host:~$ dpkg -l 'thunderbird*' Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht) ||/ Name Version Architektur Beschreibung +++-=============================-==================-============-==================================================================
ii thunderbird 1:91.8.0-1~deb10u1 amd64 mail/news client with RSS, chat and integrated spam filter support
ii thunderbird-l10n-de 1:91.8.0-1~deb10u1 all German language package for Thunderbird
user@host:~$ apt policy thunderbird
thunderbird:
Installiert: 1:91.8.0-1~deb10u1
Installationskandidat: 1:91.8.0-1~deb10u1
Versionstabelle:
*** 1:91.8.0-1~deb10u1 500
500 http://security.debian.org/debian-security buster/updates/main amd64 Packages
100 /var/lib/dpkg/status
1:78.14.0-1~deb10u1 500
500 http://ftp.de.debian.org/debian buster/main amd64 Packages

Ich hatte das Problem aber auch schon auf meinem RasPi4 entdeckt, dort weiss ich aber gerade nicht, was für eine TB-Version
ich verwende.

Kann das jemand nachvollziehen, oder geht es bei Euch mit der Version?

MfG,
Pierre Bernhardt

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 13.04.22 um 11:56 schrieb Pierre Bernhardt:

ich hab nun zum 2. mal mit bekommen, das Thunderbird große Dateianhänge nicht
speichern konnte. So scanne ich meine Dokument mit einem Dokumentenscanner und sende Sie mir selber als EMail zu. Das funktionierte bisher auch immer bis ca. 100 MB große EMail.

Das Problem ist größer als Erwartet. Die Größe der Anhänge ist nicht relevant.
Auch wenn ich mehrere Bilder von wenigen MB in einer Mail erhalte welche einzeln
kein Problem darstellen, werden die Bilder nicht korrekt gespeichert sobald
die Mail zu Groß wird. In einem aktuellen Fall habe ich mir selber von meinem Smartphone eine EMail von ca. 31 MByte zu gesendet welche als Anhänge 8 Bilder zwischen 2 und 4 MByte enthält.
Alle gespeicherten Foto haben dann nur eine Größe von 45 Byte.

MfG,
Pierre

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13.04.22 11:56, Pierre Bernhardt wrote:

Es scheint nur große Mails zu betreffen.

ii  thunderbird                   1:91.8.0-1~deb10u1 amd64

Nur der Vollstängigkeit halber: Mit

ii thunderbird 1:91.8.0-1~deb11u1
amd64

kann ich Dein Problem nicht reproduzieren.

Ich würde auf den Mailprovider tippen, oder auf ein Layer 8 Problem.

Viele Grüße
Ulf

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Fri, 15 Apr 2022 15:20:22 +0200
schrieb Pierre Bernhardt <[email protected]>:

Am 13.04.22 um 11:56 schrieb Pierre Bernhardt:

ich hab nun zum 2. mal mit bekommen, das Thunderbird große
Dateianhänge nicht speichern konnte. So scanne ich meine Dokument
mit einem Dokumentenscanner und sende Sie mir selber als EMail zu.
Das funktionierte bisher auch immer bis ca. 100 MB große EMail.

Das Problem ist größer als Erwartet. Die Größe der Anhänge ist nicht relevant. Auch wenn ich mehrere Bilder von wenigen MB in einer Mail
erhalte welche einzeln kein Problem darstellen, werden die Bilder
nicht korrekt gespeichert sobald die Mail zu Groß wird. In einem
aktuellen Fall habe ich mir selber von meinem Smartphone eine EMail
von ca. 31 MByte zu gesendet welche als Anhänge 8 Bilder zwischen 2
und 4 MByte enthält. Alle gespeicherten Foto haben dann nur eine
Größe von 45 Byte.

Welche Größe hat die E-Mail effektiv?

Angehängte Binär-Daten, wozu auch Bilder gehören, blähen die E-Mails,
durch eine Base64 Codierung, ordentlich auf.
Außerdem limitieren die meisten Provider die Größe der E-Mails!

--
Gruß Jochen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Moin,

On 13.04.22 11:56, Pierre Bernhardt wrote:

Kann das jemand nachvollziehen, oder geht es bei Euch mit der Version?

Ich habe das mal probiert, und eine E-Mail mit 9 Anhängen mit insgesamt
24,7 MB Größe erzeugt. Der Imap-Server (Dovecot) läuft dabei auf dem
lokalen System. Ergebnis:

$ ls -lh .maildir/.Drafts/cur/
insgesamt 34M
-rw------- 1 user user 34M Apr 16 11:07 '1650100058.M240727P40184.alpha,S=35001669,W=35481188:2,Da'


Meine Thunderbird-Version:

$ dpkg -l | grep -i thunderbird
ii thunderbird
1:91.7.0+build2-0ubuntu0.21.10.1 amd64 Email, RSS and newsgroup client with integrated spam filter

Kleiner Unterschied hier: Ich bin auf Ubuntu, Du auf Debian. Aber
jedenfalls hat's funktioniert.


Du sagst, daß das Dein eigener IMAP ist. Erstens, welcher ist das,
Dovecot? Zweitens, kannst Du nachsehen, wie groß die resultierende Datei tatsächlich ist? So könntest Du sehen, ob schon die Mail falsch
gespeichert wird, oder ob TB sie nur falsch anzeigt.


Weiterer Vorschlag, Du könntest per tcptump/wireshark nachsehen, ob TB
die Mail tatsächlich in voller Größe auf den IMAP-Server schiebt, oder
ob schon auf dem Netzwerk nur ein paar kB anstatt der vielen MB
übertragen werden.


Wie schauts mit den Logs auf dem IMAP aus, jammert der vielleicht über irgendwas?


Wenn Du TB über eine Konsole startest, gibt er Dir da vielleicht schon Fehlermeldungen? Wenn Du es via strace machst? Gib mal den Output von

hexdump -C /pfad/zur/48byte/datei

Dann kann ich Dir auch einen grep geben, mit dem Du Deine Ausgangsdatei durchsuchen kannst. Allerdings glaube ich nicht, daß das viel bringt,
aber wer weiß.


Sind die 48 Bytes immer die gleichen bei jedem Bild, oder ist das
jedesmal was anderes?

--
Andre Tann

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 15.04.22 um 15:52 schrieb Henning Follmann:

On Fri, Apr 15, 2022 at 03:20:22PM +0200, Pierre Bernhardt wrote:
Hat das mit Deinem MUA zu tun (Thunderbird)? Und warum denkst Du das?

Mit einem mutt auf dem selben System an selben Server mit selber Anmeldung
die selbe Mail kann ich abrufen und die angehängten Dateien in das selbe Verzeichnis speichern.
Damit dürfte der Server (dovecot), das FS, die Workstation, Account etc. alles raus fallen und nur noch der Unterschied mutt zu Thunderbird das Problem
sein. Jedenfalls etwas das Thundebird macht aber mutt nicht.

Hast Du schon andere MUA probiert. Und hast Du das Problem nur, wenn
die angehaengte Datei von dem Scanner kommt?

Wie beschrieben ist es nicht von den Dateien und der einzenen Datei-
größe der Anhänge abhängig, sonder die Mailgröße scheint Hinweis zu
sein.

Hat Dein MTA ein Groessenlimit?

Bisher hatte der das nicht. mutt würde ja dann das gleiche Problem
haben, oder?

Wo speicherst Du Deine Anhaenge und hat das fs ein Quota/Limit?

Im lokalen ext4-FS ohne so etwas. Aber wie geschrieben mutt kann
die Dateien speichern.

Und was hast Du versucht, um das Problem besser zu verstehen?

Es mit mutt nicht nachvollziehen können.
MfG,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 16.04.22 um 11:19 schrieb Andre Tann:

Moin,

On 13.04.22 11:56, Pierre Bernhardt wrote:

Kann das jemand nachvollziehen, oder geht es bei Euch mit der Version?

Ich habe das mal probiert, und eine E-Mail mit 9 Anhängen mit insgesamt 24,7 MB Größe erzeugt. Der Imap-Server (Dovecot) läuft dabei auf dem lokalen System. Ergebnis:

Danke, mein dovecot auf aktuellem Debian 10 läuft mit mbox-Dateien. Ich hatte vorher einen alten imaps laufen und habe dann umgestellt. Eine
Migration auf maildir hatte ich mal vor aber noch nicht die Zeit dafür gefunden. Die Mail liegt aber noch in meiner Inbox als mbox Datei rum.

Aber wie schon geschrieben halte ich das Problem eigentlich für eins
innerhalb oder in Zusammenhang mit Thunderbird. Es muss ja nicht TB
die Ursache sein, aber es kann etwas sein was TB verwendet, aber mutt
nicht. Mehr siehe unten.

Meine Thunderbird-Version:

$ dpkg -l | grep -i thunderbird
ii  thunderbird 1:91.7.0+build2-0ubuntu0.21.10.1            amd64        Email, RSS and newsgroup client with integrated spam filter

Es gab inzwischen ein Update:
user@host:~/Downloads/bla $ dpkg -l thunderbird Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht) ||/ Name Version Architektur Beschreibung +++-==============-==================-============-==================================================================
ii thunderbird 1:91.8.0-1~deb11u1 arm64 mail/news client with RSS, chat and integrated spam filter support

Du sagst, daß das Dein eigener IMAP ist. Erstens, welcher ist das, Dovecot? Zweitens, kannst Du nachsehen, wie groß die resultierende Datei tatsächlich ist? So könntest Du sehen, ob schon die Mail falsch gespeichert wird, oder ob TB sie nur falsch

anzeigt.
Zu 1:
ii dovecot-core 1:2.3.4.1-5+deb10u6 amd64 secure POP3/IMAP server - core files
ii dovecot-imapd 1:2.3.4.1-5+deb10u6 amd64 secure POP3/IMAP server - IMAP daemon

Zu 2:
Gute Idee. Ich konnte die eml-Datei aus Thunderbird komplett speichern. Soweit so gut und es
hängt dann eher wohl mit dem extrahieren der einzelnen Dateien zusammen und nicht mit dem
speichern der ganzen Datei.

-rw-r--r-- 1 pi pi 32279876 16. Apr 14:12 email.eml

Das hat mich auf die Idee gebracht mal die Dateil lokal
in TB zu laden und siehe da, ich kann alle Dateien auf
einmal extrahieren:
-rw-r--r-- 1 pi pi 2203636 16. Apr 14:27 20220411_165731.jpg
-rw-r--r-- 1 pi pi 2256311 16. Apr 14:28 20220411_165736.jpg
-rw-r--r-- 1 pi pi 3131457 16. Apr 14:28 20220413_150514.jpg
-rw-r--r-- 1 pi pi 2302803 16. Apr 14:28 20220413_150642.jpg
-rw-r--r-- 1 pi pi 3907370 16. Apr 14:28 20220413_151550.jpg
-rw-r--r-- 1 pi pi 2757029 16. Apr 14:28 20220413_151710.jpg
-rw-r--r-- 1 pi pi 3469148 16. Apr 14:28 20220413_151749.jpg
-rw-r--r-- 1 pi pi 3559150 16. Apr 14:28 20220413_151838.jpg

Das bedeutet das es für TB ein Problem ist, wenn ich die Datei
vom Mailserver über imap öffne gegenüber wenn ich die per
TB gespeicherte Datei vom lokalem FS in TB öffne.

Weiterer Vorschlag, Du könntest per tcptump/wireshark nachsehen, ob TB die Mail tatsächlich in voller Größe auf den IMAP-Server schiebt, oder ob schon auf dem Netzwerk nur ein paar kB anstatt der vielen MB übertragen werden.

Wie schauts mit den Logs auf dem IMAP aus, jammert der vielleicht über irgendwas?

Nein, wärend des Öffnens der Mail, noch beim download der ganzen Mail noch beim
Download der einzelnen Dateien wurde die Logdatei auf dem Server verändert.

Wenn Du TB über eine Konsole startest, gibt er Dir da vielleicht schon Fehlermeldungen? Wenn Du es via strace machst? Gib mal den Output von

Uh, tb meckert ja nie über Fehler oder Probleme wenn man das nicht einstellt. Leider finde ich den Artikel nicht wo man logs aktivieren konnte. Ich muss
da mal nach suchen.

strace habe ich erstellt während des speichern einer der Dateien als bla.jpg. Ein grep auf bla.jpg ergibt:

faccessat(AT_FDCWD, "/home/user/Downloads/bla/test/bla.jpg", F_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
newfstatat(AT_FDCWD, "/home/user/Downloads/bla/test/bla.jpg", 0x7e899f3a30, 0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
newfstatat(AT_FDCWD, "/home/user/Downloads/bla/test/bla.jpg", 0x7e899f3a30, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/home/user/Downloads/bla/test/bla.jpg", O_WRONLY|O_CREAT|O_TRUNC, 0664) = 168
newfstatat(AT_FDCWD, "/home/user/Downloads/bla/test/bla.jpg", {st_mode=S_IFREG|0644, st_size=0, ...}, 0) = 0

Interessant ist dann also der fd (?) 168 . Ein egrep auf das log mit 168 und bla.log
ergibt dann:

faccessat(AT_FDCWD, "/home/user/Downloads/bla/test/bla.jpg", F_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
newfstatat(AT_FDCWD, "/home/user/Downloads/bla/test/bla.jpg", 0x7e899f3a30, 0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
newfstatat(AT_FDCWD, "/home/user/Downloads/bla/test/bla.jpg", 0x7e899f3a30, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)

openat(AT_FDCWD, "/home/user/.local/share", O_RDONLY) = 168
fsync(168) = 0
close(168) = 0
openat(AT_FDCWD, "/home/user/Downloads/bla/test/bla.jpg", O_WRONLY|O_CREAT|O_TRUNC, 0664) = 168
newfstatat(AT_FDCWD, "/home/user/Downloads/bla/test/bla.jpg", {st_mode=S_IFREG|0644, st_size=0, ...}, 0) = 0
write(168, "\16'\254z\263Zr\32\342r\33^\236)\341j[p\212\267Z\271\360'~\266\240zJ&\246W"..., 45) = 45
close(168) = 0

Man kann also auch schön sehen wie die Datei angelegt, geschrieben (45 byte) und dann geschlossen wird. Es gab dann noch weitere 168 fd am Ende und nach den beiden newfstatat aber die hatten mit der Datei bla.jpg nichts zu tun
und daher habe ich die Zeilen weg gelassen.

hexdump -C /pfad/zur/48byte/datei

00000000 0e 27 ac 7a b3 5a 72 1a e2 72 1b 5e 9e 29 e1 6a |.'.z.Zr..r.^.).j| 00000010 5b 70 8a b7 5a b9 f0 27 7e b6 a0 7a 4a 26 a6 57 |[p..Z..'~..zJ&.W| 00000020 ad b6 17 ab ba 7b 5e ae 07 a5 69 d7 a7 |.....{^...i..| 0000002d

Dann kann ich Dir auch einen grep geben, mit dem Du Deine Ausgangsdatei durchsuchen kannst. Allerdings glaube ich nicht, daß das viel bringt, aber wer weiß.

Sind die 48 Bytes immer die gleichen bei jedem Bild, oder ist das jedesmal was anderes?

Gute Idee. Alle Dateien haben den gleichen Inhalt: user@host:~/Downloads/bla/test $ md5sum *
493ecd0116f5431407695a5c0188e6d2 20220411_165731.jpg 493ecd0116f5431407695a5c0188e6d2 20220411_165736.jpg 493ecd0116f5431407695a5c0188e6d2 20220413_150514.jpg 493ecd0116f5431407695a5c0188e6d2 20220413_150642.jpg 493ecd0116f5431407695a5c0188e6d2 20220413_151550.jpg 493ecd0116f5431407695a5c0188e6d2 20220413_151710.jpg 493ecd0116f5431407695a5c0188e6d2 20220413_151749.jpg 493ecd0116f5431407695a5c0188e6d2 20220413_151838.jpg 30a62d8743b34157c8f8f1fd8aed3fe1 email.eml

Also im Moment wäre mein Workaround die Mail einfach
speichern und lokal öffnen oder mutt zum speichern der
Inhalte verwenden. Aber eine Dauerlösung ist das eher
nicht.

MfG,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Nachtrag. Ich habe thunderbird --verbose gestarte und erhalte beim
öffnen der EMail folgende Meldung:

Wenn Du TB über eine Konsole startest, gibt er Dir da vielleicht schon Fehlermeldungen? Wenn Du es via strace machst? Gib mal den Output von

INFO -> [[ ... using verbose mode ... ]]
DEBUG -> call '/usr/lib/thunderbird/thunderbird '
IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: PClientManager::Msg_ExpectFutureClientSource Processing error: message was deserialized, but the handler returned false (indicating failure)

IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: PClientManager::Msg_ForgetFutureClientSource Processing error: message was deserialized, but the handler returned false (indicating failure)


Wenn ich dann ein jpg aus der Datei speichere wird aber nichts ergänzt.
Nur wenn ich jedes mal die Mail neu anzeigen lasse oder neu öffne.

Allerdings werden diese Meldungen auch angezeigt wenn ich die lokal gespeicherte Mail mit TB öffne. Mit dieser kann ich ja die Dateien
korrekt abspeichern.

MfG,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hallo,

ich konnte das Problem auf mein Profil einschränken. Mit einem neu
angelegtem Profil tritt das Problem nicht auf.
Ich werde mal nachsehen ob ich wirklich ein komplett neues Profil
anlegen muss, es ausreicht nur den Provider neu anzulegen oder
ob es vielleicht irgend eine Einstellung ist die da quer schießt.

Wenn jemand ein Tipp hat, gehe ich dem gerne nach. Ich würde ungern
das Profil komplett neu anlegen.

MfG,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)