Michael Heydekamp ([EMAIL PROTECTED]) schrieb am 01.07.04: > Alfred Schroeder <[EMAIL PROTECTED]> wrote on 30.06.04:
>> Hat noch jemand die "Wichtige Information zum T-Online Banking" von >> "T-Online Banking" <[EMAIL PROTECTED]> erhalten? > Ich jedenfalls nicht. Multipart oder Singlepart? multipart/alternative > Im folgenden gehe ich von Singlepart aus. Falsch, aber das h�tte ich auch gleich dazu schreiben k�nnen. >> Es scheint in letzter Zeit Mode zu werden, dass Listserver (hier: X- >> Mailer: Listserv for OMO 1.0) "Binary" als Content-Transfer-Encoding >> angeben, obwohl -abgesehen von LF- keinerlei Zeichen ausserhalb 7Bit >> vorkommen. > LF ist ja auch 7bit. Aehm, stimmt nat�rlich. >> Der eigentliche Text (egal, ob /plain oder /html) ist quoted-printable >> codiert, also eigentlich mit XP prblemlos zu lesen, aber durch die >> bescheuerte Deklaration wirft UUZ beim Konvertieren nach dem Header >> alle LFs weg und XP zeigt nur Schrott an. > Hmm, LFs darf der UUZ gerade bei binary gerade *nicht* wegwerfen. Und > ich w�rde mal behaupten, da� er das auch nicht tut, denn das w�re > geradezu t�dlich f�r jedes Binary. Eben. Ich habe inzwischen herausgefunden, dass es sehr wahrscheinlich an dieser Testversion des UUZ liegt: |ZConnect <-> RFC/UUCP/SMTP Converter with MIME (c) 1993-1999 Peter Mandrella |FreeXP-Version v3.40.1a RC3 (c) 2002-2004 by FreeXP <[EMAIL PROTECTED]> | |Compiled on 2004/05/29 at 23:45:09 with Borland Pascal 7.01 Der UUZ vom 03.05.2004 aus der DOSBOX-Edition konvertiert korrekt. > Ein Test, den ich gerade durchgef�hrt habe, best�tigt das auch. Mit welchem UUZ hast Du getestet? Versuch es bitte noch einmal mit dem aus "ftp.freexp.de/freexp/snapshot/test/uuz_test.zip" und mit einer Multipart-Mail. Bei mir schmeist der Genannte definitiv LFs aus dem Body, also BUG? > Der Unterschied zwischen Binary und Text liegt im wesentlichen darin, > da� bei binary einfach nichts gemacht wird (speziell keine qp/b64- > Decodierung und keine Charset-Konvertierung). > Wenn im Text also qp-codierte Zeichen enthalten sein sollten (man kann > auch 7bit-Zeichen qp-codieren, und bei manchen sollte man das auch), > dann werden die eben nicht decodiert. Sie liegen zwar unkonvertiert vor, werden aber w�hrend der Anzeige im Lister korrekt (mit Umlauten etc.) dargestellt. > Was genau hei�t denn "zeigt nur Schrott an"? Ich kann eine urspr�nglich > als "7bit" deklarierte und auf "binary" umgemodelte Mail nach der UUZ- > Konvertierung problemlos lesen - vorausgesetzt, sie enth�lt keine > qp/b64-codierten Zeichen. Sie enth�lt qp-codierte Zeichen, die aber im Lister korrekt angezeigt werden (wenn vorher in der Rfc-Mail im Header von "binary" auf "7bit" ge�ndert wird, bei "binary" nur Brei, der gesammte Body besteht aus *einer* Zeile). Was ich meine: Aus: Hallo Michael wie geht es Dir? Mir geht es gut! Gruss Alex wird: Hallo Michaelwie geht es Dir?Mir geht es gut!GrussAlex >> Gibt es eine M�glichkeit, dies zu vermeiden (ausser der, sich die >> Original RFC-Mail zu sichern, "Content-Transfer-Encoding: binary" >> durch "Content-Transfer-Encoding: 7bit" zu erstzen, und das Ganze >> nochmal durch UUZ zu jagen...)? > Schick mal bitte eine solche Mail im Originalformat nach c.f.dev, ich > mu� mir mal ansehen, wie die beschaffen ist. Muss ich mich da erst eintragen, oder geht es so? > Wenn das Problem das ist, da� sie codierte Zeichen enth�lt, w��te ich > keinen anderen Weg. Bodies von Binaries darf der UUZ nicht anr�hren. > In diesem Fall mal T-Online ansprechen, normalerweise kann man mit denen > ja reden. Da der UUZ vom 3.5. keine LFs vernichtet, denke ich erstmal an einen Bug in dem vom 29.5. (Weis der Teufel, was mich geritten hat, den zu verwenden, ohne vorher "_index.txt" gelesen zu haben.) Gruss Alex ------------------------------------------------------------------------ FreeXP Support-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
