UIps, jetzt habe ich den selben Bug zweimal bestätigt. Wie kann ich denn den zweiten Eintrag wieder löschen?
Beiträge löschen im BT können nur die BT-Mods.
Ich bekomme ab und an Mail mit langen Anhangsnamen. So wie dieses Mail AÖÜ (2).html.rar.eml.
The Bat! 10 kann das wohl nicht dkodieren, es zeigt Teil.att, während Thunderbird oder K9-Mail das schon dekodiert.
Der Anhang sollte als Dateiname ÄÖÜ HTML-Dokument (2).html.rar lauten.Wie ist das bei euch mit The Bat! 10.x und 9.x?
⚠️ Wer es hier bestätigen kann, bitte auch auf https://bt.ritlabs.com/view.php?id=2233 bestätigen.
Hier unter The Bat! 8.8.9 auch!
Habe ich allerdings in meinen Eingängen früher eher selten erlebt. Habe ich es eher mit dem Versender eMail Programm verknüpft (schrottige eMail Programme).
Noch einen Test mit einem aktuellen Thunderbird 102.9.0 (64-Bit).
Da wird der Dateianhang korrekt angezeigt.
Im Bugtracker bestätigt!
Ich kann das zwar mit der o.g. Test-Nachricht bestätigen, aber mit meinen eigenen Tests nicht. Ich hab's von TB! zu TB!, von anderen Mail-Programmen zu TB! und auch von verschiedenen Webmailern zu TB! geschickt und alle Unicode- und Umlaut-Anhänge sind korrekt angekommen. Könnt ihr auch selbst testen.
Es liegt demnach definitiv am Vivaldi Mail. Man sieht auch anhand des Quelltextes, dass der Dateiname des Anhangs aus unverständlichen Gründen in mehrere Zeilen zerlegt wurde. Also anstelle von
Content-Disposition: attachment;
filename="utf-8''%C3%84%C3%96%C3%9C%20HTML-Dokument%20(2).html.rar"steht dort
Content-Disposition: attachment;
filename*0*=utf-8''%C3%84%C3%96%C3%9C%20HTML-Dokument%20(2).ht;
filename*1*=ml.rarOb das jetzt so RFC-konform ist, müssen die Entwickler prüfen. Jedenfalls haben sie im Changelog zu v10.3.3.6 darauf hingewiesen, dass dieser Parameter zu lang ist, was wohl ungewöhnlich ist.
Edit::
Habe jetzt bemerkt, dass Thunderbird bei sehr langen Namen ebenfalls im Quelltext umbricht. Es sieht dann z.B. so aus:
Content-Disposition: attachment;
filename*0*=UTF-8''...;
filename*1*=...;
filename*2*=...Allerdings hat TB! mit solchen Anhängen keine Probleme. Es kann demnach nicht am zu lang kodierten Parameter liegen, sondern an etwas Anderem.
Es fällt z.B. auf, dass der Dateiname von Vivaldi Mail gar nicht kodiert wird, weil er im Klartext sichtbar ist, was ja eigentlich nicht sein darf. Es müsste nämlich so aussehen:
Content-Disposition: attachment;
filename="=?UTF-8?B?QcOWw5wgKDIpLnJhcg==?="Der gesamte Dateiname des Anhangs muss also für einen Menschen unleserlich sein.
Thunderbird verteilt zwar ebenfalls auf mehrere Zeilen, kodiert dann aber richtig. Vivaldi Mail scheint es aber nicht richtig zu machen. Vielleicht liegt es daran.
So, ein weiterer Test bestätigt es. Vivaldi Mail kodiert nicht mit UTF-8, sondern verwendet das sog. URL-Encoding. Damit werden in einigen Browsern Links mit Nicht-ASCII Zeichen kodiert.
Wenn man z.B. auf https://www.urldecoder.io/ den Text
%C3%84%C3%96%C3%9C%20HTML-Dokument%20(2).html.rareingibt, erscheint nach der Entschlüsselung der richtige Dateiname
ÄÖÜ HTML-Dokument (2).html.rarWer Notepad++ nutzt, kann es auch dort unter Plugins mit MIME Tools testen.
Wenn ein Programm etwas falsch verschlüsselt, kann man von einem anderen Programm nicht erwarten, dass es richtig entschlüsselt.
Wie es The Bat! beim Versenden bei Dateinamen macht, ist ja weniger relevant weil nicht viele Leute The Bat! als Client nutzen.
Wie gesagt, ich habe es mit verschiedenen Methoden getestet und mit keiner gab es Schwierigkeiten.
Ich bekomme auch oft Nachrichten mit Anhängen mit Nicht-ASCII Zeichen, erstellt mit Outlook, WLM, Thunderbird, Webmailern und verschiedenen Handy Apps. Mir wäre es längst aufgefallen, wenn damit etwas nicht stimmen würde. Offensichtlich besteht aber dieses Problem nur mit Vivaldi Mail. Wenn du das Programm hast, dann kannst du nachschauen, ob es dort irgendwo eine Einstellung in Bezug auf die Kodierung von Anhängen gibt.
Aber Thunderbird macht mit derselben Methode wie Vivaldi Mail mit dem Splitten der Namen und Nicht-ASCII-Zeichen!
Nicht immer. Es hängt wohl von der Länge des Dateinamens ab. Benenne den Anhang in ÄÖÜ.rar um. Dann wirst du wahrscheinlich auch nur eine Zeile sehen.
Entscheidend ist aber wohl nicht der Umbruch, da Thunderbird-Nachrichten mit Umbruch in TB! korrekt dargestellt werden, was wahrscheinlich auch du festgestellt hast, sondern zusätzlich die richtige Kodierung.
Dass andere MUAs solche Nachrichten richtig anzeigen, liegt eventuell daran, dass sie nicht darauf achten, welche Kodierung im Quelltext angegeben ist, sondern sie selbst überprüfen und richtig erkennen. Und TB! tut das halt nicht. Daher hat Stefan in TBBETA geschrieben, dass sie den Parser anpassen müssen, was dauern wird.
Das erinnert mich an einige Browser, die zumindest früher immer strikt darauf achteten, welche Kodierung im Header der Webseite bzw. der Haupt-HTML-Datei angegeben wurde, und immer nur diese einschalteten. Also z.B. wenn dort das stand
<meta http-equiv="content-type" content="text/html; charset=utf-8">dann wurde sofort UTF-8 aktiviert. War aber der Webseitentext in Wirklichkeit nicht als UTF-8 kodiert, gab es ein Kauderwelsch und man musste immer manuell umschalten. Manche Browser haben aber hingegen den Text selbst analysiert und wählten dann auch die passende Kodierung. So etwas Ähnliches haben wir wohl auch hier.
Jedenfalls kann es nicht dem Empfänger angelastet werden, wenn der Versender nicht richtig verschlüsselt.
s/UTF-8-kidierte/UTF-8-kodierte/