+- 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.