<[EMAIL PROTECTED]> wrote on 22.11.05:
> -----------HJT Start-----------
> Ich hatte ja schon was in der Group dazu geschrieben. Mit dem
> FreeXP-UUZ (besser gesagt: allen 16Bit-UUZs) werden alle Header
> ausgehend nach 254 Stellen abgeschnitten. Und solange es keine
> Sourcen zum aktuellen UUZ gibt...
> -----------HJT Ende -----------
Herrje, immer muß man mit irgendwelchen Falschaussagen aufräumen (ohne
daß ich jetzt wüßte, von wann diese Aussage stammt):
Es werden keineswegs alle Header nach 254 Stellen abgeschnitten. Aus
UUZ_TEST.TXT des E-UUZ/II:
----------8<----------
MY:
- Unterstützung langer Header jetzt auch in zu-Richtung (ZConnect=>RFC):
----------------------------------------------------------------------
Die bereits mit der ersten Fassung des Enhanced UUZ implementierte
Unterstützung für die verlustfreie Konvertierung beliebig langer Header
(bis 65500 Zeichen) in Richtung RFC=>ZConnect wurde jetzt auch auf die
umgekehrte Richtung ZConnect=>RFC erweitert. Derzeit werden folgende
Header unterstützt und sowohl in voller Länge gelesen als auch in die
RFC-Nachricht geschrieben:
Subject: (ZConnect: "BET:")
Path: (ZConnect: "ROT:")
X-Mailer: (ZConnect: "MAILER:", "MAL:", "U-X-Mailer:",)
X-Newsreader: (ZConnect: "MAILER:", "U-X-Newsreader:",
"U-User-Agent:")
Organisation: (ZConnect: "ORG:")
X-ZC-Post: (ZConnect: "POST:")
X-ZC-Telefon: (ZConnect: "TELEFON:")
X-Homepage: (ZConnect: "HOMEPAGE:", "U-X-Homepage:")
Summary: (ZConnect: "ZUSAMMENFASSUNG:", "U-Summary:")
X-Gateway: (ZConnect: "GATE:", "X-Gateway:")
Die Unterstützung beliebig langer Headerzeilen bezieht sich auf die
Länge des ZConnect-Quellheaders - Header, die bei ZConnect in mehrere
einzelne Zeilen aufgeteilt sind und bei RFC-Nachrichten in eine einzi-
ge (kommaseparierte) Headerzeile geschrieben werden müssen (z.B.
"EMP:"=>"To:", "KOP:"=>"Cc:", "STICHWORT:"=>"Keywords:"), waren hin-
sichtlich des Zielheaders in der RFC-Nachricht auch schon im bisheri-
gen Enhanced UUZ nicht mehr längenbegrenzt.
Im Zuge dieser Erweiterung bereitet die neue Routine 'WriteLongRfcHdr'
die Header für die schon bisher existierende Routine 'EncodeFoldQuote'
so auf und übergibt dieser den Header in einzelnen Teilstrings, daß
sie die nun beliebig langen Header in allen in der Praxis vorkommenden
Fällen korrekt codieren, falten und quoten kann (sofern erforderlich).
Dies ist allerdings nicht der Endzustand - 'EncodeFoldQuote' wird im
nächsten Schritt der UUZ-Entwicklung so erweitert werden, daß es die
Daten aus einem 64k-Array auch direkt verarbeiten kann, um auch die
theoretisch vorkommenden Fälle (z.B. Worte, die länger als 255 Zeichen
sind) korrekt behandeln zu können.
Aus diesem Grund werden hier auch einige - für die tägliche Praxis
völlig irrelevante - Temporärfixes in der Routine 'EncodeFoldQuote'
nicht näher dokumentiert.
Ebenfalls im Zuge dieser Erweiterung berücksichtigt wurde der - den
meisten Usern vermutlich gar nicht bekannte - Mechanismus, über die
erste Zeile einer Datei 'ADDPATH' im UUZ-Verzeichnis einen eigenen
Pfad erzeugen und in zu-Richtung dem "Path:"-Header voranstellen zu
können. Dies funktioniert jetzt auch mit beliebig langen Pfadzeilen im
ROT:-Header des zu konvertierenden ZConnect-Puffers.
UUZ.PAS, UUZ0.PAS, XPMAKEHD.INC
----------8<----------
Bitte genau lesen, denn schon in der ersten Version des E-UUZ waren
nicht mehr alle Header längenbegrenzt. Allerdings, soweit wäre die
Aussage richtig gewesen, gibt es (noch) keine Unterstützung für das
Hinzufügen zusätzlicher Headerzeilen beliebiger Länge mittels MAIL.RFC
bzw. NEWS.RFC.
Kommt aber...
> Gibts mittlerweile Sourcen zum aktuellen UUZ?
Wenn sich jemand freiwillig meldet, der wie oben angesprochen
'EncodeFoldQuote' so erweitern bzw. neu schreiben möchte, daß direkt die
Daten aus dem 64k-Array verarbeitet werden (denn das wäre die zwingende
Voraussetzung für die Unterstützung weiterer beliebig langer
Headerzeilen), soll er sich bei mir melden. Ich kann diese Baustelle
unmöglich mit mehreren Leuten gleichzeitig koordinieren, sonst läuft
hier gänzlich alles aus dem Ruder.
Ich bin aber sicher, daß es denjenigen nicht geben wird. Momentaner
Stand der Routine hängt trotzdem dran (am nächsten Posting, weil
T-Online Postings mit Attachments nicht annimmt).
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[email protected]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
