<[EMAIL PROTECTED]> wrote on 24.11.05: > Von: Michael Heydekamp [mailto:[EMAIL PROTECTED]
[...] >> Danke für die Erläuterung, aber ich meinte den Zusammenhang >> zwischen dem Kürzen von Headern bei der UUZ-Konvertierung und >> der Frage, wie und wodurch er vorher in den ZC-Puffer gekommen >> ist. Den seh ich nicht. > Na irgendwie muß doch der Header in den Puffer kommen, [...] Eben - irgendwie! Wie, ist völlig wurscht. Insofern ist die Aussage "Erzeuge ich den Header mit ZHM, wird er auch gekürzt" so richtig wie sinnlos. :-) Das könnten wir jetzt endlos fortsetzen: - "Erzeuge ich den Header mit edlin, wird er auch gekürzt" - "Schreibe ich den Header händisch mit edit.com in den Puffer, wird er auch gekürzt" - "Schreibe ich den Header händisch mit Word in den Puffer, wird er auch gekürzt" - [... please insert your 978 favorite ways to create ZConnect headers ...] Jetzt klar, was ich meine mit "kein Zusammenhang"? >>>> Der UUZ interessiert sich nur für das, was ihm letztlich als ZC- >>>> Puffer hingeworfen wird (von wem auch immer das vorher erzeugt/ >>>> bearbeitet wurde). >>> OK. ZHM manipuliert lt. Beschreibung diesen Puffer.....aber da >>> steht nicht drin, ob vor oder nach UUZ-Behandlung. >> Vor schätze ich, Du siehst den Header in XP nach Fertigstellung der >> Mail doch, oder? Der UUZ wird jedenfalls erst beim Netcall tätig, >> wie/wann wird denn ZHM aufgerufen? > im Rahmen der Ausgangsfilterbatch Dann ist es immer noch klar vor dem UUZ. >>> OK, damit ist nochmal klargestellt, daß der Face-Header vom UUZ >>> gekürzt wird, wenn er einen solchen findet. >> Können wir auch gerne noch ein paar Mal klarstellen. :-) Aber >> das war eigentlich nie die Frage. > Für mich schon, denn überlange Face-Header führten bei mir zu > Problemen, Ja, aber die Ursache war doch von Beginn an klar, sonst hättest Du kaum nach dem UUZ-Code gefragt. Denn daß es am UUZ lag, hatte HJT bereits gesagt, auch wenn seine Aussage bezogen auf *alle* Header so nicht stimmte. Aber jetzt mal zum Face-Header grundsätzlich -- ich hab mich da gerade mal etwas belesen, aber das Ganze wirft für mich immer noch Fragen auf: 1. Erstmal ist das rein vom Bezeichner her ein RFC-widriger Header. Insofern wäre sogar zu überlegen, ihn zumindest bei News vom UUZ komplett killen zu lassen, statt ihn (als IMO überflüssigen Overhead und ob gekürzt oder nicht) ins Netz zu blasen. Mir ist schon klar, daß das als Bevormundung verstanden würde, nur fallen etwaige Vorwürfe gegen die Verwendung von "Face:" ja auch auf das Programm zurück. Ich hab nicht den Eindruck, daß dieser Header sehr viele Freunde im Usenet hat. 2. Da er an die 998-Zeichen-Grenze stößt, muß er (zumindest bei Mail) gefolded werden. Wenn man ihn aber "einfach so" folded, entstehen beim Unfolden Leerzeichen im base64-String und ich bin im Moment nicht sicher, ob er dann noch korrekt decodiert werden kann/muß. Sollte er nicht decodiert werden können, müßte man den Umweg gehen, ihn einer MIME-Codierung zu unterziehen und in einzelne encoded words á la "=?US-ASCII?Q?...Zeile...?=" zu splitten. Das verbrät aber jede Menge zusätzlicher Zeichen (d.h. die Bildgröße müßte entsprechend kleiner werden) und außerdem weiß ich nicht, ob die gegenwärtigen Implementationen z.B. in Gnus damit klarkämen. Die "Spezifikation" in http://quimby.gnus.org/circus/face/ kotzt sich da leider nicht so richtig aus (und der Zählweise der 998 Bytes kann ich sowieso nicht ganz folgen, CRLFs werden eigentlich gar nicht mitgezählt). Hier wäre also zu überlegen, ob man nicht Face: (und für X-Face: gilt vermutlich dasselbe?) einer Sonderbehandlung beim Unfolding unterziehen muß (Leerzeichen einfach eliminieren). Wäre halt nur gegen alle Unfolding-Regeln in RFC2822. Unabhängig davon müßte man dem UUZ nicht nur beibringen, längere Header als 254 Zeichen aus MAIL.RFC auszulesen, sondern vor allem, dort auch gefoldete Header zu akzeptieren (das ist nämlich im Moment sowieso nicht der Fall). 3. Bei News hingegen sollte der Header gar nicht gefolded werden. Soweit mal das, was mir im Moment spontan dazu einfällt und ich zur Diskussion stellen möchte. BTW: Kannst Du Deinem Newsclient nicht mal beibringen, keine References zu killen? Michael ------------------------------------------------------------------------ FreeXP Support-Mailingliste [email protected] http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
