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

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.

Zitat von Zitronella

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

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