+- UUZ_ENH.TXT ----------------------------------------------+
| |
| Vollständige Dokumentation aller Änderungen |
| des "Enhanced UUZ" seit dem 30.08.2003 |
| (c) 2003-2006 FreeXP <support@freexp.de> |
| 21.01.2006 |
+------------------------------------------------------------+
+-----------------------------------------------------+
| 28.09.2004-21.01.2006 (Release E-UUZ/II v3.40.2) |
+-----------------------------------------------------+
MY:
- Relevante Bugfixes (u.a. MIME-Decodierung, Speicherlecks, fehlerhafte
LEN:-Header), neue Importschnittstellen für "mbox"- und "raw"-Format,
bessere Absicherung gegen defekte RFC-Puffer, neue und erweiterte
Funktionen (u.a. Erzeugung des Headers "User-Agent:", Unterstützung
langer und gefalteter RFC-Headerzeilen in MAIL.RFC und NEWS.RFC, Para-
meterübergabe via UUZ.OPT).
========================================================================
MY:
- Fix (-uz): Logik-Bug in der MIME-Decodierung behoben
----------------------------------------------------------------------
In dem in der täglichen Praxis bisher nicht eingetretenen Fall, daß
bei zwei unmittelbar aufeinanderfolgenden 'encoded words' die Anzahl
der sich zwischen diesen 'encoded words' befindlichen (und daher zu
entfernenden) Leerzeichen größer/gleich der Anzahl der für die MIME-
Delimiter ("=?US-ASCII?Q?...?=") des ersten 'encoded word' verwendeten
Zeichen war, entstand ein Arithmetik-Überlauf, in dessen Folge es
nicht nur zu einem fehlerhaft decodierten Header, sondern zu allen
erdenklichen und unkalkulierbaren Folgen bis hin zu einer völlig
unbrauchbaren Nachricht oder gar einem (theoretischen, weil bisher
in der Praxis nicht vorgekommenem) Absturz kommen konnte.
Der Bug wurde vom Autor rein zufällig anläßlich eines von ihm selbst
zu Testzwecken im Bereich Headerfolding erstellten Postings entdeckt
(siehe Message-ID <9Ha5ICFQCHB@my.freexp.de> in der Newsgroup
de.comm.software.newsserver).
MIMEDEC.PAS
MY:
- Diverse Erweiterungen, Anpassungen und Korrekturen bei RFC-Headern,
die Datums-/Uhrzeit-/Zeitzonenangaben enthalten (-zu):
----------------------------------------------------------------------
1. Die Header "Date:", "Received:", "From_" (nur UUCP-Mails) und der
MIME-Parameter "modification-date=" enthalten neben Datum, Uhrzeit
und Zeitzone jetzt auch den Wochentag in dem in RFC2822 definierten
Format ("Mon, ", "Tue, " usw.).
2. Der "Date:"-Header wird nicht mehr als allererster Header, sondern
im Anschluß an den "Subject:"-Header geschrieben (Anpassung an
übliche Gepflogenheiten).
3. Die "From_"-Zeile von UUCP-Mails enthält nicht mehr Erstellungs-
datum und -uhrzeit der Nachricht im RFC-Format (wie es im "Date:"-
Header steht), sondern es wird eine Zeile mit dem *aktuellen*
Datum/Uhrzeit im sog. "asctime"-Format erzeugt:
------------------------------------------------------------------
- Bisher: From my 06 Oct 2004 19:08:33 +0200 remote from freexp.de
- Jetzt : From my Wed Oct 6 19:09:24 2004 remote from freexp.de
------------------------------------------------------------------
Das RFC-Format ist sowohl laut der Beispiele in RFC976 als auch in
der Praxis beim UUCP-Austausch an dieser Stelle zumindest unüblich,
möglicherweise sogar falsch.
Unklar (weil in RFC976 nicht geregelt) ist bisher, ob dort Lokal-
zeit oder UTC erwartet wird. Momentan verwendet der UUZ dort die
Lokalzeit, wie es auch aus einigen Praxisbeispielen ersichtlich
war.
4. Bei Headern, die Datum/Uhrzeit des Zeitpunkts der Konvertierung
enthalten ("Received:", "From_"-Zeile bei UUCP-Mails), wird die
Zeitzone nicht mehr blind aus dem Erstellungsdatum im EDA:-Header
der Nachricht übernommen, da dies im Fall, daß Erstellungs- und
Konvertierzeitpunkt in unterschiedlichen Zeitperioden liegen, zu
einer falsch deklarierten Zeitzone führen würde - bzw. in der
Vergangenheit auch konkret dazu geführt hat. (Beispiel: Nachricht
wird am Abend des letzten Tages der Sommerperiode erzeugt, aber
erst in der Nacht oder am nächsten Morgen konvertiert und
versandt.)
Stattdessen wird die aktuelle Zeitzone jetzt mit zwei alternativen
Methoden ermittelt:
a) Wenn die TZ-Variable - wie es im Normalbetrieb mit XP der Fall
ist - nicht (oder nicht im korrekten Format) gesetzt ist, ist
die im EDA:-Header deklarierte Zeitzone des Erstellungsdatums
zwar nach wie vor die entscheidende Grundlage, jedoch wird jetzt
zusätzlich geprüft, ob Erstellungs- und aktuelles Datum in der-
selben Zeitperiode liegen. Ist dies nicht der Fall, wird die
Zeitzone des aktuellen Datums aus der Zeitzone des Erstellungs-
datums errechnet, indem je nach Konstellation 1 Stunde addiert
(Winter => Sommer) bzw. subtrahiert (Sommer => Winter) wird.
Liegen Erstellungs- und aktuelles Datum in derselben Zeit-
periode, wird die Zeitzone wie bisher aus dem Erstellungsdatum
unverändert übernommen.
Maßgebend für die Definition der Zeitperiode ist ausschließlich
die aktuell für die EU geltende Regelung, deren Algorithmus auch
bei der automatischen Zeitzonenumstellung in FreeXP verwendet
wird. Die Angabe "S" bzw. "W" im ZConnect-Header ist unzuverläs-
sig und wird wie bisher ignoriert.
Das obige Verfahren funktioniert daher in allen Fällen zuverläs-
sig, in denen die Konvertierung in einem Land stattfindet, in
dem a) eine mit der in der EU geltenden Regelung identische
Winter-/Sommerzeitregelung angewandt wird, und b) dessen Zeit-
zone identisch ist mit dem Land, in dem die Nachricht erstellt
wurde (was nahezu immer der Fall sein dürfte). Mit anderen
Worten: Bisher stimmte die Zeitzonenangabe im geschilderten Fall
praktisch nie, jetzt stimmt sie praktisch immer.
b) Durch das Setzen der Umgebungsvariablen "TZ" im Format
-------------------------------------------------
set TZ=CET-1CEST,3,-1,0,7200,10,-1,0,10800,3600
-------------------------------------------------
kann das in a) beschriebene Verfahren neutralisiert werden;
stattdessen wird dann die in der TZ-Variablen deklarierte Zeit-
zone in jedem Fall und völlig unabhängig von der im EDA:-Header
deklarierten Zeitzone des Erstellungsdatums übernommen.
Das obige Beispiel gilt für Mitteleuropa und würde in der
Winterperiode die Zeitzone "+0100" (ZConnect: W+1) und in der
Sommerperiode die Zeitzone "+0200" (ZConnect: S+2) zurückgeben.
Für andere Länder sind die Werte entsprechend anzupassen, eine
ausführliche Erläuterung zur TZ-Variablen befindet sich in der
FreeXP-Hilfe zum Menüpunkt C/O/N/Umstellung.
Durch die Auswertung der TZ-Variablen ist der UUZ daher in der
Lage, in allen Ländern mit einer beliebigen (oder gar keiner)
Winter-/Sommerzeitregelung die korrekte Zeitzone des aktuellen
Datums zu deklarieren.
Zwingend erforderlich ist die Verwendung der TZ-Variablen im
Grunde dann, wenn der UUZ als Gate-Konvertierer eingesetzt wird:
Dort können Nachrichten aus beliebigen Zeitzonen vorkommen (aus
denen ohne TZ-Variable unterschiedliche lokale Zeitzonen berech-
net würden), während dem UUZ im Standardbetrieb mit XP nur Nach-
richten aus einer einzigen Zeitzone (nämlich der des Users)
vorgelegt werden.
5. Enthält der EDA:-Header keine Zeitzonenangabe, gelten automatisch
jetzt MEZ (=CET, =UTC+1, Winter) bzw. MESZ (=CEST, =UTC+2, Sommer)
als Defaultwerte, da die Angabe einer Zeitzone im "Date:"-Header
gemäß RFC2822 Pflicht ist und die bisherige Angabe von "?0000"
wegen des beliebigen zufallsabhängigen Zeichens als "Vorzeichen"
ungültig war.
6. Ist der EDA:-Header leer bzw. existiert überhaupt nicht, wird statt
eines ungültigen "Date:"-Headers mit dem Inhalt " Jan :: 0000"
jetzt ein gültiger Header mit dem aktuellen Datum/Uhrzeit und der
Zeitzone MEZ/MESZ im korrekten Format erzeugt (da der Header
Pflicht ist, war der totale Verzicht keine Option).
7. Bei der Datums-/Zeitangabe von Dateien (Quelle: DDA:-Header) im
MIME-Parameter "modification-date=" wird als Zeitzone nicht mehr
"+0000", sondern "-0000" deklariert. Das negative Vorzeichen signa-
lisiert gemäß RFC2822, daß keine Information über eine Zeitzone
vorliegt, während "+0000" signalisiert, daß es sich exakt um die
Zeitzone "UTC" handelt.
8. Bei allen anderen Zeitzonenangaben wird eine evtl. als "W-0" oder
"S-0" im EDA:-Header deklarierte Zeitzone zu "+0000" korrigiert und
konvertiert.
9. (Zu später) Y2K-Fix: Bei einer Nachricht, die am ersten Tag eines
neuen Jahrhunderts zu einer Uhrzeit erzeugt wurde, zu der das kor-
respondierende Datum in UTC-Zeitrechnung noch im alten Jahrhundert
lag (in unserer Zeitzone also am 01.01.2000 zwischen 00:00 und
00:59 Uhr, in Australien zwischen 00:00 und 11:59 Uhr), wurde bei
der Konvertierung - und zwar unabhängig davon, wann diese statt-
fand, also auch noch Tage oder Wochen später - fälschlicherweise
das Jahr "1900" statt "2000" deklariert, weil aus der den lokalen
Zeitstempel (und eine nur zweistellige Jahresangabe) enthaltenden
Variable 'hd.datum' das Jahrzehnt "00" und aus der den UTC-Zeit-
stempel (sowie ein vierstelliges Jahr) enthaltenden Variable
'hd.zdatum' das Jahrhundert übernommen und so zu "1900" zusammen-
gesetzt wurde. Dieser Fall wird jetzt korrekt behandelt, was sich
in der Praxis aber erst wieder in gut 94 Jahren positiv bemerkbar
machen wird, wenn der letzte noch aktive FreeXP-User kurz nach
Silvester tapfer seine Neujahrsgrüße verfaßt. ;-)
UUZ.PAS, UUZ0.PAS
MY:
- Änderung (-zu): Bei der ZC=>RFC-Konvertierung von Postings mit dem
Schalter "-client" (= NNTP-Betrieb) wird - sofern nicht durch die
Existenz der Datei 'ADDGATE' gleichzeitig ein Gatebetrieb signalisiert
wird - kein "Path:"-Header mehr erzeugt. Gründe:
1. Der Header wird von den großen Newsservern (news.t-online.de,
news.individual.de) ohnehin mit "not-for-mail" überschrieben und
ist i.d.R. schon von daher überflüssig. Manche Newsserver wie
news.individual.de "sichern" den ursprünglichen "Path:"-Header
dabei als "X-Orig-Path:" (siehe dazu auch Punkt 3.).
2. Es besteht beim clientseitigen Einliefern eines Postings beim
Newsserver keine technische Notwendigkeit für diesen Header; er
wird daher auch von keinem (dem Autor bekannten) Newsreader
generiert.
3. Der Header enthält die Mailadresse im Format "do.main!user". Usern,
die zum Zweck der Spam-Vermeidung ihre Absenderadresse bei Postings
mittels eines Ausgangsfilters ändern, wird i.d.R. nicht bewußt
sein, daß sie den ZConnect-Header ROT: ebenfalls anpassen müssten,
wenn sie über einen Server posten, der den "Path:"-Header nicht
überschreibt (wie z.B. news.freexp.de) oder der ihn zwar über-
schreibt, den ursprünglichen Header aber als "X-Orig-Path:"
sichert. Es würde daher unbewußt und ungewollt über den "Path:"-
Header eine Mailadresse preisgegeben werden, was mit dem Ändern der
Absenderadresse gerade vermieden werden sollte.
4. Beim Posten von vom UUZ erzeugten RFC-Postings in technische
Newsgroups kommt es seitens der Teilnehmer bisweilen zu Fehlinter-
pretationen und Mißverständnissen hinsichtlich des "Path:"-Headers
und infolgedessen zu Fragen an den User, die oft nicht (oder nicht
korrekt) beantwortet werden können.
UUCP-Postings sind von der Änderung nicht betroffen und enthalten wie
bisher einen "Path:"-Header in der bekannten Form.
UUZ.PAS
MY:
- Änderung (-zu): Bei der RFC=>ZC-Konvertierung von UUCP-Mails mit einer
mit dem String "From_" beginnenden ersten Zeile wird die Bildschirm-
ausgabe des Envelope-Absenders "from user@do.main" hinter dem Datei-
namen dann nicht mehr erzeugt, wenn ein solcher aus der "From_"-Zeile
gar nicht ermittelt werden konnte (bisher wurde in diesem Fall dennoch
"from_" ohne Adresse ausgegeben, was "broken" wirkte).
UUZ.PAS
MY:
- Interne Änderung: Anzahl der Zeichen, die sich nach dem Aufruf von
'ReadString' mindestens noch im Puffer befinden müssen, von 4 auf 5
erhöht (Vorbereitung für mbox-Unterstützung).
UUZ0.PAS
MY:
- Anpassungen und Korrekturen in der Routine 'ReadRFCheader' (auch im
Vorgriff auf mbox-Unterstützung, siehe nächster Abschnitt, -uz):
----------------------------------------------------------------------
1. Die Routine prüft jetzt - ähnlich wie bisher schon 'ReadRfcBody' -
bei der RFC=>ZC-Konvertierung von SMTP- und mbox-Mails anhand der
einschlägigen Merkmale (".", "From_") "vorausschauend" auf das Ende
der Nachricht. Wird festgestellt, daß die Mail in der nächsten
Zeile beendet ist (bzw. im Falle mbox, daß mit der nächsten Zeile
eine neue Mail beginnt), wird das Lesen des Headers abgebrochen.
2. Ungültige RFC-Headerzeilen mit einem Bezeichner, der Leerzeichen
oder andere ungültige Zeichen außerhalb des zulässigen Bereichs
33d-126d enthält, werden jetzt verworfen. Solche Header könnten
sonst dazu führen, daß der Puffer nicht verarbeitet werden kann.
Außerdem bestünde bei RFC-Puffern, die mehrere Nachrichten enthal-
ten, die Gefahr, daß z.B. die eine mbox-Nachricht einleitende
"From_"-Zeile mit einem RFC-Header verwechselt wird, weil sie oft
Doppelpunkte in einer Uhrzeitangabe enthält.
3. Nicht mehr verworfen hingegen werden Zeilen mit/ohne Leerzeichen
oder Doppelpunkten, die sich *nach* einer *unmittelbar* auf die
Schlüsselzeilen "DATA" (SMTP), "From_" (UUCP/mbox) oder "#! rnews"
(Newsbatch) folgenden Leerzeile befinden. Diese Zeilen werden jetzt
als Body betrachtet, obwohl (bzw. weil) eine so beschaffene Mail
per Definition gar keinen RFC-Header enthält. Es wird dann eine
Nachricht mit den (überwiegend leeren) ZConnect-Pflichtheadern und
einem Body erzeugt.
4. ASM-Routine 'LoZZ' entsorgt und durch 'LoString(zz)' ersetzt.
'LoZZ' konnte zu einem RTE 204 oder zu defekten Nachrichten führen,
wenn der übergebene String leer war (was z.B. vorkommt, wenn eine
Zeile im Header keinen Doppelpunkt - und also keinen Bezeichner -
enthält).
Alle beschriebenen Maßnahmen dienen dazu,
a) auch dann formal halbwegs korrekte und sauber lesbare Resultate zu
produzieren, wenn der zu konvertierende RFC-Puffer fehlerhaft ist
(ohne jegliche Header, mit oder ohne Body), statt wie bisher in
solchen Fällen zu mitunter (zufälligen) fatalen Folgen wie
Abstürzen, Endlosschleifen oder defekten ZConnect-Puffern zu
führen, und
b) Anfang und Ende jeder Nachricht in Puffern mit mehreren Nachrichten
unter allen (un)denkbaren Umständen sicher und korrekt zu erkennen,
auch wenn der Bereich zwischen den jeweiligen Schlüsselzeilen
("DATA" und "." beim SMTP-, mit "From_" beginnende Zeilen beim
UUCP/mbox- und "#! rnews" beim Newsbatch-Format) nicht den erwarte-
ten standardkonformen (oder auch gar keinen) Inhalt hat. Damit
werden jetzt z.B. auch bei einem BSMTP-Puffer wie ...
----------------------------
HELO freexp.de
MAIL FROM:<theo@tester.de>
RCPT TO:<my@freexp.de>
DATA
.
MAIL FROM:<theo@tester.de>
RCPT TO:<my@freexp.de>
DATA
.
QUIT
----------------------------
... trotz des Fehlens aller Header und des Body zwei (natürlich
leere) Nachrichten erzeugt. Ein mbox-Puffer wie ...
---------------------------------
From - Sun Sep 26 08:04:46 2004
From - Mon Sep 27 09:05:47 2004
From - Tue Sep 28 10:06:48 2004
---------------------------------
... wird zu drei (ebenfalls leeren) Nachrichten konvertiert.
Im Zusammenhang mit der neu implementierten mbox-Unterstützung war ein
Teil dieser Maßnahmen ohnehin schlicht notwendig, da mbox-Mails anders
als (B)SMTP-Mails kein definiertes Ende (sondern nur einen definierten
Anfang) haben.
UUZ.PAS, UUZ0.PAS
MY:
- Neue Importschnittstelle "mbox" implementiert (-uz):
----------------------------------------------------------------------
1. Der Enhanced UUZ/II unterstützt neben UUCP- und (B)SMTP-Mails jetzt
auch Mailpuffer im mbox-Format. Damit können mbox-Puffer, die von
den meisten Mailreadern beim Export erzeugt werden und beliebig
viele Nachrichten enthalten können, in das ZConnect-Format konver-
tiert und anschließend nach XP importiert werden. Das erleichtert
den Datenaustausch mit diesen Programmen erheblich und es lassen
sich damit auch Mailinglistenarchive, die im mbox-Format zum Down-
load angeboten werden (z.B. Pipermail), komfortabel konvertieren.
2. Von den insgesamt vier existierenden mbox-Formaten werden die
beiden gängigsten explizit unterstützt:
-----------------------------------------
- mboxo (irreversibles ">From_ quoting")
- mboxrd (reversibles ">From_ quoting")
-----------------------------------------
Da der Anfang jeder mbox-Mail ausschließlich an einer mit "From_"
(wobei der Unterstrich für ein Leerzeichen steht) beginnenden Zeile
zu erkennen ist, wird beim mbox-Format allen Zeilen in Header und
Body, die ebenfalls mit "From_" beginnen, das Quotezeichen ">"
vorangestellt, damit diese nicht mit dem Beginn einer neuen Mail
verwechselt werden können.
Bei einer Konvertierung sind diese Quotezeichen daher wieder zu
entfernen. Der Unterschied beider Formate liegt darin, daß bei
"mboxo" nur mit "From_" beginnenden Zeilen ein ">" vorangestellt
wird, während dies bei "mboxrd" auch bei den Zeilen geschieht, die
vor dem "From_" bereits eine beliebige Anzahl von Quotezeichen
(ohne jedes Leerzeichen dazwischen!) besitzen.
Entsprechend unterschiedlich ist beim Ent-Quoten zu verfahren:
-------------------------------------------------------------------
- mboxo: Das ">From_ quoting" des mboxo-Formates ist nicht voll-
ständig reversibel, weil Zeilen, die schon von vornehe-
rein mit ">From_" beginnen, nicht von denen zu unter-
scheiden sind, die mit "From_" begannen und erst beim
Schreiben des Formats mit einem Quotezeichen versehen
wurden. Es kann also bei mboxo-Mails im Unterschied zum
mboxrd-Format im Einzelfall vorkommen, daß Quotezeichen
vor Zeilen entfernt werden, bei denen sie eigentlich
nicht hätten entfernt werden sollen. Dies ist prinzip-
bedingt nicht zu vermeiden.
- mboxrd: Die meisten Mailreader dürften allerdings inzwischen das
mboxrd-Format verwenden. Dort existiert dieses Problem
nicht, weil eine ursprünglich mit ">From_" beginnende
Zeile beim Schreiben des mbox-Puffers zu ">>From_" umge-
wandelt (und vom UUZ wieder zu ">From_" zurückgewandelt)
wird. Da sich beim mboxrd-Format theoretisch beliebig
viele ">" vor einer mit "From_" beginnenden Zeile befin-
den können, wird auch der Fall abgefangen, daß die Anzahl
der ">" größer ist als die maximale Länge eines Pascal-
Strings. Auch wenn dem String "From_" z.B. 741 Quote-
zeichen ">" vorangehen sollten und/oder sich die String-
grenze mitten in einem "From_" befindet, wird dies
korrekt erkannt und genau ein ">" entfernt.
-------------------------------------------------------------------
Leider geben die meisten Programme keinerlei Auskunft darüber,
welches mbox-Format sie unterstützen bzw. generieren, so daß im
Zweifel nur Ausprobieren (d.h. gezielter Export von Testmails, die
entsprechende Zeilen enthalten) hilft.
Wem das zu aufwendig ist oder wer keine Möglichkeit dazu hat,
sollte vom mboxo-Format als kleinstem gemeinsamen Nenner ausgehen.
3. Da auch der Anfang einer UUCP-Mail an einer mit "From_" beginnenden
Zeile zu erkennen ist, gibt es leider keine Möglichkeit, UUCP-Mails
programmseitig sicher und zuverlässig von mbox-Mailpuffern zu
unterscheiden. Zwar können sich nie mehrere UUCP-Mails in einer
Datei befinden und es findet dort auch kein ">From_ quoting" statt,
aber weder muß ein mbox-Mailpuffer mehrere Mails enthalten noch ist
die Existenz von weiteren mit "From_" beginnenden Zeilen nach der
einleitenden "From_"-Zeile garantiert (sondern man kann eher meist
vom Gegenteil ausgehen). Eine Erkennung über den in der ersten
"From_"-Zeile von UUCP-Mails meistens vorkommenden String "remote
from" ist nicht zuverlässig genug, außerdem läge selbst dann immer
noch keine Information darüber vor, *welches* mbox-Format konver-
tiert werden soll.
Es war daher nicht zu vermeiden, für die jeweiligen mbox-Formate
eigene Kommandozeilenparameter zur Verfügung zu stellen und die
Verantwortung für deren korrekte Verwendung dem User aufzuerlegen:
-----------------------------------------------------------------
- Parameter "-mboxo" für das mboxo-Format;
- Parameter "-mboxrd" bzw. schlicht "-mbox" (weil Quasi-Standard)
für das mboxrd-Format.
-----------------------------------------------------------------
Bei beiden Formaten wird als Netztyp "41" (= RFC/Client) in den
XP-Header "X-XP-NTP:" geschrieben. Der Dateiname ist wie bei allen
anderen Nachrichtenformaten beliebig.
4. Die letzte Leerzeile am Ende einer mbox-Mail wird entfernt, da sie
beim Schreiben des mbox-Mailpuffers zusätzlich erzeugt wurde (bzw.
erzeugt worden sein sollte - das Format sieht vor, daß sich vor
jeder eine Mail einleitenden "From_"-Zeile eine Leerzeile befindet,
worauf sich der E-UUZ/II aber hinsichtlich der Erkennung des
Anfangs einer Mail nicht verläßt).
5. Infolge der im vorherigen Abschnitt beschriebenen Anpassungen in
der Routine 'ReadRFCheader' sowie der prinzipiellen Gleichbehand-
lung von (B)SMTP- und mbox-Nachrichten beim Lesen des Body in der
Routine 'ReadRfcBody' ist gewährleistet, daß alle in diesem
Dokument an anderer Stelle ausführlich beschriebenen Fixes und
Korrekturen für die Decodierung und Konvertierung von qp/base64-
und/oder UTF-7/8-codierten Nachrichten (Stichworte 'start_of_UTF',
'end_of_UTF' und 'maxUTFLen') in gleicher Weise auch für Mails im
mbox-Format gelten und dort greifen.
6. Eine Envelope-From-Adresse in der "From_"-Zeile wird erkannt und in
den WAB:-Header übernommen. (Dazu wird die im Zuge dieser Änderun-
gen ebenfalls deutlich verbesserte Routine 'mailstring' aus
XPOVL.PAS verwendet, die jetzt auch Kommentare, quoted-strings,
quoted-pairs und Domain-Literale gemäß RFC2822 unterstützt).
7. Die Formate "mboxcl" und "mboxcl2", die sich von den obigen durch
die Existenz eines Content-Length-Headers unterscheiden, werden
zwar nicht explizit unterstützt, können aber - mit geringfügigen
Einschränkungen - dennoch mit der vorliegenden Fassung des E-UUZ/II
konvertiert werden (bei beiden Formaten ist *ausschließlich* der
Parameter "-mboxo" zu verwenden!):
-------------------------------------------------------------------
- mboxcl: Verwendet dasselbe irreversible ">From_ quoting" wie das
mboxo-Format und daher gelten hierfür auch dieselben
Hinweise. Obwohl der Content-Length-Header vom UUZ nicht
ausgewertet wird, sollte die Konvertierung ansonsten
genauso fehlerfrei sein wie beim mboxo-Format.
- mboxcl2: Verwendet (leider) gar kein ">From_ quoting" und verläßt
sich stattdessen ganz auf die - wenn man den verwendeten
Quellen glauben darf, allerdings unzuverlässige -
Größenangabe im Content-Length-Header. Es kann daher
passieren, daß bei der Konvertierung fälschlicherweise
der Beginn einer neuen Nachricht erkannt wird, wenn im
Body eine mit "From_" beginnende Zeile vorkommen sollte.
Sorry, nicht zu vermeiden - allerdings wird das Format
zum Glück auch selten bis gar nicht verwendet.
-------------------------------------------------------------------
Der Aufwand für eine "richtige" Unterstützung für diese seltenen
mbox-Formate wäre momentan nicht zu rechtfertigen.
8. Die mbox-Unterstützung wurde mit großer Sorgfalt entwickelt und
so intensiv wie möglich getestet. Zum Abschluß wurde ein mbox-
Puffer mit über 23.000 Mails fehlerfrei konvertiert. :-)
Des weiteren wurde sichergestellt, daß die vorgenommenen Änderungen
im Source nicht zu neuen Problemen bei der Konvertierung "normaler"
Mails und Postings in den schon bisher unterstützten Formaten
führen können.
9. Quellen, die für die Entwicklung der mbox-Unterstützung als Grund-
lage dienten:
http://www.qmail.org/qmail-manual-html/man5/mbox.html
http://homepages.tesco.net/~J.deBoynePollard/FGA/mail-mbox-formats.html
UUZ.PAS, UUZ0.PAS
MY:
- Fix (-uz): Bei RFC-Puffern > 16384 Zeichen konnte es um diese Position
herum (oder einem ganzzahligen Vielfachen davon) zum Überschreiben
bzw. Überlagern von (und damit zur Ausgabe falscher) Zeichen kommen,
wenn folgende Randbedingungen erfüllt waren:
a) Die Routine 'ReadString' befand sich weniger als die Anzahl der
Zeichen (bisher 4, jetzt 5), die sich nach ihrem Aufruf mindestens
noch im Lesepuffer befinden müssen, vor dem absoluten Pufferende
(=> 'add2buf' wird aufgerufen, liest bis zu 4 nächste Zeichen ein
und stellt den gesamten Restpuffer von 5 Zeichen an den Anfang des
Arrays);
b) In diesem Restpuffer befindet sich ein Zeilenende (=> 'add2buf'
liest nach dem Zeilenende ein weiteres Mal bis zu 4 fehlende
Zeichen ein, ohne daß zwischenzeitlich die Prozedur 'reload'
durchlaufen wurde, die den Lesepuffer vollständig bzw. bis zum
Dateiende gefüllt hätte).
Beim zweiten Durchlauf von 'add2buf' im Fall b) konnte die im Fall a)
unkritische Reihenfolge der Anweisungen (blockread() -> fastmove() ->
move()) zum Überschreiben/Überlagern von Zeichen im Lesepuffer führen.
Je nach Position der Zeilenenden im Puffer konnte zudem ein falscher
LEN:-Header die Folge sein. Reihenfolge der Anweisungen korrigiert in
move() -> blockread() -> fastmove().
Das beschriebene Problem konnte nur in den Testversionen v3.40.1a/b
auftreten, weil erst dort die Routine implementiert wurde, die sicher-
stellt, daß sich immer eine bestimmte Mindestanzahl von Zeichen im
Lesepuffer befindet.
UUZ0.PAS
MY:
- Diverse Fixes beim Parsen von Mail-Adressen (-uz):
----------------------------------------------------------------------
1. Bei einer RFC2822-konform gestalteten Adresse wie
-------------------------------------------------------------------
"Maikel \"Tank, the Hatchet\" Lehr" <send_me_spam@shadowport.net>
-------------------------------------------------------------------
wurde der Realname dann nicht korrekt behandelt, wenn sie die erste
in einem Header vorkommende Adresse war (inhaltlich sinnloser Test
auf eine zumal zu diesem Zeitpunkt nicht initialisierte Variable,
der zur Nichtbeachtung der quoted-pairs und damit zur Fehlinterpre-
tation des Komma-Delimiters führte).
2. Bei Group-Adressierung wie
-----------------------------------------------------------------
Group1: <my@freexp.de>, <mw@freexp.de>; Group2: <theo@test.de>;
-----------------------------------------------------------------
wird bei der Suche nach dem die Group abschließenden Semikolon
jetzt berücksichtigt, ob es sich inmitten eines Kommentars, quoted-
strings oder einer Adresse befindet (bisher wäre in einem solchen
Fall das Semikolon fälschlicherweise für den Abschluß der Group
gehalten worden). Anschließend werden die Group-Adressen ein
zweites Mail durchlaufen, um evtl. vorhandene RFC822-Route-Adressen
wie
-------------------------------------------------
<@machine1.tld,@machine2.tld: mary@example.net>
-------------------------------------------------
zu entfernen.
3. Logikfehler beim Ermitteln und Entfernen von RFC822-Route-Adressen
beseitigt: Statt nach dem Entfernen die Position zurückzusetzen und
den Header ab der korrekten Position weiterzulesen, wurde die
Schleife überflüssigerweise an einer zu späten Position fortgesetzt
(kein sichtbarer Bug hierzu bekannt).
MIMEDEC.PAS
MY:
- Speicherlecks und benachbarte Bugs im Zusammenhang mit der
Konvertierung von "Received:"- in ROT:-Header beseitigt (-uz):
----------------------------------------------------------------------
1. Wenn beim Zusammenbau des ROT:-Headers aus den in den "Received:"-
Headern einer Mail eingetragenen Mailservern die resultierende
Gesamtlänge des ROT:-Headers größer als die max. Stringlänge wurde,
wurde ein "langer" Header im dafür vorgesehenen char-Array angelegt
und der dafür notwendige Speicher reserviert. Wenn sich anschlies-
send aber herausstellte, daß der hinter dem Schlüsselwort "by "
eingetragene Server bereits identisch mit dem letzten Eintrag im
ROT:-Header ist und daher gar nicht übernommen werden soll/darf,
wurde jedoch nicht der ursprünglich reservierte Speicher freigege-
ben, sondern ein um die Stringlänge+1 des hinter "by " stehenden
Mailservers reduzierter Wert. Darüber hinaus wurde in diesem Fall
das char-Array für den langen Header evtl. unnötigerweise angelegt,
denn der hinter dem Schlüsselwort "from " stehende Server hätte
alleine meistens noch in den String gepaßt.
Durch diese fehlerhafte Vorgehensweise fragmentierte der zur Verfü-
gung stehende Hauptspeicher und es kam bei der Konvertierung extrem
großer Mailpuffer (= mehrere tausend Nachrichten) zu einem kontinu-
ierlichen Speicherverlust, der in einen RTE 203 (Heap-Überlauf)
münden konnte, wenn der Mailpuffer entsprechend viele solcher Nach-
richten enthielt, auf die dieselben Randbedingungen zutrafen. Der
Bug wirkte sich bisher nur in reinen Testumgebungen aus, da im
Normalbetrieb mit XP weder die Menge der Nachrichten noch die
durchschnittliche Anzahl der "Received:"-Header pro Mail erreicht
wird, um zu diesem Resultat führen zu können.
2. Wenn der String eines hinter dem Schlüsselwort "by " im
"Received:"-Header eingetragenen Mailservers identisch war mit dem
rechten Teil des aktuell letzten (und gleichzeitig längeren)
Eintrags im ROT:-Header, dann wurde dieser Server fälschlicherweise
als vermeintlicher Dupe verworfen. Beispiel:
-------------------------------------------------------------------
Aktuell letzter Eintrag in ROT: sf-list2.mail.sourceforge.net
Eintrag hinter "by " in "Received": mail.sourceforge.net
-------------------------------------------------------------------
In diesem Fall fehlte der zweite Mailserver anschließend im ROT:-
Header (Uralt-Bug in allen UUZ-Versionen). Es werden jetzt nur noch
die Mailserver als Dupe verworfen, die auch wirklich welche sind.
3. Der hinter "from " eingetragene Server wird wegen real vorkommender
Header wie
-------------------------------------------------------------------
Received: from kboks.kruemel.org (kboks.kruemel.org [192.168.1.1])
by kboks.kruemel.org (Weasel v1.73) for [...]
-------------------------------------------------------------------
jetzt ebenfalls einem Dupecheck gegen den im selben Header befind-
lichen und hinter "by " stehenden Server unterzogen. Bisher wurde
in einem solchen Fall der Server doppelt in den ROT:-Header über-
nommen.
4. Wegen ebenfalls real vorkommender Header wie
-------------------------------------------------------------------
Received: from by localhost (amavisd-new, port ) id XXO6TU4B for
-------------------------------------------------------------------
werden vermeintlich hinter dem Schlüsselwort "from " stehende Server
mit dem Namen "by" verworfen.
5. Wenn bei real vorkommenden Headern wie
-------------------------------------------------------------------
Received: from ruby ( [217.118.66.232])
by mx.gmail.com with ESMTP id c28sm204201nfb.2005.10.28.11.42.41;
Fri, 28 Oct 2005 11:42:52 -0700 (PDT)
-------------------------------------------------------------------
der rechte Teil des Servernamens hinter dem Schlüsselwort "from "
(in diesem Fall "ruby") zufällig identisch war mit dem Schlüssel-
wort "by ", dann wurde nicht der hinter "by " stehende Server in
den ROT:-Header übernommen, sondern das Schlüsselwort "by" als
vermeintlicher Server selbst (bzw. es würde aufgrund der unter 4.
beschriebenen Änderung jetzt verworfen werden). Es wird jetzt
geprüft, ob sich das Schlüsselwort ganz am Anfang des Headers oder
anderenfalls ein Leerzeichen davor befindet. Falls nicht, wird die
Suche nach dem Schlüsselwort hinter der ersten Fundstelle fort-
gesetzt und so der in diesem Beispiel bisher fehlende Server
"mx.gmail.com" korrekt in den ROT:-Header aufgenommen.
6. In der Routine 'GetReceived', in der dieser Zusammenbau des ROT:-
Headers stattfindet, wurde bei der Prüfung, ob der resultierende
Header noch in einen Pascal-String paßt oder bereits ein char-Array
für einen langen Header angelegt werden muß, auf einen zu hohen
(253 statt 248 Zeichen) geprüft, weil die Länge des Bezeichners
"ROT: " nicht berücksichtigt wurde. Dies konnte bei ROT:-Headern,
deren resultierende Gesamtlänge (ohne Bezeichner) zwischen 249 und
253 Zeichen lag, zu einem Zeichenverlust am Ende des Headers führen
(der Verlust trat jedoch dann nicht ein, wenn die Routine im Falle
des unter Punkt 1. beschriebenen Szenarios unnötigerweise bereits
ein char-Array angelegt hatte).
7. Befand sich nach dem letzten "Received:"-Header der Nachricht noch
ein "Path:"-Header (kommt z.B. bei in Mailinglisten gegatete
Postings aus Newsgroups vor, siehe FreeXP-Supportforen), dann wurde
der vorher aus diesen "Received:"-Headern gebildete ROT:-Header
durch den Pfad im "Path:"-Header komplett überschrieben.
Befand sich der "Path:"-Header vor oder inmitten der "Received:"-
Header, wurden die Mailserver in den vor dem "Path:"-Header
befindlichen "Received:"-Headern unterschlagen und die Mailserver
in allen folgenden "Received:"-Headern an den "Path:"-Header
angehängt und in den resultierenden ROT:-Header übernommen.
Da dieses Verhalten weder bei Mail noch bei News wünschenswert und
korrekt ist, wird jetzt wie folgt verfahren:
- Bei Mails wird ein "Path:"-Header hinsichtlich des ROT:-Headers
jetzt grundsätzlich ignoriert (dafür im Unterschied zu früher
aber als "U-Path:" in den ZConnect-Header geschrieben).
- Analog werden bei News jetzt "Received:"-Header hinsichtlich des
ROT:-Headers ignoriert (und wie schon bisher als "U-Received:" in
den ZConnect-Header geschrieben).
8. Im Zuge dieser Fixes wurde die Routine komplett neugeschrieben und
verarbeitet jetzt direkt die Daten aus dem char-Array 'HdrLine',
statt wie bisher sowohl jeden "Received:"-Header selbst als auch
jeden aus einem "Received:"-Header herausoperierten Mailserver in
einem String zwischenzulagern. Dadurch sind jetzt folgende
Beschränkungen aufgehoben, die trotz der Unterstützung eines
beliebig langen ROT:-Headers und des Schreibens des originalen
"Received:"-Headers als "U-Received:" in ebenfalls beliebiger Länge
immer noch bestanden:
- Es würden jetzt auch Mailserver korrekt ausgewertet werden, die
sich jenseits des 253. Zeichens im "Received:"-Header befinden.
- Die Länge des Namens eines Mailservers ist nicht mehr auf 255
Zeichen begrenzt.
Zugegebenermaßen ist dies nicht sonderlich praxisrelevant, jeden-
falls konnte bei Testpuffern mit insgesamt über 3.000 Mails kein
Fall festgestellt werden, in dem sich das ausgewirkt hätte.
9. Zum Zweck der einfacheren Auswertung/Verarbeitung von Strings in
char-Arrays (auch in anderen Routinen) neue Hilfsroutine
'posLong()' implementiert, mit der sich Existenz und Position eines
Strings in einem char-Array vom Typ 'LongHdrP' (bzw. einem Teil
davon) ermitteln läßt.
UUZ.PAS, MIMEDEC.PAS
MY:
- Speicherleck beseitigt (-uz): Wenn die im "Followup-To:"-Header einge-
tragene Newsgroup identisch mit der Newsgroup im "Newsgroups:"-Header
war, dann wurde zwar wie beabsichtigt kein überflüssiger ZC-Header
Diskussion-in: erzeugt, gleichzeitig aber auch der für diesen Header
reservierte Speicher nicht wieder freigegeben. Ähnlich wie bei dem in
Punkt 1. des vorstehenden Abschnitts beschriebenen Szenario hätte dies
in Extremfällen zu einem kontinuierlichen Speicherverlust mit
anschließendem RTE 203 führen können (dazu hätte der Newspuffer je
nach Länge des Namens der Newsgroup und dem beim Start des E-UUZ zur
Verfügung stehenden Hauptspeichers ca. 150 Postings enthalten müssen,
auf die diese Randbedingung zutrifft).
UUZ.PAS, UUZ0.PAS
MY:
- Interne Änderung (-uz): Das via 'allocMem' in einem Dummy-Array reser-
vierte Speicherminimum für lange ZC-Header wird jetzt nach der Konver-
tierung jeder Nachricht komplett freigegeben und vollständig neu
reserviert (statt nur für die Header den Speicher neu zu reservieren,
die in der vorherigen Nachricht vorkamen). Dies dient der Vermeidung
einer theoretisch möglichen Fragmentierung des Hauptspeichers.
Des weiteren prüft 'allocMem' jetzt zusätzlich auf die Verfügbarkeit
des Speichers für das anschließend anzulegende char-Array 'HdrLine',
in das jede RFC-Headerzeile eingelesen wird, und bricht im Falle, daß
dieser Speicher nicht verfügbar ist, die Verarbeitung kontrolliert ab
(dieser Fall kann nur bei Programmstart oder neuen bzw. bisher nicht
entdeckten Speicherlecks eintreten).
UUZ.PAS, UUZ0.PAS
MY:
- Interne Änderung (-uz): Bei allen Prüfungen auf verfügbaren Haupt-
speicher via 'MaxAvail', bei denen mittels Addition auf mehrere
Elemente gleichzeitig geprüft, anschließend der Hauptspeicher aber
für jedes Element einzeln angefordert wird, wird mittels der neuen
Subroutine 'GetMemAmount' vor der Addition der tatsächlich von BP
angeforderte Speicher (der immer ein Vielfaches von 8 beträgt) berech-
net. Theoretisch hätte es sonst passieren können, daß die Prüfung auf
den verfügbaren Speicher positiv ausfällt, der angeforderte Speicher
anschließend aber gar nicht zur Verfügung steht. Beispiel: Bei 16
verfügbaren Bytes wäre eine Prüfung auf 3+4+8=15 Bytes positiv
ausgefallen. Angefordert worden wären aber anschließend 8+8+8=24
Bytes.
UUZ.PAS, UUZ0.PAS
MY:
- Fehlerlog für Speicherlecks implementiert (-uz): Der E-UUZ/II prüft
jetzt vor und nach der Konvertierung jeder einzelnen Nachricht die
Menge des verfügbaren Hauptspeichers ('maxavail' und 'memavail') und
erzeugt im Falle von Differenzen einen Eintrag in der Fehlerlogdatei
UUZ_ERR.LOG (unter Angabe der MsgID der diesen Fehler auslösenden
Nachricht). An eine ggf. bereits existierende Logdatei wird immer
angehängt. Seit den oben beschrieben Fixes konnte bisher jedoch kein
Fehlerlog mehr gesichtet werden. :)
UUZ.PAS, UUZ0.PAS
MY:
- Angabe problematischer Dateinamen für Quell- und Zieldatei abgefangen
(-uz/-zu): Sämtliche Dateinamen, die UUZ-intern eine spezielle Bedeu-
tung haben und von ihm ausgelesen, benutzt oder selbst erzeugt werden,
sind jetzt nicht mehr als Name einer Quell- oder Zieldatei zulässig.
Dies sind:
--------------------------------------------------------------------
UUZ.SWP, UUZ.TMP, UUZ.OPT, UUZ_ERR.LOG, MAIL.RFC, NEWS.RFC, ADDPATH,
ADDGATE, XP_NTVDM.DLL
--------------------------------------------------------------------
Bisher wurde z.B. bei Angabe von MAIL.RFC als Quelldatei versucht, aus
dieser Datei die zusätzlichen Header auszulesen, die in zu-Richtung in
die RFC-Nachricht geschrieben werden sollen. Bei Angabe von MAIL.RFC
als Zieldatei wurde eine diese RFC-Header enthaltende Datei umbenannt
bzw. gar gelöscht.
Die Routine prüft nur auf den reinen Kommandozeilen-String und läßt
sich durch Angabe eines absoluten oder relativen Pfades vor dem
Dateinamen gewaltsam austricksen. Ein höherer Aufwand wäre an dieser
Stelle nicht gerechtfertigt, weil hier nur versehentliche Fehler im
Test- oder Externbetrieb abgefangen werden sollen, die im Normalbe-
trieb mit FreeXP oder XP2 ohnehin nicht auftreten können.
UUZ0.PAS
MY:
- Interne Änderung (-uz): Die Dateien MAIL.RFC, NEWS.RFC und ADDPATH,
die die in zu-Richtung zusätzlich in die RFC-Nachricht zu schreibenden
Header bzw. einen voranzustellenden Pfad enthalten, werden in
uz-Richtung jetzt nicht mehr überflüssigerweise eingelesen bzw.
geprüft.
UUZ0.PAS
MY:
- Optik-Fixes (-uz): Bei der Konvertierung großer RFC-Puffer mit mehr
als 99.999 Nachrichten versagte die Anzeige der Anzahl der aktuell
konvertierten Nachrichten und der Bildschirm wurde mit Zeichenmüll
gefüllt. Anzeige von bisher fünf- auf jetzt sechsstellige Zahlenwerte
ausgelegt (max. 10 Stellen wären möglich, sieht aber auch blöd aus).
Bei der Ausgabe der Gesamtanzahl der konvertierten Mails und News am
Ende der Verarbeitung ist die Stellenanzahl nicht mehr ein fester Wert
von 5, sondern richtet sich nach dem höheren der beiden Werte (dadurch
werden sowohl größere Werte korrekt dar- als auch keine überflüssigen
Leerzeichen mehr vorangestellt).
UUZ.PAS
MY:
- Optik-Fix (-zu): Anzeige der aktuellen und gesamten Anzahl von News
und Mails rechtsbündig ausgerichtet und auf 6 Stellen ausgelegt.
UUZ.PAS
MY:
- Fixes und Erweiterungen bei der Verarbeitung zusätzlicher
RFC-Headerzeilen in den Dateien MAIL.RFC und NEWS.RFC (-zu):
----------------------------------------------------------------------
Bei der Verarbeitung der in den Dateien MAIL.RFC und NEWS.RFC
enthaltenen und zusätzlich in die RFC-Nachricht zu schreibenden
Headerzeilen bestanden bisher folgende Beschränkungen bzw. Probleme:
- Die Zeilen durften nicht länger als 253 Zeichen sein (längere Zeilen
wurden abgeschnitten).
- Gefaltete (d.h. mit einem Leer- oder TAB-Zeichen beginnende) Header-
zeilen wurden, wenn sie nicht zufällig bis Pos. 3 einen Doppelpunkt
enthielten, nicht unterstützt, sondern als "Illegal Line" betrachtet
und die Verarbeitung der Datei wurde komplett abgebrochen.
- Andererseits fand nur eine völlig unzureichende Prüfung auf gültige
RFC-Headerzeilen statt (Doppelpunkt bis Pos. 3 war ausreichend, um
eine Headerzeile als gültig zu betrachten).
- Es konnten max. 10 Headerzeilen verarbeitet werden.
Alle diese Beschränkungen/Probleme bestehen nicht mehr. :-) Es werden
jetzt beliebig lange und auch gefoldete Headerzeilen unterstützt,
wobei hinsichtlich der Gültigkeit einer RFC-Headerzeile folgende
Regeln gemäß RFC2822 gelten:
- Die Headerzeile darf nicht länger als 998 Zeichen sein (längere
Zeilen müssen gefoldet werden).
- Auf die für Mails empfohlene max. Zeilenlänge von 78 Zeichen wird
nicht geprüft (weil eben "nur" empfohlen).
- Der Bezeichner ('field name') und der Inhalt ('field body') des
Headers dürfen nur zulässige Zeichen enthalten (d.h. insbesondere
keine 8bit-Zeichen, aber es gelten je nach Kontext weitere und
unterschiedliche Beschränkungen).
- Der Inhalt einer Headerzeile ('field body') darf weder leer sein
noch nur aus Leer- oder TAB-Zeichen bestehen.
- Die Gültigkeit einer evtl. vorhandenen MIME-Codierung wird nicht
überprüft und liegt in der Verantwortung des Users.
- Die Routine verarbeitet sowohl Dateien mit CRLF- als auch solche mit
LF-Zeilenenden.
- Die Anzahl der Headerzeilen in MAIL/NEWS.RFC ist nicht mehr be-
grenzt. Die einzige Beschränkung, die im Sinne der Vermeidung
übertrieben großer RFC-Header besteht, ist die Gesamtgröße der Datei
(max. 65500 Bytes, was für einen RFC-Header eindeutig schon zuviel
wäre).
- Evtl. vorhandene Leerzeilen werden nicht als ungültig zurückgewie-
sen, beim Schreiben der Header aber ignoriert (eine Leerzeile leitet
per Definition den Body der Nachricht ein).
Wird in der Datei eine ungültige Zeile festgestellt, wird die gesamte
Datei wie bisher nicht verarbeitet. Wurden alle Zeilen als gültig
erkannt, werden sie "as is" geschrieben (d.h. keiner weiteren Ver-
arbeitung wie MIME-Codierung o.ä. unterzogen), außer daß ein evtl.
versehentlich vorangestelltes Prefix "U-" entfernt wird. Die zusätz-
lichen Headerzeilen werden jetzt an einer früheren Stelle geschrieben
(vor "X-RFC-Converter:" statt wie bisher hinter "Lines:").
Soll ein RFC-Header MIME-codiert und/oder gefoldet werden, läßt sich
der E-UUZ dafür als Tool einsetzen:
a) Dummy-ZC-Puffer erstellen,
b) gewünschten Headerinhalt in die BET:-Zeile schreiben,
c) ZC-Puffer mit "uuz -zu -client <Quelldatei> .\" konvertieren,
d) Inhalt des "Subject:"-Headers aus der erzeugten Datei (*.OUT) in
den eigenen Header übernehmen.
Da für Mail und News unterschiedliche Regeln hinsichtlich des Foldens
gelten, ist dabei darauf zu achten, daß der ZC-Puffer einen passenden
Empfänger (Mailadresse oder Newsgroup) enthält. Wenn der Bezeichner
('field name') des eigenen Headers in MAIL.RFC kürzer oder länger als
"Subject:" ist, ist das Folding ggf. manuell anzupassen und dabei auf
korrekte Zeilenlängen zu achten (max. 78, wenn die Zeile kein 'encoded
word' enthält, max. 76, wenn sie eines enthält). Sofern es sich bei
dem eigenen Header um einen strukturierten Header handelt, der Mail-
adressen o.ä. enthält, darf nicht die BET:-Zeile, sondern müssen z.B.
EMP: oder KOP: für die Erstellung eines RFC-konformen Headers heran-
gezogen werden.
UUZ.PAS, UUZ0.PAS
MY:
- Workaround Für VSoup-Software-Header analog zum schon seit längerem
existierenden Workaround für UKA_PPP-Software-Header, weitere Details
siehe dort (-uz):
VSoup fügt dem vom UUZ erzeugten Software-Header zusätzlich den Header
"User-Agent:" hinzu, so daß bei der uz-Konvertierung der Inhalt des
die XP-Version enthaltenden Headers meist überschrieben wurde (es sei
denn, auf dem Transportweg wurde die Reihenfolge der Header verändert,
dann wurde u.U. der VSoup-Header überschrieben).
Der Inhalt des VSoup-Headers wird jetzt mit "via" an den XP-Header
angehängt, unabhängig von der Reihenfolge des Auftretens. Dieser
Workaround unterstützt *keine* beliebig langen Zeilen. Sollte die
Zeile durch die Stringaddition länger werden als ein Pascal-String,
wird der VSoup-Header verworfen.
UUZ.PAS
MY:
- Software-Header "User-Agent:" implementiert (-zu):
----------------------------------------------------------------------
Statt der experimentellen Software-Header "X-Newsreader:" (News) und
"X-Mailer:" (Mails) erzeugt der E-UUZ/II für fast alle Inkarnationen
von ZConnect-MAILER:-Headern der unter der "alten" SLizenz weiterent-
wickelten CrossPoint-Versionen jetzt den längst zum Quasi-Standard
gewordenen RFC-Header "User-Agent:", wie er im USEFOR-Draft (Nachfol-
geentwurf zu RFC1036) beschrieben und definiert ist. Die Syntax des
Headers ist an die dort niedergelegten Regeln gebunden und er kann
daher nicht völlig wahlfrei gestaltet werden. Der vom E-UUZ/II gene-
rierte "User-Agent:"-Header hat für alle Inkarnationen/XP-Versionen
die folgende einheitliche Form:
------------------------------------------------------------------------
<XP> (CrossPoint)/<ver> ["<nick>"] ([<R>;] [<cOS>/<rOS> <ovr>;] [<dat>])
------------------------------------------------------------------------
Die eckigen Klammern zeigen an, daß die Angabe optional ist bzw. nicht
in allen MAILER:-Headern zwingend vorkommen muß, die in "<>" einge-
schlossenen Platzhalter haben folgende Bedeutung:
----------------------------------------------------------------------
<XP> : Der Name des weiterentwickelten XP-Derivats, also "OpenXP",
"OpenXP/16", "XP2", "FreeXP" usw. Es werden alle beliebigen
Namen unterstützt außer denen, die unzulässige Zeichen enthal-
ten (wobei unzulässige Schrägstriche wie bei "OpenXP/16" auto-
matisch entfernt werden), sowie "UKAW" und "Agent", die
erkennbar keine XP-Versionen sind, als "CrossPoint/UKAW" und
"CrossPoint/Agent" real aber vorkommen.
<ver> : Die Versionsnummer (v3.31.006, v3.40 usw.) ohne "v" und ggf.
mit der durch einen Bindestrich angehängten "Statusbezeich-
nung" wie "alpha", "beta", "RC3" usw.
<nick>: Der "Rufname" (z.B. "Halloween") einer Version. Klammerzusätze
bei älteren XP2-Versionen wie "(www.xp2.de)" sind keine
Rufnamen, daher werden bei allen XP-Versionen außer FreeXP nur
die Begriffe als Rufnamen gewertet, die innerhalb der Klam-
mern zusätzlich in Anführungszeichen eingeschlossen sind. Bei
FreeXP gelten alle in Klammern eingeschlossenen Strings außer
"(XMS)" und "(EMS)" als Rufnamen, etwaig fehlende Anführungs-
zeichen werden ergänzt.
<R> : Die Registrierungsnummer (z.B. "R/C816" oder auch "R/Free").
Org- und Kom-Registrierungen werden berücksichtigt.
<cOS> : Die Betriebssystemplattform, für die die jeweilige XP-Version
compiliert wurde (z.B. "DOS16" oder "W32"). Bei XP2-Versionen
wird diese immer aus dem MAILER:-Header ausgelesen (wobei
Schrägstriche entfernt werden), bei OpenXP und OpenXP/16 wird
sie im Falle der Versionen v3.2x-v3.4x sowie bei FreeXP immer
fest mit "DOS16" definiert. Bei allen anderen (bisher unbe-
kannten) XP-Derivaten würde die Angabe weggelassen werden.
<rOS> : Die Kurzbezeichnung der Betriebssystemplattform bzw. -version,
unter der XP bzw. der UUZ aktuell läuft. Diese wird vom UUZ
zur Laufzeit ermittelt, unterstützt werden dabei DOS, Win3.x,
Win95/98/Me, WinNT/2K/2K3/XP/Vista, Linux/DOSEMU und DOSBox.
WinNT, Win2K(3), WinXP und WinVista können nur voneinander
unterschieden werden, wenn die XP_NTVDM.DLL von FreeXP im UUZ-
Verzeichnis liegt, anderenfalls würden sie als "WinNT" zusam-
mengefaßt werden. Darüber hinausgehende Informationen über die
OS-Version (wie z.B. die unter X/S/S angezeigte Build-/Revisi-
onsnummer) werden im "User-Agent:"-Header nicht ausgegeben.
Bei nativen XP2-Compilaten für die Plattform Linux (so es
solche jemals geben sollte, in den Quelltexten ist sie jeden-
falls vorgesehen) würde die Angabe weggelassen werden, da ein
solches Compilat ohnehin nur unter dieser Plattform lauffähig,
sie daher redundant (weil bereits in <cOS> enthalten) und der
E-UUZ/II auch gar nicht in der Lage wäre, die genaue Linux-
Distribution und -Version zu ermitteln.
<ovr> : Angabe, ob der Overlay-Cache im EMS oder im XMS angelegt
wurde (kann derzeit nur bei OpenXP/16 und FreeXP vorkommen).
Der String wird immer in eckige Klammern eingeschlossen, es
sei denn, es liegen weder eine Registrierungsnummer noch ein
Compilierdatum noch weitere betriebssystemspezifische Angaben
vor.
<dat> : Datums- und Zeitstempel, an dem die Version compiliert wurde
(üblicherweise hinter einem "@" stehend, kann derzeit nur bei
OpenXP, OpenXP/16 und FreeXP vorkommen).
----------------------------------------------------------------------
Typische "User-Agent:"-Header für FreeXP und XP2 würden also wie folgt
aussehen können (Compilierdatum wegen der Zeilenlänge hier unterschla-
gen):
----------------------------------------------------------------------
User-Agent: FreeXP (CrossPoint)/3.40-RC3 (R/C816; DOS16/Win98 [XMS])
User-Agent: XP2 (CrossPoint)/3.31.006-Beta (R/C816; DOS16/WinXP)
----------------------------------------------------------------------
Weiterführende und ergänzende Anmerkungen/Hinweise zum "User-Agent:"-
Header:
1. Er wird nur bei den zur CrossPoint-Familie gehörenden XP-Versionen
(= alte SLizenz) erzeugt, und dort nur bei denen (das sind aller-
dings die weitaus meisten), deren MAILER:-Header mit
"CrossPoint/<XP>" oder
"CrossPoint [<XP>]" beginnen, oder die mit
"CrossPoint " beginnen und auf " (www.xp2.de)" enden
(ältere XP2-Versionen haben sich seltsamer-
weise nicht mit "XP2" zu erkennen gegeben,
sondern durch die Angabe des URL am Ende des
Headers).
Von OpenXP-Versionen (GPL) erzeugte MAILER:-Header, die nicht wie
oben beschrieben gestaltet sind, würden also z.B. nicht angetastet
(und die von allen anderen Programmen erzeugten Header sowieso
nicht).
2. Selbst wenn die unter 1. genannten Voraussetzungen vorliegen, wird
dennoch kein "User-Agent:"-Header erzeugt, falls
a) der ursprüngliche MAILER:-Header länger als 255 Zeichen ist,
oder
b) der resultierende "User-Agent:"-Header länger als 254 Zeichen
werden würde, wobei Informationen über Betriebssystemplattfor-
men, die nicht Bestandteil des originalen MAILER:-Headers sind,
bei der Berechnung unberücksichtigt bleiben und daher ggf. unter
den Tisch fallen würden, oder
c) durch die Existenz einer nicht-leeren Textdatei ADDGATE ein
Gatebetrieb signalisiert wird (Ausnahme siehe Punkt 3.).
In diesen Fällen wird der MAILER:-Header wie bisher unverändert und
in voller Länge nach "X-Mailer:" bzw. "X-Newsreader:" übernommen.
Der Aufwand, in den Fällen a) und b) auch längere Header zu unter-
stützen, ist angesichts der gänzlich fehlenden Praxisrelevanz zu
hoch.
3. Im Falle einer Konvertierung in uz- und unmittelbar anschließend
wieder in zu-Richtung erkennt die Routine, ob es sich bereits um
einen von ihr selbst im USEFOR-konformen Format generierten
XP-Header handelt, übernimmt in diesem Sonderfall den Inhalt unver-
ändert und stellt ihm den Headernamen "User-Agent:" voran. Dies
gilt auch für den Gatebetrieb.
Bei von allen anderen Programmen und XP-Versionen erzeugten Headern
wird wie bisher "X-Mailer:" bzw. "X-Newsreader:" erzeugt, weil
diese nicht an eine bestimmte Syntax gebunden sind und der UUZ
nicht die Syntax der von anderen Programmen erzeugten Header prüfen
kann und will. Anderenfalls würde u.U. der Originalinhalt der von
Fremdprogrammen erzeugten Header verändert werden (müssen).
4. Die oben beschriebene Gestaltung (erst der Name des XP-Derivats,
dann "CrossPoint" in Klammern, dann Versionsnummer) war deshalb
notwendig, weil zum einen nicht direkt an einen Kommentar
(= Klammerzusatz) angrenzende Leerzeichen sowie ausgerechnet die
von fast allen XP-Versionen verwendeten Zeichen "[", "]" und "/" im
"User-Agent:"-Header außerhalb eines Kommentars unzulässig sind
bzw. eine spezielle Bedeutung haben (hinter "/" steht per Defini-
tion immer die Versionsnummer). Zum anderen ist nur so gewährlei-
stet, daß die jeweiligen XP-Derivate in Newsreader-Statistiken auch
unter ihrem eigenen "Produktnamen" (statt alle gemeinsam unter
"CrossPoint") aufgeführt und dabei gleichzeitig die Auflagen der
alten SLizenz hinsichtlich der Namensgebung des Programms beachtet
werden.
Die Gestaltung des Headers ist bereits am 02.01.2006 rein vorsorg-
lich mit dem Lizenzgeber Peter Mandrella einvernehmlich abgestimmt
worden.
5. Die Routine berücksichtigt (soweit bekannt) Sonderfälle wie die
"DOSBOX-Edition" von FreeXP, die nicht durch allgemeingültige
Routinen zu behandeln waren. Bei der Ermittlung des Rufnamens, der
Versionsnummer und der "Statusbezeichnungen" werden wegen früherer
etwas unglücklich gestalteter Header wie
--------------------------------------------------------
MAILER: CrossPoint/OpenXP v3.40myRC3@0601021904 R/C816
--------------------------------------------------------
Heuristiken angewendet, die bei allen bisher bekannten und geteste-
ten Inkarnationen von MAILER:-Headern einwandfrei funktionieren
(und auch bei schrägen Testkonstrukten, die real bisher so nicht
vorgekommen sind). Auch seltene (aber real vorkommende) Anhängsel
wie bei
--------------------------------------------------------------------
MAILER: CrossPoint [OpenXP/16] v3.40 RC3 @ 2804022000 R/C816- CS R
--------------------------------------------------------------------
bringen die Routine nicht ins Schleudern. Die Reihenfolge der
einzelnen Elemente im Header spielt (nahezu) keine Rolle, vom
Bereich Versionsnummer/Statusbezeichnung mal abgesehen.
Soweit die MAILER:-Header dem von der jeweiligen XP-Version erzeug-
ten Originalformat entsprechen, erfolgt die Umwandlung in das
USEFOR-konforme Format verlustfrei. Benutzerspezifische Ergänzungen
und Veränderungen werden, soweit sie die Struktur des Headers nicht
bis zur Unkenntlichkeit zerstört haben, ebenfalls berücksichtigt
(ein "CrossPoint/MeinXP R/C816 V6 v3.31.90rcRC 1" würde vollstän-
dig und korrekt als "MeinXP (CrossPoint)/3.31.90rc-RC1 (R/C816)" in
den "User-Agent:"-Header übernommen werden).
6. Als Begriffe für "Statusbezeichnungen" werden - in beliebiger
Schreibweise - unterstützt: "alpha", "beta", "Pre", "RCn" (weitere
sind bisher nicht gesichtet worden).
7. Die Gestaltung des "User-Agent:"-Headers kann benutzerseitig durch
folgende UUZ-Kommandozeilenparameter beeinflußt werden:
-------------------------------------------------------------------
"-OSfamily": Statt der verwendeten Version des Betriebssystems
("DOS-6.22", "Win98", "WinXP") wird nur die Familie
ausgegeben, zu der das Betriebssystem gehört ("DOS",
"Win9x", WinNT"). Nur wirksam, wenn weder "-privacy"
noch "-noUAgent" angegeben wurden.
"-privacy" : Sämtliche Informationen über das Betriebssystem (dazu
gehören alle der weiter oben beschriebenen Platzhalter
<cOS>, <rOS> und <ovr>) werden unterdrückt, selbst
wenn sie bereits Bestandteil des originalen MAILER:-
Headers waren. Nur wirksam, wenn "-noUAgent" nicht
angegeben wurde.
"-noUAgent": Es wird kein "User-Agent:"-Header erzeugt, der Inhalt
des MAILER:-Headers wird wie bisher unverändert und
ungekürzt nach "X-Mailer:" bzw. "X-Newsreader:" über-
nommen.
-------------------------------------------------------------------
Um Kommandozeilenparameter des UUZ auch dann nutzen zu können, wenn
die jeweilige XP-Version keine entsprechenden Dialogoptionen zur
Verfügung stellt, können diese jetzt über die Parameterdatei
UUZ.OPT übergeben werden, mehr dazu im übernächsten Abschnitt.
8. Sofern nach den obigen Regeln ein "User-Agent:"-Header erzeugt
wird, wird bei Mails gleichzeitig eine Kurzform davon (ohne sämt-
liche Kommentare, d.h. alle in Klammern stehenden Zusätze) für den
vom UUZ ebenfalls erzeugten "Received:"-Header verwendet. Bisher
wurde immer der komplette String aus den im Laufe der Jahre immer
umfangreicher gewordenen MAILER:-Headern in den "Received:"-Header
übernommen, jetzt würde die verschlankte Fassung z.B. so aussehen
(Datum wegen Zeilenlänge gekürzt):
--------------------------------------------------------------------
Received: by freexp.de (FreeXP/3.40-RC3); 25 Dec 2005 18:07:15 +0100
--------------------------------------------------------------------
Informationen wie Rufnamen, Betriebssystem, Compilierdatum u.ä.
sind in einem reinen Transport-Header wie "Received:" schlicht
überflüssig und unangebracht.
----------------------------------------------------------------------
9. WICHTIGER Hinweis für alle Benutzer von UKAW und UKAD:
UKAW/UKAD verändern in allen Versionen der letzten Jahre (seit
v2.43/v1.65 von April 2001) die Software-Header ("X-Newsreader:",
"X-Mailer:", "User-Agent:") aller ausgehenden Nachrichten, um sich
dort mit dem Zusatz "/Agent" selbst zu verewigen und Anhängsel wie
"via NNTP" oder "via BSMTP" zu erzeugen. Davon abgesehen, daß dies
für sich schon eine kaum zu tolerierende Unsitte ist, ignorieren
UKAW/UKAD im Falle "User-Agent:" dabei, daß der Header nicht völlig
wahlfrei gestaltet werden kann und produzieren dadurch Header in
einer ungültigen Syntax, die nicht mit der Spezifikation im USEFOR-
Draft konform ist. Im Falle der hier beschriebenen Form des "User-
Agent:"-Headers unterschlagen sie dabei zusätzlich nahezu alle im
originalen Header enthaltenen Informationen und verstümmeln ihn
(offenbar mangels eines tauglichen Parsers) zu:
-------------------------------------------------
User-Agent: CrossPoint/Agent [FreeXP], via NNTP
-------------------------------------------------
Abgesehen von der ungültigen Syntax sind also Versionsnummer,
Registrierungsnummer, sämtliche betriebssystemspezifischen Infor-
mationen und das Compilierdatum vernichtet worden. Stattdessen
definiert sich "Agent" als die Versionsnummer von CrossPoint. Wer
UKAW/UKAD in einer dieser Versionen zusammen mit dem E-UUZ/II von
FreeXP einsetzt, *muß* daher handeln, um keine ungültigen Software-
Header zu erzeugen.
FreeXP hat - ursprünglich aus ganz anderem Anlaß - bereits im Juni
2005 ein Patch-Tool zur Verfügung gestellt, mit dem sich alle
bekannten und aktuell im Einsatz befindlichen UKAW-Versionen so
patchen lassen, daß u.a. Software-Header generell nicht mehr
verändert werden. Als (unbeabsichtigter) Nebeneffekt werden auch
die von UKAW bisher zusätzlich erzeugten Header "X-Nntp-Client:"
und "X-BSmtp-Client:" nicht mehr erzeugt. Mit demselben Tool läßt
sich der Patch auch wieder rückgängig machen, Weitere Details siehe
in UKAWP.TXT (wie das Patchtool UKAWP.EXE selbst Bestandteil des
Archivs, in dem auch diese Dokumentation liegt). Das Tool ist
separat zum Download verfügbar unter:
-----------------------------------------------
ftp://ftp.freexp.de/freexp/clients/ukawp.zip
http://www.freexp.de/freexp/clients/ukawp.zip
-----------------------------------------------
Nicht der Spezifikation entsprechende "User-Agent:"-Header werden
von Dritten (aus verständlicher Unkenntnis heraus, aber dennoch
unberechtigt) sicher nicht UKAW, sondern primär der verwendeten
XP-Version, sekundär evtl. auch dem E-UUZ/II, angelastet werden,
obwohl diese daran völlig unschuldig sind. Nicht nur deshalb sollte
der Patch bei Einsatz des E-UUZ/II von FreeXP unbedingt angewendet
werden.
Im Interesse sauberer, von unnötigem Ballast befreiter und unverän-
derter Header ist der Einsatz des Patch-Tools aber auch dann sinn-
voll und empfehlenswert, wenn ein anderer UUZ als der E-UUZ/II von
FreeXP eingesetzt wird, der keinen "User-Agent:"-Header erzeugt.
Außerdem wird er auch noch wegen eines kapitalen Bugs in UKAW v3.50
und UKAD v2.50 benötigt, mehr dazu im nächsten Abschnitt.
----------------------------------------------------------------------
UUZ.PAS, UUZ0.PAS
MY:
- Änderung (-zu): Header "X-XP-Version:" wird nicht mehr in allen Fällen
erzeugt und kann nun auch komplett deaktiviert werden
----------------------------------------------------------------------
Der vom E-UUZ erzeugte Header "X-XP-Version:" ist ein Workaround für
das oben beschriebene Verhalten von UKAW/UKAD, die Software-Header zu
verändern. Er wird jetzt nur noch dann erzeugt, wenn der Name des
Programms den String "CrossPoint" in beliebiger Schreibweise enthält
(war im Falle einer unmittelbar aufeinanderfolgenden uz- und zu-Kon-
vertierung bei von anderen Programmen als XP erzeugten Nachrichten
schlicht unzutreffend...).
Mit dem Kommandozeilenparameter "-noXPver" läßt er sich nun auch
komplett deaktivieren. Im Falle der Anwendung des oben beschriebenen
Patch-Tools ist er überflüssig und die Deaktivierung in diesem Fall
daher auch die unbedingt empfohlene Verfahrensweise.
In folgenden Fällen sollte er jedoch aktiviert bleiben:
a) Es wird UKAW bis v2.95 oder UKAD bis v1.95 in ungepatchter Fassung
eingesetzt und der Header "User-Agent:" ist mit dem Schalter
"-noUAgent" deaktiviert worden (UKAW/UKAD verändern in diesen
Versionen nur Nachrichten mit den Headern "X-Newsreader:" oder
"X-Mailer:").
b) Es wird UKAW v3.00-v3.38 oder UKAD v2.00-v2.38 in ungepatchter
Fassung eingesetzt (UKAW/UKAD verändern in diesen Versionen alle
Software-Header).
Unbedingt und in jedem Fall deaktiviert werden sollte er allerdings
beim Einsatz von UKAW v3.50 bzw. UKAD v2.50, auch wenn die Version
ungepatcht ist. Während der Testphase zum oben beschriebenen Header
"User-Agent:" hat sich nämlich ein kritischer Bug in diesen Versionen
herausgestellt, der dazu führen kann, daß ausgehend wie eingehend
Header zerstört und Nachrichten deshalb z.B. nicht mehr korrekt
decodiert werden können. Dies hängt mit dem destruktiven Bemühen von
UKAW/UKAD, alle mit "X-XP-" und "X-RFC-" beginnenden Header zu
vernichten (was auf die vom E-UUZ erzeugten Header "X-XP-Version:" und
"X-RFC-Converter:" abzielt) sowie der dabei völlig fehlenden Berück-
sichtigung gefalteter Headerzeilen zusammen. Weitere Details dazu
siehe UKAWP.TXT.
Alles in allem sollte man schon aufgrund dieses Bugs in UKAW/UKAD die
Versionen v3.50 (UKAW) bzw. v2.50 (UKAD) gar nicht in ungepatchtem
Zustand betreiben. Dann werden die besagten Header nicht mehr entfernt
und es kann daher auch nicht zu den erwähnten Folgen kommen. Da aber
gleichzeitig auch keine Software-Header mehr verändert werden, sollte
dann natürlich "X-XP-Version:" ebenfalls deaktiviert werden.
UUZ.PAS, UUZ0.PAS
MY:
- Parameterdatei UUZ.OPT implementiert (-uz/-zu):
----------------------------------------------------------------------
Über die Parameterdatei UUZ.OPT können dem UUZ jetzt Kommandozeilen-
optionen übergeben werden. Dies ist sinnvoll (und im Zusammenhang mit
den neuen Optionen zum "User-Agent:"-Header sogar notwendig), wenn die
jeweilige XP-Version keine Möglichkeit vorsieht, die gewünschten
Optionen per Konfigurationsdialog im Programm zu setzen, oder wenn
aufgrund der Länge der verwendeten Pfad- und Dateinamen die Gesamt-
länge der Kommandozeile an die Grenzen stößt, die das jeweilige
Betriebssystem vorgibt.
Beim Anlegen von UUZ.OPT sind folgende Regeln zu beachten:
1. Die Datei muß im UUZ-Verzeichnis (i.d.R. identisch mit dem
XP-Verzeichnis) liegen.
2. Die Datei wird vor den auf der Kommandozeile angegebenen Parametern
ausgewertet. Dadurch haben direkt auf der Kommandozeile angegebene
Parameter Priorität. Da Kommandozeilenparameter aber nicht umkehr-
bar sind, wäre dies im Moment nur für die Optionen
-mbox[o|rd]
-bBoxname
-uUser
relevant, weil nur hier ein auf der Kommandozeile angegebener Wert
einen ggf. davon abweichend in UUZ.OPT gesetzten Wert überschreiben
würde.
3. Die Datei muß pro Zeile genau einen Parameter enthalten. Die Optio-
nen sind genauso einzutragen wie auf der Kommandozeile (d.h. mit
führendem "-").
4. Es werden nur mit einem führenden "-" versehene Parameter (im UUZ-
Jargon "Switches") ausgewertet. D.h., es können keine Datei- und
Verzeichnisnamen, Sites, Domains etc. übergeben werden. Der Grund
liegt darin, daß dann eine bestimmte Reihenfolge beim Vornehmen der
Einträge in UUZ.OPT einzuhalten gewesen wäre, unterschiedliche
Bereiche für uz- und zu-Konvertierung (Sections) in UUZ.OPT vorge-
sehen und ausgewertet sowie außerdem die Einträge in UUZ.OPT mit
den Optionen auf der Kommandozeile "irgendwie" zu einem sinnvollen
Ganzen hätten verschmolzen werden müssen.
5. Die Parameter "-uz" und "-zu" (also die Konvertierungsrichtung)
können nur über die Kommandozeile gesetzt werden.
6. Bei den Parametern
-client
-LFN
-xp2
kann optional durch Voranstellen von "uz:" bzw. "zu:" definiert
werden, für welche Konvertierungsrichtung die Option gelten soll.
Alle übrigen Parameter werden automatisch nur für die Richtung
ausgewertet, für die sie gültig sind, ein etwaiges "uz:" oder "zu:"
vor diesen Optionen wird ignoriert.
7. Leerzeilen und nicht den obigen Regeln entsprechende Einträge in
UUZ.OPT werden ohne Fehlermeldung ignoriert.
8. Die via UUZ.OPT übergebenen Parameter gelten naturgemäß global,
box-spezifische Differenzierungen sind daher nicht möglich.
9. Die Verwendung von Umgebungsvariablen ist nicht möglich.
MY:
- Interne Änderung: Das via 'InitWinVersion' reservierte Handle für die
XP_NTVDM.DLL wird jetzt via 'DestructWinVersion' auch wieder sauber
freigegeben.
UUZ.PAS
MY:
- Behandlung des UUZ-Suchpfades korrigiert/optimiert: UUZ erzeugt und
erwartet seine intern verwendeten Dateien wie MAIL.RFC, NEWS.RFC,
UUZ.OPT, UUZ_ERR.LOG etc. jetzt auch dann in seinem eigenen Verzeich-
nis ("OwnPath"), wenn er von einem anderen Verzeichnis aus mit relati-
vem oder voll qualifiziertem Pfad aufgerufen wurde. Bisher wurden
die Dateien in diesem Fall im aktuellen Verzeichnis ("ShellPath")
erzeugt bzw. erwartet und konnten dann nicht gefunden werden.
Diese Änderung ist nur relevant für den Extern- oder Testbetrieb. Im
Normalbetrieb mit FreeXP und XP2 wurden die Dateien auch bisher schon
in dem Verzeichnis erzeugt und erwartet, in dem sich der UUZ selbst
befand.
UUZ.PAS, UUZ0.PAS, TYPEFORM.PAS
MY:
- Behandlung von Mailadressen in "Newsgroups:"- und "Followup-To:"-
Headern korrigiert/optimiert (-uz):
----------------------------------------------------------------------
Zwar dürfen weder in "Newsgroups:"- noch in "Followup-To:"-Headern
Mailadressen vorkommen, bisweilen tun sie das aber trotzdem. Diesem
Umstand tragen die nachfolgenden Änderungen Rechnung:
1. Bei einer oder mehreren Mailadressen in einem "Newsgroups:"-Header
werden diese jetzt nicht mehr wie bisher als vermeintliches Brett
behandelt und mit durch "/" ersetzten Punkten in einen EMP:-Header,
sondern als echte Mailadresse in einen OEM:-Header übernommen.
Newsgroup-Namen werden wie bisher ausschließlich in EMP:-Header
übernommen.
Dadurch wird anders als bisher bei einer öffentlichen Antwort auf
ein solches Posting nicht mehr eine zusätzliche Mail an eine ungül-
tige Mailadresse wie
--------------------------------------------------
EMP: +t-online:/theo/tester@test/de
--------------------------------------------------
erstellt, und bei einer PM-Antwort stehen die Mail-Adressen aus den
Headern "Newsgroups:" und "Followup-To:" jetzt im korrekten Format
zur Verfügung.
Enthält der "Newsgroups:"-Header ausschließlich eine oder mehrere
Mailadressen, wird die erste in einen EMP:- und die übrigen in
OEM:-Header übernommen (ansonsten würde ein ZConnect-Puffer ohne
EMP:-Header erzeugt werden).
2. Kommen Mailadressen in einem "Followup-To:"-Header vor, wird der
Header nicht mehr wie bisher komplett verworfen, sondern die News-
groups in Diskussion-in:- und die Mailadressen in ANTWORT-AN:-
Header geschrieben.
In beiden Fällen durchlaufen die Mailadressen - unabhängig von dem
Format, in dem sie vorliegen - dieselbe Behandlung wie Adressen im
"To:"- oder "Reply-To:"-Header (d.h. insbesondere, daß Kommentare
sowie überflüssige quoted-strings und quoted-pairs entfernt werden).
Etwaige Realnames werden dabei berücksichtigt, analog zu Adressen im
"To:"- oder "Reply-To:"-Header aber anschließend verworfen.
UUZ.PAS, UUZ0.PAS, MIMEDEC.PAS
MY:
- Erzeugung des "Received:"-Headers bei Mails geändert/korrigiert (-uz):
Der Header wird jetzt nicht mehr wie bisher mittels einer Stringaddi-
tion zusammengesetzt, sondern dessen einzelne Bestandteile durchlaufen
separat die Routine 'EncodeFoldQuote'. Praktische Konsequenzen:
1. Es können keine Zeichen mehr durch einen Stringüberlauf verloren-
gehen (z.B. im Falle eines langen Software-Strings und/oder einer
langen Adresse des Envelope-Empfängers).
2. Der Header wird nicht mehr fest verdrahtet vor einem etwaigen
Envelope-Empfänger sowie dem Datum gefaltet, sondern nur noch dann
(und an der spätestmöglichen Position), wenn die Gesamtlänge des
Headers dies erfordert. Vergleich vorher/nachher:
---------------------------------------------------------------------
Received: by freexp.de (FreeXP/3.40);
Mon, 09 Jan 2006 23:52:45 +0100
Received: by freexp.de (FreeXP/3.40); Mon, 09 Jan 2006 23:56:45 +0100
---------------------------------------------------------------------
3. Wird durch die Existenz der Datei ADDGATE ein Gatebetrieb signali-
siert, entfällt die Angabe des Mailprogramms im "Received:"-Header.
UUZ.PAS
MY:
- Behandlung von Cancel/Supersedes- und Control-Nachrichten überarbeitet
(-uz):
----------------------------------------------------------------------
1. Cancel- und Supersedes-Nachrichten werden nur noch dann als solche
behandelt, wenn es sich entweder um Postings (News) oder um Mails
in eine Mailingliste handelt. Als Mailinglisten-Nachrichten gelten
Mails dann, wenn sie einen der folgenden RFC-Header enthalten:
-------------------------------------------------------
"List-Help:" (RFC2369)
"List-Subscribe:" (RFC2369)
"List-Unsubscribe:" (RFC2369)
"List-Post:" (RFC2369)
"List-Owner:" (RFC2369)
"List-Archive:" (RFC2369)
"List-Id:" (RFC2919)
"X-List-Administrivia:" (proprietärer Mailman-Header)
-------------------------------------------------------
Im Falle von Mails, die diese Voraussetzungen nicht erfüllen, werden
die RFC-Header "Control: cancel <MsgID>" und "Supersedes: <MsgID>"
ignoriert.
2. Im XP2-Modus wird eine Nachricht mit einem "Control:"-Header nur
noch dann als Cancel-Nachricht behandelt, wenn der Headerinhalt
auch tatsächlich den String "cancel " enthält. Bisher wäre auch bei
"Control:"-Headern mit ganz anderem Inhalt blind das Cancel-Flag
gesetzt worden (was allerdings i.d.R. keine Auswirkungen gehabt
hätte, weil es an der Message-ID der zu cancelnden Nachricht
gefehlt hätte). Die bisherige Logik entsprach dem Verhalten des UUZ
von XP2, jetzt ist sie mit der Logik des E-UUZ im Standard-Modus
identisch. Die XP2-spezifische und sich von FreeXP unterscheidende
Behandlung von Cancel-Nachrichten (Cancel-Flag statt der ZC-Header
"STAT: CTL" und "CONTROL: cancel MsgID") wird nach wie vor berück-
sichtigt.
3. Bei allen "Control:"-Headern, die keinen Cancel-Befehl enthalten,
wird der Inhalt nur noch dann in den ZC-Header CONTROL: übernommen,
wenn es sich um ein Posting handelt (also auch nicht bei Mails in
eine Mailingliste). Im XP2-Modus wird wie bisher grundsätzlich kein
CONTROL:-Header erzeugt.
Die beschriebenen Änderungen dienen dazu, technisch bisher durchaus
mögliches Canceln/Superseden privater Mails zu unterbinden.
UUZ.PAS, UUZ0.PAS
MY:
- Neue Importschnittstelle für das "raw"-Format implementiert:
----------------------------------------------------------------------
Der E-UUZ/II kann jetzt auch Mails im sog. "raw"-Format (Mailformat,
wie es von einer POP3-Mailbox ausgeliefert wird) direkt konvertieren,
ohne wie bisher auf die üblichen Schlüsselzeilen ("HELO" bei SMTP-
Mails, "From_" bei UUCP/mbox-Mails) am Anfang der Mail angewiesen zu
sein. Naturgemäß kann eine Datei im raw-Format immer nur eine einzige
Mail enthalten.
Das Format wird automatisch erkannt. Eine Datei wird vom E-UUZ dann
als Mail betrachtet, wenn die erste Zeile einen syntaktisch gültigen
RFC-Headerbezeichner enthält.
Ansonsten gelten hinsichtlich der Auswertung von RFC-Headerzeilen
sowie der Erkennung und Behandlung von Header und Body exakt dieselben
Regeln, wie sie in diesem Dokument bereits an früherer Stelle
('ReadRFCheader') ausführlich behandelt wurden.
UUZ.PAS, UUZ0.PAS
- Beteiligte Entwickler an dieser UUZ-Version:
----------------------------------------------------------------------
MY - Michael Heydekamp (Programmierung und Dokumentation)
MW - Martin Wodrich (Erweiterung der Windows-Versionserkennung)
- Credits für diese UUZ-Version:
----------------------------------------------------------------------
Hans-Jürgen Tänzer - Umfassende Massentests, wertvolle Anregungen
und intensive Fachdiskussionen
-+
Johann Addicks |
Oliver Gampe |
Reinhard Irmer |
Franklin Schiftan +- Praxistests (FreeXP/XP2)
Alfred Schröder |
Jörg Tewes |
Martin Wodrich |
-+
+--------------------------------------------------------------+
| 26.09.2003-07.08.2004 (Testversionen E-UUZ/II v3.40.1a/b) |
+--------------------------------------------------------------+
MY:
- Erneut umfassende Umbauten, Änderungen, Fixes und Erweiterungen,
speziell in den Bereichen Zeichensatzunterstützung und Decodierung
(base64, quoted-printable, UTF-7/8) von Nachrichtentexten und
teilweise Headern sowie der Auswertung und Deklaration von
MIME-Nachrichten ("Enhanced UUZ" => "Enhanced UUZ/II")
========================================================================
MY:
- Neue Zeichensätze implementiert:
----------------------------------------------------------------------
Da FreeXP bzw. der Enhanced UUZ seit Erscheinen der letzten Version
nur noch explizit unterstützte Zeichensätze konvertiert (statt wie
früher *alle* ISO-Zeichensätze blind auf Basis der mitunter unzutref-
fenden Tabelle für ISO-8859-1 "kaputtzukonvertieren"), wurden zu den
bisherigen neun die folgenden zehn zusätzlichen Zeichensätze imple-
mentiert:
1. ISO-8859-3 (alias "Latin 3", Süd-Europa/Türkei)
2. ISO-8859-4 (alias "Latin 4", Nord-Europa/Baltikum)
3. ISO-8859-10 (alias "Latin 6", Nord-Europa)
4. ISO-8859-13 (alias "Latin 7", Nord-Europa/Baltikum)
5. ISO-8859-14 (alias "Latin 8", West-Europa/Gälisch)
6. ISO-8859-16 (alias "Latin 10", Ost-Europa, mit Euro)
7. Windows-1250 (alias "Win Latin 2", Ost-Europa, mit Euro)
8. Windows-1254 (alias "Win Turkish", Türkei, mit Euro)
9. Windows-1257 (alias "Win Baltic", Nord-Europa/Baltikum, mit Euro)
10. Mac OS Roman (alias "MacRoman", West/Nord-Europa, mit Euro)
Diese Zeichensätze kommen in Mails und auch in den de.* Newsgruppen
tatsächlich vor (vermutlich nicht selten infolge einer fehlerhaften
Konfiguration). Es werden wie schon bei den bisherigen alle bei der
IANA registrierten Aliasnamen dieser neu implementierten Zeichensätze
unterstützt.
Damit unterstützt FreeXP jetzt *alle* Latin-Zeichensätze der ISO-8859-
Reihe (einschließlich der erst jüngst zugelassenen wie ISO-8859-16),
alle vier in den USA und Europa gängigen Win-Latin-Codepages, die
Macintosh-Codepage (ab Mac OS 8.5 mit Euro-Symbol), die DOS-Codepages
850 und 858 sowie die Unicode-Codierungen UTF-7/8.
Immerhin 10 dieser nunmehr insgesamt 19 unterstützten Zeichensätze
bzw. Codierungen enthalten das Euro-Symbol.
MIMEDEC.PAS
MY:
- Detailkorrekturen bei der Konvertierung einzelner Zeichen:
----------------------------------------------------------------------
1. CP437 => ISO-8859-1:
Das Steuerzeichen #7 (BEL, optisch identisch mit einem "Bullet")
wird jetzt in ein "*" konvertiert (bisher: "Middle Dot" #183).
2. ISO-8859-2 => CP437:
Zeichen #208 wird jetzt nach "D" konvertiert (bisher: "T"). Es
handelt sich hier nicht wie in ISO-8859-1 um das an derselben
Position befindliche und identisch aussehende Zeichen "Latin
Capital Letter Eth" (Unicode U+00D0), sondern um das Zeichen "Latin
Capital Letter D with Stroke" (Unicode U+0110).
3. ISO-8859-9 => CP437:
a) Zeichen #208 wird jetzt nach "G" konvertiert (bisher: "T").
b) Zeichen #221 wird jetzt nach "I" konvertiert (bisher: "Y").
c) Zeichen #254 wird jetzt nach "s" konvertiert (bisher: "t").
4. Windows-1252/1250/1254/1257 => CP437:
a) Nicht definierte Zeichen werden jetzt in ein Leerzeichen
konvertiert (statt in das Zeichen #177, das als Platzhalter
für unkonvertierbare Zeichen verwendet wird).
b) Zeichen #130 ("single low-9 quotation mark") wird jetzt in einen
Apostroph #39 konvertiert (bisher: Komma #44).
c) Das Zeichen #149 ("Bullet") wird jetzt in das Zeichen "*" #42
konvertiert (bisher: "Black Square" #254).
5. Mac OS Roman => CP437:
Tabelle komplett überarbeitet und an die schon seit der letzten
Version umfassend geänderten Konvertierregeln der ISO- und Win-
Zeichensätze angeglichen. (Anmerkung: Eine Konvertiertabelle für
Mac OS Roman war schon immer in XP enthalten, wurde aber bisher nur
bei Fido-Nachrichten verwendet).
6. UTF-7/8 => CP437 (Sonderfall):
Das Unicode-Zeichen U+03B5 (kleines griechiches Epsilon, identisch
mit dem Zeichen #238 "ε" in CP437) wird *nicht* in das eigentlich
richtige Zeichen "ε" konvertiert, sondern in ein "e". Da das
Zeichen "ε" zukünftig für das Euro-Symbol reserviert ist, würde
FreeXP sonst bei UTF-7/8-codierten Nachrichten, die das Zeichen "î"
enthalten, dieses nicht von einem Euro-Symbol unterscheiden können
und daher beide miteinander verwechseln. Diese Vorsichtsmaßnahme
ist allerdings eher theoretischer Natur, denn im wirklichen Leben
wird das Zeichen "ε" - im Unterschied zum Euro-Symbol - so gut wie
nie verwendet.
7. Bei allen Zeichensätzen, die das Zeichen "Macron" enthalten (ein
hochstehender waagerechter Strich, der ähnlich wie die Umlautpunkte
oberhalb von Zeichen stehen kann und eigentlich nicht einzeln vor-
kommt), wird dieses jetzt in einen Bindestrich #45 konvertiert
(bisher: Rahmengrafikzeichen #196).
MIMEDEC.PAS
MY:
- Unterstützung von Zeichensatz-Aliasnamen erweitert:
----------------------------------------------------------------------
Zusätzlich zu den offiziell bei der IANA registrierten (und somit für
MIME-Nachrichten einzig zulässigen) Zeichensatz-Aliasnamen werden
jetzt auch die Aliasnamen aus der primär auf Linux-Systemen verwende-
ten Library "GNU libc iconv" unterstützt. Es tauchten immer wieder
Postings in Newsgruppen sowie Mails auf, die den Zeichensatz mit
einem dieser eigentlich nicht zulässigen Aliasnamen wie "iso8859-1"
(richtig wäre z.B. "iso-8859-1") deklarierten; diese Nachrichten
wurden dann nicht konvertiert, was jetzt trotz fehlerhafter Deklara-
tion der Fall ist.
MIMEDEC.PAS
MY:
- UTF-7/8-Konvertierung nochmals erweitert:
----------------------------------------------------------------------
Alle 165 Zeichen, die außerhalb von ISO-8859-1 in einem der übrigen
von FreeXP unterstützten ISO-, Win-, Mac- oder DOS-Latin-Zeichensätze,
nicht aber in CP437 enthalten sind (z.B. typographische Anführungs-
zeichen, große und kleine Zeichen mit "Macron", "Ogonek" usw.), wurden
bisher nur dann konvertiert bzw. transliteriert, wenn die Nachricht
auch in einem dieser Zeichensätze vorlag und deklariert war. Kamen
dieselben Zeichen jedoch in einer UTF-7/8-codierten Nachricht vor,
wurden sie inkonsequenterweise durch das Zeichen #177 als unkonver-
tierbar repräsentiert. Jetzt umfaßt die UTF-7/8-Decodierung exakt
denselben Zeichenvorrat wie die Summe aller von FreeXP unterstützten
Latin-Zeichensätze.
MIMEDEC.PAS
MY:
- Header-Variablen 'charset' (= Inhalt des ZC-Headers CHARSET:) und
'ccharset' von bisher 7 Zeichen auf jetzt 30 Zeichen vergrößert, um
zukünftig auch beliebige und nicht ZC-konforme Charset-Bezeichner
in zu-Richtung unterstützen und auswerten zu können.
UUZ0.PAS
MY:
- Bei defekten ausgehenden Newspuffern ohne oder mit leerem EMP:-Header
(i.d.R. verursacht durch einen fehlerhaften Eingabepuffer) wird jetzt
keine zweckfreie (eben weil defekte) Ausgangsdatei *.OUT mehr erzeugt.
UUZ.PAS
MY:
- Fix (-zu): Bei einem fehlerhaften Eingabepuffer wird eine zwischen-
zeitlich bereits angelegte Temporärdatei 'UUZ.TMP' nach der Erkennung
des Fehlers jetzt gelöscht.
UUZ.PAS
MY:
- Interne Änderung: Das Setzen der MIME-Information bei ausgehenden
Nachrichten über 'SetMimeData' erfolgt bei Mails jetzt nicht mehr
doppelt. Dies verbessert geringfügig die Performance, war aber vor
allem wegen der verbesserten Zeichensatzbehandlung im Externbetrieb
und der Behandlung des Headers "U-Content-Type:" (siehe weiter unten)
schlicht notwendig.
UUZ.PAS, UUZ0.PAS
MY:
- Umfassende Fixes, Änderungen und Erweiterungen bei der ZC=>RFC-Konver-
tierung von Nachrichten, die einen oder mehrere der Header "CHARSET:",
"X-Charset:" und/oder "U-Content-Type:" enthalten:
----------------------------------------------------------------------
1. Fix: Bei der Konvertierung von Nachrichten, die einen Header
"U-Content-Type:", jedoch keinen Header CHARSET: oder X-Charset:
enthielten, wurde bei gleichzeitiger Nichtverwendung des Schalters
"-chkbody" (der sich von XP aus nicht setzen läßt) die Nachricht
zwar IBM=>ISO-konvertiert, aber statt des korrekten Zeichensatzes
ISO-8859-1/15 der Zeichensatz deklariert, der sich im Header
"U-Content-Type:" befand (das konnte z.B. auch "UTF-8" sein). Dies
führte nicht selten zu einer fehlerhaften Deklaration, denn dabei
handelte es sich zwar um den Zeichensatz, in dem sich die originale
RFC-Nachricht vor der Konvertierung in den IBM-Zeichensatz befunden
hatte, nicht aber zwingend um den Zeichensatz, in den sie danach
beim Versand wieder rekonvertiert wurde (nämlich ISO-8859-1/15).
Bei Nachrichten, die sich im Originalzustand ohnehin bereits im
Zeichensatz ISO-8859-1/15 befunden hatten, wirkte sich dieser
Fehler nicht aus. Darüber hinaus waren FreeXP-User von dem Problem
ohnehin nicht betroffen, weil von FreeXP erzeugte Nachrichten immer
einen Header CHARSET: oder X-Charset: enthalten, der dem UUZ mit-
teilt, in welchem Zeichensatz sich die Nachricht bereits befindet
und daher nicht konvertiert werden darf (CHARSET:) bzw. in welchen
Zeichensatz sie konvertiert werden soll, mit dem sie dann auch zu
deklarieren ist (X-Charset:).
Das Problem konnte also nur im Externbetrieb bei gate-typischen
Szenarien entstehen, bei denen eine RFC=>ZC-Konvertierung und
unmittelbar anschließend eine ZC=>RFC-Konvertierung durchgeführt
wurde. Bei Verwendung des in diesen Fällen ohnehin zu empfehlenden
Parameters "-chkbody" wurde der Fehler schon bisher vermieden.
Der "charset"-Parameter im Header "U-Content-Type:" wird jetzt in
allen Fällen ignoriert. Ist weder der Header X-Charset: noch der
Header CHARSET: enthalten, setzt der UUZ mangels Charset-Angabe
jetzt intern den Schalter "-chkbody", prüft somit den Nachrichten-
text auf das Vorkommen von 8bit-Zeichen und erzeugt eine korrekt
konvertierte und deklarierte Nachricht (wobei er per Definition wie
bisher davon ausgeht, daß die Nachricht im IBM-Zeichensatz vorliegt
und nach ISO-8859-1/15 zu konvertieren ist). Die Deklaration der
Transportcodierung im neu erzeugten RFC-Header "Content-Transfer-
Encoding:" (7/8bit) richtet sich dabei wie bisher nach dem ermit-
telten Zeichensatz.
2. ZC-Nachrichten, die einen Header CHARSET: enthalten (mit XP kann so
eine Konstellation in einer ZConnect-Box erzeugt werden, indem der
Schalter "ZConnect: ISO-Zeichensatz" unter C/O/E/V aktiviert wird),
fand auch bisher schon keine Zeichensatzkonvertierung statt, wenn
der Header eine ZC-konforme Zeichensatzbezeichnung ("ISO1" bis
"ISO9") enthielt - das ist beabsichtigt und korrekt und wird daher
auch so bleiben.
Da inzwischen aber unkonvertierte ZConnect-Puffer aufgetaucht sind
(offenbar von Gates erzeugt oder aus OpenXP exportiert), die nicht
im IBM-Zeichensatz vorliegen und deren im Header CHARSET: dekla-
rierter Zeichensatz sowohl hinsichtlich des verwendeten Zeichen-
satzes selbst ("UTF-8") als auch hinsichtlich der Bezeichnung
("ISO-8859-15") nicht mehr den ZConnect-Spezifikationen entspre-
chen, wurde dieses Verhalten für alle vom Enhanced UUZ unterstütz-
ten und nicht unterstützten Zeichensätze erweitert, ohne dabei die
Kompatibilität mit anderen XP-Versionen aufzugeben:
a) Existiert ein Header CHARSET:, wird die Nachricht ungeachtet
der verwendeten Zeichensatzbezeichnung nicht konvertiert - mit
einer Ausnahme: Wenn ein im Sinne von XP lokaler Zeichensatz
enthalten ist (also US-ASCII oder IBM437), wird die Nachricht
trotzdem in den entsprechenden ISO-Zeichensatz konvertiert.
b) Bei allen vom Enhanced UUZ eingehend unterstützten Latin-
Zeichensätzen (inkl. UTF-7/8) sowie bei den nicht unterstützten
Non-Latin-Zeichensätzen der ISO-8859-Reihe (ISO-8859-5 bis -8
und -11) wird dabei jeder IANA-registrierte oder in der weiter
oben erwähnten iconv-Library enthaltene Aliasname in den
jeweiligen "preferred MIME name" übersetzt ("IBM819" wird zu
"ISO-8859-1", "csIsoLatinArabic" zu "ISO-8859-6"). Bei der
Erkennung lokaler Charsets (siehe Punkt 2. a)) werden ebenfalls
alle Aliasnamen (wie z.B. "cspc8codepage437") unterstützt und
ausgewertet.
c) Gehört der deklarierte Zeichensatz weder zu einem der vom UUZ
unterstützten noch zu einem der fünf nicht unterstützten Non-
Latin-Zeichensätze aus der ISO-8859-Reihe und ist daher gänzlich
unbekannt, wird die Zeichensatzbezeichnung aus dem CHARSET:-
Header 1:1 übernommen.
d) Eine automatische Überprüfung des Nachrichtentextes findet bei
Existenz des CHARSET:-Headers wie bisher nicht statt. Diese läßt
sich aber nach wie vor im Externbetrieb mit der Kommandozeilen-
option "-chkbody" erzwingen; dabei würde dann ein evtl. 8bit-
Zeichensatz nach "US-ASCII" korrigiert werden, wenn die Nach-
richt nur 7bit-Zeichen enthält.
e) Eine angeblich im Zeichensatz "UTF-7" vorliegende Nachricht wird
per Definition immer mit "7bit" deklariert - selbst dann, wenn
der Schalter "-chkbody" verwendet und die Nachricht 8bit-Zeichen
enthalten sollte. Der Enhanced UUZ kann dann nicht entscheiden,
welches der tatsächliche Zeichensatz ist und hält sich daher
strikt an die Angabe im CHARSET:-Header, obwohl damit eine ein-
deutig fehlerhaft deklarierte Nachricht erzeugt wird (weil schon
der Eingabepuffer eindeutig fehlerhaft ist). Man kann halt nicht
alles reparieren, eine halbwegs seriöse Heuristik für diesen
Fall existiert nicht, und auch die sonst recht treffsichere
Glaskugel des Enhanced UUZ hat ihre Grenzen.
3. Nachrichten mit dem Header X-Charset: (zulässig sind hier nur die
Zeichensätze US-ASCII, ISO-8859-1 und ISO-8859-15, aber jetzt auch
mitsamt aller ihrer registrierten und unregistrierten Aliasnamen)
liegen per Definition im IBM-Zeichensatz vor und werden daher wie
bisher in den angegebenen ISO-Zeichensatz konvertiert und mit
diesem Zeichensatz deklariert.
a) Mit dem Schalter "-chkbody" läßt sich extern nach wie vor eine
Überprüfung des Body erzwingen und so ggf. eine Korrektur eines
fehlerhaft deklarierten Zeichensatzes herbeiführen (z.B. bei
Nachrichten, die fälschlicherweise als US-ASCII deklariert sind,
aber wie im Falle des Paragraphenzeichens "" nach der ISO-Kon-
vertierung 8bit-Zeichen enthalten - siehe auch den Abschnitt
weiter unten zur Kompatibilität des Enhanced UUZ mit XP2).
b) Sollte der Header X-Charset: einen "unerwünschten" lokalen
Zeichensatz (z.B. IBM437, kann im Betrieb mit FreeXP nicht
vorkommen) enthalten, wird er ignoriert, intern der Schalter
"-chkbody" gesetzt und so eine korrekt konvertierte und dekla-
rierte Nachricht im entsprechenden ISO-Zeichensatz erzeugt.
4. Im rein theoretischen Fall, daß sowohl ein Header CHARSET: als auch
ein Header X-Charset: existieren, besitzt der Header CHARSET:
Priorität.
Alle beschriebenen Änderungen gelten ausschließlich für die Behandlung
des Nachrichtentextes (Header liegen per Definition immer im IBM-Zei-
chensatz vor und sind daher immer zu konvertieren).
MIMEDEC.PAS, UUZ.PAS, UUZ0.PAS, XPMAKEHD.INC
MY:
- Konvertierung von Nachrichten mit nicht unterstützten Zeichensätzen
verbessert (-uz):
----------------------------------------------------------------------
Bei Nachrichten in einem von FreeXP eingehend nicht unterstützten
Zeichensatz wird dieser jetzt in den ZConnect-Header CHARSET:
geschrieben (und die Nachricht wie bisher *nicht* konvertiert). Dabei
wird, soweit möglich und vorhanden, der Name des Zeichensatzes in die
ZConnect-spezifische Bezeichnung ("ISO1" bis "ISO9") oder alternativ
in den "preferred MIME name" gemäß IANA umgewandelt. Ist beides nicht
möglich, wird der Name des Zeichensatzes, wie er im Header "Content-
Type:" deklariert ist, unverändert übernommen.
Dieses Vorgehen hat in Verbindung mit den oben beschriebenen Änderun-
gen, durch die es überhaupt erst ermöglicht und sinnvoll wird, den
Vorteil, daß bei einer unmittelbar anschließenden Konvertierung in
zu-Richtung a) der korrekte Zeichensatz deklariert und b) die Nach-
richt 1:1 und ohne Zeichenverlust weiterversandt werden kann.
Es ist weniger für XP-User, sondern eher für Anwender interessant und
von Bedeutung, die den Enhanced UUZ im Gate- oder Externbetrieb ein-
setzen und ist für diesen Fall deshalb gerechtfertigt und notwendig,
weil ansonsten keine Möglichkeit bestünde, Nachrichten mit nicht
unterstützten Zeichensätzen unmittelbar hintereinander in beide
Richtungen korrekt zu konvertieren und weiterzuversenden.
Die neue Verfahrensweise unterscheidet sich zu der von OpenXP insbe-
sondere dadurch, daß *unterstützte* Zeichensätze nach wie vor nach
CP437 konvertiert werden. Daher ist sie auch mit früheren XP-Versionen
(die genau wie alle aktuellen XP-Versionen Nachrichten in nicht unter-
stützten Zeichensätzen weder konvertiert noch unkonvertiert lesbar
darstellen können) 100%ig kompatibel, während OpenXP sich offenbar
dazu entschlossen hat, diese Kompatibilität aufzugeben und den Zei-
chensatz von RFC-Nachrichten überhaupt nicht mehr zu konvertieren,
wodurch die von OpenXP erzeugten ZConnect-Puffer für andere XP-
Versionen, sofern sie 8bit-Zeichen enthalten, mitunter unbrauchbar
sind (FreeXP wird jedoch in einer der nächsten Versionen - möglicher-
weise sogar in der nächsten - ebenfalls solche unkonvertierten Single-
part-Nachrichten mit beliebigen unterstützten Zeichensätzen im
CHARSET:-Header korrekt darstellen können).
UUZ0.PAS
MY:
- Fix für einen relativ kapitalen Bug bei der ZC=>RFC-Konvertierung, der
erstaunlicherweise bisher entweder nicht aufgetreten oder nicht
aufgefallen ist:
Wenn die Nachricht zwar einen CHARSET:-Header, jedoch *keine* Header
"U-Content-Type:" und "U-Content-Transfer-Encoding:" enthielt (absolut
realistisches Szenario, das in einer ZConnect-Box auftreten kann, wenn
der Schalter "ZConnect: ISO-Zeichensatz" unter C/O/E/V gesetzt ist),
dann wurde die Nachricht nicht konvertiert (was korrekt ist), aber es
wurden auch nicht die zwingend erforderlichen Header "Content-Type:"
und "Content-Transfer-Encoding:" neu erzeugt. Bisher wurde nur auf den
Header X-Charset: geprüft und nicht berücksichtigt, daß auch Nachrich-
ten, die wegen des CHARSET:-Headers nicht konvertiert werden dürfen,
diese Header trotzdem benötigen.
Bei in einer RFC-Box erstellten Nachrichten oder bei Verwendung des
Parameters "-chkbody" trat der Bug nicht zutage.
UUZ0.PAS
MY:
- Fix: Wenn ein Header Zeichen enthielt, die durch die IBM=>ISO-Konver-
tierung von einem 8bit- in ein 7bit-Zeichen transliteriert wurden
(z.B. Gamma "â" => "G") und gleichzeitig keine weiteren 8bit-Zeichen
enthielt, aufgrund derer der Header hätte MIME-codiert werden müssen,
dann hat der Enhanced UUZ zwar korrekt erkannt, daß keine Codierung
erforderlich ist, hat dann aber nicht den nach ISO-8859-x konvertier-
ten 7bit-String in den Header geschrieben, sondern den unkonvertierten
8bit-String im IBM-Zeichensatz. :-(
In dieser seltenen Konstellation konnten also theoretisch uncodierte
8bit-Zeichen in Header gelangen. Der Fall konnte nur bei Rahmengrafik-
und einigen griechischen Zeichen aus CP437 eintreten, die in der
Praxis so gut wie nie in Headern verwendet werden - vermutlich deshalb
ist der Bug auch nie aufgetreten und gemeldet worden.
UUZ.PAS
MY:
- Charset-Fallback implementiert (-uz):
----------------------------------------------------------------------
Es kommt nicht selten vor, daß Nachrichten im Zeichensatz ISO-8859-x
deklariert sind, in Wirklichkeit aber im Zeichensatz Windows-125x
vorliegen (typischer Fehler von OjE). Bei den meisten Zeichen ist das
kein Problem (speziell nicht im Fall ISO-8859-1 und Windows-1252, weil
diese Zeichensätze im Bereich 0xA0 bis 0xFF identisch sind), aber wenn
die Nachricht Zeichen aus dem Bereich 0x80 bis 0x9F enthielt, wurden
diese bisher nicht korrekt (bzw. gar nicht) konvertiert, weil dieser
Bereich bei allen ISO-Zeichensätzen für Steuerzeichen reserviert ist.
Bei Windows-Zeichensätzen hingegen liegen dort z.B. typographische
Anführungszeichen, verlängerte Bindestriche, das Euro-Symbol usw.,
also durchaus Zeichen, die auch oft Verwendung finden und konvertier-
bar sind.
Der Enhanced UUZ prüft jetzt bei allen Nachrichten, die mit einem der
unterstützten ISO-Zeichensätze deklariert sind, ob sie Zeichen aus dem
Bereich 0x80 bis 0x9F enthalten. Ist das der Fall, schließt der UUZ
daraus, daß die Deklaration "ISO-8859-x" offenbar falsch ist und nimmt
ein "Fallback" auf den verwandtesten Windows-Zeichensatz vor (das ist
der, der in der Region, wo der ursprünglich deklarierte ISO-Charset am
ehesten verwendet wird, Standard ist). Dabei gilt folgende Zuordnung:
ISO-8859-1 => Windows-1252 (West-Europa)
ISO-8859-2 => Windows-1250 (Ost-Europa)
ISO-8859-3 => Windows-1254 (Süd-Europa/Türkei)
ISO-8859-4 => Windows-1257 (Nord-Europa/Baltikum)
ISO-8859-9 => Windows-1254 (Türkei)
ISO-8859-10 => Windows-1257 (Nord-Europa)
ISO-8859-13 => Windows-1257 (Nord-Europa/Baltikum)
ISO-8859-14 => Windows-1252 (West-Europa/Gälisch)
ISO-8859-15 => Windows-1252 (West-Europa)
ISO-8859-16 => Windows-1250 (Ost-Europa)
Da die Zeichensätze ISO-8859-1 und Windows-1252 sowie ISO-8859-9 und
Windows-1254 im Bereich 0xA0 bis 0xFF jeweils identisch sind, wurden
sie jeweils zu einer einzigen Tabelle zusammengefaßt (da passiert das
Fallback also quasi automatisch).
Sofern der UUZ ein Charset-Fallback für den Nachrichtentext vorgenom-
men hat, vermerkt er das im Header "X-Fallback-Charset:", läßt aber
die originale Charset-Deklaration im Header "U-Content-Type:" unange-
tastet.
Außer im Nachrichtentext funktioniert das Fallback auch in MIME-
codierten Headern beliebiger Länge (bis 65500 Zeichen). Allerdings
wird dann *kein* gesonderter Header "X-Fallback-Charset:" erzeugt,
weil in Headern mehrere Zeichensätze gleichzeitig vorkommen können und
man nicht für jedes einzelne encoded word einen eigenen Header erzeu-
gen kann, bei dem zudem die Zuordnung zum jeweiligen encoded word
nicht eindeutig wäre.
UUZ0.PAS, MIMEDEC.PAS
MY:
- Decodierungsroutinen für Header und Body (UTF-8, UTF-7, base64,
quoted-printable) anläßlich eines Bugreports komplett renoviert,
gefixt, erweitert und robuster gestaltet.
Während der für das Beheben des gemeldeten Bugs notwendigen Tests
stellten sich so viele weitere - bisher unbemerkte - Fehler heraus,
daß umfassende und grundlegende Änderungen erforderlich waren. Die
bisherigen Routinen für die Decodierung/Konvertierung speziell des
Nachrichtentextes (Body) waren auf eine Multibyte-Decodierung teil-
weise gar nicht oder unzureichend ausgelegt und gingen des weiteren
davon aus, daß codierte Zeilen nie länger sein können als es in den
einschlägigen RFCs vorgesehen ist bzw. als es die Längenbeschränkung
von Pascal zuläßt - was aber nicht immer der Praxis entspricht (bei
Headern bestand der größte Teil der Probleme seit Erscheinen der
ersten Fassung des Enhanced UUZ nicht mehr, auch wenn der Auslöser im
konkreten Fall ein Header war).
Dieser Text richtet sich primär an Entwickler und interessierte
Anwender und ist daher entsprechend ausführlich, weil das Verständnis
der Materie für zukünftige Arbeiten am UUZ unerläßlich ist.
----------------------------------------------------------------------
1. (Bugfixes für Decodierung ungültiger UTF-8-Sequenzen)
Ein über 2 Jahre alter Bugfix in der UTF-8-Decodierung, der dazu
diente, auch umbrochene bzw. sich über mehrere Teilstrings
erstreckende Multibyte-Sequenzen decodieren zu können (so etwas
kann z.B. bei zusätzlich base64- oder quoted-printable-codierten
Zeilen vorkommen, aber auch bei Zeilen mit mehr als 253 Zeichen),
führte im konkreten Fall, daß eine Nachricht im Zeichensatz
ISO-8859-x vorlag, aber fälschlicherweise als UTF-8 deklariert war,
dazu, daß ein falscher LEN:-Header erzeugt wurde. Der defekte
Puffer wurde von FreeXP zwar problemlos eingelesen, konnte aber von
externen Tools wie XPFILTER und XPBMF, die auf einen gültigen
ZConnect-Puffer angewiesen sind, nicht mehr korrekt bearbeitet
werden. Bei genauerer Prüfung stellte sich heraus, daß der besagte
Fix weitere Probleme (möglicher Zeichenverlust, bei entsprechenden
Konstellationen wurden sogar korrekt codierte Zeichen gar nicht
mehr decodiert) verursachen konnte.
Das grundlegende Problem des Fixes bestand darin, daß er keinerlei
Fehler- und Plausibilitätsprüfungen vornahm und nur dann korrekt
funktionieren konnte, wenn die zu decodierende UTF-8-Sequenz gültig
war - was bei Nachrichten, die in Wirklichkeit gar nicht UTF-8-
codiert sind, nicht der Fall ist (z.B. kann eine UTF-8-Sequenz nie
7bit-Zeichen enthalten). Die Routine unterlag dann mitunter dem
Irrtum, es müßten noch weitere Zeichen folgen, die zur aktuellen
(angeblichen) UTF-8-Sequenz gehören, merkte sich die bereits
empfangenen Zeichen in der lokalen Variablen 'sc_rest' und wartete
auf den vermeintlich noch fehlenden Rest der Sequenz.
Wenn man sich aber z.B. ohnehin bereits am Ende eines Headers
befunden hatte, erfolgte der nächste Eintritt in die Routine u.U.
erst dann, wenn man sich inzwischen bereits im Body derselben oder
sogar irgendwo in einer der folgenden Nachrichten befand, ohne daß
der Variableninhalt zwischenzeitlich zurückgesetzt worden wäre. In
der Folge wurden "fremde" Bytesequenzen mit dem alten Variablen-
inhalt verquickt und völlig unsinnig "decodiert" - es entstand eine
Art "Bytesalat".
Zur Entstehung des falschen LEN:-Headers kam es deshalb, weil genau
so eine Konstellation vorlag und der Body jeder RFC-Nachricht zwei-
mal gelesen wird - einmal, um die Länge des Nachrichtentextes für
den LEN:-Header ermitteln und danach den ZConnect-Header komplett
schreiben zu können, ein zweites Mal, um den Body selbst zu
schreiben. Beim ersten Lesen wurde die sich noch aus dem fehlerhaft
als "UTF-8" deklarierten Subject:-Header in der Variablen 'sc_rest'
befindliche Sequenz aus 4 Bytes mit den ersten 2 Zeichen des Nach-
richtentextes verquickt und "decodiert" - dies führte zum für eine
Multibyte-Decodierung typischen Entfernen eines Zeichens und somit
zur Ermittlung einer um 1 Byte zu geringen Länge. Bei dieser
"Decodierung" wurde der Inhalt von 'sc_rest' zurückgesetzt, so daß
beim zweiten Lesen keine fehlerhafte Decodierung mehr stattfand,
somit auch kein Zeichen mehr entfernt und der Body daher in der
korrekten Länge geschrieben wurde => tatsächliche und vorher
ermittelte Länge stimmten nicht mehr überein. (Daß die Differenz im
konkreten Fall genau 1 Byte betrug, war Zufall, es hätten in
anderen Fällen auch bis zu 4 Bytes sein können.)
Zur Vermeidung dieses sowie aller anderen in diesem Zusammenhang
existierenden theoretischen und praktischen Probleme wurden daher
folgende umfassende Gegenmaßnahmen ergriffen:
a) Es werden nur noch UTF-8-Sequenzen decodiert, die nach den in
"The Unicode Standard, Version 4.0" und RFC3629 von November
2003 (das den bisher gültigen Standard RFC2279 von Januar 1998
ersetzt) niedergelegten Regeln eine gültige UTF-8-Sequenz
bilden. Das hat automatisch zur Folge, daß auch Sequenzen mit
7bit-Zeichen, wie sie bei ISO-8859-x oder allen anderen Latin-
Zeichensätzen zwangsläufig vorkommen, nicht mehr blind kaputt-
decodiert und auch keine vermeintlich unvollständigen Sequenzen
in der Variablen 'sc_rest' mehr abgelegt werden.
b) Stattdessen werden 8bit-Zeichen, die sich in einer angeblichen
und/oder ungültigen UTF-8-Sequenz befinden, der Standardkonver-
tierung von Windows-1252 in den IBM-Zeichensatz CP437 unterzo-
gen. Dadurch werden in den allermeisten Fällen die Zeichen in
fälschlicherweise als UTF-8 deklarierten Nachrichten korrekt
"erraten" und bei einer Antwort auf eine solche Nachricht
korrekt wiedergegeben.
Das Durchführen dieser Standardkonvertierung folgt demselben
"robustness principle" wie es für Nachrichten gilt, bei denen
gar kein Zeichensatz deklariert ist. Selbst wenn das "erratene"
Zeichen ausnahmsweise falsch sein sollte (weil die Nachricht in
einem völlig anderen Zeichensatz als Windows-1252 vorliegt), ist
es innerhalb von XP immer genauso richtig wie ein gar nicht kon-
vertiertes Zeichen (nämlich falsch ;-)).
c) Um nicht fälschlicherweise zufällig gültige, aber unvollständige
UTF-8-Bytesequenzen am Ende eines Teilstrings vom einen Header
zum anderen bzw. bis zum Body oder gar vom Body zu einem Header
der nächsten Nachricht mitzuschleppen und dort mit - zufällig
ebenfalls gültigen - UTF-8-Bytesequenzen am Anfang des jeweils
nächsten Headers oder Body zu verquicken und damit eine zwar
technisch gültige, aber inhaltlich fehlerhafte Decodierung
durchzuführen, werden jetzt alle in Headern vorkommenden encoded
words, alle einzelnen RFC-Headerzeilen, Gesamtheader und Body
sowie die einzelnen Zeilen im Nachrichtentext über die globale
Variable 'start_of_UTF' streng voneinander abgegrenzt. In allen
diesen Fällen wird eine etwaige Restsequenz in 'sc_rest' jetzt
verworfen.
(Multibyte-Sequenzen dürfen sich gemäß RFC2047 weder über mehre-
re encoded words noch über mehrere Zeilen im Body erstrecken und
es sind aus der Praxis auch keine solchen Fälle bekannt. Wenn
UTF-8-codierte Nachrichten zusätzlich base64/qp-codiert sind,
dann können und dürfen sich Multibyte-Sequenzen hingegen durch-
aus über mehrere codierte Zeilen erstrecken. Dies wird von der
neuen Routine korrekt behandelt und unterstützt, siehe dazu auch
Punkt 3.)
d) So ein zu verwerfender Rest kann darüber hinaus jetzt aber gar
nicht mehr entstehen, da über die an den entsprechenden Stellen
gesetzte globale Variable 'end_of_UTF' geprüft wird, ob man sich
am Ende eines encoded word, Headers oder einer Zeile im Body
befindet. Sollte sich dort der gültige Anfang einer unvollstän-
digen UTF-8-Bytesequenz befinden, wird diese trotzdem nicht in
'sc_rest' abgelegt, weil keine zu dieser Sequenz gehörenden
Daten mehr folgen können.
e) Bei der Decodierung von Headern und Body werden jetzt nur noch
Teilstrings mit einer Länge von max. 248 Zeichen (bisher: 253
Zeichen) an die UTF-8-Routine übergeben. Damit wird verhindert,
daß durch die Stringaddition der max. 3 Zeichen (bisher: 5
Zeichen) langen Bytesequenz in 'sc_rest' ein Überlauf und damit
Zeichenverlust entstehen kann (Variable 'maxUTFLen' in
MIMEDEC.PAS eingeführt).
2. (Erweiterung der UTF-7-Decodierung für beliebig lange Zeilen und
Sequenzen)
Die UTF-7-Decodierung besaß einen solchen Fix für die Decodierung
umbrochener bzw. sich über mehrere Teilstrings erstreckender
Sequenzen bisher nicht - vermutlich, weil es dort wegen der belie-
bigen und undefinierten Länge der Sequenz (UTF-7 ist eine Variante
der base64-Codierung) noch erheblich schwieriger zu implementieren
gewesen wäre als bei UTF-8. ;)
Dadurch konnte dort zwar das für UTF-8 beschriebene Problem mit der
Erzeugung eines ungültigen LEN-Headers auch nicht auftreten, dafür
kam es aber eben bei der Decodierung von gleichzeitig base64/qp-
codierten Nachrichten oder bei Zeilen mit mehr als 253 Zeichen zu
möglichen Problemen (je nachdem, ob sich die Schnittstelle zweier
Teilstrings inmitten einer UTF-7-codierten Sequenz befunden hat
und/oder das Ende der zu decodierenden Sequenz im aktuellen Teil-
string nicht vorhanden war).
Die UTF-7-Decodierung ist jetzt ebenfalls für beliebig lange
Zeilen und Sequenzen in Headern und im Body ausgelegt (bisher:
253 Zeichen) und berücksichtigt die Regeln und Besonderheiten der
base64-Codierung (siehe auch Punkt 5.)
Alle unter Punkt 1. a) bis e) für UTF-8 beschriebenen Maßnahmen
gelten sinngemäß auch für die UTF-7-Decodierung, wobei die Prüfung
auf ungültige Bytesequenzen dort gänzlich anderen (und weniger
präzisen) Regeln unterliegt: Wenn nach dem eine UTF-7-Sequenz
einleitenden "+" nicht mindestens 3 gültige 7bit-Zeichen folgen,
wird die Decodierung der aktuellen Sequenz abgebrochen und das "+"
sowie ein ggf. abschließendes "-" bleiben erhalten (bisher wären
sie entfernt worden).
3. (Berücksichtigung von Zeilenumbrüchen in base64/qp-decodierten
Teilstrings)
Als "Zeilen" im Sinne der vorhergehenden Punkte 1. und 2. gelten
alle Zeichen in unbegrenzter Anzahl zwischen zwei Zeilenumbrüchen
(CR/LF/CRLF, siehe auch Punkt 4.) bzw. in einem encoded word in
einem RFC-Header *nach* einer etwaigen base64/qp-Decodierung.
Daher mußte die base64/qp-Decodierung des Nachrichtentextes so
angepaßt werden, daß Zeilenumbrüche im decodierten String sicher
erkannt und nur Strings an eine evtl. nachfolgende UTF-7/8-Decodie-
rungsroutine übergeben werden, die nicht über einen Zeilenumbruch
hinausgehen (bisher konnten sich Zeilenumbrüche mitten im zu
decodierenden String befinden). Anderenfalls wäre eine saubere
Abgrenzung einzelner Zeilen im Nachrichtentext (und damit das
korrekte Setzen der Variablen 'start_of_UTF' und 'end_of_UTF' für
eine unmittelbar anschließende UTF-7/8-Decodierung) nicht möglich
gewesen.
4. Bei der Decodierung von base64/qp-codierten Texten (Content-Type
text/*) werden einzelne im decodierten String vorkommende CR und LF
jetzt durch CRLF ersetzt (bereits vorhandene CRLF bleiben unverän-
dert erhalten).
5. (Erweiterung der Transportdecodierung für beliebig lange Zeilen
(Body) unter Berücksichtigung einer ggf. anschließenden Zeichen-
satzdecodierung (UTF-7/8) für darin enthaltene, ebenfalls beliebig
lange Zeilen, die wiederum beliebig lange codierte Bytesequenzen
enthalten können (Header und Body))
Bei der Decodierung der im Header "Content-Transfer-Encoding:"
für den Nachrichtentext deklarierten Transportcodierung ("base64"
oder "quoted-printable") wie auch bei der Zeichensatzdecodierung
("UTF-7" oder "UTF-8") von Headern und Body werden nur gültige und
in sich abgeschlossene Teilstrings an die jeweiligen Subroutinen
übergeben bzw. in diesen Subroutinen decodiert:
"base64" (Transport): Übergebene Stringlänge ist durch 4
teilbar oder kleiner 4 (am Ende des
Gesamtstrings).
"quoted-printable" (Transport): Übergebener String endet mit einem
uncodierten oder mit einem voll-
ständigen codierten Zeichen wie
"=E4" (nicht aber mit unvollstän-
dig codierten wie "=E4=E").
UTF-7 (Zeichensatz): Bearbeiteter String endet mit einem
uncodierten Zeichen oder mit einer
codierten Bytesequenz, deren Länge
kleiner 4 oder durch 4 teilbar ist.
UTF-8 (Zeichensatz): Bearbeiteter String endet mit einem
uncodierten Zeichen oder mit einer
codierten Bytesequenz, deren Länge
durch das erste Zeichen der Sequenz
definiert wird.
Evtl. überhängende Reststrings, Restbytes oder unvollständige Byte-
sequenzen, wie sie bei Zeilen > 248 Zeichen oder nach einer
base64/qp-Decodierung entstehen können, werden zwischengespeichert
und anschließend gemeinsam mit dem nachfolgenden Teilstring
decodiert.
Dies funktioniert auch bei doppelt codierten Headern oder Zeilen in
Headern oder im Body (Transportcodierung "quoted-printable" oder
"base64" im Body bzw. "Q" oder "B" im Header sowie Zeichensatz-
deklaration "UTF-7" oder "UTF-8").
Erst und nur durch dieses Verfahren ist es überhaupt möglich,
beliebig lange und ggf. doppelt codierte Zeilen und Sequenzen
trotz der Längenbeschränkungen von Pascal korrekt zu decodieren. Es
erfordert allerdings ein peinlich genaues Vorgehen und die Berück-
sichtigung aller (un)denkbaren Szenarien, um korrekt und robust
funktionieren zu können.
Bisher war speziell die Transportdecodierung des Nachrichtentextes
- im Unterschied zu der von RFC-Headern - nicht für längere Zeilen
ausgelegt (laut RFC2045 sind bei base64- und qp-Codierung max. 76
Zeichen pro Zeile erlaubt, aber in der Praxis kommen auch deutlich
längere Zeilen von mehreren hundert Zeichen vor) und arbeitete
daher zwar meistens, aber eben nicht immer korrekt und robust.
Eine ggf. anschließende Zeichensatzdecodierung funktionierte prak-
tisch nur bei UTF-8-codierten Headern halbwegs zuverlässig, in
allen anderen Fällen (UTF-8 im Body, UTF-7 in Header und Body) war
das Ergebnis mitunter teilweise oder gänzlich unbrauchbar.
Damit ist der Enhanced UUZ für alle sinnvollen und unsinnigen sowie
zulässigen und unzulässigen Formen und Kombinationen von Transport-
und Zeichensatzcodierung gerüstet und decodiert diese jetzt korrekt
und robust:
Auch eine durchgehende, z.B. 3.852 Zeichen lange und base64-codier-
te Zeile im Nachrichtentext, aus der nach der base64-Decodierung
eine ebenfalls durchgehende, 2.889 Zeichen lange und UTF-7-codierte
Zeile resultiert, die ihrerseits aus einer einzigen durchgehenden
UTF-7-Sequenz besteht (was wegen der doppelten base64-Codierung ein
ebenso unsinniges wie aufgrund der Länge der Ursprungszeile unzu-
lässiges Szenario wäre), bereitet dem Enhanced UUZ jetzt keinerlei
Schwierigkeiten mehr.
6. Bei der qp-Decodierung von Zeilen im Body mit mehr als 253 - bzw.
jetzt 248 - Zeichen (die laut RFC2045 unzulässig sind, in der
Praxis aber öfter als selten vorkommen) wurden u.U. Leerzeichen
aus dem Text entfernt, weil die Routine als allererste Maßnahme
alle rechten Leerzeichen im String entfernt hat. Zwar fordert
RFC2045 genau das, aber das darf man natürlich auch nur am echten
Zeilenende und nicht am Ende jedes einzelnen Teilstrings einer
überlangen qp-codierten Zeile machen...
7. Bei der qp-Decodierung wird das Zeichen 0x00 in Headern und Body
jetzt decodiert (bisher behielt es die codierte Form "=00" bei).
Offenbar wurde bisher angenommen, es könne sich bei qp-codierten
Nachrichten nur um Textnachrichten handeln, die kein 0x00 enthalten
können bzw. dürfen - aber auch Binärdaten können theoretisch
qp-codiert sein, denn das ergibt sich nicht aus der Art der Codie-
rung, sondern ausschließlich aus dem Header "Content-Type:" ...
(siehe dazu auch weiter unten).
8. Wie bisher schon bei Headerzeilen oder wenn sie uncodiert vorkamen,
werden in Textnachrichten die codierten Zeichen 0x00 und 0x1A (#26,
Ctrl-Z) nach der b64/qp- und Zeichensatz-Decodierung/Konvertierung
jetzt durch ein Leerzeichen bzw. ein ">" ersetzt. Das Zeichen 0x1A
würde sonst an einigen Stellen im Programm (z.B. im Editor) als EOF
(Dateiende) fehlinterpretiert werden.
ToDo: Da die Routinen für die UTF-7/8-Decodierung auch bei der Anzeige
von MIME-Multiparts im Lister verwendet werden, sind diese neuen
Änderungen noch auf Kompatibilität mit den bereits vorgenommenen
Bugfixes für die Anzeige langer Zeilen > 255 Zeichen zu prüfen
und die älteren Fixes ggf. anzupassen und/oder zu erweitern.
UUZ.PAS, UUZ0.PAS, MIMEDEC.PAS, TYPEFORM.PAS
MY:
- Redundanten Code für das Lesen des Body aller Nachrichtentypen (UUCP-
Mail, SMTP-Mail, Newsbatch) entrümpelt, in der neuen Routine
'ReadRfcBody' zusammengefaßt und optimiert.
UUZ.PAS, UUZ0.PAS
MY:
- Diverse notwendige Fixes für die zentrale Routine 'ReadString':
----------------------------------------------------------------------
1. Die Routine liefert jetzt am Zeilenende für die Variable 'eol'
(= Zeilenende erreicht) immer einen Wert von 2 zurück, und zwar
jetzt auch dann, wenn die Zeile zufällig genauso lang ist wie die
max. an die Stringvariable zurückzugebende Zeilenlänge (248 Zeichen
eingehend, 253 Zeichen ausgehend). Bisher wurde in solchen Fällen
ein Wert von 0 zurückgegeben (und daraus mitunter falsche Schlüsse
gezogen).
2. Am Dateiende wird jetzt ein Wert von 3 an 'eol' übergeben (auch,
wenn dort kein Zeilenumbruch (CR/LF) vorhanden sein sollte). Diese
Änderung hat den positiven Nebeneffekt, daß jetzt auch ZConnect-
Puffer in zu-Richtung ohne abschließenden Zeilenumbruch korrekt
konvertiert werden (bisher fehlte dann die letzte Zeile fast voll-
ständig, lediglich das erste Zeichen dieser Zeile wurde nahtlos an
das letzte Zeichen der vorherigen Zeile angehängt).
Damit können Routinen, die 'ReadString' aufrufen, jetzt sicher davon
ausgehen, daß bei 'eol=0' noch weitere Zeichen außer CR/LF in dersel-
ben Zeile folgen werden. Diese Änderung ist wichtig sowohl für die
oben im Zusammenhang mit UTF/base64/qp-Decodierung beschriebenen
Fixes als auch für das korrekte Lesen und Schreiben von Puffern
allgemein.
3. Endlosschleife bei der Konvertierung von News-Puffern, die als
Zeilenabschluß CR statt CRLF oder LF verwenden, behoben (zufällig
beim Testen entdeckt und in der Praxis noch nicht aufgetreten,
betrifft alle existierenden UUZs aller XP-Versionen). Der Enhanced
UUZ akzeptiert jetzt auch alleinstehende CR als Zeilenabschluß.
4. 'ReadString' hat schon bisher nur Teilstrings übergeben, die sauber
an einer Wortgrenze getrennt waren. Dabei wird neben Leerzeichen,
Komma und Semikolon jetzt auch das Tabulatorzeichen #9 als Trenn-
zeichen akzeptiert.
5. Damit Routinen, die 'ReadString' aufrufen, auch die nächsten im
Lesepuffer, aber wegen des Erreichens der max. Stringlänge nicht
mehr im aktuellen Teilstring befindlichen Zeichen prüfen können,
stellt 'ReadString' jetzt sicher, daß immer mindestens vier Zeichen
im Lesepuffer zur Verfügung stehen (sofern vorhanden). Ist das
zufällig nicht der Fall, obwohl das Dateiende noch nicht erreicht
ist, lädt 'ReadString' diese Zeichen nach. Diese Änderung ist
relevant z.B. für die vorzeitige Erkennung des Endes einer SMTP-
Mail (was wiederum notwendig für eine korrekte UTF-7/8-Decodierung
ist) als auch für das korrekte Entfernen der XP-typischen zwei
Leerzeichen am Ende jeder Zeile (siehe weiter unten), sowie für
alle anderen (zukünftigen) Routinen, die einen "look ahead" auf die
max. nächsten 5 Zeichen machen müssen.
UUZ0.PAS
MY:
- Fix: Wenn sich nach der RFC=>ZC-Konvertierung einer eingegangenen
Textnachricht (nicht bei Binärnachrichten!) kein Zeilenumbruch (CRLF)
am Ende des Puffers befindet, wird dieser jetzt hinzugefügt (kann
insbesondere bei base64-codierten Texten im Body vorkommen). Bisher
wurde der EMP:-Header einer nachfolgenden Nachricht in diesem Fall
nahtlos an das letzte Zeichen der vorherigen Nachricht angehängt. Der
Fall, daß der Puffer nur mit einem einzelnen CR oder LF abgeschlossen
ist, wird ebenfalls behandelt. Im Falle von SMTP-Mails (die mit den
Zeilen "." und "QUIT" enden) mußte hierfür die Logik beim Lesen des
Body dahingehend angepaßt werden, daß die Routine bereits den Inhalt
der nächsten Zeile prüft, während die aktuelle Zeile noch bearbeitet
wird (ansonsten könnte das Ende der Nachricht nicht "vorhergesehen"
und außerdem auch nicht die für die UTF-7/8-Decodierung notwendigen
Variablen 'start_of_UTF' und 'end_of_UTF' korrekt gesetzt werden,
siehe weiter oben).
UUZ0.PAS
MY:
- Fix (-uz): Zwei theoretisch mögliche (in der Praxis bisher nicht auf-
getretene) Endlosschleifen bei unvollständig/defekt base64-codierten
RFC-Headern, bei denen sowohl Header als auch das betreffende encoded
word länger als 255 Zeichen waren, in 'UTF8ToIBM' und 'DecodeEW' beho-
ben (letztere Schleife verbunden mit einem Crash, insofern nicht ganz
"endlos" ;-)).
In solchen Fällen wird der unvollständige Header jetzt soweit codiert
wie möglich und die übrigbleibende Restsequenz verworfen.
MIMEDEC.PAS
MY:
- Ausgehende Nachrichten (-zu) werden jetzt auch dann qp-codiert, wenn
sie keine 8bit-Zeichen enthalten. Sinnvoll, um die max. Zeilenlänge im
Body für den Transport einerseits auf 76 Zeichen begrenzen zu können
und andererseits zu verhindern, daß extrem lange Zeilen nach der von
RFC2822 definierten Grenze von 998 Zeichen - bzw. beim letzten Wort
davor - zwangsumbrochen werden müssen (lange qp-codierte Zeilen
enthalten 'soft line breaks', die Zeile wird bei der Decodierung
wieder zusammengesetzt; daher sind qp-codierte Zeilen in decodierter
Form prinzipiell nie längenbegrenzt).
UUZ.PAS
MY:
- Fix (-uz): Wenn ein RFC-Header mit mehr als 255 Zeichen an der letzten
Position des ersten zu decodierenden Teilstrings einen codierten
Zeilenumbruch (CR oder LF) enthielt (der durch ein Leerzeichen ersetzt
wurde) und der nächste Teilstring ebenfalls mit einem codierten
Zeilenumbruch oder mit einem Leerzeichen begann, dann entstanden zwei
Leerzeichen, obwohl ansonsten mehrere CR/LF hintereinander nur durch
ein einziges Leerzeichen ersetzt bzw. ganz entfernt wurden, wenn sich
links oder rechts davon bereits ein Leerzeichen befand. Dies ist ein
Fix für ein ebenfalls theoretisches und bisher in der Praxis nicht
aufgetretenes Szenario, weil Header keine codierten Zeilenumbrüche
enthalten (dürfen) und die Entscheidung, mehrere CR/LF hintereinander
durch nur ein Leerzeichen zu ersetzen bzw. ganz zu entfernen, ohnehin
völlig willkürlich ist (*daß* sie in irgendeiner Form entfernt werden
müssen, ist bei Headern allerdings zwingend und liegt in der Natur der
Sache).
MIMEDEC.PAS
MY:
- Fix (-uz): Der Header "X-XP-Version:", der bisher Priorität gegenüber
allen anderen Software-Headern besaß, verliert diese jetzt, wenn ein
anderer Software-Header existiert, dessen Beginn identisch mit dem
Inhalt von "X-XP-Version:" ist und der darüber hinaus weitere Zeichen
enthält. Damit bleiben Header, die Anhänge wie "via UKA_PPP x.xx",
"via XPNews" o.ä. enthalten, aber gegenüber "X-XP-Version:" ansonsten
unverändert sind, jetzt wieder erhalten.
UUZ.PAS
MY:
- Workaround für UKA_PPP-Software-Header bei Usenet-Postings: UKA_PPP
hat in einigen (allen?) Versionen beim Versenden von Postings die Ei-
genschaft, dem vom UUZ erzeugten Header "X-Newsreader:" einen weiteren
Header "X-Mailer:" mit dem Inhalt "NOS-BOX x.xx" oder "UKA_PPP x.xx"
hinzuzufügen. Da der UUZ bei der Konvertierung eingehender Nachrichten
im Falle mehrerer Software-Header immer den jeweils letzten in den
ZConnect-Header MAILER: geschrieben hat, konnten die Empfänger dieser
Postings oft nur den jeweiligen UKA_PPP-Eintrag sehen, nicht aber die
verwendete CrossPoint-Version.
Wenn ein Header "X-Mailer:" vorhanden ist, der mit "UKA_PPP" oder
"NOS-BOX" beginnt, dann wird dieser jetzt an einen etwaig zusätzlich
vorhandenen Software-Header mit dem Wort "via" angefügt, statt einen
bereits gelesenen Header zu ersetzen oder durch einen nachfolgenden
Haeder überschrieben zu werden. Damit wird derselbe String erzeugt,
den auch UKA_PPP selbst bei Mails im UUCP-Format (nicht aber bei Mails
im SMTP-Format) generiert.
Obwohl UKA_PPP den Header "X-Mailer:" am Ende des Gesamtheaders hinzu-
fügt und dieser daher immer erst *nach* dem Header "X-Newsreader:"
vorkommen sollte, ist nicht ausgeschlossen (und in der Praxis auch
schon vorgekommen), daß Clients oder Server die Reihenfolge der Header
ändern. Daher wurde der Workaround so konzipiert, daß die Reihenfolge
der Header in diesem Fall keine Rolle spielt.
Dieser Workaround unterstützt *keine* beliebig langen Zeilen. Wenn die
Summe aus dem UKA_PPP-Header und dem eigentlichen Software-Header
länger ist als ein Pascal-String, wird der UKA_PPP-Header verworfen
(wird aber in der Praxis nie vorkommen). Der Workaround ist zu unwich-
tig und das Eintreten des Szenarios zu unwahrscheinlich, als daß ein
höherer Aufwand zu rechtfertigen wäre.
UUZ.PAS
MY:
- Workaround für Endlosschleife bei der ZC=>RFC-Konvertierung von
defekten ZConnect-Puffern mit zu großem LEN:-Header: Alle bisher
existierenden UUZ-Versionen laufen in eine Endlosschleife, wenn der
LEN:-Header der einzigen oder letzten Nachricht im Puffer einen zu
hohen Wert enthielt. In diesem Fall liest der Enhanced UUZ jetzt die
Nachricht bis zum Dateiende und konvertiert sie somit korrekt.
Enthalten auch etwaige vorherige Nachrichten im Puffer LEN:-Header mit
zu hohen Werten, werden sie zwar konvertiert, aber wie bisher nicht
korrekt. Ziel des Workarounds war nicht die Reparatur defekter LEN-
Header (dafür gibt es den Puffer-Reparierer ZPR), sondern lediglich
das Vermeiden der Endlosschleife.
UUZ.PAS
MY:
- Behandlung von Leerzeichen am Zeilenende beim Schreiben des Nachrich-
tentextes (Body) ausgehender RFC-Nachrichten komplett überarbeitet:
----------------------------------------------------------------------
1. Es werden jetzt nur noch die XP-typischen zwei Leerzeichen am
Zeilenende bei fortlaufend umbrochenen Absätzen entfernt, jedoch
nicht mehr einzelne bzw. mehr als zwei Leerzeichen oder nur aus
Leerzeichen bestehende Zeilen (der Signaturtrenner war davon ohne-
hin auch bisher schon ausgenommen). Als "Zeile" gilt wie bisher
jede Zeile beliebiger Länge.
2. Dafür funktioniert das Entfernen der zwei Leerzeichen jetzt auch
in allen Fällen korrekt (befanden sich die Leerzeichen an Pos. 253
und 254, funktionierte es bisher z.B. nicht).
3. Wird die Nachricht qp-codiert, wird das letzte Leerzeichen am
absoluten Ende einer Zeile jetzt gemäß RFC2045 ebenfalls codiert
(bisher ging der UUZ davon aus, daß gar keine Leerzeichen vorhanden
sein können, was aber im Falle mehrerer Leerzeichen am Zeilenende
ab Pos. 252/253 hintereinander auch bisher schon nicht gewährlei-
stet war). Beim Signaturtrenner bestand dieses Problem aufgrund
einer Sonderbehandlung nicht, diese ist durch die generelle
Änderung jetzt aber überflüssig geworden und wurde daher entfernt.
UUZ.PAS
MY:
- Der für den Transport von SMTP-Mails am Zeilenanfang im Body hinzuzu-
fügende Punkt, wenn die Zeile selbst ebenfalls mit einem Punkt beginnt
("dot stuffing"), wird bei der Berechnung der max. zu schreibenden
Zeichen pro Zeile (998 ohne Codierung, 76 bei qp-Codierung) jetzt
ignoriert - die Zeilen können also in diesem Fall jetzt um jeweils 1
Zeichen länger werden, da der Punkt beim Transport ohnehin entfernt
wird.
Dasselbe gilt für News-Postings, bei denen der Punkt vom Client hinzu-
gefügt wird: Dort hat der UUZ deshalb bisher immer ein Zeichen Reserve
gelassen, dies passiert jetzt nicht mehr.
Das bisherige (und mit der ersten Fassung des Enhanced UUZ eingeführ-
te) Vorgehen war nicht wirklich falsch oder schädlich, aber unnötig
und ungewöhnlich.
UUZ.PAS
MY:
- Fix: Als Seiteneffekt der oben beschriebenen Bugfixes wurde ein Bug
behoben, der ebenfalls bisher weder aufgefallen noch aufgetreten ist:
Beim Schreiben der ohnehin nur informativen Header mit dem Prefix
"X-Orig-" (Kopie der jeweiligen originalen RFC-Headerzeile im
ZConnect-Header) konnte es unter seltenen Umständen passieren, daß ein
Leerzeichen zwischen zwei Worten entfernt wurde (die Decodierung des
Headers und somit das Resultat im BET:-Header waren trotzdem korrekt).
Unter welchen Umständen das genau passierte, wurde genauso wenig näher
untersucht wie die Frage, welchem der o.a. Fixes die Behebung dieses
Bugs zu verdanken ist. ;-)
Beobachtet wurde das Verhalten jedenfalls bei zwei encoded words,
wovon das erste exakt 254 Zeichen lang war (was in der Praxis ohnehin
nur bei von OpenXP produzierten Headern vorkommen kann und zudem
unzulässig ist).
???.PAS
MY:
- Logik beim Lesen des RFC-Headers etwas geändert, u.a. mit der konkre-
ten - in der Praxis aber kaum relevanten - Folge, daß bei Headern, die
mit einer beliebigen Anzahl vorlaufender Leerzeichen beginnen, diese
jetzt unter allen Umständen vollständig entfernt würden (bisher nur
die bis Pos. 253). Des weiteren hätte es in bestimmten - in der Praxis
ebenfalls noch nicht aufgetretenen - Szenarien passieren können, daß
die Routine falsche Schlüsse zieht und glaubt, sie befände sich am
Anfang des nächsten Headers, obwohl sie sich noch in der Fortsetzung
des aktuellen Headers befindet. Reine Vorsichtsmaßnahme.
UUZ.PAS
MY:
- Fix (-uz): Bei Nachrichten mit einem "Content-Type:"-Header, dessen
mehrere Parameter mit Semikolon, aber ohne anschließendes Leerzeichen
separiert waren, wurde bisher der Zeichensatz nicht korrekt ausge-
wertet, weil der unmittelbar nachfolgende Parameter für einen Teil des
Zeichensatznamens gehalten wurde (Fehlermeldung "ERR: Unsupported
character set: iso-8859-1;format=flowed"). In der Folge wurde der
Nachrichtentext dann auch nicht konvertiert. :-(
UUZ0.PAS
MY:
- Workaround: Einige Mail<=>News-Gates setzen offenbar Header in der
"neuen" Form 'Real Name <local.part@do.main>' in die auch intern von
XP verwendete "alte" Form 'local.part@do.main (Real Name)' um, verges-
sen dabei aber mitunter, die auch bei der neuen Form oft ohnehin über-
flüssig gesetzten Anführungszeichen vor und hinter dem Realname zu
entfernen. Die Routine des UUZ entfernt daher diese Anführungszeichen
gemäß RFC2822 bisher ebenfalls nicht (weil sog. quoted-strings in
Kommentaren - ein Realname in Klammern ist technisch betrachtet ein
Kommentar - eigentlich nicht als quoted-strings gelten).
Bei Headern, die in der alten Form vorliegen, werden etwaige Anfüh-
rungszeichen vor und hinter dem Realname jetzt trotzdem entfernt, wenn
sie sich wirklich am Anfang und Ende des Realname befinden und wenn
der Realname aus mindestens zwei Worten besteht (bei nur einem in
Anführungszeichen eingeschlossenen Wort wird davon ausgegangen, daß es
sich um einen "Nickname" o.ä. handelt, bei dem sie bewußt gesetzt
wurden).
MIMEDEC.PAS
MY:
- Geänderte Behandlung des ZConnect-Headers "Antwort-an:":
----------------------------------------------------------------------
-uz: Seit dem Erscheinen des ersten Enhanced UUZ wurden mehrere
Absender im From:-Header in mehrere ZConnect-Header ANTWORT-AN:
geschrieben (weil mehrere ABS:-Header laut ZConnect-Spezifikation
nicht zulässig sind, mehrere ANTWORT-AN:-Header aber schon). Die
Großschreibung sollte zur späteren Unterscheidung in FreeXP von
den "echten" Headern für Reply-To-Adressen in der bisherigen
Schreibweise "Antwort-an" dienen und erreichen, daß nach der noch
vorzunehmenden Erweiterung der Reply-To-All-Routine die Adressen
in den Headern ANTWORT-AN: als Absender erkannt und angezeigt
werden können. Da ANTWORT-AN: aber ausgerechnet der Standard-
schreibweise im ZConnect-Raum entspricht, hätte das nicht korrekt
funktioniert, wenn ZConnect-Puffer anderer Programme (z.B. von
OpenXP) in FreeXP eingelesen worden wären, die diese Standard-
schreibweise verwenden. FreeXP verwendet daher jetzt ebenfalls
die Standardschreibweise "ANTWORT-AN:" für "echte" Reply-To-
Adressen, für mehrere Adressen aus dem From:-Header jedoch jetzt
stattdessen die Schreibweise "antwort-An:", die mit an Sicherheit
grenzender Wahrscheinlichkeit von keinem anderen ZConnect-
Programm verwendet wird. Die zukünftige Reply-To-All-Routine muß
daher die genaue Schreibweise des Headers prüfen, um Absender-
und Reply-To-Adressen voneinander unterscheiden zu können (d.h.
auch, daß die frühere Schreibweise "Antwort-an:" und die aktuelle
Schreibweise "ANTWORT-AN:" gleichbehandelt werden, was im Sinne
der Abwärtskompatibilität sinnvoll und notwendig ist).
-zu: Folgerichtig prüft der UUZ bei der Konvertierung in zu-Richtung
jetzt die Schreibweise des Headers ANTWORT-AN: und erzeugt bei
Headern in der Schreibweise "antwort-An:" nicht mehr einen Header
"Reply-To:", sondern fügt die im Header enthaltene Adresse dem
Header "From:" hinzu (i.d.R. ist durch den ZConnect-Header ABS:
ja eine Absenderadresse bereits vorhanden), ein evtl. vorhandener
Realname wird dabei übernommen. Dies funktioniert mit so vielen
"antwort-An:"-Headern, wie in der Konstanten 'maxabs' als max.
Anzahl von Absendern definiert ist (derzeit 50).
Damit ist gewährleistet, daß sich nach einer unmittelbar aufein-
anderfolgenden RFC=>ZC=>RFC-Konvertierung (typisches Gate-
Szenario, das aber auch von XP-Anwendern praktiziert wird), sich
die Adressen aus dem ursprünglichen From:-Header auch wieder im
neu erzeugten From:-Header befinden.
UUZ0.PAS, XPMAKEHD.INC
MY:
- Variable 'control' von 150 auf midlen+9 vergrößert: 'midlen' (max.
Länge der Message-ID) hatte inzwischen eine Größe von 160 Zeichen,
daher wäre beim Versuch, eine Nachricht mit einer Message-ID von mehr
als 141 Zeichen Länge zu canceln, durch das Hinzufügen des Strings
'cancel' und der beiden spitzen Klammern ein unvollständiger Subject:-
Header erzeugt worden (in der Praxis ist dieser Fall offenbar bisher
nicht vorgekommen).
UUZ0.PAS
MY:
- Zeitzone "CEST" ergänzt (ausgerechnet die einzige korrekte Schreib-
weise für die Mitteleuropäische Sommerzeit - "Central European Summer
Time" - fehlte, falsche wie "MEST" hingegen wurden ausgewertet).
UUZ0.PAS
MY:
- Bei Zeitzonenangaben im "Date:"-Header, die die Zeitzone nicht direkt
über ein numerisches Offset, sondern über eine Abkürzung wie "CET"
angeben, kann es zudem vorkommen, daß die Sommerzeit mit dem Zusatz
"DST" (= "Daylight Saving Time") deklariert wird (scheint speziell bei
älteren unixoiden Systemen häufiger vorzukommen). Bisher wurde diese
Angabe ignoriert, jetzt erhöht der Enhanced UUZ das Offset in diesem
Fall um +1 und errechnet so die korrekte Lokalzeit.
UUZ0.PAS
MY:
- Fix (-uz): Der Kommandozeilenschalter "-graberec" (Adresse des
Envelope-Empfängers aus "Received:"-Headern auslesen) funktionierte
zwar intern noch, war aber nach außen ohne konkrete Wirkung, weil die
die Adresse enthaltende Variable nur dann ausgewertet wurde, wenn
gleichzeitig auch der Schalter "-UseEnvTo" angegeben worden war.
"-graberec" ist jetzt auch wieder ohne "-UseEnvTo" benutzbar; darüber
hinaus wird die aus dem "Received:"-Header ausgelesene Adresse jetzt
auf Plausibilität geprüft und anschließend derselben Behandlung
unterzogen (spitze Klammern, Kommentare usw. entfernen) wie alle
anderen Header, die Mail-Adressen enthalten. Dadurch werden etwaige
Strings nach dem Schlüsselwort "for", die gar keine Adressen sind
(kein "@" enthalten), jetzt sofort verworfen und in den folgenden
Received:-Headern weiter nach einer Adresse gesucht, statt nach dem
ersten gefundenen String die Suche abzubrechen und erst später
festzustellen, daß es sich gar nicht um eine Adresse handelt.
Werden "-graberec" und "-UseEnvTo" gleichzeitig angegeben, besitzt
"-graberec" jetzt niedrigere Priorität (auch, weil das Verfahren
ohnehin recht fragwürdig ist). In diesem Fall würden die "echten"
Envelope-Header (siehe Beschreibung der nächsten Änderung) Vorzug
genießen, aber so ist es immerhin möglich, beide Schalter sinnvoll
miteinander zu kombinieren und nur dann die aus den "Received:"-
Headern ausgelesene Adresse zu verwenden, wenn keiner der übrigen vom
UUZ unterstützten Envelope-Header vorhanden ist.
UUZ.PAS, UUZ0.PAS, MIMEDEC.PAS
MY:
- Zusätzlich zu den bisher schon unterstützten RFC-Headern für Envelope-
Empfänger ("Envelope-To:", "X-Envelope-To:", "Delivered-To:") werden
jetzt noch "X-Original-To:" (Postfix) und "Original-Recipient:" (gemäß
RFC2298) unterstützt. Bei letzterem wird ein etwaig vor der Adresse
angegebener Adresstyp (z.B. "rfc822;") entfernt.
Es "gewinnt" bei mehreren Headern immer der jeweils letzte vorkommen-
de. Lediglich der Header "Delivered-To:" besitzt wie bisher eine
niedrigere Priorität als die übrigen und wird nur verwendet, wenn
kein anderer der unterstützten Envelope-Header vorkommt (hat aber
immer noch Priorität gegenüber "-graberec", siehe oben).
UUZ.PAS
MY:
- Hinweise für Benutzer von UKA_PPP (nur ZConnect-Box):
Aus den bisherigen Erfahrungen mit dem Zusammenspiel von Enhanced UUZ
und dem Betrieb von UKA_PPP in einer ZConnect-Box resultieren einige
Empfehlungen, die nachfolgend zusammengefaßt sind und denen man folgen
sollte:
----------------------------------------------------------------------
1. Wie schon in der Dokumentation zur ersten Fassung des Enhanced UUZ
erwähnt, sollte der Aufruf des Programms X_SPOOL.EXE mit dem
Schalter "/xc" unmittelbar vor dem UUZ-Aufruf im Netcall-Script
(i.d.R. heißt diese Datei "XPNEWS") entfernt bzw. auskommentiert
werden. Damit wird die bisher mitunter fehlerhafte Deklaration von
Zeichensatz und deren Codierung vermieden, da die Funktion von
X_SPOOL.EXE nun stellvertretend und sehr viel besser vom Enhanced
UUZ (über den Schalter "-chkbody", siehe auch Punkt 2. b)) übernom-
men wird.
Es sind neben der Änderung des UUZ-Aufrufs (siehe Punkt 2. a)) noch
weitere Anpassungen am Script erforderlich; eine vollständige Über-
sicht ist unter Punkt 3. zu finden - bitte unbedingt *alle* dort
aufgeführten Änderungen vornehmen, um den korrekten Ablauf des
Netcalls sicherzustellen.
2. a) Der UUZ-Aufruf im Netcall-Script sollte nun wie folgt aussehen:
exec $homedir+"\uuz.exe -zu -client -chkbody outfile.z .\SPOOL"
Damit garantiert der Enhanced UUZ u.a., daß Headerzeilen mit
8bit-Zeichen korrekt MIME-codiert werden (die früheren Schalter
"-MIME" und "-1522" sind Default, nicht mehr abschaltbar und
daher überflüssig).
Bisher fehlte im Standardaufruf des UUZ im UKA_PPP-Script
schlicht der Schalter "-1522", so daß bei Verwendung älterer
UUZ-Versionen permanent Header mit uncodierten 8bit-Zeichen
erzeugt und versandt wurden (sog. "Hullen-Syndrom"). :-(
b) Der Schalter "-chkbody" (siehe auch Punkt 1.) stellt sicher, daß
der Body der Nachricht auf das Vorkommen von 8bit-Zeichen unter-
sucht und daher sowohl Zeichensatz als auch dessen Codierung
jetzt immer korrekt deklariert werden.
c) Zuguterletzt ist durch den Schalter "-client" gewährleistet, daß
Mails im SMTP-Format erstellt werden, die UKA_PPP unverändert
und korrekt versendet.
Zum Hintergrund:
Bei den bisher im UUCP-Format erstellten Mails hat UKA_PPP bei
der internen Umwandlung in das SMTP-Format im Falle von Mails
mit Kopienempfängern Änderungen an der Adressierung der Nach-
richten vornehmen müssen, um den Versand von Dupes zu vermeiden
(zudem wurde durch die etwas sonderbare, bei UUCP-Mails aber
notwendige Gestaltung der "To:"- und "Cc:"-Header seitens des
UUZ jedem der Cc:-Empfänger der falsche Eindruck vermittelt, er
selbst sei To:- und die übrigen Adressaten die Cc:-Empfänger).
Bei dieser Umwandlung hat UKA_PPP aber stellenweise nicht
berücksichtigt, daß Headerzeilen gefaltet sein können, was im
Betrieb mit dem Enhanced UUZ sogar zum Verlust von Kopienempfän-
gern ("Cc:") und/oder zur Kürzung des Subjects führen konnte.
Der Enhanced UUZ trägt insofern mit dazu bei, als daß er gemäß
RFC2822 Kopienempfänger kommasepariert in einen einzigen
"Cc:"-Header schreibt (statt mehrere einzelne "Cc:"-Header zu
erzeugen) und sowohl diesen wie auch den "Subject:"-Header bei
Bedarf faltet. Beides war beim "alten" UUZ nicht der Fall, aber
von dem bisherigen Verhalten gehen die Routinen in UKA_PPP aus.
Diese möglichen Probleme sind durch die direkte Erstellung von
SMTP-Mails über den Schalter "-client" automatisch behoben, da
UKA_PPP die Nachrichten nun nicht mehr umformatieren muß, dies
daher auch nicht tut und die Nachrichten 1:1 versendet.
Voraussetzung ist allerdings, daß die letzte aktuelle UKA_PPP-
Version v1.7x2 vom 25.04.2000 verwendet wird, alle vorherigen
Versionen sind für den direkten Versand von Mails im SMTP-Format
nicht geeignet.
3. Gleichzeitig werden durch den Schalter "-client" die ausgehenden
Nachrichten jetzt direkt mit den richtigen Dateinamen erzeugt und
durch die Angabe des Zielverzeichnisses ".\SPOOL" unmittelbar im
Spool-Verzeichnis von UKA_PPP abgelegt. Dies macht sämtliche Auf-
rufe von X_SPOOL.EXE sowie einige weitere Befehle im Script XPNEWS
überflüssig. Der Einfachheit und Übersichtlichkeit halber folgt der
entsprechende Block des Scripts, wobei alle zu entfernenden Befehle
mit einem "#" am Beginn der Zeile auskommentiert sind:
----------8<----------
[...]
# if $file "d-????.out",a$ > 0
# exec "x_spool.exe d-????.out /um"
# end if
if $file "outfile.z", a$ > 0
# exec "x_spool.exe outfile.z /xc"
exec $homedir+"\uuz.exe -zu -client -chkbody outfile.z .\SPOOL"
shell "del outfile.z"
# shell "del x-????.*"
# shell "del c-????.*"
# exec "x_spool.exe d-????.out /um"
end if
[...]
----------8<----------
Die auskommentierten Zeilen können auch ganz entfernt werden, dann
wird es etwas übersichtlicher:
----------8<----------
[...]
if $file "outfile.z", a$ > 0
exec $homedir+"\uuz.exe -zu -client -chkbody outfile.z .\SPOOL"
shell "del outfile.z"
end if
[...]
----------8<----------
Diese Hinweise gelten nicht für das Add-On für den Betrieb von UKA_PPP
in einer RFC/Client-Box, denn dort sind sie bereits von vorneherein
berücksichtigt. Der Betrieb in einer RFC/Client-Box ist dem in einer
ZConnect-Box aus vielerlei Gründen unbedingt vorzuziehen.
MY:
- Der Enhanced UUZ ist jetzt kompatibel mit XP2. :-)
XP2-Anwender, die den Enhanced UUZ einsetzen möchten (was zu empfehlen
ist), sollten unbedingt folgende Hinweise beachten:
----------------------------------------------------------------------
1. Unter Edit/Boxen/<Box>/Edit/Clients/UUZ-In kann folgende Aufruf-
zeile eingetragen werden:
UUZ.EXE -uz -ppp $SPOOL $PUFFER [bis v3.30.020 Beta]
UUZ.EXE -uz $SCREENLINES -ppp $SPOOL $PUFFER $BOX [ab v3.30pre..]
Dabei handelt es sich um den Default-Eintrag von XP2, der mit <F2>
vorgeschlagen wird und nicht angepaßt werden muß. Der Eintrag kann
aber auch ganz entfallen, dann wird der ebenfalls funktionierende
Standardaufruf von XP2 verwendet.
2. Unter Edit/Boxen/<Box>/Edit/Clients/UUZ-Out ist folgende Aufruf-
zeile einzutragen:
UUZ.EXE -zu -ppp $PUFFER $SPOOL [bis v3.30.020 Beta]
UUZ.EXE -zu $SCREENLINES -ppp $PUFFER $SPOOL [ab v3.30pre..]
Diesen Eintrag sollte man vornehmen, aber auch hier würde der weit
umfangreichere Standardaufruf von XP2 funktionieren (die Parameter
"MIME" und "-1522" sind beim Enhanced UUZ Default, nicht mehr
abschaltbar und daher überflüssig, und der Parameter "-SMTP" ist
durch "-ppp" bereits impliziert).
Ebenfalls überflüssig und auch wirkungslos ist der XP2-spezifische
Parameter "-absnsstyle", der dazu führen soll, daß Absenderadressen
in der "neuen" Form 'Real Name <local.part@do.main>' erzeugt werden
(statt in der alten Form 'local.part@do.main (Real Name)'). Das
macht der Enhanced UUZ ohnehin per Default, nur codiert er dabei
die Headerzeile im Unterschied zum XP2-UUZ auch in allen Fällen
korrekt.
3. Wer seine ausgehenden Nachrichten einer quoted-printable-Codierung
unterziehen möchte (was beim UUZ von XP2 unbedingt zu vermeiden -
weil gnadenlos kaputt -, beim Enhanced UUZ aber sogar zu empfehlen
ist), muß, wenn ein manueller Eintrag im Feld "UUZ-Out" vorhanden
ist, dort den Parameter "-qp" ergänzen.
Ist kein manueller Eintrag vorhanden, reicht es, den Schalter
"MIME: quoted-printable verwenden" unter C/O/E/V zu aktivieren.
4. Der Enhanced UUZ erkennt im Betrieb mit XP2 automatisch, daß er
sich XP2-kompatibel zu verhalten hat. :-) Dazu liest er die erste
Zeile der XPOINT.CFG ein und prüft auf das Vorkommen des Strings
"XP2".
Wer dieser Automatik nicht traut oder den Enhanced UUZ im Extern-
betrieb zu einem XP2-kompatiblen Verhalten zwingen möchte, kann/muß
zusätzlich den Parameter "-xp2" im UUZ-Aufruf angeben.
5. Wenn man den Enhanced UUZ nur mit "uuz" aufruft, wird man auf der
Hilfeseite einen weiteren Parameter "-chkbody" entdecken. Dieser
Parameter ist im XP2-Modus automatisch aktiviert, muß daher nicht
mit angegeben werden und hat zur Folge, daß der UUZ den Body jeder
Nachricht auf das Vorkommen von 8bit-Zeichen prüft und in der Folge
selbständig und korrekt den Zeichensatz und dessen Codierung in den
RFC-Headern "Content-Type:" und "Content-Transfer-Encoding:"
deklariert.
Diese Maßnahme war notwendig, um die Gefahr fehlerhaft deklarierter
Nachrichten zu eliminieren, denn die Deklaration, die XP2 dem UUZ
über den selbst generierten Header "X-Charset:" mitteilt und die
dieser ansonsten übernehmen würde, ist mitunter fehlerhaft.
Beispiel: Ein Text, der das Paragraphenzeichen "", aber ansonsten
nur 7bit-Zeichen enthält, würde von XP2 im Header "X-Charset:"
nicht als ISO-8859-1, sondern gar nicht deklariert werden. Das
Zeichen "" wird aber bei der IBM=>ISO-Konvertierung vom ursprüng-
lichen Wert #21 (Steuerzeichen in CP437) in das 8bit-Zeichen #167
in ISO-8859-1 konvertiert. Mangels korrekter Deklaration seitens
XP2 würde also eine 8bit-Nachricht, aber ohne bzw. mit falscher
Zeichensatz-/Codierungsdeklaration "US-ASCII" und "7bit" erzeugt
werden (kein deklarierter Zeichensatz ist immer gleichbedeutend mit
US-ASCII und 7bit). Dasselbe Resultat entsteht, wenn man z.B. über
das Clipboard oder per Taste <Alt-nnn> 8bit-Zeichen, die keine
Umlaute (äöüßÄÖÜ) *und* in ISO-8859-1 enthalten sind (also z.B.
Akzentzeichen wie " ‚¡¢£") in eine Nachricht einfügt, für die über
die Brettgruppe oder den User der ASCII-Zeichensatz definiert wurde
- diese Zeichen konvertiert XP2 eben nicht nach ASCII (sondern in
das entsprechende Zeichen in ISO-8859-1) und erzeugt so eine 8bit-
Nachricht, ohne dies entsprechend zu deklarieren.
Umgekehrt deklariert XP2 mitunter bei Nachrichten an Nicht-ASCII-
Bretter/-User als Zeichensatz ISO-8859-1, obwohl US-ASCII richtig
und ausreichend wäre (nämlich bei Zeichen wie #224 "à" (kleines
alpha), die, weil sie in ISO-8859-1 nicht vorhanden sind, in ein
7bit-Zeichen - in diesem Fall "a" - transliteriert werden), da es
nicht den Ziel-, sondern den Quellzeichensatz auf das Vorkommen von
8bit-Zeichen prüft (übrigens ein genereller Fehler aller früheren
XP-Versionen).
Alle diese Fehler werden durch den im XP2-Modus automatisch akti-
vierten Parameter "-chkbody" korrigiert.
6. Die Kompatibilität des Enhanced UUZ mit XP2 besteht im einzelnen
aus folgenden Komponenten:
a) Bei der RFC=>ZC-Konvertierung eingehender Nachrichten werden
diese an einen evtl. bereits (oder noch) vorhandenen ZC-Puffer
"3PPUFFER" angehängt. In einer FreeXP-Umgebung wird ein bereits
existierender ZC-Puffer mit der Endung .BAK versehen und in
jedem Fall ein neuer erzeugt. Dieses Verhalten würde bei XP2
mitunter - speziell bei Multiserver-Netcalls - zu Datenverlust
führen.
b) Die Behandlung ausgehender und eingehender Cancel-Nachrichten
entspricht dem (auch schon bei früheren XP-Versionen üblichen)
Verfahren über ausschließlich den Betreff-Header. Bei FreeXP
wird dies zusätzlich über die ZC-konformen Header "STAT: CTL"
und "CONTROL: cancel [MsgID]" geregelt (wodurch auch ZConnect-
User canceln können), die aber von XP2 nicht unterstützt
werden.
c) Alle XP2-spezifischen Funktionen (Header "X-XP-Mode" für HdrOnly
und MsgID-Request, Parameter "-bBoxname" für die Auswertung des
Boxnamens bei der Konvertierung eingehender Nachrichten) werden
vom Enhanced UUZ unterstützt. :-)
d) Darüber hinaus gelten alle in dieser Dokumentation beschriebenen
Fixes, Änderungen und Erweiterungen für XP2 in gleichem Maße wie
für FreeXP.
Es ist allerdings darauf hinzuweisen, daß sich die vielfältigen
Änderungen, Korrekturen und Erweiterungen im Bereich der Deco-
dierung und Konvertierung von Zeichensätzen nur bei Singlepart-
Nachrichten auswirken, da Multipart-Nachrichten nicht vom UUZ,
sondern von XP selbst decodiert/konvertiert werden. Es kann
daher in Einzelfällen zu Inkonsistenzen kommen (d.h. derselbe
Text würde vom Enhanced UUZ u.U. anders und richtiger decodiert
und/oder konvertiert werden als er von XP2 in einer Multipart-
Nachricht decodiert/konvertiert wird).
e) Der Enhanced UUZ wurde mit folgenden XP2-Versionen erfolgreich
getestet:
CrossPoint [XP2] v3.30.020 Beta (21.02.2001)
CrossPoint [XP2] v3.30.pre6 (27.12.2001)
CrossPoint [XP2] v3.30.pre7 (20.04.2002)
CrossPoint [XP2] v3.31.006 (20.04.2002)
UUZ.PAS, UUZ0.PAS
MY+MW:
- Zusätzlich zum Header "X-RFC-Converter:" werden Datum und Uhrzeit der
verwendeten UUZ-Version jetzt auch auf der Hilfeseite (Aufruf "uuz"
ohne Parameter) ausgegeben. In beiden Fällen wird dazu jetzt nicht
mehr der Zeitstempel der Datei verwendet (weil sich dieser durch
Entpack- und Kopiervorgänge verändern kann), sondern es wird der echte
Zeitpunkt der Compilierung fest eincompiliert, kann nicht mehr verän-
dert werden und erlaubt so eine sichere Indentifizierung der verwende-
ten UUZ-Version.
Dies geschieht über die neue Unit COMPDATE.PAS, die vom ebenfalls
neuen Hilfsprogramm GENDATE.PAS bei jeder via BUILD.BAT angestoßenen
Compilierung neu erzeugt wird und die aktuellen Datums- und Uhrzeit-
werte in Konstanten zur Verfügung stellt. Im Zuge dieser Änderung
wurde auch das Format des Datums umgestellt (von TT/MM/JJ auf
JJJJ/MM/TT).
Compilate, die aus der IDE der Entwicklungsumgebung von Borland Pascal
heraus erstellt wurden (z.B. zu Testzwecken), verwenden nach wie vor
den Zeitstempel der Datei, da dort das Verfahren mit der Unit
COMPDATE.PAS nicht funktionieren kann.
Das Eincompilieren des exakten Zeitpunkts der Compilierung wird später
auch bei anderen Programmen (XP, ZPR, ZFIDO, MAGGI usw.) Anwendung
finden.
UUZ0.PAS [+GENDATE.PAS, +COMPDATE.PAS]
MY:
- Optik-Fix: Da die Anzahl der verfügbaren UUZ-Optionen sowie ihre
Erläuterungen im Laufe der Zeit umfangreicher geworden sind und jetzt
auch der Compile-Timestamp in einer zusätzlichen Zeile ausgegeben wird
(siehe vorherige Änderung), passt die Ausgabe der Hilfeseite inklusive
des UUZ-Logos beim Standardwert von 25 Zeilen nicht mehr auf eine
Bildschirmseite. Die Ausgabe hält daher jetzt je nach aktueller
Zeilenanzahl rechtzeitig an und wartet auf einen Tastendruck.
UUZ0.PAS
MY:
- Fix (-zu): Bei der Übergabe des Zielverzeichnisses funktionierte die
Angabe eines relativen Pfades wie ".\" (= aktuelles Verzeichnis) oder
"..\" (= eine Verzeichnisebene höher) nicht, wenn dieser im Ergebnis
auf das Hauptverzeichnis des aktuellen Laufwerks verwies. Die Ursache
lag in der zentralen Routine 'IsPath()', die diesen Fall nicht geprüft
hat. Die Angabe relativer Pfade funktioniert jetzt in allen Fällen und
die Änderung wirkt sich auf alle Routinen in FreeXP insgesamt aus, die
'IsPath()' verwenden.
FILEIO.PAS
MY:
- Fix (-uz): Wenn beim manuellen Aufruf des UUZ (z.B. beim Testen) für
Quell- und Zieldatei versehentlich derselbe Dateiname angegeben wurde
und die Quelldatei existierte, wurde sie mit einer 0-Byte-Datei über-
schrieben und somit vernichtet (im XP2-Modus wurde hingegen der kon-
vertierte ZConnect-Puffer an die originale RFC-Nachricht angehängt,
was auch nicht zu einem viel sinnvolleren Ergebnis führt).
In beiden Fällen wird jetzt eine Fehlermeldung wegen einer "ungültigen
Zieldatei" ausgegeben. Der Test ist allerdings sehr simpel und prüft
nur auf Gleichheit der Strings - er läßt sich daher durch die Angabe
eines absoluten und eines relativen Pfades, die beide auf dasselbe
Verzeichnis verweisen, gewaltsam austricksen (wenn man das unbedingt
möchte). Mehr Aufwand ist an dieser Stelle nicht gerechtfertigt, weil
hier nur versehentliche Tippfehler im Test- oder Externbetrieb abge-
fangen werden sollen, die im Normalbetrieb mit FreeXP oder XP2 nicht
vorkommen können (und daher auch noch nie vorgekommen sind).
UUZ0.PAS
MY:
- Inkonsistenz beseitigt (-uz): Im Falle, daß ein Header mit identischer
Bedeutung in der RFC-Nachricht mehrfach existierte (sowas kommt z.B.
bei Software- oder Envelope-Headern schon mal vor), wurde per Design
der letzte vorkommende Header berücksichtigt. Handelte es sich dabei
jedoch um einen Header, der die max. Länge eines Pascal-Strings über-
schritt und daher im Array 'LongHdr' abgelegt werden mußte, hatte
jeweils der erste vorkommende Header "gewonnen" (Pointervariable wurde
in 'SaveLongHdr' nicht disposed, wenn sie bereits einen Wert hatte).
Jetzt wird in *beiden* Fällen der jeweils letzte vorkommende Header
berücksichtigt (außer, es gelten für den betreffenden Header irgend-
welche Sonderregeln).
UUZ0.PAS
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
MY:
- Behandlung der Header "X-Gateway:" und "GATE:" geändert:
(Quelle zu diesem Thema:
http://www.dt.e-technik.uni-dortmund.de/~ma/gatebau97/Gb97/node2.html)
-uz: Der Header "X-Gateway:" wird in RFC=>ZC-Richtung jetzt in den
GateBau'97-konformen Header "GATE:" konvertiert (bisher behielt
er die ursprüngliche Bezeichnung aus der RFC-Nachricht bei).
-zu: Die Header "GATE:" und "X-Gateway:" werden in ZC=>RFC-Richtung
jetzt in den Header "X-Gateway:" konvertiert (bisher wurden sie
komplett ignoriert). Sollte eine ZConnect-Nachricht beide Header
enthalten, hat der Header "GATE:" Vorrang vor "X-Gateway:". Diese
Behandlung in zu-Richtung findet allerdings nur dann statt, wenn
die Datei 'ADDGATE' im UUZ-Verzeichnis existiert und ihre erste
Zeile nicht leer ist (siehe nächste Änderung unten). Sie ist nur
für echten Gatebetrieb von Bedeutung und für XP-User irrelevant;
im Normalbetrieb mit XP (und/oder wenn die Datei 'ADDGATE' nicht
existiert) werden die Header "GATE:" bzw. "X-Gateway:" in
zu-Richtung wie bisher ignoriert.
UUZ.PAS, UUZ0.PAS, XPMAKEHD.INC
MY:
- Über die erste Zeile der Datei 'ADDGATE' im UUZ-Verzeichnis kann jetzt
eine Gateway-Domain definiert werden, die in folgender Form dem Inhalt
eines etwaig existierenden Headers "X-Gateway:" (RFC=>ZC) bzw. "GATE:"
oder ebenfalls "X-Gateway:" (ZC=>RFC) vorangestellt wird:
- RFC=>ZC: "RFC1036/2822/2047 <Domain> [<UUZ-Version>]"
- ZC=>RFC: "ZCONNECT <Domain> [<UUZ-Version>]"
Existiert in der Quellnachricht kein Header "X-Gateway:" bzw. "GATE:",
wird er in der Zielnachricht neu erzeugt; anderenfalls wird der zu-
sätzliche Eintrag vom bereits existierenden Headerinhalt mit einem
Komma separiert.
Die Gesamtlänge des hinzuzufügenden Gateway-Strings ist derzeit auf
120 Zeichen begrenzt. Hinsichtlich der Header in Quell- und Zielnach-
richt werden jedoch beliebig lange Zeilen (bis 65500 Zeichen) unter-
stützt.
Diese Erweiterung ist nur für echten Gatebetrieb von Bedeutung und für
XP-Anwender daher irrelevant (genauer gesagt: XP-Anwender sollten die
Verwendung dieser Funktion unbedingt vermeiden, um keine unsinnigen
und falschen Gateway-Header zu erzeugen).
UUZ.PAS, UUZ0.PAS, XPMAKEHD.INC
MY:
- Fix (-uz): Erkennung von Text-/Binärnachrichten komplett überarbeitet
----------------------------------------------------------------------
Anläßlich eines ausschließlich aus Textteilen bestehenden, aber
dennoch im Header "Content-Transfer-Encoding:" als "binary" deklarier-
ten Newsletters von T-Online im MIME-Multipart-Format, dessen konver-
tierter ZConnect-Puffer infolgedessen vom UUZ mit dem ZConnect-Header
"TYP: BIN" und daher in XP mit dem Flag "B" versehen und dort auch als
Binärnachricht behandelt wurde, wurde deutlich, daß die bisherigen
Regeln für die Klassifizierung als Text- oder Binärnachricht untaug-
lich bzw. schlicht falsch waren. Die Erkennung als Text- oder Binär-
nachricht wird daher jetzt nur noch ausschließlich vom Inhalt des
Headers "Content-Type:" abhängig gemacht:
a) Alle Nachrichten vom "Media Type" text/*, multipart/* und message/*
(ergänzt wurde message/*) gelten als Textnachrichten (UUZ erzeugt
keinen "TYP:"-Header). Im Falle der "Composite Media Types"
multipart/* und message/* ist das deswegen richtig, weil die
Nachricht bzw. ihre Bestandteile zwar (codierte) binäre Komponenten
- auch gemischt mit Textkomponenten - enthalten kann, diese aber
nicht vom UUZ, sondern erst später in XP selbst beim Öffnen oder
Extrahieren des jeweiligen Nachrichtenteils behandelt und ggf.
decodiert werden.
b) Demzufolge gelten als Binärnachrichten nur noch alle Singlepart-
Nachrichten vom "Media Type" application/*, image/*, audio/*,
video/* und model/* (UUZ erzeugt den Header "TYP: BIN").
c) Keinen Einfluß auf die Klassifizierung als Text- oder Binärnach-
richt mehr haben hingegen die Deklarationen "binary", "base64" oder
"quoted-printable" im Header "Content-Transfer-Encoding:": Es
handelt sich hierbei um die Transportcodierung, die keinerlei
Rückschlüsse auf den Typ der Nachricht (Text oder Binär) zuläßt.
Bisher konnte es aufgrund der unvollständigen Prüfung auf "base64"
und "binary" fälschlicherweise vorkommen, daß einerseits qp-codier-
te Binärnachrichten als Textnachrichten, andererseits aber base64-
codierte oder als "binary" deklarierte Text- oder Multipart-Nach-
richten als Binärnachrichten erkannt wurden.
d) Anmerkung zur Deklaration "Content-Transfer-Encoding: binary":
Obwohl der Header den Schluß nahelegt (und prinzipiell auch dafür
gedacht ist), es handele sich hierbei um uncodierte Binärdaten und
die Nachricht sei daher als Binärnachricht zu klassifizieren, ist
der Transport uncodierter Binärdaten im RFC-Raum bisher weder
standardisiert noch findet er in der Praxis statt (siehe Abschnitt
6.2. in RFC2045). Es gibt derzeit keine Umstände, unter denen die
Deklaration "binary" gültig wäre, daher ist sie zu ignorieren bzw.
wie "8bit" zu behandeln. Der UUZ ist, da er in uz-Richtung seit
jeher ausschließlich zeilenorientiert arbeitet, auf die korrekte
Behandlung eingehender uncodierter Binärdaten auch gar nicht ausge-
legt und die Lese- und Schreibroutinen müßten umfassenden Änderun-
gen unterzogen werden, um die (beabsichtigte) Ersetzung von Zeilen-
umbrüchen (LF=>CRLF) und die damit verbundene Veränderung uncodier-
ter Binärdaten zu verhindern - aber selbst dann würden diese Daten
immer noch und in gleicher Weise von SMTP/NNTP-Clients wie UKAW
unbrauchbar gemacht werden, noch bevor der UUZ sie überhaupt zu
Gesicht bekäme - ein Umbau des UUZ in dieser Hinsicht ist auf
absehbare Zukunft also weder notwendig noch sinnvoll.
e) Die Variablen 'mpart' und 'binaer' werden jetzt nicht mehr an drei
verschiedenen Stellen gesetzt, sondern nur noch einmal zentral in
der Routine 'MimeAuswerten'.
Die beschriebenen Änderungen führen in der Praxis u.a. dazu, daß beim
Beantworten von bisher fälschlicherweise als Binärnachricht erkannten
Textnachrichten keine überflüssige Rückfrage mehr erfolgt, ob man
die vermeintliche Binärnachricht wirklich quoten wolle (umgekehrt
erfolgt die Rückfrage jetzt bei qp-codierten Binärnachrichten, wo sie
bisher unterblieben wäre). Des weiteren findet bei bisher fälsch-
licherweise als Binärnachricht erkannten Singlepart-Textnachrichten
jetzt die erforderliche Zeichensatzkonvertierung statt, und es ist
sichergestellt, daß das weiter oben beschriebene Anhängen von Zeilen-
umbrüchen (CRLF) an das Ende eines ZConnect-Puffers im Bedarfsfall nur
noch bei echten (dafür jetzt aber auch bei *allen*) Textnachrichten
erfolgt.
Zwingend notwendig waren diese Änderungen aber auch noch aus einem
anderen Grund: Da der UUZ ZConnect-Nachrichten mit dem Header
"TYP: BIN" konsequent als Binärnachrichten betrachtet, hat er folge-
richtig bei einer ZC=>RFC-Konvertierung den kompletten Body der
erzeugten RFC-Nachricht base64-codiert. Im Falle von als "binary"
deklarierten Multipart-Nachrichten führte also eine unmittelbar auf-
einanderfolgende RFC=>ZC=>RFC-Konvertierung dazu, daß die Struktur der
Multipart-Nachricht vollständig zerstört wurde.
UUZ.PAS, UUZ0.PAS
MY:
- Interne Änderung: Die bisher nur in zu-Richtung und jetzt auch in
uz-Richtung (siehe unten) verwendete globale Variable 'convibm' wurde
nach 'convcharset' umbenannt.
UUZ.PAS, UUZ0.PAS
MY:
- Fix (-uz): Die bisherige Regel, daß alle Multipart-Nachrichten sowie
Singlepart-Nachrichten vom "Subtype" */html keiner Zeichensatzkonver-
tierung seitens des UUZ unterzogen werden, wurde auf folgende Content-
Types erweitert:
a) message/* - ähnlich wie multipart/* ein "Composite Media Type", der
eine RFC-Nachricht, die ihrerseits aus mehreren Teilen bestehen
kann, enthält. Die Zeichensatzkonvertierung würde das Original-
format der Nachricht zerstören. (Evtl. ist eine spätere direkte
Unterstützung dieses speziellen Content-Type in FreeXP vorgesehen.)
b) */richtext und */enriched (RTF, siehe RFC1896) - ähnlich wie */html
ein Format, das von XP nicht selbst interpretiert und konvertiert
wird und daher zur korrekten Darstellung ebenfalls an ein externes
Programm übergeben werden muß. Umlaute und Sonderzeichen würden
nach einer Konvertierung in den IBM-Zeichensatz nicht mehr richtig
dargestellt werden können.
Intern wird die Entscheidung über die Zeichensatzkonvertierung jetzt
einmal zentral in der Routine 'MimeAuswerten' getroffen und in der
globalen Variablen 'convcharset' gespeichert, die dann an den jewei-
ligen Stellen ausgewertet wird (statt wie bisher die Entscheidung
mehrfach und jedes Mal neu - und teilweise nach unterschiedlichen
Kriterien - zu treffen).
UUZ.PAS, UUZ0.PAS
MY:
- Weitere Fixes und Änderungen bei der Auswertung und Erzeugung des
Headers "(U-)Content-Type:":
----------------------------------------------------------------------
Zwar wurden Singlepart-Nachrichten vom Subtyp */html bei der RFC=>ZC-
Konvertierung keiner Zeichensatzkonvertierung unterzogen, aber auf den
eigentlich zwingend logischen Gedanken, daß man solche Nachrichten in
ZC=>RFC-Richtung dann ebenfalls keiner Zeichensatzkonvertierung unter-
ziehen darf, schien bisher niemand gekommen zu sein.
Des weiteren wurden Textnachrichten ungeachtet des tatsächlichen und
aus dem Header "U-Content-Type:" klar ersichtlichen Subtyps pauschal
als "text/plain" deklariert, und der MIME-Typ message/* wurde gleich
völlig ignoriert und daher ebenfalls als "text/plain" deklariert.
Ergebnis waren gnadenlos kaputtkonvertierte und grundfalsch dekla-
rierte Nachrichten. :-(
Zur Ehrenrettung muß man zwar hinzufügen, daß sich dieses Verhalten im
Normalbetrieb mit XP nicht auswirkte, weil XP weder HTML-Nachrichten
noch den MIME-Typ message/* erzeugt, aber XP-Anwender, die den UUZ aus
verschiedensten Gründen für eine RFC=>ZC=>RFC-Konvertierung einsetzen
(solche Fälle sind aus der Realität bekannt) und Gatebetreiber wurden
mit defekten Nachrichten "belohnt".
Es wurden daher folgende Gegenmaßnahmen ergriffen:
-uz: Singlepart-Textnachrichten vom Subtyp */html, */richtext und
*/enriched werden nicht nur wie oben beschrieben keiner Zeichen-
satzkonvertierung mehr unterzogen, sondern es wird auch ein ggf.
im Header "Content-Type:" deklarierter Zeichensatz in den
ZConnect-Header "CHARSET:" geschrieben (wobei, sofern möglich,
der Zeichensatzname in die ZConnect-typische Bezeichnung ("ISO1",
"ISO9" usw.) übersetzt wird). Dadurch alleine ist bei einer nach-
folgenden Konvertierung in ZC=>RFC-Richtung bereits garantiert,
daß keine Zeichensatzkonvertierung mehr stattfindet (siehe Erläu-
terungen weiter oben zu den umfassenden Änderungen und Erweite-
rungen zum Thema Zeichensatzauswertung und -behandlung von
ZConnect-Nachrichten).
Das Erzeugen des Headers "CHARSET:" hat übrigens auch den ange-
nehmen Nebeneffekt, daß beim Lesen solcher Nachrichten wenigstens
die im Text vorhandenen 8bit-Zeichen in den IBM-Zeichensatz kon-
vertiert und dadurch lesbar dargestellt werden - und vielleicht
spendiert ja doch nochmal jemand einen einfachen HTML-Parser für
FreeXP, dann könnten solche HTML-only-Nachrichten sogar dort
halbwegs brauchbar verarbeitet werden...
-zu: Sollte bei einer Singlepart-Nachricht vom Subtyp */html,
*/richtext oder */enriched kein Zeichensatz deklariert gewesen
sein, existiert auch der ZConnect-Header "CHARSET:" nicht, und
die Nachricht würde normalerweise der Standardkonvertierung in
den Zeichensatz ISO-8859-1 unterzogen werden. Dieses wird jetzt
ebenfalls gezielt verhindert, denn auch solche Nachrichten können
natürlich 8bit-Zeichen enthalten, die bei einer Konvertierung
zerstört würden. Es wird allerdings trotz des Vorkommens von
8bit-Zeichen kein Zeichensatz deklariert (nicht einmal bei Ver-
wendung des Schalters "-chkbody"), weil dieser schlicht nicht
bekannt ist.
Gleichzeitig wird der Subtyp solcher Nachrichten jetzt korrekt
deklariert, eine Nachricht vom MIME-Typ "text/enriched" oder
"text/html" wird jetzt also nicht mehr kurzerhand zu "text/plain"
umdeklariert.
Dasselbe gilt folgerichtig jetzt auch für Nachrichten vom MIME-
Typ message/*: Es findet keine Zeichensatzkonvertierung mehr
statt und der MIME-Typ im Header "Content-Type:" wird korrekt
beibehalten (eine etwaige Zeichensatzdeklaration im äußeren
"Content-Type:"-Header ist hier irrelevant und dürfte gar nicht
vorkommen).
UUZ.PAS, UUZ0.PAS
MY:
- Optik-Fix (-uz): Bei der im Falle eines nicht unterstützten Zeichen-
satzes erzeugten Fehlermeldung "ERR: Unsupported character set:" wird
der Name des Zeichensatzes jetzt in der Schreibweise, wie sie im
Header "Content-Type:" der RFC-Nachricht verwendet wurde, wiedergege-
ben (statt wie bisher in Kleinschreibung).
Im Falle, daß ohnehin keine Zeichensatzkonvertierung stattfindet, weil
eines der oben beschriebenen Kriterien erfüllt ist (MIME-Multipart
o.ä.) wird der Header erst gar nicht mehr erzeugt.
UUZ0.PAS
MY:
- Fix (-uz): Der Enhanced UUZ fängt jetzt unzulässige Deklarationen im
Header "Content-Transfer-Encoding:" ab: Da bei den "Composite Media
Types" multipart/* und message/* nur "7bit", "8bit" und "binary" als
Transportcodierung im äußeren "Content-Transfer-Encoding:"-Header
zulässig sind, wird jede unzulässige Deklaration wie "base64" oder
"quoted-printable" jetzt ignoriert, die Nachricht wie "8bit" behandelt
und daher nicht decodiert (bisher wurden in diesem Fall einzelne
Nachrichtenteile im Body, deren Codierung zufällig mit der im äußeren
"Content-Transfer-Encoding:"-Header deklarierten Codierung identisch
war, fälschlicherweise decodiert).
Für einzelne Subtypes des MIME-Typs message/* existieren noch restrik-
tivere Einschränkungen hinsichtlich der zulässigen Codierungen; da UUZ
"7bit", "8bit" und "binary" aber ohnehin gleichbehandelt (nämlich nur
liest und nicht decodiert), müssen diese nicht gesondert berücksich-
tigt werden.
UUZ0.PAS
MY:
- Interne Änderung (-zu): Lokale Variable 'binmail' in 'ZtoU' entsorgt;
stattdessen wird jetzt die bisher nur in uz-Richtung verwendete
globale Variable 'binaer' eingesetzt und ebenso wie die Variable
'mpart' nun einmal zentral in der Routine 'SetMimeData' gesetzt (statt
wie bisher außerhalb an zwei verschiedenen Stellen). 'binaer' ist
jetzt wieder true, wenn typ='B' (nicht wenn typ<>'T').
UUZ.PAS, UUZ0.PAS
MY:
- Bei Binärnachrichten wird jetzt auch für Singleparts (= Schalter
"Binärnachrichten als 'MIME-Multipart-Attachments'" unter C/O/E/V
deaktiviert) der Header "Content-Disposition:" gemäß RFC2183 mit den
Parametern "attachment", Dateiname ("filename="), Dateidatum
("modification-date=") und jetzt auch Dateigröße ("size=") erzeugt.
Daher entfallen die bisherigen (und nicht standardkonformen) Parameter
"name=" und "x-date" im Header "Content-Type:" sowohl bei Singlepart-
als auch bei Multipart-Attachments - bei letzteren waren diese Angaben
ohnehin redundant, da bei vom UUZ erzeugten Multipart-Binaries schon
immer ein innerer Header "Content-Disposition:" mit den genannten
Parametern - vom neuen Parameter "size=" abgesehen - erzeugt wurde.
UUZ.PAS
MY:
- (-zu): MIME-Boundary (wird bei der Konvertierung von mit "i" auf
Userbrett in XP erzeugten Binärnachrichten in eine Multipart-Nachricht
erzeugt) an die in den MIME-Multipart-Routinen von FreeXP verwendete
Fassung angeglichen und als eigene Funktion nach mimedec.pas verlagert
(zwecks späterer Verwendung auch in FreeXP). Das Boundary hat jetzt
die Form "-==_FreeXP_Next_MIME_Part_[Zufallsstring]_==-".
UUZ.PAS, UUZ0.PAS, MIMEDEC.PAS
MY:
- Interne Änderung (-zu/uz): Länge des MIME-Boundaries im Record
'header' von 70 auf 100 Zeichen erhöht und damit an die Länge im
Record 'mimedata' angepaßt.
UUZ0.PAS, XP0.PAS, XPMAKEHD.INC
MY:
- Fix (-zu): Bei MIME-Nachrichten vom Typ multipart/related werden jetzt
gemäß RFC2387 die bisher schlicht unterschlagenen Parameter "start="
und "start-info" beachtet und in den neu erzeugten äußeren "Content-
Type:"-Header geschrieben.
UUZ.PAS, UUZ0.PAS, XPMAKEHD.INC
MY:
- Fix (-zu): Beim Schreiben des äußeren "Content-Type:"-Headers von
Multipart-Nachrichten wird jetzt die Länge des Typs, des Boundary-
Delimiters und weiterer etwaiger Parameter beachtet und der Header bei
Bedarf (d.h. wenn er länger als 78 Zeichen würde) gefaltet. Bisher
wurden alle Parameter ungeachtet der Gesamtlänge grundsätzlich in eine
einzige Zeile geschrieben (was auch zu Zeichenverlust führen konnte).
Da der Header "Content-Type:" samt seiner vielfältigen Parameter in
einer eigenen Routine verarbeitet wird, läuft er nicht wie andere
Header durch die Routine 'EncodeFoldQuote', die diese Behandlung auto-
matisch vorgenommen hätte.
UUZ.PAS
MY:
- Bezeichnung des Schalters "-gate" (-zu) in "-chkbody" geändert:
Da im Verlaufe der Entwicklung und der praktischen Anwendung des
Enhanced UUZ der Schalter "-gate", der den Body von ZConnect-Nachrich-
ten auf das Vorkommen von 8bit-Zeichen prüft und dabei fehlerhafte
Deklarationen von Zeichensatz und Transportcodierung repariert, seine
ursprüngliche, rein gate-typische Bedeutung verloren hat und auch im
XP-Umfeld zum Einsatz kommt (speziell im Betrieb mit UKA_PPP, wo er
unbedingt zu empfehlen, sowie mit XP2, wo er ohnehin Default ist),
wurde die etwas irreführende Bezeichnung "-gate" in die wesentlich
treffendere und aussagekräftigere Bezeichnung "-chkbody" geändert (im
Sinne der Abwärtskompatibilität funktioniert die Angabe von "-gate"
aber nach wie vor).
Alle früheren Referenzen in diesem Dokument auf den Schalter "-gate"
wurden in "-chkbody" geändert.
UUZ.PAS, UUZ0.PAS
MY:
- Im Zusammenhang mit der vorstehenden Änderung wird die Erzeugung des
Headers "X-XP-Version:" bei der ZC=>RFC-Konvertierung jetzt auch nicht
mehr vom Schalter "-gate" (bzw. jetzt "-chkbody") abhängig gemacht,
sondern als Merkmal für echten Gatebetrieb dient jetzt ausschließlich
die Existenz einer nicht-leeren ersten Zeile in der Datei 'ADDGATE' im
UUZ-Verzeichnis (siehe dazu weiter oben). Nur wenn diese existiert,
wird der Header "X-XP-Version:" nicht mehr erzeugt.
Es ist absolut zu vermeiden, die Erzeugung des Headers "X-XP-Version:"
im Normalbetrieb mit XP damit verhindern zu wollen, daß man die Datei
'ADDGATE' mit einer nicht-leeren ersten Zeile erzeugt - es würden dann
speziell bei ausgehenden RFC-Nachrichten völlig falsche und unsinnige
Header "X-Gateway:" erzeugt werden.
Der Header "X-XP-Version:" wird in absehbarer Zeit voraussichtlich
ohnehin wieder eliminiert werden, sobald dessen Notwendigkeit nach
Lage der Dinge nicht mehr gegeben ist.
UUZ.PAS
MY:
- Fix (-uz): Wenn der allererste (auf die mit "From ..." beginnende
erste Zeile folgende) RFC-Header einer UUCP-Mail zu den Headern
gehörte, die mit dem Prefix "U-" in die ZConnect-Nachricht geschrieben
werden (z.B. "X-Envelope-To:" => "U-X-Envelope-To:"), dann wurde die
Headerbezeichnung - bis auf das erste Zeichen - in Kleinschreibung
übernommen. Jetzt wird die Originalschreibweise verwendet.
UUZ.PAS
MY:
- Sub-Versionsnummer für den UUZ eingeführt, die auf der UUZ-Hilfeseite
und im Header "X-RFC-Converter:" hinter der Hauptversionsnummer von XP
ausgegeben wird. Da die Entwicklung von FreeXP und des UUZ nicht
zwangsläufig synchron verlaufen, lassen sich so die jeweiligen UUZ-
Versionen besser voneinander unterscheiden (statt wie bisher nur am
Dateidatum identifiziert werden zu können).
UUZ0.PAS
MY:
- Aufgrund der Fülle und Relevanz der Änderungen, Fixes und Erweiterun-
gen dieser neuen Version (oder Generation?) des Enhanced UUZ wurde der
'Marketingname' des Programms zwecks leichterer Unterscheidung zum
Vorgänger (z.B. in Newsgroup-Diskussionen o.ä.) in "Enhanced UUZ/II"
geändert (abgekürzt "E-UUZ/II").
UUZ0.PAS
- Beteiligte Entwickler an diesen UUZ-Version(en):
----------------------------------------------------------------------
MY - Michael Heydekamp (Programmierung und Dokumentation)
- Credits für diese UUZ-Version(en):
----------------------------------------------------------------------
Johann Addicks - Diverse Anregungen (z.B. Charset-Fallback,
Gateway-Header und -Domain)
Oliver Gampe - Erstmalige Erkennung des Problems bei der Deco-
dierung von Multibyte-Zeichensätzen (UTF-7/8)
Joachim Merkel - Analysen im Zusammenhang mit dem gemeinsamen
Betrieb von Enhanced UUZ und UKA_PPP
Hans-Jürgen Tänzer - Erkennung diverser Bugs und Anregung, den echten
Compilierungszeitpunkt fest zu verdrahten
-+
Uwe Morgener |
Franklin Schiftan +- Testen der Kompatibilität mit XP2
Jörg Tewes |
-+
Und alle hier nicht namentlich genannten Anwender des Enhanced UUZ,
die durch ihr Feedback zu einer weiteren Verbesserung des Programms
beigetragen haben.