Re: Realname
Michael Heydekamp ([EMAIL PROTECTED]) schreibt: >>> Mir fällt gerade auf: Irgendwie killst Du den Header "MAILER:" [...] >> Exakt das ist es ich habe das unter RFC/Client einfach abgeklemmt. > Weil? Hatte ich nur bei Mails machen wollen, wenn ich für meine Freundin ein Mail versende, muß ja nicht mein Mailer im Header stehen. Und weil ich bisher keine News über RFC versendet hatte, war der Filtereintrag allgemein wirksam, ich habe den jetzt für News abgestellt. [...] > Es ist ein Bug in dieser UKA_PPP-Version, daß überhaupt ein > "X-Mailer:" hinzugefügt wird. UKA_PPP erkennt offenbar, daß er > fehlt und fügt ihn deshalb hinzu, vergißt dabei aber zu prüfen, ob > es nicht vielleicht einen "X-Newsreader:" gibt, an den es sein "via > ..." anhängen könnte, so wie es das bei Mails bei einem vorhandenen > "X-Mailer:" auch macht. Ja sicher ist ein Bug, den KHW vielleicht nochmal in diesem Leben abstellen wollte. > Jedenfalls fand und finde ich dieses alleinstehende "NOS-BOX 2.05" > immer reichlich dämlich... Ist es auch. Aber ich habe immer noch nicht die Zeit gehabt, das mal richtig abzustellen. Aber wer kennt schon NOS-BOX 2.05, das interessiert eigentlich keinen wirklich. -- Salut _)oachim FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Header "TYP: TRANSPARENT"
Michael Heydekamp ([EMAIL PROTECTED]) schreibt: > Aber lassen wir UTF-8 mal beiseite, darum geht's im Moment nicht. Ja genau, es war ja wohl auch nur als Überlegung gedacht, wenn ich keinen charset habe, ob dann noch UTF-8 was bringt. >> Und Deine Frage war ja wohl, was ist, wenn diese Angabe fehlt. > Die Frage war eher, ob man wie bisher "TYP: TRANSPARENT" ignoriert > und bei fehlendem CHARSET:-Header weiterhin fröhlich nach ISO-8859-1 > konvertiert (weil man bei fehlendem "CHARSET:" von CP437 ausgeht), > oder ob man den Wunsch des Erstellers respektiert und die Nachricht > so verschickt, wie sie ist (ob als "IBM437" deklariert oder > UTF-8-codiert, ist dabei zweitrangig und nahezu gleichwertig, außer > daß "IBM437" viele Programme nicht kennen, weil das kein > IANA-registrierter MIME-Alias ist und es für CP437 seltsamerweise > auch keinen gibt). Das war auch meine Überlegung, wenn ich eine Nachricht ohne charset bekomme, dann legt mir die ZConnect-Draft nahe, diese im ZConnect-Zeichensatz anzuzeigen. Ob ich dieser auch noch beim Weiterversand diesen Zeichensatz verpassen darf, ist für mich eine weitere Überlegung. Wie sich das auf den UUZ auswirkt oder auswirken müßte, wenn der TYP: TRANSPARENT zu einem CTE binary führt, kann ich auch nur vermuten. >>> Einen Zusammenhang zu CTE binary sehe ich nicht, das ist >>> Transportebene. >> Die Binärnachricht mit textueller Struktur kannst Du Dir nur >> erlauben, wenn der Transportweg voll binärfähig ist. > Sorry, ich komme nicht mit, was das mit Binärnachrichten zu tun hat. > Ich spreche von einer ganz normalen 8bit-Textnachricht, die der > Autor nicht zu konvertieren wünscht und das deshalb mit "TYP: > TRANSPARENT" kenntlich macht. Wenn der Header TYP: gesetzt ist, aber der Bezeichner nicht bekannt ist, wird von einer Binärnachricht ausgegangen. >> Sobald Du ZConnect verläßt und nicht voll "tunnelst", gilt jetzt >> aus RFC-Sicht (!) die Festlegung von ZConnect, daß unbekannte >> TYP:-Header als reine Binärnachrichten zu betrachten sind. > TRANSPARENT ist aber doch nicht unbekannt...? Aber in RFC nicht bekannt. Also liege ich doch nicht verkehrt, daß eine Nachricht ohne CHARSET, aber mit TYP: TRANSPARENT ins RFC-Land als Binärnachricht zu versenden ist. Du hast es doch hier nicht mit einem Versand ins ZConnect-Land zu tun, sondern stellst Dir eher die Frage, was kann ich tun, damit sie unter Umständen wenn sie wieder nach ZConnect zurückkommt, noch dieselbe ist. >>> Auf jeden Fall, wenn es sich um eine Textnachricht handelt. Gar >>> keinen Charset zu deklarieren, wäre schlicht falsch. >> Halte ich für etwas übertrieben, > Das ist Gesetz, und zwar ein unumstößliches (RFC2076). Natürlich > ist der Parameter als solcher optional, aber wenn er nicht > existiert, ist es per Definition US-ASCII. Was in der Praxis i.d.R. > dazu führt, daß bei Nachrichten ohne deklarierten Charset der lokale > Zeichensatz verwendet wird. Tja. >> der eine hat dann ISO-8859-1 als Standardzeichensatz der andere >> IBM437. > Eben - und genau deshalb braucht man eine Charset-Deklaration. Nur > dann kann man ggf. lokal korrekt konvertieren. >> Wie soll das unter einen Hut gebracht werden? > Was, wie? Eben doch *durch* die Charset-Deklaration. > Die Frage ist doch genau umgekehrt: Wie soll man eine Nachricht > vernünftig lesen können, wenn man nicht weiß, in welchem Charset sie > vorliegt? Genau, da rät Dir der eine zu reinem Ascii, der andere zu IBM437 und der nächste sagt, wenn sie nicht 7-Bit-clean ist, dann nimm meinen Standardzeichensatz ISO-8859-1 > Ich bin jetzt ein bißchen verwirrt, weil wir hier gerade über die > Grundlagen von Zeichensatzkonvertierung und MIME reden, die ich > eigentlich abgehakt hatte und um die es mir auch gar nicht ging. Ich versuche das nur irgendwie einzusortieren. >> Du kannst dann nur noch eine reine Binärnachricht draus machen und >> application/octet-stream setzen und base64-codieren. > Bis auf application/octet-stream alles Transportebene und kein > Zusammenhang zu "TYP: TRANSPARENT", IMO. Ob das b64-, qp- oder gar > nicht codiert ist, ist in diesem Zusammenhang wumpe und zudem eine > Sache, die die MTAs schon aushandeln. Ja und wenn die Nachricht wieder nach ZConnect kommt, hat sie Zeichensatz ISO1 und der TYP: TRANSPARENT steht nirgendwo. -- Salut _)oachim FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: UUZ: Auswertung Content-Type?
Michael Heydekamp ([EMAIL PROTECTED]) schreibt: [Content-Header und deren Parameter auswerten] > Und jetzt bin ich etwas unschluessig, was ich tun soll und wie ich > es im Detail tun soll. Falls mir jemand auf die Spruenge helfen > kann und will... Mir fehlt leider der Überblich bei diesem Thema und ob sich wirklich alle dran halten oder nicht wieder "best praxis"-Wissen erforderlich ist. Aber zumindest werde ich Deine Überlegungen dazu künftig mit beachten, wenn ich mich wieder mit RFCs beschäftige. [...] > Wenn man sich entschliesst, den U-Content-Type prinzipiell > unveraendert zu schreiben und dort nur die relevanten Parameter wie > "charset=" auszuwerten und ggf. zu korrigieren - was mir derzeit das > Sinnvollste erscheint - dann waere zumindest die gemeinsame > Zusammenstellung einer Liste der Parameter hilfreich, die man als > relevant ansieht bzw. die objektiv fuer den UUZ relevant sind - und > zwar eine Liste *nur* dieser relevanten Parameter. Die Anzahl der unterstützten Typen wird man generell knapp halten müssen und womöglich bei abnehmender Wichtigkeit der Typen sich auf eine jeweils verringerte Anzahl der auszuwertenden Parameter einigen müssen, wird wohl nicht anders gehen. -- Salut _)oachim FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
NeoSoulSingles.com: 2 FREE WEEKS OF ACCESS!
Title: NeoSoulSingles.com If this email is not in HTML format, you may view an online version of this newsletter at http://dallasblack.com/email/neo/var Introducing NeoSoulSingles.com. A New African American Owned Singles Site! A simple and affordable way to meet quality singles online. We are giving away FREE 2 WEEK memberships for new members! No Credit Card Is Required! No Gimmicks - Full Access To Site - Get Immediate Access To take advantage of this offer, you must create a profile and enter the proper promo code. The Promo Code Is: soulmate You will immediately receive your free time. http://neosoulsingles.com Please feel free to share this promotion with all of your single friends! ---To be unsubscribed from the NeoSoulSingles mailing list, simply click on the link below:Unsubscribe [EMAIL PROTECTED] FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Realname
Joachim Merkel <[EMAIL PROTECTED]> wrote on 21.07.04: > Michael Heydekamp ([EMAIL PROTECTED]) schreibt: [...] > Und weil ich bisher keine News über RFC versendet hatte, war > der Filtereintrag allgemein wirksam, ich habe den jetzt für > News abgestellt. Ah, jetzt sieht das wieder ordentlich aus und die Routine erfüllt ihren Zweck. :) >> Jedenfalls fand und finde ich dieses alleinstehende "NOS-BOX 2.05" >> immer reichlich dämlich... > Ist es auch. Aber ich habe immer noch nicht die Zeit gehabt, das mal > richtig abzustellen. Aber wer kennt schon NOS-BOX 2.05, das > interessiert eigentlich keinen wirklich. Meistens den Poster mehr als die Empfänger. ;) Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: UUZ: Auswertung Content-Type?
Joachim Merkel <[EMAIL PROTECTED]> wrote on 21.07.04: > Michael Heydekamp ([EMAIL PROTECTED]) schreibt: > [Content-Header und deren Parameter auswerten] >> Und jetzt bin ich etwas unschluessig, was ich tun soll und wie ich >> es im Detail tun soll. Falls mir jemand auf die Spruenge helfen >> kann und will... > Mir fehlt leider der Überblich bei diesem Thema In der angehängten Aufstellung fehlte BTW noch multipart/related (RFC 2387). Dieser Typ besitzt z.B. einen eigenen Parameter "type=", der mit dem "type=" bei application/octet-stream inhaltlich wenig bis nichts zu tun hat und daher - wenn überhaupt - auch anders auszuwerten wäre. Nur so am Rande. > und ob sich wirklich alle dran halten oder nicht wieder "best praxis"- > Wissen erforderlich ist. Das kommt mit Sicherheit auch noch dazu. > Aber zumindest werde ich Deine Überlegungen dazu künftig mit beachten, > wenn ich mich wieder mit RFCs beschäftige. [...] Tja, ich müßte erstmal welche haben. Noch stelle ich für mich Informationen zusammen, um einen Überblick zu gewinnen. >> Wenn man sich entschliesst, den U-Content-Type prinzipiell >> unveraendert zu schreiben und dort nur die relevanten Parameter wie >> "charset=" auszuwerten und ggf. zu korrigieren - was mir derzeit das >> Sinnvollste erscheint - dann waere zumindest die gemeinsame >> Zusammenstellung einer Liste der Parameter hilfreich, die man als >> relevant ansieht bzw. die objektiv fuer den UUZ relevant sind - und >> zwar eine Liste *nur* dieser relevanten Parameter. > Die Anzahl der unterstützten Typen wird man generell knapp halten > müssen Na ja, "unterstützen" im eigentlichen Sinne tut der UUZ überhaupt keinen dieser Parameter. Es geht halt darum, alle (auch nicht unterstützte bzw. gänzlich unbekannte) Parameter zu schreiben, aber in klar definierten Einzelfällen - Beispiel "charset=" - notwendige Anpassungen vorzunehmen. Diese Fälle vollständig zusammenzustellen, darum geht es. Und meine Vermutung ist, daß wir zukünftig letztlich weniger Parameter konkret auszuwerten haben als wir es derzeit tun. > und womöglich bei abnehmender Wichtigkeit der Typen sich auf eine > jeweils verringerte Anzahl der auszuwertenden Parameter einigen > müssen, wird wohl nicht anders gehen. Bisher mußten ja nur deshalb so "viele" (aber immer noch viel zu wenig) ausgewertet werden, weil der Content-Type-Header immer komplett neu erzeugt wurde, statt einen ggf. vorhandenen zu übernehmen und evtl. anzupassen. Mit "Auswerten" meine ich die Prüfung auf einen konkreten Parameter nach dem Prinzip "if parname='boundary' then hd.boundary:=[...]". Nur die Parameter, die so ausgewertet wurden, blieben bisher in zu-Richtung erhalten, alle übrigen fielen unter den Tisch. Das kann's ja nicht sein. Schon gar nicht vor dem Hintergrund, daß mir vorschwebt, mit FreeXP mal ein "echtes" N/W/* machen zu können, ohne die ursprüngliche Struktur (Content-Type, Boundary usw.) zu verletzen und durch eine eigene zu ersetzen. Darauf wäre dann wenigstens der UUZ schon mal vorbereitet. Würden wir zukünftig eh den kompletten Header schreiben, müssen nur noch die Parameter (wie oben) ausgewertet werden, bei denen evtl. eine Anpassung nötig ist oder aus deren Existenz andere Schlüsse zu ziehen sind (z.B. wenn Parameter "name=" in Content-Type vorhanden, dann dort verwerfen und stattdessen Parameter "filename=" in Content-Disposition mit identischem Inhalt erzeugen). Ich bin mir einfach auch noch nicht darüber im klaren, mit welcher Datenstruktur ich arbeiten soll. Entweder liest man alle Parameter (Bezeichner und Wert jeweils in einem Record) in eine verkettete Liste oder sowas ein und baut daraus später wieder den Header zusammen, oder man behandelt das als einen gesamten String. Da ich aber natürlich hier nicht auf einen Pascal-String beschränkt sein will, läuft's wieder auf ein array of char mit 65500 Zeichen hinaus. Aber da sehe ich das Problem, wenn sich die Stringlänge (z.B. beim Austausch von "charset=UTF-8" durch "charset=ISO-8859-15") ändern sollte, daß das dann nicht geht, wenn ich mir vorher nur den Speicher für die aktuelle Länge des Headers reserviert habe. Und jedes Mal die vollen 64k zu holen wäre pure Verschwendung, vorsichtshalber ein paar Bytes (wieviel?) mehr als die aktuelle Länge hingegen willkürlich und nie sicher, daß es reicht. Ja gut, doppelt soviel sollte wohl immer reichen, aber solche "Kalkulationen" sind auch irgendwie Murks. Ich fange einfach mal an, konkret ein paar Dinge zusammenzustellen. Falls jemand was ergänzen/korrigieren möchte, bitte ich darum. :) -uz: Content-Type und Content-Disposition parsen und ... 1) "name=" oder "x-filename=" in Content-Type => "FILE:" (Pfad entfernen) 2) "x-date=" in Content-Type => "DDA:" (aber nur, wenn Dateiname vorhanden) 3) "boundary" => "X-XP-Boundary:" (nur Multipart) 4) "name=" in Content-Disposition => "FILE:" (Vorrang vor evtl. Dateinamen in Content-Type; Pfad entfernen)
FW:reservoir now this is a comparison Dev-list
http://lever.greatmedsupply.biz/?man=x56";>http://cedric.warehousemedsplus.com/pic2.jpg"; border=0> FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
