Gr.JPG-Dateien kommen defekt an

    Edit: Es ist nicht sinnvoll, sich an einen Thread zu hängen, der eine nur ähnliche oder sogar andere Thematik behandelt ( :arrow: Erstellen neuer Themen). Ich habe deshalb mit deinem Beitrag diesen neuen Thread eröffnet.Mod. graba


    Hallo zusammen!

    da ich hier schon oft Hilfreiches gelesen habe, habe ich mich hier nun auch registriert und will mich mal an dieses Thema dranhängen, denn mir und einigen meiner Kunden passiert seit einiger Zeit (mind. seit dem 25.10.2012) genau das gleiche.
    Groessere JPGs werden exakt mit dem gleichen Fehler, wie damals oben von Christiane illustriert, dargestellt.

    In fast allen Fällen kommt Win7 und nun auch Win8 (64bit) mit TB 16.02 zum Einsatz. Interessanterweise kann ich gleiches aber auch bei TB 16.02 unter meinen Linux-Clients (ubuntu) beobachten. Das Problem kann demnach höchstwahrscheinlich nicht an Windows selbst liegen. Auch kommen in meinem Fall 2 unterschiedliche IMAP-Server zum Einsatz (Dovecot und Cyrus). Betrachte ich die betroffenen Mails unter einem Web-Client (z.B. SqirrelMail), so werden die Bilder korrekt dargestellt und gespeichert.
    Speichere ich betroffene Datei mit Thunderbird, so enthält sie den Fehler.

    Jetzt haben mich in den letzten 4 Tagen 3 Kunden angesprochen, dass sie diese Probleme mit TB haben, scheint demnach kein Einzelfall zu sein.

    Vielleicht hat ja jemand eine Idee.
    Ich weiss, der Post hier ist schon älter, ich habe aber nichts gefunden, was mir weiterhilft.
    Die Suche nach Worten wie " jpg Anhang defekt fehlerhaft "in Verbindung mit Thunderbird ist auch ein bischen undankbar :redface:

    Danke und Gruesse
    Jens

    Danke  graba !

    Ich persönlich halte das Problem übrigens nicht für einen Fehler von Thunderbird, sondern eher einen der verwendeten und evtl. falsch konfigurierten Sicherheitssoftware, läuft diese auch auf Linux? Das gleiche, was auch  Peter_Lehmann  vermutet hat - in dem Uralt-Thread.
    Mehr kann ich dazu leider nicht sagen.
    Gruß

    Hallo,
    zunächstmal Sorry für die Mühe, die graba mit der Schieberei hatte.

    Zitat

    Wegen deiner speziellen nicht simulierbaren Serverumgebung darfst du aber hier keine große Hilfe erwarten.


    Naja so speziell wie bei mir ist es bei den anderen Vorfällen gar nicht (2 davon holen ihre Mails ganz 'üblich' via POP3 bei 2 bekannten Webspaceprovidern ab)

    Zitat

    ...sondern eher einen der verwendeten und evtl. falsch konfigurierten Sicherheitssoftware, läuft diese auch auf Linux?...


    Eher unwahrscheinlich, unterschiedlieche AV-Software und auf dem Linux-Client läuft ausser einem Rootkit-Scanner nichts.

    Habt Dank, hätte ja sein können, dass hier jemand ähnliche Erfahrungen gemacht hat.
    Wenn ich rausbekommen habe, woran es lag, schreib ich's hier,

    Gruss Jens

    Hallo Jens,

    falls Du das Problem reproduzieren kannst, ohne dass Du dazu wochenlang jpgs hin- und herschieben musst, könntest Du mal testen, ob das Phänomen auch mit einem ganz neuen Profil auftritt (keine Erweiterungen, ganz leere lokale Mailboxen, ... ).
    Außerdem solltest Du für einen solchen Test unter Ansicht -> Nachrichteninhalt die Option "Reiner Text" wählen und Anhänge nicht eingebunden anzeigen lassen. Du solltest die Anhänge für die Tests auch nicht aus dem TB heraus öffnen sondern speichern und danach mit einem Programm Deiner Wahl öffnen.

    Vielleicht testest Du das zunächst unter Linux, um AV und Co. gleich mal auszuschließen.


    Gruß

    Susanne

    Hallo,
    entschuldigt, dass ich mich hier mit einschalte. Ich habe mit schrecken aktuell die selbe Erfahrung mit einem Bilderanhang in einer Behördenmitteilung gemacht, die ich auch mit Bcc an mich gesendet habe. Ein blick in den Server hat mich aber beruhigt dort sind sie o.K. Darauf habe ich extra mein Testprofil geöffnet, in dem ich das Konto einmal als POP und als IMAP sauber ohne Add unterhalte. Siehe da im POP alles paletti, im IMAP beschädigt! Ich hänge mal ein Foto aus einer nachträglichen Testmail an mich selber dran.
    http://www.imagebanana.com/view/uryoswwc/Test.jpg
    Überrings um das Bild überhaupt einstellen zu können, musste ich einen Bildschirmabzug von dem gespeicherten Bild aus dem empfangenen Anhang machen, Der Upload konnte das Bild nicht übernehmen. Darauf wollte ich mit IrvanView ein neues .jpg speichern und auch das wurde als nicht möglich abgelehnt???

    M.f.G. Kienberger

    Hallo,
    wenn das wirklich an IMAP und Thunderbird liegen sollte, müsste man mehrere Einträge in der erweiterten Konfiguration (Extras, Einstellungen, Erweitert, Allgemein, "Konfiguration bearbeiten"))überprüfen und evtl korrigieren. Allerdings muss man sich ein wenig ins Thema einlesen und das ist leider nur in Englisch.
    Es handelt sich dabei um diese Einträge:

    mail.imap.mime_parts_on_demand
    mail.imap.mime_parts_on_demand_threshold
    mail.imap.mime_parts_on_demand_max_depth
    mail.imap.fetch_by_chunks
    mail.imap.chunk_size

    http://kb.mozillazine.org/Entire_message…an_IMAP_message

    Erfahrungsgemäß taucht aber das Problem nur bei bestimmten eigenen Servern auf.
    Siehe die Beschreibung in der Ausgangsfrage des Threads, welche ich mit "Serverumgebung" bezeichnet hatte.

    Gruß

    mrb
    tut mir leid, ich kann auf Englisch nicht mal husten, erst recht nicht lesen. Trotzdem hier mal:

    mail.imap.chunk_size;352256
    mail.imap.mime_parts_on_demand;true
    mail.imap.mime_parts_on_demand_threshold;30000

    der Rest ist nicht vorhanden.
    PS. bei einem einzelnen empfangenen Bild habe ich dieses Phänomen noch nicht festgestellt.

    M.f.G. Kienberger

    Zitat von "graba"

    und du bist wirklich der Überzeugung, dass mit einer solch alten TB-Version, die etliche Sicherheitsdefizite aufweist, alles in Ordnung ist? Wie lange wohl? :rolleyes:


    woraus leitest du deine Meinung ab, dass ich diese Version verwenden werde?

    Zitat von "graba"

    ALLES in Ordnung!


    Heißt nur was drin steht!

    M.f.G. Kienberger

    mrb
    ich habe in Anlehnung an Ver.3.1.9 die fehlende Zeile > mail.imap.mime_parts_on_demand_max_depth;15
    nach Ver. 16.0.2 kopiert schon flutscht es auch hier.

    > So da habe ich mich zu weit aus dem Fenster gelehnt, nach einem zweiten Neustart die alte Geschichte nur in einer anderen Verfälschung. Damit bin ich draußen.

    Trotzdem:
    Merci vielmals für deine Hilfe.

    M.f.G. Kienberger

    Zitat von "SusiTux"

    ... könntest Du mal testen, ob das Phänomen auch mit einem ganz neuen Profil auftritt (keine Erweiterungen, ganz leere lokale Mailboxen, ... ).

    Hast Du das mal ausprobiert?

    So Leute geschafft.
    Jetzt mal chronologisch:
    Nachrichteninhalt mit 5 Bilder je ca. 180KB im Anhang.

    Komplette neue V.16.0.2 Install. mit frischen Profi > Bilder defekt.
    Komplette neue V.3.1.9 Install. mit frischen Profi > Bilder i.O
    Zugriff mit V.16.0.2 auf das Profil von V.3.1.9 > Bilder i.O
    Zugriff mit V.16.0.2 auf mein Arbeitsprofil > Bilder i.O

    und das auch noch heute und so bleibt es jetzt.
    Was ich feststellen kann, ist eine wesentliche Veränderung der Einträge gegenüber der alten V.16.0.2:
    mail.imap.chunk_size;1105920
    mail.imap.min_chunk_size_threshold;1658880
    Leider habe ich es versäumt die Einträge in der neuen V.16.0.2 Install. mit frischen Profil festzuhalten und somit die Möglichkeit zum Vergleich vertan. Ob damit letzlich auch die Ursache für die fehlerhafte Bilddarstellung verbunden war, entzieht sich meiner Kenntnis. Durch aus möglich, dass an anderer Stelle noch zusätzliche Veränderungen durch den Profilwechsel ausgelöst wurde.

    M.f.G. Kienberger

    Hallo ...

    Leider fehlt mir die Definition von "größeren JPG-Dateien". Und da ich persönlich davon überzeugt bin, dass das Medium "E-Mail" nie für den Transport von Massendaten entwickelt wurde, denn dazu gab und gibt es schon immer bessere Protokolle, betrachte ich mal Bilder in einer Größe von ca. 5 MB als "größere Bilder". Größere habe ich leider nicht.

    Also habe ich einfach einmal 4 Bilder in dieser Größe genommen ...

    Code
    peter@sonne:~/temp/test> la
insgesamt 19852
drwxr-xr-x  3 peter users    4096 18. Nov 12:59 .
drwxr-x--- 19 peter peter    4096 18. Nov 12:57 ..
-rw-r--r--  1 peter users 5396410  1. Sep 20:41 Hochzeit_065.jpg
-rw-r--r--  1 peter users 5104436  1. Sep 20:41 Hochzeit_066.jpg
-rw-r--r--  1 peter users 5001222  1. Sep 20:41 Hochzeit_067.jpg
-rw-r--r--  1 peter users 4799093  1. Sep 20:41 Hochzeit_068.jpg
peter@sonne:~/temp/test>

    ... und diese Bilder (gegen meine Überzeugung) per Mail an mich selbst geschickt. Dazu habe ich auch bewusst einen großen Umweg über mehrere Mailprovider eingebaut, indem ich sie von meinem gmx.com-Account an meinen üblichen 1&1-Account versandt habe. Ich musst ja auch Provider nehmen, welche mit diesen Monstermails umgehen können.

    Von diesen Bildern habe ich vor dem Versand und nach deren Empfang und der Speicherung in .../empfangen jeweils die Hashwerte genommen:

    Code
    peter@sonne:~/temp/test> md5sum Ho* >> bilder.md5
peter@sonne:~/temp/test> cp bilder.md5 empfangen/
peter@sonne:~/temp/test> cd empfangen/
peter@sonne:~/temp/test/empfangen> md5sum Ho* >> bilder.md5
peter@sonne:~/temp/test> less bilder.md5
peter@sonne:~/temp/test/empfangen>

    Und wie nicht anders zu erwarten, sind die Hashwerte der gesendeten Bilder (oben) identisch mit den Hashwerten der empfangenen Bilder (unten).

    Code
    cb174528cdec2a7df86c23ea4dbe5c43  Hochzeit_065.jpg
6991aa0957f453475de61b8cc0ded1e0  Hochzeit_066.jpg
24d6cc15bc55a50dba1b70d3f6e95dfc  Hochzeit_067.jpg
efc40465a445c49ce51f3d50b1ea9c98  Hochzeit_068.jpg
cb174528cdec2a7df86c23ea4dbe5c43  Hochzeit_065.jpg
6991aa0957f453475de61b8cc0ded1e0  Hochzeit_066.jpg
24d6cc15bc55a50dba1b70d3f6e95dfc  Hochzeit_067.jpg
efc40465a445c49ce51f3d50b1ea9c98  Hochzeit_068.jpg

    Selbstverständlich sehen auch die Bilder im internen Betrachter des TB genau so aus, wie die gesendeten Bilder und auch wie mit einem ordentlichen ext. Bildbetrachter.
    Da ich sämtliche Mails zumindest mit einer elektronischen Signatur versende, hat die Signaturprüfung auch keinen Fehler angezeigt, ich hätte mir also die kleine Mühe mit der externen Hashwertberechnung eigentlich sparen können.

    Fazit: Ich kann (und konnte noch nie!) irgend eine Verfäschung von mit dem Thunderbird gesendeten oder empfangenen Dateien feststellen.
    Die von mir beschriebene Überprüfung der Hashwerte ist für mich die einzige gültige Bestätigung dafür, dass irgend eine Übertragung Daten verfälscht - oder auch nicht.

    Wer von "defekt ankommenden" Bildern spricht, sollte sich deshalb die kleine Mühe machen, und dieses auch beweisen.


    MfG Peter

    Thunderbird 45.8.x, Lightning 4.7.x, openSUSE Tumbleweed, 64bit
    S/MIME, denn ich will bestimmen, wer meine Mails lesen kann.
    Nebenbei: die Benutzung der (erweiterten) Suche, und von Hilfe & Lexikon ist völlig kostenlos - und keinesfalls umsonst!
    Und: Ich mag kein ToFu und kein HTML in E-Mails!