Dateiname einer PDF im Anhang bei Weiterleitung wird zu "...un%64%20%44%61%74%65<gekürzt>.pdf" oder sogar .dat

  • Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:

    • Thunderbird-Version (konkrete Versionsnummer:( 78.5.0 (64 Bit)
    • Betriebssystem + Version: Windows 10 Pro 64 Bit (20H2)
    • Kontenart (POP / IMAP): IMAP
    • Postfachanbieter (z.B. GMX): web.de
    • Speicherdienst (z.B. Dropbox): -
    • Eingesetzte Antivirensoftware: Windows Defender
    • Firewall (Betriebssystem-intern/Externe Software): OS


    Hallo zusammen,


    gestern habe ich ein Problem bei der Weiterleitung eines PDF-Anhangs festgestellt. Vielleicht kennt jemand das Problem oder hat Interesse mitzurätseln, woran es liegt?


    Im Original sieht das so aus:

    Beim Weiterleitungs-Empfänger dann so:

    oder so


    Die .dat kommt reproduzierbar an, wenn ich die original empfangene Mail weiterleite. Das Verhalten ändert sich zu .pdf, wenn der ursprüngliche Anhang in eine neu erstellte Mail per Drag & Drop direkt ohne Zwischenspeicherung auf dem Dateisystem übernommen wird.


    Folgende Tests habe ich dann mit der PDF-Datei versucht:

    • PDF zunächst abgespeichert. Alle Versuche hier sind mit der ursprünglich empfangenen PDF Datei gelaufen. Die wurde nur entweder erst abgespeichert und umbenannt oder vom geöffneten Mailfenster in ein Verfassenfenster rübergezogen.
    • "AGB, Widerrufs- und Datenschutzerklärung.pdf" in "ABC, DEF- und GHI.pdf" umbenannt: kommt genau so beim Empfänger an (Komma und Bindestrich sind also nicht der Grund).
    • "AGB, Widerrufs- und Datenschutzerklärung.pdf" in "ABC, DEF- und langer-Text-damit-der-Dateiname-lang-wird.pdf" umbenannt: kommt genau so beim Empfänger an (ein langer Dateiname für einen Anhang in Thunderbird ist also auch nicht das Problem).
    • Abgespeicherte "AGB, Widerrufs- und Datenschutzerklärung.pdf" in eine neu erstellte Mail als Anhang eingefügt: kommt als "AGB, Widerrufs- un%64%20%44%61%74%65%6E%73%63%68%75%74%7A%65%72%6B%6C%C3%A4%72%75%6E%67%2E%70%64%66.pdf" an.
    • Ob die PDF-Datei einzeln oder zusammen mit anderen Anhängen versendet wird, ändert ebenfalls nichts an der Veränderung des Dateinamens beim Empfänger.
    • Kommt die ursprüngliche PDF-Datei als .dat an, kann man sie dennoch auch einfach wieder zu .pdf umbenennen und öffnen.
    • Inhaltliche Änderungen an der PDF sind nicht auszumachen.

    Das ist doch einigermaßen merkwürdig :/


    Gruß

    Sehvornix

  • Ergänzung: Das gleiche passiert auch bei Versand über einen anderen Provider. Hier konkret, wenn ich die besagte Datei im selben Thunderbird über ein 1und1-Konto versende.


    Ein Hinweis ist vielleicht, dass das Umkodieren an der selben Stelle einsetzt, aber bedingt durch den geänderten Dateinamen dies nun sichtbar wird (ab Stelle 18).

    Ich hatte die Datei zur Unterscheidung 1 x mit dem Prefix 'abgesp ' ergänzt.


    Habe trotzdem keine Idee für den Grund.


    Gruß

    Sehvornix

  • Ich kann den Fehler unter ansonsten identischen Bedingungen (OS, Thunderbird-Version etc.) auch für docx bestätigen. Ein Teil des Dateinamens wird beim Weiterleiten in base64 kodiert und verunstaltet. Das ist kein triviales Problem, weil dienstliche Mails beim Empfänger damit sofort unter Spamverdacht geraten.

  • Die Frage ist, wenn es beim Empfänger falsch ankommt, welchen Mail Klienten dieser nutzt und welcher Provider.

    Ich konnte das Problem nicht reproduzieren.

    Ich erhalte Mail mit Anhang und klickte auf Weiterleiten an eine andere Mailadresse und sie kam mit korrektem Anhangsnamen an.

  • Hallo,


    billyshears_mz , danke für die Info. Gut zu wissen, dass das nicht nur hier auftritt und auch mit anderen Dateitypen passieren kann.


    Zitronella , danke auch für Deinen Input. Ich bin der These nachgegangen, ob es am Provider oder Mail-Client liegen könnte.

    Die Frage ist, wenn es beim Empfänger falsch ankommt, welchen Mail Klienten dieser nutzt und welcher Provider.

    Das ergibt bisher noch kein klares Bild. Im Gesendet-Ordner von Thunderbird sind die Anhänge noch nicht Base64-verstümmelt, soweit ich das mittels Thunderbird prüfen kann. Im Webmailer beim Zielprovider stehen die Anhänge auch korrekt:

    Allerdings nicht mehr, wenn ich mein Smartphone hernehme und dort in den Posteingang des per IMAP angebundenen Postfaches schaue:

    Das ist doch merkwürdig, da der Client des Smartphones eigentlich nur auf den Server schauen sollte und das wiedergibt, was von dort geliefert wird.


    In Outlook 2019 / POP3 (in dem Fall), kommt es wieder wie bekannt an:


    Das muss auch nicht via web.de laufen. Ich habe im selben Thunderbird auch ein 1und1-Konto konfiguriert. Wenn ich das benutze und von 1und1 and 1und1 maile, sieht es nicht besser aus.


    Es kommt dabei nicht auf die ursprüngliche PDF mit den AGB / Widerrufserklärung an. Der eigentliche Inhalt scheint mir für den Effekt nicht verantwortlich zu sein. Und da auch Worddokumente betroffen sind, würde ich schon fast ausschließen, dass es mit dem binären Rest einer PDF-Datei zusammenhängen könnte.


    Außerdem ist das Verhalten auch nicht schon immer so. Erst kürzlich analog weitergeleitete Mails mit der gleichen AGB-PDF hinten dran, sind korrekt am Zielsystem angekommen. Dazwischen lag vermutlich nur der Schritt von TB 78.4 zu 78.5, was ich aber leider zeitlich nicht besser eingegrenzt bekomme.


    Wer testen möchte, kann das mit der angefügten 'leeren' PDF tun. Die hat lediglich den identischen Dateinamen und produziert auch diese ab der 18. Stelle nicht korrekt Base64-decodierten Dateinamen im Mailanhang auf Empfängerseite.


    Gruß

    Sehvornix


    AGB, Widerrufs- und Datenschutzerklärung.pdf

  • ich nutze kein Mail auf dem Smartphone. Aber man könnte ja mal eine Mail über das Webinterface senden als Weiterleitung und dann gucken wie es in Thunderbird ankommt und wie bei Android App.

  • Ich kann Sehvornix' Beobachtungen nur in jeder Hinsicht bestätigen. Das Phänomen ist im Gesendet-Ordner noch nicht sichtbar und tritt auf

    - seit dem Update auf 78.5

    - unabhängig vom Inhalt der Datei

    - unabhängig vom Mailclient des Empfängers

    - bei docx und pdf (vielleicht auch bei anderen Formaten?).

  • Ich kann diesen Fehler mit der Datei aus #6 nicht reproduzieren. TB 78.7.1 Win 10 am PC / Sailfish Mail am Smartphone


    Test 1:

    Mit dem TB Mail von Account 1 (T-Online) an Account 2 (GMX), dann weitergeleitet an Account 3 (Strato).


    Test 2:

    Mit dem TB Mail von Account 1 an Account 2, von dort über das Smartphone weitergeleitet auf Account 3.


    Alles gut. Der Dateiname bleibt korrekt erhalten. Der Anhang lässt sich öffnen.


    Schauts mal, ob der Fehler bei euch mit der 78.7.1 noch auftritt.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

  • Hallo Susanne,


    danke für den erneuten Test.


    O. g. Beobachtungen gelten für die seinerzeit genutzte 78.5.0.


    Mit 78.6.0 und auch mit 78.7.1 (64-Bit) besteht das Problem in abgemilderter Form fort. Der Dateiname im Anhang wird nicht richtig decodiert und enthält Fehler . Das die PDF als .dat zurückkam, ist bisher noch nicht wieder aufgetreten. Die PDF-Dateien lassen sich öffnen. Inhalte habe ich nicht auf Veränderungen analysiert.


    Gruß

    Sehvornix

  • Dann bleibt die Frage, weshalb das bei dir immer noch auftritt, bei mir und Zitronella aber nicht. Irgendeinen Unterschied muss es geben.

    Mir fällt als Besonderheit ein, dass ich Nachrichten stets im Textformat versende und anzeigen lasse. Anhänge eingebunden anzeigen ist aktiv, auch wenn das bei Textanzeige und pdf eh keine Rolle spielen sollte.

    Ich verwende Maildir, keine Ahnung ob das einen Einfluss auf das temporäre Zwischenspeichern der Anhänge Einfluss hat. AV ist der Windows Defender.


    Außerdem habe ich nur zwei Erweiterungen: AllowHTML und Cardbook. Ich verwende keine Scripte oder sonstige Anpassungen.


    Hast du das mal mit einem frischen Profil getestet? Falls das damit auch auftritt, könntest du eine solche E-Mail mal signieren und im nächsten Schritt zusätzlich verschlüsseln. Dann bekämst du einen Hinweis, ob der "Schaden" bereits vor dem Versenden oder erst nach dem Empfang entsteht.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)