UUZ: X/U-Header
Hi, ich habe hier einen User-Request vorliegen, generell *alle* RFC-Header (ausser denen, die direkt interpretiert werden wie "To:", "From:" usw.) in uz-Richtung mit dem Prefix "U-" zu versehen, damit sie bei einer anschliessenden Konvertierung in zu-Richtung automatisch und ohne weiteres Zutun wieder in den entsprechenden RFC-Header umgewandelt werden. Derzeit passiert das nur bei einigen bestimmten Headern, aber z.B. nicht bei Headern mit dem Prefix "X-". Die gehen bei einer zu-Konvertierung also verloren. Derzeit traue ich mich da noch nicht ran, weil ich nicht sicher bin oder vergessen habe, wieso der UUZ das nicht eigentlich schon immer macht. Die XP-spezifischen header wie "X-Charset:" koennen der Grund nicht sein, die kann man ja explizit davon ausnehmen. Es irritiert mich auch, dass der OpenXP-UUZ extra einen Schalter besitzt, alle X-Header in zu-Richtung nicht wegzuwerfen - eben das haette man ja auch erreichen koennen, indem man diese Header vorher mit dem Prefix "U-" versehen haette. Kann mir jemand auf die Spruenge helfen, was gegen diesen Vorschlag spricht? Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: UUZ: X/U-Header
Michael Heydekamp ([EMAIL PROTECTED]) schrieb: > Kann mir jemand auf die Spruenge helfen, was gegen diesen Vorschlag > spricht? Wenn damit das Folding von X-Face z.B. vermieden wird, womit das im Original erhalten bliebe, warum nicht. Intern ist das ziemlich egal, ins ZC-Netze soll sowas natürlich nicht geschickt werden, s.a. ZConnect-Draft Mir persönlich würde das nichts ausmachen, weil ich den Mist bis auf wichtige MIME-Header sowieso vor dem Einlesen rausfiltern lasse, bei anderen würde die MessageBase damit belastet werden. -- Salut _)oachim FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: UUZ: X/U-Header
Joachim Merkel <[EMAIL PROTECTED]> wrote on 26.05.04: > Michael Heydekamp ([EMAIL PROTECTED]) schrieb: >> Kann mir jemand auf die Spruenge helfen, was gegen diesen Vorschlag >> spricht? > Wenn damit das Folding von X-Face z.B. vermieden wird, womit > das im Original erhalten bliebe, warum nicht. Einen Zusammenhang zu Folding sehe ich da jetzt eigentlich nicht, und vermieden würde es - bai Mail - dadurch auch nicht (bei News wird ja eh nicht gefoldet). Was ist denn problematisch am Folding von X-Face? > Intern ist das ziemlich egal, ins ZC-Netze soll sowas natürlich nicht > geschickt werden, s.a. ZConnect-Draft Hmm, genau das könnte der Knackpunkt und Grund für das bisherige Verhalten sein. Der UUZ und XP laufen durch dasselbe 'makeheader' in xpmakehd.inc. Wenn der UUZ jetzt allen X-Headern ein "U-" voranstellen würde, würde dann XP diese Header (außer die, die explizit davon ausgenommen sind) beim Beantworten übernehmen? Eigentlich doch nicht, IMO, aber muß ich mal checken... Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: UUZ: X/U-Header
Michael Heydekamp ([EMAIL PROTECTED]) schrieb: > Was ist denn problematisch am Folding von X-Face? Wie Du weißt, wird es X-Face nicht mehr im Original hergestellt, wenn es erneut -zu behandelt wird. War ja nur ein Beispiel, warum derartige Wünsche vielleicht doch begründet sind. >> Intern ist das ziemlich egal, ins ZC-Netze soll sowas natürlich nicht >> geschickt werden, s.a. ZConnect-Draft > Hmm, genau das könnte der Knackpunkt und Grund für das bisherige > Verhalten sein. > Der UUZ und XP laufen durch dasselbe 'makeheader' in xpmakehd.inc. Wenn > der UUZ jetzt allen X-Headern ein "U-" voranstellen würde, würde dann XP > diese Header (außer die, die explizit davon ausgenommen sind) beim > Beantworten übernehmen? Eigentlich doch nicht, IMO, aber muß ich mal > checken... Soweit ich weiß, fliegen die alle raus, genauer habe ich da auch nicht nachgesehen. Aber XP erzeugt eigentlich die notwendigen Header komplett neu und alles andere wandert nach /Dev/Nul. -- Salut _)oachim FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: UUZ: X/U-Header
Martin Wodrich ([EMAIL PROTECTED]) schrieb: > Kleiner Hinweis: Die Datei heißt /dev/null und nicht /Dev/Nul . > (Der Gag stammt aus der Unixwelt und daher ist der Devicename länger > und die Groß- udn Kleinschreibung ist wichtig). nagut, DOS-NUL-Device <> /dev/null, wurde aber für MSDOS 2.0 wie anderes von Unix geklaut oder gab's das vielleicht schon vorher? -- Salut _)oachim FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: UUZ: X/U-Header
Joachim Merkel <[EMAIL PROTECTED]> wrote on 26.05.04: > Michael Heydekamp ([EMAIL PROTECTED]) schrieb: >> Was ist denn problematisch am Folding von X-Face? > Wie Du weißt, wird es X-Face nicht mehr im Original hergestellt, > wenn es erneut -zu behandelt wird. Weiß ich jetzt grad nicht, hab's vielleicht vergessen. Von wem wird es nicht wiederhergestellt - UUZ? Möglicherweise wird es in zu-Richtung gefaltet (dann aber nur bei Mail), aber das dürfte doch eigentlich kein Problem sein. Falls doch, muß man mal sehen, ob man eine Sonderbehandlung für X-Face: einbaut. Aber irgendwie ist das sowieso ein anderes Thema. >>> Intern ist das ziemlich egal, ins ZC-Netze soll sowas natürlich >>> nicht geschickt werden, s.a. ZConnect-Draft >> Hmm, genau das könnte der Knackpunkt und Grund für das bisherige >> Verhalten sein. >> Der UUZ und XP laufen durch dasselbe 'makeheader' in xpmakehd.inc. >> Wenn der UUZ jetzt allen X-Headern ein "U-" voranstellen würde, >> würde dann XP diese Header (außer die, die explizit davon >> ausgenommen sind) beim Beantworten übernehmen? Eigentlich doch >> nicht, IMO, aber muß ich mal checken... > Soweit ich weiß, fliegen die alle raus, genauer habe ich da auch > nicht nachgesehen. Aber XP erzeugt eigentlich die notwendigen Header > komplett neu und alles andere wandert nach /Dev/Nul. Es gibt ja zwei Szenarien, die wir unterscheiden müssen: 1. uz-Konvertierung, anschließend Beantwortung in XP, danach zu-Konvertierung. 2. uz-Konvertierung und unmittelbar anschließend zu-Konvertierung (wozu auch immer). Und speziell für letzteres Szenario ist ja der Mechanismus "versehe Header in uz-Richtung mit Prefix "U-", damit er in zu-Richtung automatisch wieder restauriert wird" gedacht und wurde in der Vergangenheit - z.B. von Robo - auch auf den einen oder anderen Header ausgedehnt (ohne daß man dem CVS-Log entnehmen könnte, warum). Die Frage ist jetzt, warum das nicht bei allen Headern gemacht wurde. Entweder, weil man keine Notwendigkeit sah oder keinen Bock hatte, oder weil es konkrete Gründe gibt, die dagegen sprechen. Ich werde wohl mal Robo anrufen müssen, da einfach rumzubasteln ist mir zu heikel. Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: UUZ: X/U-Header
Michael Heydekamp ([EMAIL PROTECTED]) schrieb: >> Wie Du weißt, wird es X-Face nicht mehr im Original hergestellt, >> wenn es erneut -zu behandelt wird. > Weiß ich jetzt grad nicht, hab's vielleicht vergessen. Von wem wird > es nicht wiederhergestellt - UUZ? ja. > Möglicherweise wird es in zu-Richtung gefaltet (dann aber nur bei > Mail), aber das dürfte doch eigentlich kein Problem sein. Falls > doch, muß man mal sehen, ob man eine Sonderbehandlung für X-Face: > einbaut. Nein, bei -uz, wenn die Faltung bei -zu rückgängig gemacht wird, ist ein Leerzeichen drin, das vorher nicht drin war. Ist einfach nachvollziehbar. > Aber irgendwie ist das sowieso ein anderes Thema. Auf jeden Fall ist der Aufwand abzuwägen, es ist verlockend einfach, daß leicht gefordert werden kann, sichere alle Header mit U- davor und konkret bleibt es vielleicht nur bei einer Auswahl. [...] > Es gibt ja zwei Szenarien, die wir unterscheiden müssen: > 1. uz-Konvertierung, anschließend Beantwortung in XP, danach >zu-Konvertierung. > 2. uz-Konvertierung und unmittelbar anschließend zu-Konvertierung >(wozu auch immer). > Und speziell für letzteres Szenario ist ja der Mechanismus "versehe > Header in uz-Richtung mit Prefix "U-", damit er in zu-Richtung > automatisch wieder restauriert wird" gedacht und wurde in der > Vergangenheit - z.B. von Robo - auch auf den einen oder anderen > Header ausgedehnt (ohne daß man dem CVS-Log entnehmen könnte, > warum). Schon klar. Die Frage ist eigentlich, ob nicht für beide Fälle auch zwei Programme geigneter wären, bei entsprechender Modularisierung in wesentlichen Teilen identisch, aber leichter zu pflegen. > Die Frage ist jetzt, warum das nicht bei allen Headern gemacht wurde. Vermutlich zuviel Aufwand und viel Aufwand beim Recherchieren, und Erstellen einer genauen Spezifikation. > [...] da einfach rumzubasteln ist mir zu heikel. Nicht nur das, eingebaut werden muß es auch noch. -- Salut _)oachim FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: UUZ: X/U-Header
Joachim Merkel <[EMAIL PROTECTED]> wrote on 27.05.04: > Michael Heydekamp ([EMAIL PROTECTED]) schrieb: [X-Face] >> Möglicherweise wird es in zu-Richtung gefaltet (dann aber nur bei >> Mail), aber das dürfte doch eigentlich kein Problem sein. Falls >> doch, muß man mal sehen, ob man eine Sonderbehandlung für X-Face: >> einbaut. > Nein, bei -uz, wenn die Faltung bei -zu rückgängig gemacht wird, > ist ein Leerzeichen drin, das vorher nicht drin war. > Ist einfach nachvollziehbar. Hast Du nochmal das Beispiel parat? Wenn ein Header gefaltet ist, hat er per Definition ein Leerzeichen. Oder umgekehrt: Wenn er kein Leerzeichen hat, kann man nicht falten. Insofern kann man eigentlich nicht sagen "das vorher nicht drin war". Es war drin. Es sei denn, der UUZ dichtet eines hinzu, aber das wäre völlig untypisch für den E-UUZ und ein Bug, wenn es so wäre. >> Und speziell für letzteres Szenario ist ja der Mechanismus "versehe >> Header in uz-Richtung mit Prefix "U-", damit er in zu-Richtung >> automatisch wieder restauriert wird" gedacht und wurde in der >> Vergangenheit - z.B. von Robo - auch auf den einen oder anderen >> Header ausgedehnt (ohne daß man dem CVS-Log entnehmen könnte, >> warum). > Schon klar. Die Frage ist eigentlich, ob nicht für beide Fälle auch > zwei Programme geigneter wären, bei entsprechender Modularisierung in > wesentlichen Teilen identisch, aber leichter zu pflegen. Och, noch kann man das eigentlich recht gut überblicken. >> Die Frage ist jetzt, warum das nicht bei allen Headern gemacht >> wurde. > Vermutlich zuviel Aufwand und viel Aufwand beim Recherchieren, > und Erstellen einer genauen Spezifikation. Möglich. >> [...] da einfach rumzubasteln ist mir zu heikel. > Nicht nur das, eingebaut werden muß es auch noch. An der Routine muß eh gebaut werden, da noch die Unterstützung langer Header implementiert werden soll. Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: UUZ: X/U-Header
Michael Heydekamp ([EMAIL PROTECTED]) schrieb: > Joachim Merkel <[EMAIL PROTECTED]> wrote on 27.05.04: >> Michael Heydekamp ([EMAIL PROTECTED]) schrieb: > [X-Face] >>> Möglicherweise wird es in zu-Richtung gefaltet (dann aber nur bei >>> Mail), aber das dürfte doch eigentlich kein Problem sein. Falls >>> doch, muß man mal sehen, ob man eine Sonderbehandlung für X-Face: >>> einbaut. Sorry, X-Face wird ja gar nicht bei -zu erneut versandt. >> Nein, bei -uz, wenn die Faltung bei -zu rückgängig gemacht wird, >> ist ein Leerzeichen drin, das vorher nicht drin war. >> Ist einfach nachvollziehbar. Es *wäre* beim erneuten Folden ein weiteres Leerzeichen drin, weil das beim Unfolden nach -uz das mit reinkommt, es sei denn, es wird genau an derselben Stelle wieder gefoldet. > Hast Du nochmal das Beispiel parat? > Wenn ein Header gefaltet ist, hat er per Definition ein Leerzeichen. > Oder umgekehrt: Wenn er kein Leerzeichen hat, kann man nicht falten. > Insofern kann man eigentlich nicht sagen "das vorher nicht drin war". > Es war drin. Es sei denn, der UUZ dichtet eines hinzu, aber das wäre > völlig untypisch für den E-UUZ und ein Bug, wenn es so wäre. Ich hatte verwechselt, das ja bei -uz un"ge"foldet wird. In: <[EMAIL PROTECTED]> hätte ich also schreiben müssen, wenn das *un*folden vermieden wird, weil der Originalheader erhalten bleibt. Eigentlich erübrigt sich mein Einwand des Mehraufwanders vermutlich, weil ein U-X-Face würde den Original-Eintrag - gefoldet - behalten, oder? Zum Speicherbedarf: Vermutlich kann man X-Face sowieso gleich unverändert mit einem U- davor belassen. Ich habe sowieso nie verstanden, warum der unfoldet wurde. [...] >> Nicht nur das, eingebaut werden muß es auch noch. > An der Routine muß eh gebaut werden, da noch die Unterstützung langer > Header implementiert werden soll. 64kb reichen noch nicht? Aber wahrscheinlich meinst Du was anderes. Wie Du erwähntest, wolltest Du schon länger Makeheader aufräumen, ich hoffe das es nicht mit der Diskussion über weitere zu bewahrende Header kollidiert. Ich denke da an das Umpacken von Nachrichten aus Brettern in Archivbrettern oder das Umladen bzw. Verschieben von Brettern in andere Bretter als ein häufiger geäußerter Wunsch. Mir fehlt da leider der Überblick, aber vielleicht kann man sich da irgendwie koordinieren. Wenn dann noch DoSend dazukommt, wird es natürlich sehr quirlig. -- Salut _)oachim M0012.MSG Description: Binary data FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: UUZ: X/U-Header
Joachim Merkel <[EMAIL PROTECTED]> wrote on 28.05.04:
> Michael Heydekamp ([EMAIL PROTECTED]) schrieb:
>> [X-Face]
Möglicherweise wird es in zu-Richtung gefaltet (dann aber nur bei
Mail), aber das dürfte doch eigentlich kein Problem sein. Falls
doch, muß man mal sehen, ob man eine Sonderbehandlung für X-Face:
einbaut.
> Sorry, X-Face wird ja gar nicht bei -zu erneut versandt.
Ok, das kommt noch hinzu, ist aber ja gerade der Zustand, weshalb es den
Änderungswunsch gibt (wobei der sich weder speziell auf X-Face: bezieht
noch X-Face: der konkrete Anlaß ist).
>>> Nein, bei -uz, wenn die Faltung bei -zu rückgängig gemacht wird, ist
>>> ein Leerzeichen drin, das vorher nicht drin war. Ist einfach
>>> nachvollziehbar.
> Es *wäre* beim erneuten Folden ein weiteres Leerzeichen drin, weil das
> beim Unfolden nach -uz das mit reinkommt, es sei denn, es wird genau
> an derselben Stelle wieder gefoldet.
Auch das kann ich nicht nachvollziehen und wäre ein Bug. Ob an der
ursprünglichen oder einer anderen Stelle gefoldet würde: Es wird immer
nur da gefoldet (und kann nur da gefoldet werden), wo sowieso schon ein
Leerzeichen vorhanden ist. Und wenn keines da ist, wird auch nicht
gefoldet.
Insofern ist mir unklar, wie da zusätzliche Leerzeichen entstehen
sollten. Ob bei mehreren Leerzeichen hier oder da gefoldet wird, ist
technisch betrachtet wumpe. Wobei man sinnvollerweise beim letzten
Leerzeichen vor Pos. 78 foldet.
> Eigentlich erübrigt sich mein Einwand des Mehraufwanders vermutlich,
> weil ein U-X-Face würde den Original-Eintrag - gefoldet - behalten,
> oder?
Nein, das geht doch gar nicht. ZConnect kennt kein Folding, deshalb muß
in uz-Richtung immer entfaltet werden.
> Vermutlich kann man X-Face sowieso gleich unverändert mit einem
> U- davor belassen. Ich habe sowieso nie verstanden, warum der
> unfoldet wurde.
Siehe oben - auch wenn man ein "U-" davorhängt, reden wir immer noch
über einen ZConnect-Header, an dessen technische Spezifikationen wir uns
halten müssen.
> [...]
>>> Nicht nur das, eingebaut werden muß es auch noch.
>> An der Routine muß eh gebaut werden, da noch die Unterstützung
>> langer Header implementiert werden soll.
> 64kb reichen noch nicht? Aber wahrscheinlich meinst Du was anderes.
Ich sprach von der Unterstützung langer Header in zu-Richtung. Die
gibt's bisher nicht (außer bei Headern wie EMP: und STICHWORT:, wo
mehrere ZC-Header zu einem einzigen RFC-Header zusammengebastelt werden,
deren Gesamtlänge ist natürlich schon bisher nicht begrenzt).
Aber ein langes Subject:, das in uz-Richtung zu einem ebenfalls langen
BET: wird, wäre bisher in zu-Richtung wieder gekappt worden.
> Wie Du erwähntest, wolltest Du schon länger Makeheader aufräumen,
> ich hoffe das es nicht mit der Diskussion über weitere zu bewahrende
> Header kollidiert.
Nein, wir sprechen hier über UUZ-spezifische Routinen, die mittels
{$ifdef ...} von den XP-Routinen für jeweils denselben Header klar
abgegrenzt sind.
In XP macht eine Unterstützung z.B. eines langen BET:-Headers zumindest
derzeit wenig Sinn, da das Eingabefeld ohnehin begrenzt ist.
> Ich denke da an das Umpacken von Nachrichten aus Brettern in
> Archivbrettern oder das Umladen bzw. Verschieben von Brettern in
> andere Bretter als ein häufiger geäußerter Wunsch.
Jup, ist aber unabhängig davon.
Michael
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: UUZ: X/U-Header
Michael Heydekamp ([EMAIL PROTECTED]) schrieb: Nein, bei -uz, wenn die Faltung bei -zu rückgängig gemacht wird, ist ein Leerzeichen drin, das vorher nicht drin war. Ist einfach nachvollziehbar. >> Es *wäre* beim erneuten Folden ein weiteres Leerzeichen drin, weil >> das beim Unfolden nach -uz das mit reinkommt, es sei denn, es wird >> genau an derselben Stelle wieder gefoldet. > Auch das kann ich nicht nachvollziehen und wäre ein Bug. Ob an der > ursprünglichen oder einer anderen Stelle gefoldet würde: Es wird > immer nur da gefoldet (und kann nur da gefoldet werden), wo sowieso > schon ein Leerzeichen vorhanden ist. Und wenn keines da ist, wird > auch nicht gefoldet. Ok. Wenn Du die im letzten Posting anliegende msg mal mit UUZ -uz behandelst, hast Du im unfoldet X-Face doch die Leerzeichen zusätzlich drin, die vor den gefoldeten Teilen in der msg stehen. Die würden dann exakt an der Stelle wieder gefoldet. Das würde dann ja wohl klappen. > Insofern ist mir unklar, wie da zusätzliche Leerzeichen entstehen > sollten. Ob bei mehreren Leerzeichen hier oder da gefoldet wird, > ist technisch betrachtet wumpe. Wobei man sinnvollerweise beim > letzten Leerzeichen vor Pos. 78 foldet. Die entstehen schon beim Unfolden, und Du bekommst Sie nicht mehr raus. >> Eigentlich erübrigt sich mein Einwand des Mehraufwanders >> vermutlich, weil ein U-X-Face würde den Original-Eintrag - >> gefoldet - behalten, oder? > Nein, das geht doch gar nicht. ZConnect kennt kein Folding, Ahja, stimmt ja.. > deshalb muß in uz-Richtung immer entfaltet werden. Genau das ist der Punkt. >> Vermutlich kann man X-Face sowieso gleich unverändert mit einem >> U- davor belassen. Ich habe sowieso nie verstanden, warum der >> unfoldet wurde. > Siehe oben - auch wenn man ein "U-" davorhängt, reden wir immer noch > über einen ZConnect-Header, an dessen technische Spezifikationen wir uns > halten müssen. Ob es dem "Antragsteller" nun um X-Face ging oder nicht, es schien mir nur mal der Hinweis darauf passend, ob es überhaupt möglich ist, den Original-Header wieder unversehrt zu versenden. -- Salut _)oachim FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: UUZ: X/U-Header
Joachim Merkel <[EMAIL PROTECTED]> wrote on 28.05.04: > Michael Heydekamp ([EMAIL PROTECTED]) schrieb: >>> Es *wäre* beim erneuten Folden ein weiteres Leerzeichen drin, weil >>> das beim Unfolden nach -uz das mit reinkommt, es sei denn, es wird >>> genau an derselben Stelle wieder gefoldet. >> Auch das kann ich nicht nachvollziehen und wäre ein Bug. Ob an der >> ursprünglichen oder einer anderen Stelle gefoldet würde: Es wird >> immer nur da gefoldet (und kann nur da gefoldet werden), wo sowieso >> schon ein Leerzeichen vorhanden ist. Und wenn keines da ist, wird >> auch nicht gefoldet. > Ok. Wenn Du die im letzten Posting anliegende msg mal mit UUZ -uz > behandelst, hast Du im unfoldet X-Face doch die Leerzeichen > zusätzlich drin, die vor den gefoldeten Teilen in der msg stehen. Nochmal ganz klar, damit's da keine Mißverständnisse gibt: Das Leerzeichen ist *nicht* zusätzlich, sondern es wird lediglich ein bereits vorhandes Leerzeichen beim Entfalten nicht entfernt und es darf auch nicht entfernt werden. Entfalten heißt nix weiter als LF|CRLF entfernen. Wenn an der Stelle kein Leerzeichen hingehört oder X-Face:-Header generell keine Leerzeichen enthalten können/dürfen (ich kenne die Specs von X-Face: nicht), dann hätte das Programm, das den Header erzeugt, den Header eben nicht einfach an einer oder mehreren beliebigen Stellen falten dürfen. Das "zusätzliche" Leerzeichen entsteht also - wenn überhaupt - nicht durch den UUZ, sondern durch das Programm, das den Header an Stellen faltet, wo vermutlich gar kein Leerzeichen existiert. Vielleicht werfen die Programme, die X-Face: auswerten, Leerzeichen auch generell raus - keine Ahnung, worauf man sich da geeinigt hat. Es gibt nur eine RFC-konforme Möglichkeit, lange Strings ohne Leerzeichen trotzdem an Pos. 78 oder früher zu falten: Den Header MIME- codieren (notfalls mit Zeichensatz US-ASCII). Da Blanks zwischen encoded words beim Entfalten und Decodieren entfernt werden müssen, entstehen dann auch keine zusätzlichen und unerwünschten Leerzeichen. > Die würden dann exakt an der Stelle wieder gefoldet. Das würde > dann ja wohl klappen. Das ja. >> deshalb muß in uz-Richtung immer entfaltet werden. > Genau das ist der Punkt. Aber keiner, an dem wir irgendwas tun könnten oder müßten. Wenn der X-Face:-Header an den gefoldeten Stellen im Ursprungszustand (den wir ja nicht kennen) wirklich keine Leerzeichen enthielt, dann ist der Header so, wie wir ihn in der RFC-Nachricht sehen, bereits defekt, bevor der UUZ überhaupt erstmalig in uz-Richtung zum Zuge kommt. > Ob es dem "Antragsteller" nun um X-Face ging oder nicht, es schien > mir nur mal der Hinweis darauf passend, ob es überhaupt möglich ist, > den Original-Header wieder unversehrt zu versenden. Das ist absolut möglich und das kann der UUZ auch - nur kann und wird er keine bereits defekt gefalteten Header wieder reparieren. Dazu müßte er raten oder eine Glaskugel implementiert bekommen. ;) Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: UUZ: X/U-Header
Michael Heydekamp ([EMAIL PROTECTED]) schrieb: > Nochmal ganz klar, damit's da keine Mißverständnisse gibt: Das > Leerzeichen ist *nicht* zusätzlich, sondern es wird lediglich ein > bereits vorhandes Leerzeichen beim Entfalten nicht entfernt und es darf > auch nicht entfernt werden. Entfalten heißt nix weiter als LF|CRLF > entfernen. Ich habe nochmal in den RFCs nachgesehen, da steht klar folding WSP ist erforderlich. War mir mir bisher nicht so ganz klar, wozu eben auch die besagte gefoldete X-Face-Zeile beitrug. Ist aber deren Problem bzw. des Mailers, wenn die Leerzeichen da nicht reingehören. >> Ob es dem "Antragsteller" nun um X-Face ging oder nicht, es schien >> mir nur mal der Hinweis darauf passend, ob es überhaupt möglich ist, >> den Original-Header wieder unversehrt zu versenden. > Das ist absolut möglich und das kann der UUZ auch[...] Damit ist das klar. Danke. -- Salut _)oachim FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
