 UUZ_ENH.TXT ͻ
                                                            
  Vollstndige Dokumentation aller nderungen               
  des "Enhanced UUZ" seit dem 28.04.2002                    
  (c) 2003-2006 FreeXP <support@freexp.de>                  
                                                21.01.2006  
ͼ

   Dieser Text liegt im Zeichensatz IBM437 vor und sollte
   mit einem DOS-Programm betrachtet und gelesen werden
   (oder z.B. mit dem internen Lister des Total Commander,
   dort mit "s" den "ASCII-Zeichensatz" aktivieren).

   Die Reihenfolge der nderungen ist chronologisch absteigend
   sortiert (neueste nderungen zuerst).


+-----------------------------------------------------+
|  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 fr "mbox"- und "raw"-Format,
  bessere Absicherung gegen defekte RFC-Puffer, neue und erweiterte
  Funktionen (u.a. Erzeugung des Headers "User-Agent:", Untersttzung
  langer und gefalteter RFC-Headerzeilen in MAIL.RFC und NEWS.RFC, Para-
  meterbergabe via UUZ.OPT).
========================================================================

MY:
- Fix (-uz): Logik-Bug in der MIME-Decodierung behoben
  ----------------------------------------------------------------------
  In dem in der tglichen 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 grer/gleich der Anzahl der fr 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 vllig
  unbrauchbaren Nachricht oder gar einem (theoretischen, weil bisher
  in der Praxis nicht vorgekommenen) Absturz kommen konnte.
  Der Bug wurde vom Autor rein zufllig anllich 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 enthlt 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 unblich,
     mglicherweise 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 fhren wrde - bzw. in der
     Vergangenheit auch konkret dazu gefhrt hat. (Beispiel: Nachricht
     wird am Abend des letzten Tages der Sommerperiode erzeugt, aber
     erst in der Nacht oder am nchsten 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
        zustzlich geprft, 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
        unverndert bernommen.
        Magebend fr die Definition der Zeitperiode ist ausschlielich
        die aktuell fr die EU geltende Regelung, deren Algorithmus auch
        bei der automatischen Zeitzonenumstellung in FreeXP verwendet
        wird. Die Angabe "S" bzw. "W" im ZConnect-Header ist unzuverls-
        sig und wird wie bisher ignoriert.
        Das obige Verfahren funktioniert daher in allen Fllen zuverls-
        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 drfte). 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 vllig unabhngig von der im EDA:-Header
        deklarierten Zeitzone des Erstellungsdatums bernommen.
        Das obige Beispiel gilt fr Mitteleuropa und wrde in der
        Winterperiode die Zeitzone "+0100" (ZConnect: W+1) und in der
        Sommerperiode die Zeitzone "+0200" (ZConnect: S+2) zurckgeben.
        Fr andere Lnder sind die Werte entsprechend anzupassen, eine
        ausfhrliche Erluterung zur TZ-Variablen befindet sich in der
        FreeXP-Hilfe zum Menpunkt C/O/N/Umstellung.
        Durch die Auswertung der TZ-Variablen ist der UUZ daher in der
        Lage, in allen Lndern 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 knnen Nachrichten aus beliebigen Zeitzonen vorkommen (aus
        denen ohne TZ-Variable unterschiedliche lokale Zeitzonen berech-
        net wrden), whrend dem UUZ im Standardbetrieb mit XP nur Nach-
        richten aus einer einzigen Zeitzone (nmlich der des Users)
        vorgelegt werden.
  5. Enthlt 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 zufallsabhngigen Zeichens als "Vorzeichen"
     ungltig war.
  6. Ist der EDA:-Header leer bzw. existiert berhaupt nicht, wird statt
     eines ungltigen "Date:"-Headers mit dem Inhalt " Jan  ::  0000"
     jetzt ein gltiger 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, whrend "+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 spter) 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 unabhngig davon, wann diese statt-
     fand, also auch noch Tage oder Wochen spter - flschlicherweise
     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 Neujahrsgre verfat. ;-)
  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. Grnde:
  1. Der Header wird von den groen Newsservern (news.t-online.de,
     news.individual.de) ohnehin mit "not-for-mail" berschrieben und
     ist i.d.R. schon von daher berflssig. Manche Newsserver wie
     news.individual.de "sichern" den ursprnglichen "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 fr diesen Header; er
     wird daher auch von keinem (dem Autor bekannten) Newsreader
     generiert.
  3. Der Header enthlt 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 bewut
     sein, da sie den ZConnect-Header ROT: ebenfalls anpassen mssten,
     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 ursprnglichen Header aber als "X-Orig-Path:"
     sichert. Es wrde daher unbewut 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 Miverstndnissen hinsichtlich des "Path:"-Headers
     und infolgedessen zu Fragen an den User, die oft nicht (oder nicht
     korrekt) beantwortet werden knnen.
  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 mssen, von 4 auf 5
  erhht (Vorbereitung fr mbox-Untersttzung).
  UUZ0.PAS

MY:
- Anpassungen und Korrekturen in der Routine 'ReadRFCheader' (auch im
  Vorgriff auf mbox-Untersttzung, siehe nchster Abschnitt, -uz):
  ----------------------------------------------------------------------
  1. Die Routine prft jetzt - hnlich wie bisher schon 'ReadRfcBody' -
     bei der RFC=>ZC-Konvertierung von SMTP- und mbox-Mails anhand der
     einschlgigen Merkmale (".", "From_") "vorausschauend" auf das Ende
     der Nachricht. Wird festgestellt, da die Mail in der nchsten
     Zeile beendet ist (bzw. im Falle mbox, da mit der nchsten Zeile
     eine neue Mail beginnt), wird das Lesen des Headers abgebrochen.
  2. Ungltige RFC-Headerzeilen mit einem Bezeichner, der Leerzeichen
     oder andere ungltige Zeichen auerhalb des zulssigen Bereichs
     33d-126d enthlt, werden jetzt verworfen. Solche Header knnten
     sonst dazu fhren, da der Puffer nicht verarbeitet werden kann.
     Auerdem bestnde 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 enthlt.
  3. Nicht mehr verworfen hingegen werden Zeilen mit/ohne Leerzeichen
     oder Doppelpunkten, die sich *nach* einer *unmittelbar* auf die
     Schlsselzeilen "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 enthlt. 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 fhren,
     wenn der bergebene String leer war (was z.B. vorkommt, wenn eine
     Zeile im Header keinen Doppelpunkt - und also keinen Bezeichner -
     enthlt).
  Alle beschriebenen Manahmen 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 Fllen zu mitunter (zuflligen) fatalen Folgen wie
     Abstrzen, Endlosschleifen oder defekten ZConnect-Puffern zu
     fhren, und
  b) Anfang und Ende jeder Nachricht in Puffern mit mehreren Nachrichten
     unter allen (un)denkbaren Umstnden sicher und korrekt zu erkennen,
     auch wenn der Bereich zwischen den jeweiligen Schlsselzeilen
     ("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 (natrlich
     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-Untersttzung war ein
  Teil dieser Manahmen 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 untersttzt neben UUCP- und (B)SMTP-Mails jetzt
     auch Mailpuffer im mbox-Format. Damit knnen mbox-Puffer, die von
     den meisten Mailreadern beim Export erzeugt werden und beliebig
     viele Nachrichten enthalten knnen, in das ZConnect-Format konver-
     tiert und anschlieend 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 gngigsten explizit untersttzt:
     -----------------------------------------
     - mboxo  (irreversibles ">From_ quoting")
     - mboxrd (reversibles ">From_ quoting")
     -----------------------------------------
     Da der Anfang jeder mbox-Mail ausschlielich an einer mit "From_"
     (wobei der Unterstrich fr 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 knnen.
     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, whrend 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-
               stndig 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 htten entfernt werden sollen. Dies ist prinzip-
               bedingt nicht zu vermeiden.
     - mboxrd: Die meisten Mailreader drften allerdings inzwischen das
               mboxrd-Format verwenden. Dort existiert dieses Problem
               nicht, weil eine ursprnglich mit ">From_" beginnende
               Zeile beim Schreiben des mbox-Puffers zu ">>From_" umge-
               wandelt (und vom UUZ wieder zu ">From_" zurckgewandelt)
               wird. Da sich beim mboxrd-Format theoretisch beliebig
               viele ">" vor einer mit "From_" beginnenden Zeile befin-
               den knnen, wird auch der Fall abgefangen, da die Anzahl
               der ">" grer ist als die maximale Lnge 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 darber,
     welches mbox-Format sie untersttzen 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 Mglichkeit 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 Mglichkeit, UUCP-Mails
     programmseitig sicher und zuverlssig von mbox-Mailpuffern zu
     unterscheiden. Zwar knnen 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 zuverlssig genug, auerdem lge selbst dann immer
     noch keine Information darber vor, *welches* mbox-Format konver-
     tiert werden soll.
     Es war daher nicht zu vermeiden, fr die jeweiligen mbox-Formate
     eigene Kommandozeilenparameter zur Verfgung zu stellen und die
     Verantwortung fr deren korrekte Verwendung dem User aufzuerlegen:
     -----------------------------------------------------------------
     - Parameter "-mboxo" fr das mboxo-Format;
     - Parameter "-mboxrd" bzw. schlicht "-mbox" (weil Quasi-Standard)
       fr 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 zustzlich 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 verlt).
  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 gewhrleistet, da alle in diesem
     Dokument an anderer Stelle ausfhrlich beschriebenen Fixes und
     Korrekturen fr 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 fr 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 untersttzt).
  7. Die Formate "mboxcl" und "mboxcl2", die sich von den obigen durch
     die Existenz eines Content-Length-Headers unterscheiden, werden
     zwar nicht explizit untersttzt, knnen aber - mit geringfgigen
     Einschrnkungen - dennoch mit der vorliegenden Fassung des E-UUZ/II
     konvertiert werden (bei beiden Formaten ist *ausschlielich* der
     Parameter "-mboxo" zu verwenden!):
     -------------------------------------------------------------------
     - mboxcl:  Verwendet dasselbe irreversible ">From_ quoting" wie das
                mboxo-Format und daher gelten hierfr 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 verlt
                sich stattdessen ganz auf die - wenn man den verwendeten
                Quellen glauben darf, allerdings unzuverlssige -
                Grenangabe im Content-Length-Header. Es kann daher
                passieren, da bei der Konvertierung flschlicherweise
                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 Glck auch selten bis gar nicht verwendet.
     -------------------------------------------------------------------
     Der Aufwand fr eine "richtige" Untersttzung fr diese seltenen
     mbox-Formate wre momentan nicht zu rechtfertigen.
  8. Die mbox-Untersttzung wurde mit groer Sorgfalt entwickelt und
     so intensiv wie mglich 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 untersttzten Formaten
     fhren knnen.
  9. Quellen, die fr die Entwicklung der mbox-Untersttzung 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 erfllt 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 mssen, vor dem absoluten Pufferende
     (=> 'add2buf' wird aufgerufen, liest bis zu 4 nchste 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 vollstndig bzw. bis zum
     Dateiende gefllt htte).
  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 fhren.
  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 fhrte).
  2. Bei Group-Adressierung wie
     -----------------------------------------------------------------
       Group1: <my@freexp.de>, <mw@freexp.de>; Group2: <theo@test.de>;
     -----------------------------------------------------------------
     wird bei der Suche nach dem die Group abschlieenden Semikolon
     jetzt bercksichtigt, ob es sich inmitten eines Kommentars, quoted-
     strings oder einer Adresse befindet (bisher wre in einem solchen
     Fall das Semikolon flschlicherweise fr den Abschlu der Group
     gehalten worden). Anschlieend 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 zurckzusetzen und
     den Header ab der korrekten Position weiterzulesen, wurde die
     Schleife berflssigerweise an einer zu spten 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
     Gesamtlnge des ROT:-Headers grer als die max. Stringlnge wurde,
     wurde ein "langer" Header im dafr vorgesehenen char-Array angelegt
     und der dafr notwendige Speicher reserviert. Wenn sich anschlies-
     send aber herausstellte, da der hinter dem Schlsselwort "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 ursprnglich reservierte Speicher freigege-
     ben, sondern ein um die Stringlnge+1 des hinter "by " stehenden
     Mailservers reduzierter Wert. Darber hinaus wurde in diesem Fall
     das char-Array fr den langen Header evtl. unntigerweise angelegt,
     denn der hinter dem Schlsselwort "from " stehende Server htte
     alleine meistens noch in den String gepat.
     Durch diese fehlerhafte Vorgehensweise fragmentierte der zur Verf-
     gung stehende Hauptspeicher und es kam bei der Konvertierung extrem
     groer Mailpuffer (= mehrere tausend Nachrichten) zu einem kontinu-
     ierlichen Speicherverlust, der in einen RTE 203 (Heap-berlauf)
     mnden 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 fhren zu knnen.
  2. Wenn der String eines hinter dem Schlsselwort "by " im
     "Received:"-Header eingetragenen Mailservers identisch war mit dem
     rechten Teil des aktuell letzten (und gleichzeitig lngeren)
     Eintrags im ROT:-Header, dann wurde dieser Server flschlicherweise
     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 anschlieend 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 Schlsselwort "from " stehende Server
     mit dem Namen "by" jetzt 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 Schlsselwort "from "
     (in diesem Fall "ruby") zufllig identisch war mit dem Schlssel-
     wort "by ", dann wurde nicht der hinter "by " stehende Server in
     den ROT:-Header bernommen, sondern das Schlsselwort "by" als
     vermeintlicher Server selbst (bzw. es wrde aufgrund der unter 4.
     beschriebenen nderung jetzt verworfen werden). Es wird jetzt
     geprft, ob sich das Schlsselwort ganz am Anfang des Headers oder
     anderenfalls ein Leerzeichen davor befindet. Falls nicht, wird die
     Suche nach dem Schlsselwort 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 Prfung, ob der resultierende
     Header noch in einen Pascal-String pat oder bereits ein char-Array
     fr einen langen Header angelegt werden mu, auf einen zu hohen
     (253 statt 248 Zeichen) geprft, weil die Lnge des Bezeichners
     "ROT: " nicht bercksichtigt wurde. Dies konnte bei ROT:-Headern,
     deren resultierende Gesamtlnge (ohne Bezeichner) zwischen 249 und
     253 Zeichen lag, zu einem Zeichenverlust am Ende des Headers fhren
     (der Verlust trat jedoch dann nicht ein, wenn die Routine im Falle
     des unter Punkt 1. beschriebenen Szenarios unntigerweise 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
     angehngt und in den resultierenden ROT:-Header bernommen.
     Da dieses Verhalten weder bei Mail noch bei News wnschenswert und
     korrekt ist, wird jetzt wie folgt verfahren:
     - Bei Mails wird ein "Path:"-Header hinsichtlich des ROT:-Headers
       jetzt grundstzlich ignoriert (dafr im Unterschied zu frher
       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
     Beschrnkungen aufgehoben, die trotz der Untersttzung eines
     beliebig langen ROT:-Headers und des Schreibens des originalen
     "Received:"-Headers als "U-Received:" in ebenfalls beliebiger Lnge
     immer noch bestanden:
     - Es wrden jetzt auch Mailserver korrekt ausgewertet werden, die
       sich jenseits des 253. Zeichens im "Received:"-Header befinden.
     - Die Lnge des Namens eines Mailservers ist nicht mehr auf 255
       Zeichen begrenzt.
     Zugegebenermaen 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 htte.
  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 lt.
  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 berflssiger ZC-Header
  Diskussion-in: erzeugt, gleichzeitig aber auch der fr diesen Header
  reservierte Speicher nicht wieder freigegeben. hnlich wie bei dem in
  Punkt 1. des vorstehenden Abschnitts beschriebenen Szenario htte dies
  in Extremfllen zu einem kontinuierlichen Speicherverlust mit
  anschlieendem RTE 203 fhren knnen (dazu htte der Newspuffer je
  nach Lnge des Namens der Newsgroup und dem beim Start des E-UUZ zur
  Verfgung stehenden Hauptspeichers ca. 150 Postings enthalten mssen,
  auf die diese Randbedingung zutrifft).
  UUZ.PAS, UUZ0.PAS

MY:
- Interne nderung (-uz): Das via 'allocMem' in einem Dummy-Array reser-
  vierte Speicherminimum fr lange ZC-Header wird jetzt nach der Konver-
  tierung jeder Nachricht komplett freigegeben und vollstndig neu
  reserviert (statt nur fr die Header den Speicher neu zu reservieren,
  die in der vorherigen Nachricht vorkamen). Dies dient der Vermeidung
  einer theoretisch mglichen Fragmentierung des Hauptspeichers.
  Des weiteren prft 'allocMem' jetzt zustzlich auf die Verfgbarkeit
  des Speichers fr das anschlieend anzulegende char-Array 'HdrLine',
  in das jede RFC-Headerzeile eingelesen wird, und bricht im Falle, da
  dieser Speicher nicht verfgbar 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 Prfungen auf verfgbaren Haupt-
  speicher via 'MaxAvail', bei denen mittels Addition auf mehrere
  Elemente gleichzeitig geprft, anschlieend der Hauptspeicher aber
  fr jedes Element einzeln angefordert wird, wird mittels der neuen
  Subroutine 'GetMemAmount' vor der Addition der tatschlich von BP
  angeforderte Speicher (der immer ein Vielfaches von 8 betrgt) berech-
  net. Theoretisch htte es sonst passieren knnen, da die Prfung auf
  den verfgbaren Speicher positiv ausfllt, der angeforderte Speicher
  anschlieend aber gar nicht zur Verfgung steht. Beispiel: Bei 16
  verfgbaren Bytes wre eine Prfung auf 3+4+8=15 Bytes positiv
  ausgefallen. Angefordert worden wren aber anschlieend 8+8+8=24
  Bytes.
  UUZ.PAS, UUZ0.PAS

MY:
- Fehlerlog fr Speicherlecks implementiert (-uz): Der E-UUZ/II prft
  jetzt vor und nach der Konvertierung jeder einzelnen Nachricht die
  Menge des verfgbaren 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 auslsenden
  Nachricht). An eine ggf. bereits existierende Logdatei wird immer
  angehngt. Seit den oben beschrieben Fixes konnte bisher jedoch kein
  Fehlerlog mehr gesichtet werden. :)
  UUZ.PAS, UUZ0.PAS

MY:
- Angabe problematischer Dateinamen fr Quell- und Zieldatei abgefangen
  (-uz/-zu): Smtliche 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 zulssig.
  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 zustzlichen 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 gelscht.
  Die Routine prft nur auf den reinen Kommandozeilen-String und lt
  sich durch Angabe eines absoluten oder relativen Pfades vor dem
  Dateinamen gewaltsam austricksen. Ein hherer Aufwand wre 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 knnen.
  UUZ0.PAS

MY:
- Interne nderung (-uz): Die Dateien MAIL.RFC, NEWS.RFC und ADDPATH,
  die die in zu-Richtung zustzlich in die RFC-Nachricht zu schreibenden
  Header bzw. einen voranzustellenden Pfad enthalten, werden in
  uz-Richtung jetzt nicht mehr berflssigerweise eingelesen bzw.
  geprft.
  UUZ0.PAS

MY:
- Optik-Fixes (-uz): Bei der Konvertierung groer RFC-Puffer mit mehr
  als 99.999 Nachrichten versagte die Anzeige der Anzahl der aktuell
  konvertierten Nachrichten und der Bildschirm wurde mit Zeichenmll
  gefllt. Anzeige von bisher fnf- auf jetzt sechsstellige Zahlenwerte
  ausgelegt (max. 10 Stellen wren mglich, sieht aber auch bld 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 hheren der beiden Werte (dadurch
  werden sowohl grere Werte korrekt dar- als auch keine berflssigen
  Leerzeichen mehr vorangestellt).
  UUZ.PAS

MY:
- Optik-Fix (-zu): Anzeige der aktuellen und gesamten Anzahl von News
  und Mails rechtsbndig ausgerichtet und auf 6 Stellen ausgelegt.
  UUZ.PAS

MY:
- Fixes und Erweiterungen bei der Verarbeitung zustzlicher
  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 zustzlich in die RFC-Nachricht zu schreibenden
  Headerzeilen bestanden bisher folgende Beschrnkungen bzw. Probleme:
  - Die Zeilen durften nicht lnger als 253 Zeichen sein (lngere Zeilen
    wurden abgeschnitten).
  - Gefaltete (d.h. mit einem Leer- oder TAB-Zeichen beginnende) Header-
    zeilen wurden, wenn sie nicht zufllig bis Pos. 3 einen Doppelpunkt
    enthielten, nicht untersttzt, sondern als "Illegal Line" betrachtet
    und die Verarbeitung der Datei wurde komplett abgebrochen.
  - Andererseits fand nur eine vllig unzureichende Prfung auf gltige
    RFC-Headerzeilen statt (Doppelpunkt bis Pos. 3 war ausreichend, um
    eine Headerzeile als gltig zu betrachten).
  - Es konnten max. 10 Headerzeilen verarbeitet werden.
  Alle diese Beschrnkungen/Probleme bestehen nicht mehr. :-) Es werden
  jetzt beliebig lange und auch gefoldete Headerzeilen untersttzt,
  wobei hinsichtlich der Gltigkeit einer RFC-Headerzeile folgende
  Regeln gem RFC2822 gelten:
  - Die Headerzeile darf nicht lnger als 998 Zeichen sein (lngere
    Zeilen mssen gefoldet werden).
  - Auf die fr Mails empfohlene max. Zeilenlnge von 78 Zeichen wird
    nicht geprft (weil eben "nur" empfohlen).
  - Der Bezeichner ('field name') und der Inhalt ('field body') des
    Headers drfen nur zulssige Zeichen enthalten (d.h. insbesondere
    keine 8bit-Zeichen, aber es gelten je nach Kontext weitere und
    unterschiedliche Beschrnkungen).
  - Der Inhalt einer Headerzeile ('field body') darf weder leer sein
    noch nur aus Leer- oder TAB-Zeichen bestehen.
  - Die Gltigkeit einer evtl. vorhandenen MIME-Codierung wird nicht
    berprft 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 Beschrnkung, die im Sinne der Vermeidung
    bertrieben groer RFC-Header besteht, ist die Gesamtgre der Datei
    (max. 65500 Bytes, was fr einen RFC-Header eindeutig schon zuviel
    wre).
  - Evtl. vorhandene Leerzeilen werden nicht als ungltig zurckgewie-
    sen, beim Schreiben der Header aber ignoriert (eine Leerzeile leitet
    per Definition den Body der Nachricht ein).
  Wird in der Datei eine ungltige Zeile festgestellt, wird die gesamte
  Datei wie bisher nicht verarbeitet. Wurden alle Zeilen als gltig
  erkannt, werden sie "as is" geschrieben (d.h. keiner weiteren Ver-
  arbeitung wie MIME-Codierung o.. unterzogen), auer da ein evtl.
  versehentlich vorangestelltes Prefix "U-" entfernt wird. Die zustz-
  lichen Headerzeilen werden jetzt an einer frheren Stelle geschrieben
  (vor "X-RFC-Converter:" statt wie bisher hinter "Lines:").
  Soll ein RFC-Header MIME-codiert und/oder gefoldet werden, lt sich
  der E-UUZ dafr als Tool einsetzen:
  a) Dummy-ZC-Puffer erstellen,
  b) gewnschten 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 fr Mail und News unterschiedliche Regeln hinsichtlich des Foldens
  gelten, ist dabei darauf zu achten, da der ZC-Puffer einen passenden
  Empfnger (Mailadresse oder Newsgroup) enthlt. Wenn der Bezeichner
  ('field name') des eigenen Headers in MAIL.RFC krzer oder lnger als
  "Subject:" ist, ist das Folding ggf. manuell anzupassen und dabei auf
  korrekte Zeilenlngen zu achten (max. 78, wenn die Zeile kein 'encoded
  word' enthlt, max. 76, wenn sie eines enthlt). Sofern es sich bei
  dem eigenen Header um einen strukturierten Header handelt, der Mail-
  adressen o.. enthlt, darf nicht die BET:-Zeile, sondern mssen z.B.
  EMP: oder KOP: fr die Erstellung eines RFC-konformen Headers heran-
  gezogen werden.
  UUZ.PAS, UUZ0.PAS

MY:
- Workaround Fr VSoup-Software-Header analog zum schon seit lngerem
  existierenden Workaround fr UKA_PPP-Software-Header, weitere Details
  siehe dort (-uz):
  VSoup fgt dem vom UUZ erzeugten Software-Header zustzlich 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 verndert,
  dann wurde u.U. der VSoup-Header berschrieben).
  Der Inhalt des VSoup-Headers wird jetzt mit "via" an den XP-Header
  angehngt, unabhngig von der Reihenfolge des Auftretens. Dieser
  Workaround untersttzt *keine* beliebig langen Zeilen. Sollte die
  Zeile durch die Stringaddition lnger 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 fr fast alle Inkarnationen
  von ZConnect-MAILER:-Headern der unter der "alten" SLizenz weiterent-
  wickelten CrossPoint-Versionen jetzt den lngst 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 vllig wahlfrei gestaltet werden. Der vom E-UUZ/II gene-
  rierte "User-Agent:"-Header hat fr 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 untersttzt auer denen, die unzulssige Zeichen enthal-
          ten (wobei unzulssige Schrgstriche 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 angehngten "Statusbezeich-
          nung" wie "alpha", "beta", "RC3" usw.
  <nick>: Der "Rufname" (z.B. "Halloween") einer Version. Klammerzustze
          bei lteren XP2-Versionen wie "(www.xp2.de)" sind keine
          Rufnamen, daher werden bei allen XP-Versionen auer FreeXP nur
          die Begriffe als Rufnamen gewertet, die innerhalb der Klam-
          mern zustzlich in Anfhrungszeichen eingeschlossen sind. Bei
          FreeXP gelten alle in Klammern eingeschlossenen Strings auer
          "(XMS)" und "(EMS)" als Rufnamen, etwaig fehlende Anfhrungs-
          zeichen werden ergnzt.
  <R>   : Die Registrierungsnummer (z.B. "R/C816" oder auch "R/Free").
          Org- und Kom-Registrierungen werden bercksichtigt.
  <cOS> : Die Betriebssystemplattform, fr die die jeweilige XP-Version
          compiliert wurde (z.B. "DOS16" oder "W32"). Bei XP2-Versionen
          wird diese immer aus dem MAILER:-Header ausgelesen (wobei
          Schrgstriche 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 wrde die Angabe weggelassen werden.
  <rOS> : Die Kurzbezeichnung der Betriebssystemplattform bzw. -version,
          unter der XP bzw. der UUZ aktuell luft. Diese wird vom UUZ
          zur Laufzeit ermittelt, untersttzt werden dabei DOS, Win3.x,
          Win95/98/Me, WinNT/2K/2K3/XP/Vista, Linux/DOSEMU und DOSBox.
          WinNT, Win2K(3), WinXP und WinVista knnen nur voneinander
          unterschieden werden, wenn die XP_NTVDM.DLL von FreeXP im UUZ-
          Verzeichnis liegt, anderenfalls wrden sie als "WinNT" zusam-
          mengefat werden. Darber 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 fr die Plattform Linux (so es
          solche jemals geben sollte, in den Quelltexten ist sie jeden-
          falls vorgesehen) wrde die Angabe weggelassen werden, da ein
          solches Compilat ohnehin nur unter dieser Plattform lauffhig,
          sie daher redundant (weil bereits in <cOS> enthalten) und der
          E-UUZ/II auch gar nicht in der Lage wre, 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 fr FreeXP und XP2 wrden also wie folgt
  aussehen knnen (Compilierdatum wegen der Zeilenlnge 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)
  ----------------------------------------------------------------------
  Weiterfhrende und ergnzende Anmerkungen/Hinweise zum "User-Agent:"-
  Header:
  1. Er wird nur bei den zur CrossPoint-Familie gehrenden 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, wrden 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 ursprngliche MAILER:-Header lnger als 255 Zeichen ist,
        oder
     b) der resultierende "User-Agent:"-Header lnger als 254 Zeichen
        werden wrde, wobei Informationen ber Betriebssystemplattfor-
        men, die nicht Bestandteil des originalen MAILER:-Headers sind,
        bei der Berechnung unbercksichtigt bleiben und daher ggf. unter
        den Tisch fallen wrden, oder
     c) durch die Existenz einer nicht-leeren Textdatei ADDGATE ein
        Gatebetrieb signalisiert wird (Ausnahme siehe Punkt 3.).
     In diesen Fllen wird der MAILER:-Header wie bisher unverndert und
     in voller Lnge nach "X-Mailer:" bzw. "X-Newsreader:" bernommen.
     Der Aufwand, in den Fllen a) und b) auch lngere Header zu unter-
     sttzen, ist angesichts der gnzlich fehlenden Praxisrelevanz zu
     hoch.
  3. Im Falle einer Konvertierung in uz- und unmittelbar anschlieend
     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 fr 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 prfen
     kann und will. Anderenfalls wrde u.U. der Originalinhalt der von
     Fremdprogrammen erzeugten Header verndert werden (mssen).
  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 auerhalb eines Kommentars unzulssig sind
     bzw. eine spezielle Bedeutung haben (hinter "/" steht per Defini-
     tion immer die Versionsnummer). Zum anderen ist nur so gewhrlei-
     stet, da die jeweiligen XP-Derivate in Newsreader-Statistiken auch
     unter ihrem eigenen "Produktnamen" (statt alle gemeinsam unter
     "CrossPoint") aufgefhrt 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 bercksichtigt (soweit bekannt) Sonderflle wie die
     "DOSBOX-Edition" von FreeXP, die nicht durch allgemeingltige
     Routinen zu behandeln waren. Bei der Ermittlung des Rufnamens, der
     Versionsnummer und der "Statusbezeichnungen" werden wegen frherer
     etwas unglcklich 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 schrgen Testkonstrukten, die real bisher so nicht
     vorgekommen sind). Auch seltene (aber real vorkommende) Anhngsel
     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 Ergnzungen
     und Vernderungen werden, soweit sie die Struktur des Headers nicht
     bis zur Unkenntlichkeit zerstrt haben, ebenfalls bercksichtigt
     (ein "CrossPoint/MeinXP R/C816 V6 v3.31.90rcRC  1" wrde vollstn-
     dig und korrekt als "MeinXP (CrossPoint)/3.31.90rc-RC1 (R/C816)" in
     den "User-Agent:"-Header bernommen werden).
  6. Als Begriffe fr "Statusbezeichnungen" werden - in beliebiger
     Schreibweise - untersttzt: "alpha", "beta", "Pre", "RCn" (weitere
     sind bisher nicht gesichtet worden).
  7. Die Gestaltung des "User-Agent:"-Headers kann benutzerseitig durch
     folgende UUZ-Kommandozeilenparameter beeinflut werden:
     -------------------------------------------------------------------
     "-OSfamily": Statt der verwendeten Version des Betriebssystems
                  ("DOS-6.22", "Win98", "WinXP") wird nur die Familie
                  ausgegeben, zu der das Betriebssystem gehrt ("DOS",
                  "Win9x", WinNT"). Nur wirksam, wenn weder "-privacy"
                  noch "-noUAgent" angegeben wurden.
     "-privacy" : Smtliche Informationen ber das Betriebssystem (dazu
                  gehren alle der weiter oben beschriebenen Platzhalter
                  <cOS>, <rOS> und <ovr>) werden unterdrckt, 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 unverndert und
                  ungekrzt nach "X-Mailer:" bzw. "X-Newsreader:" ber-
                  nommen.
     -------------------------------------------------------------------
     Um Kommandozeilenparameter des UUZ auch dann nutzen zu knnen, wenn
     die jeweilige XP-Version keine entsprechenden Dialogoptionen zur
     Verfgung stellt, knnen diese jetzt ber die Parameterdatei
     UUZ.OPT bergeben werden, mehr dazu im bernchsten Abschnitt.
  8. Sofern nach den obigen Regeln ein "User-Agent:"-Header erzeugt
     wird, wird bei Mails gleichzeitig eine Kurzform davon (ohne smt-
     liche Kommentare, d.h. alle in Klammern stehenden Zustze) fr 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 wrde die verschlankte Fassung z.B. so aussehen
     (Datum wegen Zeilenlnge gekrzt):
     --------------------------------------------------------------------
     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
     berflssig und unangebracht.
  ----------------------------------------------------------------------
  9. WICHTIGER Hinweis fr alle Benutzer von UKAW und UKAD:
     UKAW/UKAD verndern 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 Anhngsel wie
     "via NNTP" oder "via BSMTP" zu erzeugen. Davon abgesehen, da dies
     fr sich schon eine kaum zu tolerierende Unsitte ist, ignorieren
     UKAW/UKAD im Falle "User-Agent:" dabei, da der Header nicht vllig
     wahlfrei gestaltet werden kann und produzieren dadurch Header in
     einer ungltigen Syntax, die nicht mit der Spezifikation im USEFOR-
     Draft konform ist. Im Falle der hier beschriebenen Form des "User-
     Agent:"-Headers unterschlagen sie dabei zustzlich nahezu alle im
     originalen Header enthaltenen Informationen und verstmmeln ihn
     (offenbar mangels eines tauglichen Parsers) zu:
     -------------------------------------------------
       User-Agent: CrossPoint/Agent [FreeXP], via NNTP
     -------------------------------------------------
     Abgesehen von der ungltigen Syntax sind also Versionsnummer,
     Registrierungsnummer, smtliche 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 ungltigen Software-
     Header zu erzeugen.
     FreeXP hat - ursprnglich aus ganz anderem Anla - bereits im Juni
     2005 ein Patch-Tool zur Verfgung gestellt, mit dem sich alle
     bekannten und aktuell im Einsatz befindlichen UKAW-Versionen so
     patchen lassen, da u.a. Software-Header generell nicht mehr
     verndert werden. Als (unbeabsichtigter) Nebeneffekt werden auch
     die von UKAW bisher zustzlich erzeugten Header "X-Nntp-Client:"
     und "X-BSmtp-Client:" nicht mehr erzeugt. Mit demselben Tool lt
     sich der Patch auch wieder rckgngig 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 verfgbar 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 verstndlicher Unkenntnis heraus, aber dennoch
     unberechtigt) sicher nicht UKAW, sondern primr der verwendeten
     XP-Version, sekundr evtl. auch dem E-UUZ/II, angelastet werden,
     obwohl diese daran vllig unschuldig sind. Nicht nur deshalb sollte
     der Patch bei Einsatz des E-UUZ/II von FreeXP unbedingt angewendet
     werden.
     Im Interesse sauberer, von unntigem Ballast befreiter und unvern-
     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.
     Auerdem wird er auch noch wegen eines kapitalen Bugs in UKAW v3.50
     und UKAD v2.50 bentigt, mehr dazu im nchsten Abschnitt.
  ----------------------------------------------------------------------
  UUZ.PAS, UUZ0.PAS

MY:
- nderung (-zu): Header "X-XP-Version:" wird nicht mehr in allen Fllen
  erzeugt und kann nun auch komplett deaktiviert werden
  ----------------------------------------------------------------------
  Der vom E-UUZ erzeugte Header "X-XP-Version:" ist ein Workaround fr
  das oben beschriebene Verhalten von UKAW/UKAD, die Software-Header zu
  verndern. Er wird jetzt nur noch dann erzeugt, wenn der Name des
  Programms den String "CrossPoint" in beliebiger Schreibweise enthlt
  (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" lt er sich nun auch
  komplett deaktivieren. Im Falle der Anwendung des oben beschriebenen
  Patch-Tools ist er berflssig und die Deaktivierung in diesem Fall
  daher auch die unbedingt empfohlene Verfahrensweise.
  In folgenden Fllen 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 verndern 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 verndern 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. Whrend der Testphase zum oben beschriebenen Header
  "User-Agent:" hat sich nmlich ein kritischer Bug in diesen Versionen
  herausgestellt, der dazu fhren kann, da ausgehend wie eingehend
  Header zerstrt und Nachrichten deshalb z.B. nicht mehr korrekt
  decodiert werden knnen. Dies hngt mit dem destruktiven Bemhen 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 vllig fehlenden Berck-
  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 erwhnten Folgen kommen. Da aber
  gleichzeitig auch keine Software-Header mehr verndert werden, sollte
  dann natrlich "X-XP-Version:" ebenfalls deaktiviert werden.
  UUZ.PAS, UUZ0.PAS

MY:
- Parameterdatei UUZ.OPT implementiert (-uz/-zu):
  ----------------------------------------------------------------------
  ber die Parameterdatei UUZ.OPT knnen 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 Mglichkeit vorsieht, die gewnschten
  Optionen per Konfigurationsdialog im Programm zu setzen, oder wenn
  aufgrund der Lnge der verwendeten Pfad- und Dateinamen die Gesamt-
  lnge der Kommandozeile an die Grenzen stt, 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 Prioritt. Da Kommandozeilenparameter aber nicht umkehr-
     bar sind, wre dies im Moment nur fr 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
     wrde.
  3. Die Datei mu pro Zeile genau einen Parameter enthalten. Die Optio-
     nen sind genauso einzutragen wie auf der Kommandozeile (d.h. mit
     fhrendem "-").
  4. Es werden nur mit einem fhrenden "-" versehene Parameter (im UUZ-
     Jargon "Switches") ausgewertet. D.h., es knnen keine Datei- und
     Verzeichnisnamen, Sites, Domains etc. bergeben werden. Der Grund
     liegt darin, da dann eine bestimmte Reihenfolge beim Vornehmen der
     Eintrge in UUZ.OPT einzuhalten gewesen wre, unterschiedliche
     Bereiche fr uz- und zu-Konvertierung (Sections) in UUZ.OPT vorge-
     sehen und ausgewertet sowie auerdem die Eintrge in UUZ.OPT mit
     den Optionen auf der Kommandozeile "irgendwie" zu einem sinnvollen
     Ganzen htten verschmolzen werden mssen.
  5. Die Parameter "-uz" und "-zu" (also die Konvertierungsrichtung)
     knnen nur ber die Kommandozeile gesetzt werden.
  6. Bei den Parametern
       -client
       -LFN
       -xp2
     kann optional durch Voranstellen von "uz:" bzw. "zu:" definiert
     werden, fr welche Konvertierungsrichtung die Option gelten soll.
     Alle brigen Parameter werden automatisch nur fr die Richtung
     ausgewertet, fr die sie gltig sind, ein etwaiges "uz:" oder "zu:"
     vor diesen Optionen wird ignoriert.
  7. Leerzeilen und nicht den obigen Regeln entsprechende Eintrge in
     UUZ.OPT werden ohne Fehlermeldung ignoriert.
  8. Die via UUZ.OPT bergebenen Parameter gelten naturgem global,
     box-spezifische Differenzierungen sind daher nicht mglich.
  9. Die Verwendung von Umgebungsvariablen ist nicht mglich.

MY:
- Interne nderung: Das via 'InitWinVersion' reservierte Handle fr 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 fr 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 drfen 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 ausschlielich in EMP:-Header
     bernommen.
     Dadurch wird anders als bisher bei einer ffentlichen Antwort auf
     ein solches Posting nicht mehr eine zustzliche Mail an eine ungl-
     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 Verfgung.
     Enthlt der "Newsgroups:"-Header ausschlielich eine oder mehrere
     Mailadressen, wird die erste in einen EMP:- und die brigen in
     OEM:-Header bernommen (ansonsten wrde 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 Fllen durchlaufen die Mailadressen - unabhngig von dem
  Format, in dem sie vorliegen - dieselbe Behandlung wie Adressen im
  "To:"- oder "Reply-To:"-Header (d.h. insbesondere, da Kommentare
  sowie berflssige quoted-strings und quoted-pairs entfernt werden).
  Etwaige Realnames werden dabei bercksichtigt, analog zu Adressen im
  "To:"- oder "Reply-To:"-Header aber anschlieend verworfen.
  UUZ.PAS, UUZ0.PAS, MIMEDEC.PAS

MY:
- Erzeugung des "Received:"-Headers bei Mails gendert/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 knnen keine Zeichen mehr durch einen Stringberlauf verloren-
     gehen (z.B. im Falle eines langen Software-Strings und/oder einer
     langen Adresse des Envelope-Empfngers).
  2. Der Header wird nicht mehr fest verdrahtet vor einem etwaigen
     Envelope-Empfnger sowie dem Datum gefaltet, sondern nur noch dann
     (und an der sptestmglichen Position), wenn die Gesamtlnge 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, entfllt 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:" (proprietrer Mailman-Header)
     -------------------------------------------------------
     Im Falle von Mails, die diese Voraussetzungen nicht erfllen, 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 tatschlich den String "cancel " enthlt. Bisher wre auch bei
     "Control:"-Headern mit ganz anderem Inhalt blind das Cancel-Flag
     gesetzt worden (was allerdings i.d.R. keine Auswirkungen gehabt
     htte, weil es an der Message-ID der zu cancelnden Nachricht
     gefehlt htte). 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 berck-
     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 grundstzlich kein
     CONTROL:-Header erzeugt.
  Die beschriebenen nderungen dienen dazu, technisch bisher durchaus
  mgliches Canceln/Superseden privater Mails zu unterbinden.
  UUZ.PAS, UUZ0.PAS

MY:
- Neue Importschnittstelle fr 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 Schlsselzeilen ("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 gltigen
  RFC-Headerbezeichner enthlt.
  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 frherer Stelle
  ('ReadRFCheader') ausfhrlich 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 fr diese UUZ-Version:
  ----------------------------------------------------------------------
  Hans-Jrgen Tnzer - Umfassende Massentests, wertvolle Anregungen
                       und intensive Fachdiskussionen
                    
  Johann Addicks    
  Oliver Gampe      
  Reinhard Irmer    
  Franklin Schiftan  Praxistests (FreeXP/XP2)
  Alfred Schrder   
  Jrg 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 Zeichensatzuntersttzung 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 Zeichenstze implementiert:
  ----------------------------------------------------------------------
  Da FreeXP bzw. der Enhanced UUZ seit Erscheinen der letzten Version
  nur noch explizit untersttzte Zeichenstze konvertiert (statt wie
  frher *alle* ISO-Zeichenstze blind auf Basis der mitunter unzutref-
  fenden Tabelle fr ISO-8859-1 "kaputtzukonvertieren"), wurden zu den
  bisherigen neun die folgenden zehn zustzlichen Zeichenstze imple-
  mentiert:
   1. ISO-8859-3   (alias "Latin 3",     Sd-Europa/Trkei)
   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/Glisch)
   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", Trkei, 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 Zeichenstze kommen in Mails und auch in den de.* Newsgruppen
  tatschlich vor (vermutlich nicht selten infolge einer fehlerhaften
  Konfiguration). Es werden wie schon bei den bisherigen alle bei der
  IANA registrierten Aliasnamen dieser neu implementierten Zeichenstze
  untersttzt.
  Damit untersttzt FreeXP jetzt *alle* Latin-Zeichenstze der ISO-8859-
  Reihe (einschlielich der erst jngst zugelassenen wie ISO-8859-16),
  alle vier in den USA und Europa gngigen 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 untersttzten Zeichenstze
  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
        fr 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 genderten Konvertierregeln der ISO- und Win-
     Zeichenstze angeglichen. (Anmerkung: Eine Konvertiertabelle fr
     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 "" zuknftig fr das Euro-Symbol reserviert ist, wrde
     FreeXP sonst bei UTF-7/8-codierten Nachrichten, die das Zeichen ""
     enthalten, dieses nicht von einem Euro-Symbol unterscheiden knnen
     und daher beide miteinander verwechseln. Diese Vorsichtsmanahme
     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 Zeichenstzen, 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:
- Untersttzung von Zeichensatz-Aliasnamen erweitert:
  ----------------------------------------------------------------------
  Zustzlich zu den offiziell bei der IANA registrierten (und somit fr
  MIME-Nachrichten einzig zulssigen) Zeichensatz-Aliasnamen werden
  jetzt auch die Aliasnamen aus der primr auf Linux-Systemen verwende-
  ten Library "GNU libc iconv" untersttzt. Es tauchten immer wieder
  Postings in Newsgruppen sowie Mails auf, die den Zeichensatz mit
  einem dieser eigentlich nicht zulssigen Aliasnamen wie "iso8859-1"
  (richtig wre 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 auerhalb von ISO-8859-1 in einem der brigen
  von FreeXP untersttzten ISO-, Win-, Mac- oder DOS-Latin-Zeichenstze,
  nicht aber in CP437 enthalten sind (z.B. typographische Anfhrungs-
  zeichen, groe und kleine Zeichen mit "Macron", "Ogonek" usw.), wurden
  bisher nur dann konvertiert bzw. transliteriert, wenn die Nachricht
  auch in einem dieser Zeichenstze 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 reprsentiert. Jetzt umfat die UTF-7/8-Decodierung exakt
  denselben Zeichenvorrat wie die Summe aller von FreeXP untersttzten
  Latin-Zeichenstze.
  MIMEDEC.PAS

MY:
- Header-Variablen 'charset' (= Inhalt des ZC-Headers CHARSET:) und
  'ccharset' von bisher 7 Zeichen auf jetzt 30 Zeichen vergrert, um
  zuknftig auch beliebige und nicht ZC-konforme Charset-Bezeichner
  in zu-Richtung untersttzen und auswerten zu knnen.
  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 Temporrdatei 'UUZ.TMP' nach der Erkennung
  des Fehlers jetzt gelscht.
  UUZ.PAS

MY:
- Interne nderung: Das Setzen der MIME-Information bei ausgehenden
  Nachrichten ber 'SetMimeData' erfolgt bei Mails jetzt nicht mehr
  doppelt. Dies verbessert geringfgig 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 lt) 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
     fhrte 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 (nmlich 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. Darber 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 anschlieend eine ZC=>RFC-Konvertierung durchgefhrt
     wurde. Bei Verwendung des in diesen Fllen ohnehin zu empfehlenden
     Parameters "-chkbody" wurde der Fehler schon bisher vermieden.
     Der "charset"-Parameter im Header "U-Content-Type:" wird jetzt in
     allen Fllen ignoriert. Ist weder der Header X-Charset: noch der
     Header CHARSET: enthalten, setzt der UUZ mangels Charset-Angabe
     jetzt intern den Schalter "-chkbody", prft 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 fr alle vom Enhanced UUZ untersttz-
     ten und nicht untersttzten Zeichenstze erweitert, ohne dabei die
     Kompatibilitt 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 untersttzten Latin-
        Zeichenstzen (inkl. UTF-7/8) sowie bei den nicht untersttzten
        Non-Latin-Zeichenstzen der ISO-8859-Reihe (ISO-8859-5 bis -8
        und -11) wird dabei jeder IANA-registrierte oder in der weiter
        oben erwhnten 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") untersttzt und
        ausgewertet.
     c) Gehrt der deklarierte Zeichensatz weder zu einem der vom UUZ
        untersttzten noch zu einem der fnf nicht untersttzten Non-
        Latin-Zeichenstze aus der ISO-8859-Reihe und ist daher gnzlich
        unbekannt, wird die Zeichensatzbezeichnung aus dem CHARSET:-
        Header 1:1 bernommen.
     d) Eine automatische berprfung des Nachrichtentextes findet bei
        Existenz des CHARSET:-Headers wie bisher nicht statt. Diese lt
        sich aber nach wie vor im Externbetrieb mit der Kommandozeilen-
        option "-chkbody" erzwingen; dabei wrde dann ein evtl. 8bit-
        Zeichensatz nach "US-ASCII" korrigiert werden, wenn die Nach-
        richt nur 7bit-Zeichen enthlt.
     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 tatschliche Zeichensatz ist und hlt 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 serise Heuristik fr diesen
        Fall existiert nicht, und auch die sonst recht treffsichere
        Glaskugel des Enhanced UUZ hat ihre Grenzen.
  3. Nachrichten mit dem Header X-Charset: (zulssig sind hier nur die
     Zeichenstze 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" lt sich extern nach wie vor eine
        berprfung des Body erzwingen und so ggf. eine Korrektur eines
        fehlerhaft deklarierten Zeichensatzes herbeifhren (z.B. bei
        Nachrichten, die flschlicherweise 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 Kompatibilitt des Enhanced UUZ mit XP2).
     b) Sollte der Header X-Charset: einen "unerwnschten" 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:
     Prioritt.
  Alle beschriebenen nderungen gelten ausschlielich fr 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 untersttzten Zeichenstzen
  verbessert (-uz):
  ----------------------------------------------------------------------
  Bei Nachrichten in einem von FreeXP eingehend nicht untersttzten
  Zeichensatz wird dieser jetzt in den ZConnect-Header CHARSET:
  geschrieben (und die Nachricht wie bisher *nicht* konvertiert). Dabei
  wird, soweit mglich 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
  mglich, wird der Name des Zeichensatzes, wie er im Header "Content-
  Type:" deklariert ist, unverndert bernommen.
  Dieses Vorgehen hat in Verbindung mit den oben beschriebenen nderun-
  gen, durch die es berhaupt erst ermglicht und sinnvoll wird, den
  Vorteil, da bei einer unmittelbar anschlieenden 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 fr XP-User, sondern eher fr Anwender interessant und
  von Bedeutung, die den Enhanced UUZ im Gate- oder Externbetrieb ein-
  setzen und ist fr diesen Fall deshalb gerechtfertigt und notwendig,
  weil ansonsten keine Mglichkeit bestnde, Nachrichten mit nicht
  untersttzten Zeichenstzen unmittelbar hintereinander in beide
  Richtungen korrekt zu konvertieren und weiterzuversenden.
  Die neue Verfahrensweise unterscheidet sich zu der von OpenXP insbe-
  sondere dadurch, da *untersttzte* Zeichenstze nach wie vor nach
  CP437 konvertiert werden. Daher ist sie auch mit frheren XP-Versionen
  (die genau wie alle aktuellen XP-Versionen Nachrichten in nicht unter-
  sttzten Zeichenstzen weder konvertiert noch unkonvertiert lesbar
  darstellen knnen) 100%ig kompatibel, whrend OpenXP sich offenbar
  dazu entschlossen hat, diese Kompatibilitt aufzugeben und den Zei-
  chensatz von RFC-Nachrichten berhaupt nicht mehr zu konvertieren,
  wodurch die von OpenXP erzeugten ZConnect-Puffer fr andere XP-
  Versionen, sofern sie 8bit-Zeichen enthalten, mitunter unbrauchbar
  sind (FreeXP wird jedoch in einer der nchsten Versionen - mglicher-
  weise sogar in der nchsten - ebenfalls solche unkonvertierten Single-
  part-Nachrichten mit beliebigen untersttzten Zeichenstzen im
  CHARSET:-Header korrekt darstellen knnen).
  UUZ0.PAS

MY:
- Fix fr 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: geprft und nicht bercksichtigt, da auch Nachrich-
  ten, die wegen des CHARSET:-Headers nicht konvertiert werden drfen,
  diese Header trotzdem bentigen.
  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 htte MIME-codiert werden mssen,
  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 Zeichenstze 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-Zeichenstzen fr Steuerzeichen reserviert ist.
  Bei Windows-Zeichenstzen hingegen liegen dort z.B. typographische
  Anfhrungszeichen, verlngerte Bindestriche, das Euro-Symbol usw.,
  also durchaus Zeichen, die auch oft Verwendung finden und konvertier-
  bar sind.
  Der Enhanced UUZ prft jetzt bei allen Nachrichten, die mit einem der
  untersttzten ISO-Zeichenstze deklariert sind, ob sie Zeichen aus dem
  Bereich 0x80 bis 0x9F enthalten. Ist das der Fall, schliet 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 ursprnglich 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  (Sd-Europa/Trkei)
    ISO-8859-4  => Windows-1257  (Nord-Europa/Baltikum)
    ISO-8859-9  => Windows-1254  (Trkei)
    ISO-8859-10 => Windows-1257  (Nord-Europa)
    ISO-8859-13 => Windows-1257  (Nord-Europa/Baltikum)
    ISO-8859-14 => Windows-1252  (West-Europa/Glisch)
    ISO-8859-15 => Windows-1252  (West-Europa)
    ISO-8859-16 => Windows-1250  (Ost-Europa)
  Da die Zeichenstze 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 zusammengefat (da passiert das
  Fallback also quasi automatisch).
  Sofern der UUZ ein Charset-Fallback fr den Nachrichtentext vorgenom-
  men hat, vermerkt er das im Header "X-Fallback-Charset:", lt aber
  die originale Charset-Deklaration im Header "U-Content-Type:" unange-
  tastet.
  Auer im Nachrichtentext funktioniert das Fallback auch in MIME-
  codierten Headern beliebiger Lnge (bis 65500 Zeichen). Allerdings
  wird dann *kein* gesonderter Header "X-Fallback-Charset:" erzeugt,
  weil in Headern mehrere Zeichenstze gleichzeitig vorkommen knnen und
  man nicht fr jedes einzelne encoded word einen eigenen Header erzeu-
  gen kann, bei dem zudem die Zuordnung zum jeweiligen encoded word
  nicht eindeutig wre.
  UUZ0.PAS, MIMEDEC.PAS

MY:
- Decodierungsroutinen fr Header und Body (UTF-8, UTF-7, base64,
  quoted-printable) anllich eines Bugreports komplett renoviert,
  gefixt, erweitert und robuster gestaltet.
  Whrend der fr 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 fr 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 lnger sein knnen als es in den
  einschlgigen RFCs vorgesehen ist bzw. als es die Lngenbeschrnkung
  von Pascal zult - was aber nicht immer der Praxis entspricht (bei
  Headern bestand der grte Teil der Probleme seit Erscheinen der
  ersten Fassung des Enhanced UUZ nicht mehr, auch wenn der Auslser im
  konkreten Fall ein Header war).
  Dieser Text richtet sich primr an Entwickler und interessierte
  Anwender und ist daher entsprechend ausfhrlich, weil das Verstndnis
  der Materie fr zuknftige Arbeiten am UUZ unerllich ist.
  ----------------------------------------------------------------------
  1. (Bugfixes fr Decodierung ungltiger 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 knnen (so etwas
     kann z.B. bei zustzlich base64- oder quoted-printable-codierten
     Zeilen vorkommen, aber auch bei Zeilen mit mehr als 253 Zeichen),
     fhrte im konkreten Fall, da eine Nachricht im Zeichensatz
     ISO-8859-x vorlag, aber flschlicherweise 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 gltigen
     ZConnect-Puffer angewiesen sind, nicht mehr korrekt bearbeitet
     werden. Bei genauerer Prfung stellte sich heraus, da der besagte
     Fix weitere Probleme (mglicher 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 Plausibilittsprfungen vornahm und nur dann korrekt
     funktionieren konnte, wenn die zu decodierende UTF-8-Sequenz gltig
     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 mten noch weitere Zeichen folgen, die zur aktuellen
     (angeblichen) UTF-8-Sequenz gehren, 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 nchste 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 zurckgesetzt worden wre. In
     der Folge wurden "fremde" Bytesequenzen mit dem alten Variablen-
     inhalt verquickt und vllig 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 Lnge des Nachrichtentextes fr
     den LEN:-Header ermitteln und danach den ZConnect-Header komplett
     schreiben zu knnen, 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 fhrte zum fr eine
     Multibyte-Decodierung typischen Entfernen eines Zeichens und somit
     zur Ermittlung einer um 1 Byte zu geringen Lnge. Bei dieser
     "Decodierung" wurde der Inhalt von 'sc_rest' zurckgesetzt, so da
     beim zweiten Lesen keine fehlerhafte Decodierung mehr stattfand,
     somit auch kein Zeichen mehr entfernt und der Body daher in der
     korrekten Lnge geschrieben wurde => tatschliche und vorher
     ermittelte Lnge stimmten nicht mehr berein. (Da die Differenz im
     konkreten Fall genau 1 Byte betrug, war Zufall, es htten in
     anderen Fllen auch bis zu 4 Bytes sein knnen.)
     Zur Vermeidung dieses sowie aller anderen in diesem Zusammenhang
     existierenden theoretischen und praktischen Probleme wurden daher
     folgende umfassende Gegenmanahmen 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 gltigen Standard RFC2279 von Januar 1998
        ersetzt) niedergelegten Regeln eine gltige 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-
        Zeichenstzen zwangslufig vorkommen, nicht mehr blind kaputt-
        decodiert und auch keine vermeintlich unvollstndigen Sequenzen
        in der Variablen 'sc_rest' mehr abgelegt werden.
     b) Stattdessen werden 8bit-Zeichen, die sich in einer angeblichen
        und/oder ungltigen UTF-8-Sequenz befinden, der Standardkonver-
        tierung von Windows-1252 in den IBM-Zeichensatz CP437 unterzo-
        gen. Dadurch werden in den allermeisten Fllen die Zeichen in
        flschlicherweise als UTF-8 deklarierten Nachrichten korrekt
        "erraten" und bei einer Antwort auf eine solche Nachricht
        korrekt wiedergegeben.
        Das Durchfhren dieser Standardkonvertierung folgt demselben
        "robustness principle" wie es fr Nachrichten gilt, bei denen
        gar kein Zeichensatz deklariert ist. Selbst wenn das "erratene"
        Zeichen ausnahmsweise falsch sein sollte (weil die Nachricht in
        einem vllig anderen Zeichensatz als Windows-1252 vorliegt), ist
        es innerhalb von XP immer genauso richtig wie ein gar nicht kon-
        vertiertes Zeichen (nmlich falsch ;-)).
     c) Um nicht flschlicherweise zufllig gltige, aber unvollstndige
        UTF-8-Bytesequenzen am Ende eines Teilstrings vom einen Header
        zum anderen bzw. bis zum Body oder gar vom Body zu einem Header
        der nchsten Nachricht mitzuschleppen und dort mit - zufllig
        ebenfalls gltigen - UTF-8-Bytesequenzen am Anfang des jeweils
        nchsten Headers oder Body zu verquicken und damit eine zwar
        technisch gltige, aber inhaltlich fehlerhafte Decodierung
        durchzufhren, 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 Fllen wird eine etwaige Restsequenz in 'sc_rest' jetzt
        verworfen.
        (Multibyte-Sequenzen drfen 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 Flle bekannt. Wenn
        UTF-8-codierte Nachrichten zustzlich base64/qp-codiert sind,
        dann knnen und drfen sich Multibyte-Sequenzen hingegen durch-
        aus ber mehrere codierte Zeilen erstrecken. Dies wird von der
        neuen Routine korrekt behandelt und untersttzt, siehe dazu auch
        Punkt 3.)
     d) So ein zu verwerfender Rest kann darber hinaus jetzt aber gar
        nicht mehr entstehen, da ber die an den entsprechenden Stellen
        gesetzte globale Variable 'end_of_UTF' geprft wird, ob man sich
        am Ende eines encoded word, Headers oder einer Zeile im Body
        befindet. Sollte sich dort der gltige Anfang einer unvollstn-
        digen UTF-8-Bytesequenz befinden, wird diese trotzdem nicht in
        'sc_rest' abgelegt, weil keine zu dieser Sequenz gehrenden
        Daten mehr folgen knnen.
     e) Bei der Decodierung von Headern und Body werden jetzt nur noch
        Teilstrings mit einer Lnge 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 eingefhrt).
  2. (Erweiterung der UTF-7-Decodierung fr beliebig lange Zeilen und
     Sequenzen)
     Die UTF-7-Decodierung besa einen solchen Fix fr die Decodierung
     umbrochener bzw. sich ber mehrere Teilstrings erstreckender
     Sequenzen bisher nicht - vermutlich, weil es dort wegen der belie-
     bigen und undefinierten Lnge der Sequenz (UTF-7 ist eine Variante
     der base64-Codierung) noch erheblich schwieriger zu implementieren
     gewesen wre als bei UTF-8. ;)
     Dadurch konnte dort zwar das fr UTF-8 beschriebene Problem mit der
     Erzeugung eines ungltigen LEN-Headers auch nicht auftreten, dafr
     kam es aber eben bei der Decodierung von gleichzeitig base64/qp-
     codierten Nachrichten oder bei Zeilen mit mehr als 253 Zeichen zu
     mglichen 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 fr beliebig lange
     Zeilen und Sequenzen in Headern und im Body ausgelegt (bisher:
     253 Zeichen) und bercksichtigt die Regeln und Besonderheiten der
     base64-Codierung (siehe auch Punkt 5.)
     Alle unter Punkt 1. a) bis e) fr UTF-8 beschriebenen Manahmen
     gelten sinngem auch fr die UTF-7-Decodierung, wobei die Prfung
     auf ungltige Bytesequenzen dort gnzlich anderen (und weniger
     przisen) Regeln unterliegt: Wenn nach dem eine UTF-7-Sequenz
     einleitenden "+" nicht mindestens 3 gltige 7bit-Zeichen folgen,
     wird die Decodierung der aktuellen Sequenz abgebrochen und das "+"
     sowie ein ggf. abschlieendes "-" bleiben erhalten (bisher wren
     sie entfernt worden).
  3. (Bercksichtigung von Zeilenumbrchen in base64/qp-decodierten
     Teilstrings)
     Als "Zeilen" im Sinne der vorhergehenden Punkte 1. und 2. gelten
     alle Zeichen in unbegrenzter Anzahl zwischen zwei Zeilenumbrchen
     (CR/LF/CRLF, siehe auch Punkt 4.) bzw. in einem encoded word in
     einem RFC-Header *nach* einer etwaigen base64/qp-Decodierung.
     Daher mute die base64/qp-Decodierung des Nachrichtentextes so
     angepat werden, da Zeilenumbrche 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 Zeilenumbrche mitten im zu
     decodierenden String befinden). Anderenfalls wre eine saubere
     Abgrenzung einzelner Zeilen im Nachrichtentext (und damit das
     korrekte Setzen der Variablen 'start_of_UTF' und 'end_of_UTF' fr
     eine unmittelbar anschlieende UTF-7/8-Decodierung) nicht mglich
     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 unvern-
     dert erhalten).
  5. (Erweiterung der Transportdecodierung fr beliebig lange Zeilen
     (Body) unter Bercksichtigung einer ggf. anschlieenden Zeichen-
     satzdecodierung (UTF-7/8) fr darin enthaltene, ebenfalls beliebig
     lange Zeilen, die wiederum beliebig lange codierte Bytesequenzen
     enthalten knnen (Header und Body))
     Bei der Decodierung der im Header "Content-Transfer-Encoding:"
     fr den Nachrichtentext deklarierten Transportcodierung ("base64"
     oder "quoted-printable") wie auch bei der Zeichensatzdecodierung
     ("UTF-7" oder "UTF-8") von Headern und Body werden nur gltige und
     in sich abgeschlossene Teilstrings an die jeweiligen Subroutinen
     bergeben bzw. in diesen Subroutinen decodiert:
     "base64"           (Transport): bergebene Stringlnge ist durch 4
                                     teilbar oder kleiner 4 (am Ende des
                                     Gesamtstrings).
     "quoted-printable" (Transport): bergebener String endet mit einem
                                     uncodierten oder mit einem voll-
                                     stndigen codierten Zeichen wie
                                     "=E4" (nicht aber mit unvollstn-
                                     dig codierten wie "=E4=E").
     UTF-7            (Zeichensatz): Bearbeiteter String endet mit einem
                                     uncodierten Zeichen oder mit einer
                                     codierten Bytesequenz, deren Lnge
                                     kleiner 4 oder durch 4 teilbar ist.
     UTF-8            (Zeichensatz): Bearbeiteter String endet mit einem
                                     uncodierten Zeichen oder mit einer
                                     codierten Bytesequenz, deren Lnge
                                     durch das erste Zeichen der Sequenz
                                     definiert wird.
     Evtl. berhngende Reststrings, Restbytes oder unvollstndige Byte-
     sequenzen, wie sie bei Zeilen > 248 Zeichen oder nach einer
     base64/qp-Decodierung entstehen knnen, werden zwischengespeichert
     und anschlieend 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 mglich,
     beliebig lange und ggf. doppelt codierte Zeilen und Sequenzen
     trotz der Lngenbeschrnkungen von Pascal korrekt zu decodieren. Es
     erfordert allerdings ein peinlich genaues Vorgehen und die Berck-
     sichtigung aller (un)denkbaren Szenarien, um korrekt und robust
     funktionieren zu knnen.
     Bisher war speziell die Transportdecodierung des Nachrichtentextes
     - im Unterschied zu der von RFC-Headern - nicht fr lngere Zeilen
     ausgelegt (laut RFC2045 sind bei base64- und qp-Codierung max. 76
     Zeichen pro Zeile erlaubt, aber in der Praxis kommen auch deutlich
     lngere Zeilen von mehreren hundert Zeichen vor) und arbeitete
     daher zwar meistens, aber eben nicht immer korrekt und robust.
     Eine ggf. anschlieende Zeichensatzdecodierung funktionierte prak-
     tisch nur bei UTF-8-codierten Headern halbwegs zuverlssig, in
     allen anderen Fllen (UTF-8 im Body, UTF-7 in Header und Body) war
     das Ergebnis mitunter teilweise oder gnzlich unbrauchbar.
     Damit ist der Enhanced UUZ fr alle sinnvollen und unsinnigen sowie
     zulssigen und unzulssigen Formen und Kombinationen von Transport-
     und Zeichensatzcodierung gerstet 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 Lnge der Ursprungszeile unzu-
     lssiges Szenario wre), 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 unzulssig sind, in der
     Praxis aber fter als selten vorkommen) wurden u.U. Leerzeichen
     aus dem Text entfernt, weil die Routine als allererste Manahme
     alle rechten Leerzeichen im String entfernt hat. Zwar fordert
     RFC2045 genau das, aber das darf man natrlich 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 knne sich bei qp-codierten
     Nachrichten nur um Textnachrichten handeln, die kein 0x00 enthalten
     knnen bzw. drfen - aber auch Binrdaten knnen theoretisch
     qp-codiert sein, denn das ergibt sich nicht aus der Art der Codie-
     rung, sondern ausschlielich 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
     wrde sonst an einigen Stellen im Programm (z.B. im Editor) als EOF
     (Dateiende) fehlinterpretiert werden.
  ToDo: Da die Routinen fr die UTF-7/8-Decodierung auch bei der Anzeige
        von MIME-Multiparts im Lister verwendet werden, sind diese neuen
        nderungen noch auf Kompatibilitt mit den bereits vorgenommenen
        Bugfixes fr die Anzeige langer Zeilen > 255 Zeichen zu prfen
        und die lteren Fixes ggf. anzupassen und/oder zu erweitern.
  UUZ.PAS, UUZ0.PAS, MIMEDEC.PAS, TYPEFORM.PAS

MY:
- Redundanten Code fr das Lesen des Body aller Nachrichtentypen (UUCP-
  Mail, SMTP-Mail, Newsbatch) entrmpelt, in der neuen Routine
  'ReadRfcBody' zusammengefat und optimiert.
  UUZ.PAS, UUZ0.PAS

MY:
- Diverse notwendige Fixes fr die zentrale Routine 'ReadString':
  ----------------------------------------------------------------------
  1. Die Routine liefert jetzt am Zeilenende fr die Variable 'eol'
     (= Zeilenende erreicht) immer einen Wert von 2 zurck, und zwar
     jetzt auch dann, wenn die Zeile zufllig genauso lang ist wie die
     max. an die Stringvariable zurckzugebende Zeilenlnge (248 Zeichen
     eingehend, 253 Zeichen ausgehend). Bisher wurde in solchen Fllen
     ein Wert von 0 zurckgegeben (und daraus mitunter falsche Schlsse
     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 abschlieenden Zeilenumbruch korrekt
     konvertiert werden (bisher fehlte dann die letzte Zeile fast voll-
     stndig, lediglich das erste Zeichen dieser Zeile wurde nahtlos an
     das letzte Zeichen der vorherigen Zeile angehngt).
  Damit knnen Routinen, die 'ReadString' aufrufen, jetzt sicher davon
  ausgehen, da bei 'eol=0' noch weitere Zeichen auer CR/LF in dersel-
  ben Zeile folgen werden. Diese nderung ist wichtig sowohl fr die
  oben im Zusammenhang mit UTF/base64/qp-Decodierung beschriebenen
  Fixes als auch fr 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 (zufllig
     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 nchsten im
     Lesepuffer, aber wegen des Erreichens der max. Stringlnge nicht
     mehr im aktuellen Teilstring befindlichen Zeichen prfen knnen,
     stellt 'ReadString' jetzt sicher, da immer mindestens vier Zeichen
     im Lesepuffer zur Verfgung stehen (sofern vorhanden). Ist das
     zufllig nicht der Fall, obwohl das Dateiende noch nicht erreicht
     ist, ldt 'ReadString' diese Zeichen nach. Diese nderung ist
     relevant z.B. fr die vorzeitige Erkennung des Endes einer SMTP-
     Mail (was wiederum notwendig fr eine korrekte UTF-7/8-Decodierung
     ist) als auch fr das korrekte Entfernen der XP-typischen zwei
     Leerzeichen am Ende jeder Zeile (siehe weiter unten), sowie fr
     alle anderen (zuknftigen) Routinen, die einen "look ahead" auf die
     max. nchsten 5 Zeichen machen mssen.
  UUZ0.PAS

MY:
- Fix: Wenn sich nach der RFC=>ZC-Konvertierung einer eingegangenen
  Textnachricht (nicht bei Binrnachrichten!) kein Zeilenumbruch (CRLF)
  am Ende des Puffers befindet, wird dieser jetzt hinzugefgt (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 angehngt. 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) mute hierfr die Logik beim Lesen des
  Body dahingehend angepat werden, da die Routine bereits den Inhalt
  der nchsten Zeile prft, whrend die aktuelle Zeile noch bearbeitet
  wird (ansonsten knnte das Ende der Nachricht nicht "vorhergesehen"
  und auerdem auch nicht die fr 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 mgliche (in der Praxis bisher nicht auf-
  getretene) Endlosschleifen bei unvollstndig/defekt base64-codierten
  RFC-Headern, bei denen sowohl Header als auch das betreffende encoded
  word lnger als 255 Zeichen waren, in 'UTF8ToIBM' und 'DecodeEW' beho-
  ben (letztere Schleife verbunden mit einem Crash, insofern nicht ganz
  "endlos" ;-)).
  In solchen Fllen wird der unvollstndige Header jetzt soweit codiert
  wie mglich 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. Zeilenlnge im
  Body fr den Transport einerseits auf 76 Zeichen begrenzen zu knnen
  und andererseits zu verhindern, da extrem lange Zeilen nach der von
  RFC2822 definierten Grenze von 998 Zeichen - bzw. beim letzten Wort
  davor - zwangsumbrochen werden mssen (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 lngenbegrenzt).
  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 nchste 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 fr ein ebenfalls theoretisches und bisher in der Praxis nicht
  aufgetretenes Szenario, weil Header keine codierten Zeilenumbrche
  enthalten (drfen) und die Entscheidung, mehrere CR/LF hintereinander
  durch nur ein Leerzeichen zu ersetzen bzw. ganz zu entfernen, ohnehin
  vllig willkrlich ist (*da* sie in irgendeiner Form entfernt werden
  mssen, ist bei Headern allerdings zwingend und liegt in der Natur der
  Sache).
  MIMEDEC.PAS

MY:
- Fix (-uz): Der Header "X-XP-Version:", der bisher Prioritt gegenber
  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 darber hinaus weitere Zeichen
  enthlt. Damit bleiben Header, die Anhnge wie "via UKA_PPP x.xx",
  "via XPNews" o.. enthalten, aber gegenber "X-XP-Version:" ansonsten
  unverndert sind, jetzt wieder erhalten.
  UUZ.PAS

MY:
- Workaround fr 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"
  hinzuzufgen. 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 Empfnger 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 zustzlich
  vorhandenen Software-Header mit dem Wort "via" angefgt, 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-
  fgt 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 untersttzt *keine* beliebig langen Zeilen. Wenn die
  Summe aus dem UKA_PPP-Header und dem eigentlichen Software-Header
  lnger 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
  hherer Aufwand zu rechtfertigen wre.
  UUZ.PAS

MY:
- Workaround fr Endlosschleife bei der ZC=>RFC-Konvertierung von
  defekten ZConnect-Puffern mit zu groem 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 (dafr 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 Abstzen 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 Lnge.
  2. Dafr funktioniert das Entfernen der zwei Leerzeichen jetzt auch
     in allen Fllen 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 knnen, was aber im Falle mehrerer Leerzeichen am Zeilenende
     ab Pos. 252/253 hintereinander auch bisher schon nicht gewhrlei-
     stet war). Beim Signaturtrenner bestand dieses Problem aufgrund
     einer Sonderbehandlung nicht, diese ist durch die generelle
     nderung jetzt aber berflssig geworden und wurde daher entfernt.
  UUZ.PAS

MY:
- Der fr den Transport von SMTP-Mails am Zeilenanfang im Body hinzuzu-
  fgende 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 knnen also in diesem Fall jetzt um jeweils 1
  Zeichen lnger werden, da der Punkt beim Transport ohnehin entfernt
  wird.
  Dasselbe gilt fr News-Postings, bei denen der Punkt vom Client hinzu-
  gefgt 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 eingefhr-
  te) Vorgehen war nicht wirklich falsch oder schdlich, aber unntig
  und ungewhnlich.
  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 Umstnden 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 Umstnden das genau passierte, wurde genauso wenig nher
  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
  unzulssig ist).
  ???.PAS

MY:
- Logik beim Lesen des RFC-Headers etwas gendert, 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 Umstnden vollstndig entfernt wrden (bisher nur
  die bis Pos. 253). Des weiteren htte es in bestimmten - in der Praxis
  ebenfalls noch nicht aufgetretenen - Szenarien passieren knnen, da
  die Routine falsche Schlsse zieht und glaubt, sie befnde sich am
  Anfang des nchsten Headers, obwohl sie sich noch in der Fortsetzung
  des aktuellen Headers befindet. Reine Vorsichtsmanahme.
  UUZ.PAS

MY:
- Fix (-uz): Bei Nachrichten mit einem "Content-Type:"-Header, dessen
  mehrere Parameter mit Semikolon, aber ohne anschlieendes Leerzeichen
  separiert waren, wurde bisher der Zeichensatz nicht korrekt ausge-
  wertet, weil der unmittelbar nachfolgende Parameter fr 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-
  flssig gesetzten Anfhrungszeichen vor und hinter dem Realname zu
  entfernen. Die Routine des UUZ entfernt daher diese Anfhrungszeichen
  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 Anfh-
  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
  Anfhrungszeichen eingeschlossenen Wort wird davon ausgegangen, da es
  sich um einen "Nickname" o.. handelt, bei dem sie bewut gesetzt
  wurden).
  MIMEDEC.PAS

MY:
- Genderte 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 zulssig sind, mehrere ANTWORT-AN:-Header aber schon). Die
       Groschreibung sollte zur spteren Unterscheidung in FreeXP von
       den "echten" Headern fr 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 knnen. Da ANTWORT-AN: aber ausgerechnet der Standard-
       schreibweise im ZConnect-Raum entspricht, htte das nicht korrekt
       funktioniert, wenn ZConnect-Puffer anderer Programme (z.B. von
       OpenXP) in FreeXP eingelesen worden wren, die diese Standard-
       schreibweise verwenden. FreeXP verwendet daher jetzt ebenfalls
       die Standardschreibweise "ANTWORT-AN:" fr "echte" Reply-To-
       Adressen, fr 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 zuknftige Reply-To-All-Routine mu
       daher die genaue Schreibweise des Headers prfen, um Absender-
       und Reply-To-Adressen voneinander unterscheiden zu knnen (d.h.
       auch, da die frhere Schreibweise "Antwort-an:" und die aktuelle
       Schreibweise "ANTWORT-AN:" gleichbehandelt werden, was im Sinne
       der Abwrtskompatibilitt sinnvoll und notwendig ist).
  -zu: Folgerichtig prft 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 fgt 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 gewhrleistet, 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 ursprnglichen From:-Header auch wieder im
       neu erzeugten From:-Header befinden.
  UUZ0.PAS, XPMAKEHD.INC

MY:
- Variable 'control' von 150 auf midlen+9 vergrert: 'midlen' (max.
  Lnge der Message-ID) hatte inzwischen eine Gre von 160 Zeichen,
  daher wre beim Versuch, eine Nachricht mit einer Message-ID von mehr
  als 141 Zeichen Lnge zu canceln, durch das Hinzufgen des Strings
  'cancel' und der beiden spitzen Klammern ein unvollstndiger Subject:-
  Header erzeugt worden (in der Praxis ist dieser Fall offenbar bisher
  nicht vorgekommen).
  UUZ0.PAS

MY:
- Zeitzone "CEST" ergnzt (ausgerechnet die einzige korrekte Schreib-
  weise fr die Mitteleuropische 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 Abkrzung 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 hufiger vorzukommen). Bisher wurde diese
  Angabe ignoriert, jetzt erhht 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-Empfngers aus "Received:"-Headern auslesen) funktionierte
  zwar intern noch, war aber nach auen 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; darber
  hinaus wird die aus dem "Received:"-Header ausgelesene Adresse jetzt
  auf Plausibilitt geprft und anschlieend derselben Behandlung
  unterzogen (spitze Klammern, Kommentare usw. entfernen) wie alle
  anderen Header, die Mail-Adressen enthalten. Dadurch werden etwaige
  Strings nach dem Schlsselwort "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 spter
  festzustellen, da es sich gar nicht um eine Adresse handelt.
  Werden "-graberec" und "-UseEnvTo" gleichzeitig angegeben, besitzt
  "-graberec" jetzt niedrigere Prioritt (auch, weil das Verfahren
  ohnehin recht fragwrdig ist). In diesem Fall wrden die "echten"
  Envelope-Header (siehe Beschreibung der nchsten nderung) Vorzug
  genieen, aber so ist es immerhin mglich, beide Schalter sinnvoll
  miteinander zu kombinieren und nur dann die aus den "Received:"-
  Headern ausgelesene Adresse zu verwenden, wenn keiner der brigen vom
  UUZ untersttzten Envelope-Header vorhanden ist.
  UUZ.PAS, UUZ0.PAS, MIMEDEC.PAS

MY:
- Zustzlich zu den bisher schon untersttzten RFC-Headern fr Envelope-
  Empfnger ("Envelope-To:", "X-Envelope-To:", "Delivered-To:") werden
  jetzt noch "X-Original-To:" (Postfix) und "Original-Recipient:" (gem
  RFC2298) untersttzt. 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 Prioritt als die brigen und wird nur verwendet, wenn
  kein anderer der untersttzten Envelope-Header vorkommt (hat aber
  immer noch Prioritt gegenber "-graberec", siehe oben).
  UUZ.PAS

MY:
- Hinweise fr 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 zusammengefat sind und denen man folgen
  sollte:
  ----------------------------------------------------------------------
  1. Wie schon in der Dokumentation zur ersten Fassung des Enhanced UUZ
     erwhnt, sollte der Aufruf des Programms X_SPOOL.EXE mit dem
     Schalter "/xc" unmittelbar vor dem UUZ-Aufruf im Netcall-Script
     (i.d.R. heit 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 vollstndige ber-
     sicht ist unter Punkt 3. zu finden - bitte unbedingt *alle* dort
     aufgefhrten 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 frheren Schalter
        "-MIME" und "-1522" sind Default, nicht mehr abschaltbar und
        daher berflssig).
        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" gewhrleistet, da
        Mails im SMTP-Format erstellt werden, die UKA_PPP unverndert
        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 Kopienempfngern nderungen an der Adressierung der Nach-
        richten vornehmen mssen, 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:-Empfnger der falsche Eindruck vermittelt, er
        selbst sei To:- und die brigen Adressaten die Cc:-Empfnger).
        Bei dieser Umwandlung hat UKA_PPP aber stellenweise nicht
        bercksichtigt, da Headerzeilen gefaltet sein knnen, was im
        Betrieb mit dem Enhanced UUZ sogar zum Verlust von Kopienempfn-
        gern ("Cc:") und/oder zur Krzung des Subjects fhren konnte.
        Der Enhanced UUZ trgt insofern mit dazu bei, als da er gem
        RFC2822 Kopienempfnger 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 mglichen 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 fr 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 smtliche Auf-
     rufe von X_SPOOL.EXE sowie einige weitere Befehle im Script XPNEWS
     berflssig. 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 knnen 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 fr das Add-On fr den Betrieb von UKA_PPP
  in einer RFC/Client-Box, denn dort sind sie bereits von vorneherein
  bercksichtigt. Der Betrieb in einer RFC/Client-Box ist dem in einer
  ZConnect-Box aus vielerlei Grnden unbedingt vorzuziehen.

MY:
- Der Enhanced UUZ ist jetzt kompatibel mit XP2. :-)
  XP2-Anwender, die den Enhanced UUZ einsetzen mchten (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 angepat 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 wrde der weit
     umfangreichere Standardaufruf von XP2 funktionieren (die Parameter
     "MIME" und "-1522" sind beim Enhanced UUZ Default, nicht mehr
     abschaltbar und daher berflssig, und der Parameter "-SMTP" ist
     durch "-ppp" bereits impliziert).
     Ebenfalls berflssig und auch wirkungslos ist der XP2-spezifische
     Parameter "-absnsstyle", der dazu fhren 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 Fllen
     korrekt.
  3. Wer seine ausgehenden Nachrichten einer quoted-printable-Codierung
     unterziehen mchte (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" ergnzen.
     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 prft auf das Vorkommen des Strings
     "XP2".
     Wer dieser Automatik nicht traut oder den Enhanced UUZ im Extern-
     betrieb zu einem XP2-kompatiblen Verhalten zwingen mchte, kann/mu
     zustzlich 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 prft und in der Folge
     selbstndig und korrekt den Zeichensatz und dessen Codierung in den
     RFC-Headern "Content-Type:" und "Content-Transfer-Encoding:"
     deklariert.
     Diese Manahme 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 wrde, ist mitunter fehlerhaft.
     Beispiel: Ein Text, der das Paragraphenzeichen "", aber ansonsten
     nur 7bit-Zeichen enthlt, wrde 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 ursprng-
     lichen Wert #21 (Steuerzeichen in CP437) in das 8bit-Zeichen #167
     in ISO-8859-1 konvertiert. Mangels korrekter Deklaration seitens
     XP2 wrde 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 einfgt, fr 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 wre (nmlich 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 prft (brigens ein genereller Fehler aller frheren
     XP-Versionen).
     Alle diese Fehler werden durch den im XP2-Modus automatisch akti-
     vierten Parameter "-chkbody" korrigiert.
  6. Die Kompatibilitt 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" angehngt. In einer FreeXP-Umgebung wird ein bereits
        existierender ZC-Puffer mit der Endung .BAK versehen und in
        jedem Fall ein neuer erzeugt. Dieses Verhalten wrde bei XP2
        mitunter - speziell bei Multiserver-Netcalls - zu Datenverlust
        fhren.
     b) Die Behandlung ausgehender und eingehender Cancel-Nachrichten
        entspricht dem (auch schon bei frheren XP-Versionen blichen)
        Verfahren ber ausschlielich den Betreff-Header.  Bei FreeXP
        wird dies zustzlich ber die ZC-konformen Header "STAT: CTL"
        und "CONTROL: cancel [MsgID]" geregelt (wodurch auch ZConnect-
        User canceln knnen), die aber von XP2 nicht untersttzt
        werden.
     c) Alle XP2-spezifischen Funktionen (Header "X-XP-Mode" fr HdrOnly
        und MsgID-Request, Parameter "-bBoxname" fr die Auswertung des
        Boxnamens bei der Konvertierung eingehender Nachrichten) werden
        vom Enhanced UUZ untersttzt. :-)
     d) Darber hinaus gelten alle in dieser Dokumentation beschriebenen
        Fixes, nderungen und Erweiterungen fr XP2 in gleichem Mae wie
        fr FreeXP.
        Es ist allerdings darauf hinzuweisen, da sich die vielfltigen
        nderungen, Korrekturen und Erweiterungen im Bereich der Deco-
        dierung und Konvertierung von Zeichenstzen nur bei Singlepart-
        Nachrichten auswirken, da Multipart-Nachrichten nicht vom UUZ,
        sondern von XP selbst decodiert/konvertiert werden. Es kann
        daher in Einzelfllen zu Inkonsistenzen kommen (d.h. derselbe
        Text wrde 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:
- Zustzlich 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 Fllen wird dazu jetzt nicht
  mehr der Zeitstempel der Datei verwendet (weil sich dieser durch
  Entpack- und Kopiervorgnge verndern kann), sondern es wird der echte
  Zeitpunkt der Compilierung fest eincompiliert, kann nicht mehr vern-
  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 angestoenen
  Compilierung neu erzeugt wird und die aktuellen Datums- und Uhrzeit-
  werte in Konstanten zur Verfgung 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 spter
  auch bei anderen Programmen (XP, ZPR, ZFIDO, MAGGI usw.) Anwendung
  finden.
  UUZ0.PAS [+GENDATE.PAS, +COMPDATE.PAS]

MY:
- Optik-Fix: Da die Anzahl der verfgbaren UUZ-Optionen sowie ihre
  Erluterungen im Laufe der Zeit umfangreicher geworden sind und jetzt
  auch der Compile-Timestamp in einer zustzlichen 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 hlt 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 hher) nicht, wenn dieser im Ergebnis
  auf das Hauptverzeichnis des aktuellen Laufwerks verwies. Die Ursache
  lag in der zentralen Routine 'IsPath()', die diesen Fall nicht geprft
  hat. Die Angabe relativer Pfade funktioniert jetzt in allen Fllen 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) fr
  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 angehngt,
  was auch nicht zu einem viel sinnvolleren Ergebnis fhrt).
  In beiden Fllen wird jetzt eine Fehlermeldung wegen einer "ungltigen
  Zieldatei" ausgegeben. Der Test ist allerdings sehr simpel und prft
  nur auf Gleichheit der Strings - er lt sich daher durch die Angabe
  eines absoluten und eines relativen Pfades, die beide auf dasselbe
  Verzeichnis verweisen, gewaltsam austricksen (wenn man das unbedingt
  mchte). 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 knnen (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 bercksichtigt. Handelte es sich dabei
  jedoch um einen Header, der die max. Lnge eines Pascal-Strings ber-
  schritt und daher im Array 'LongHdr' abgelegt werden mute, hatte
  jeweils der erste vorkommende Header "gewonnen" (Pointervariable wurde
  in 'SaveLongHdr' nicht disposed, wenn sie bereits einen Wert hatte).
  Jetzt wird in *beiden* Fllen der jeweils letzte vorkommende Header
  bercksichtigt (auer, es gelten fr den betreffenden Header irgend-
  welche Sonderregeln).
  UUZ0.PAS

MY:
- Untersttzung langer Header jetzt auch in zu-Richtung (ZConnect=>RFC):
  ----------------------------------------------------------------------
  Die bereits mit der ersten Fassung des Enhanced UUZ implementierte
  Untersttzung fr 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 untersttzt und sowohl in voller Lnge 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 Untersttzung beliebig langer Headerzeilen bezieht sich auf die
  Lnge 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 mssen (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 lngenbegrenzt.
  Im Zuge dieser Erweiterung bereitet die neue Routine 'WriteLongRfcHdr'
  die Header fr 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
  Fllen korrekt codieren, falten und quoten kann (sofern erforderlich).
  Dies ist allerdings nicht der Endzustand - 'EncodeFoldQuote' wird im
  nchsten Schritt der UUZ-Entwicklung so erweitert werden, da es die
  Daten aus einem 64k-Array auch direkt verarbeiten kann, um auch die
  theoretisch vorkommenden Flle (z.B. Worte, die lnger als 255 Zeichen
  sind) korrekt behandeln zu knnen.
  Aus diesem Grund werden hier auch einige - fr die tgliche Praxis
  vllig irrelevante - Temporrfixes in der Routine 'EncodeFoldQuote'
  nicht nher dokumentiert.
  Ebenfalls im Zuge dieser Erweiterung bercksichtigt 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
  knnen. 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:" gendert:
  (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 ursprngliche 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 nchste nderung unten). Sie ist nur
       fr echten Gatebetrieb von Bedeutung und fr 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-
  stzliche Eintrag vom bereits existierenden Headerinhalt mit einem
  Komma separiert.
  Die Gesamtlnge des hinzuzufgenden 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-
  sttzt.
  Diese Erweiterung ist nur fr echten Gatebetrieb von Bedeutung und fr
  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-/Binrnachrichten komplett berarbeitet
  ----------------------------------------------------------------------
  Anllich eines ausschlielich 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
  Binrnachricht behandelt wurde, wurde deutlich, da die bisherigen
  Regeln fr die Klassifizierung als Text- oder Binrnachricht untaug-
  lich bzw. schlicht falsch waren. Die Erkennung als Text- oder Binr-
  nachricht wird daher jetzt nur noch ausschlielich vom Inhalt des
  Headers "Content-Type:" abhngig gemacht:
  a) Alle Nachrichten vom "Media Type" text/*, multipart/* und message/*
     (ergnzt 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) binre Komponenten
     - auch gemischt mit Textkomponenten - enthalten kann, diese aber
     nicht vom UUZ, sondern erst spter in XP selbst beim ffnen oder
     Extrahieren des jeweiligen Nachrichtenteils behandelt und ggf.
     decodiert werden.
  b) Demzufolge gelten als Binrnachrichten 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 Binrnach-
     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
     Rckschlsse auf den Typ der Nachricht (Text oder Binr) zult.
     Bisher konnte es aufgrund der unvollstndigen Prfung auf "base64"
     und "binary" flschlicherweise vorkommen, da einerseits qp-codier-
     te Binrnachrichten als Textnachrichten, andererseits aber base64-
     codierte oder als "binary" deklarierte Text- oder Multipart-Nach-
     richten als Binrnachrichten erkannt wurden.
  d) Anmerkung zur Deklaration "Content-Transfer-Encoding: binary":
     Obwohl der Header den Schlu nahelegt (und prinzipiell auch dafr
     gedacht ist), es handele sich hierbei um uncodierte Binrdaten und
     die Nachricht sei daher als Binrnachricht zu klassifizieren, ist
     der Transport uncodierter Binrdaten im RFC-Raum bisher weder
     standardisiert noch findet er in der Praxis statt (siehe Abschnitt
     6.2. in RFC2045). Es gibt derzeit keine Umstnde, unter denen die
     Deklaration "binary" gltig wre, daher ist sie zu ignorieren bzw.
     wie "8bit" zu behandeln. Der UUZ ist, da er in uz-Richtung seit
     jeher ausschlielich zeilenorientiert arbeitet, auf die korrekte
     Behandlung eingehender uncodierter Binrdaten auch gar nicht ausge-
     legt und die Lese- und Schreibroutinen mten umfassenden nderun-
     gen unterzogen werden, um die (beabsichtigte) Ersetzung von Zeilen-
     umbrchen (LF=>CRLF) und die damit verbundene Vernderung uncodier-
     ter Binrdaten zu verhindern - aber selbst dann wrden 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 bekme - 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 fhren in der Praxis u.a. dazu, da beim
  Beantworten von bisher flschlicherweise als Binrnachricht erkannten
  Textnachrichten keine berflssige Rckfrage mehr erfolgt, ob man
  die vermeintliche Binrnachricht wirklich quoten wolle (umgekehrt
  erfolgt die Rckfrage jetzt bei qp-codierten Binrnachrichten, wo sie
  bisher unterblieben wre). Des weiteren findet bei bisher flsch-
  licherweise als Binrnachricht erkannten Singlepart-Textnachrichten
  jetzt die erforderliche Zeichensatzkonvertierung statt, und es ist
  sichergestellt, da das weiter oben beschriebene Anhngen von Zeilen-
  umbrchen (CRLF) an das Ende eines ZConnect-Puffers im Bedarfsfall nur
  noch bei echten (dafr 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 Binrnachrichten 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 fhrte also eine unmittelbar auf-
  einanderfolgende RFC=>ZC=>RFC-Konvertierung dazu, da die Struktur der
  Multipart-Nachricht vollstndig zerstrt 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, enthlt. Die Zeichensatzkonvertierung wrde das Original-
     format der Nachricht zerstren. (Evtl. ist eine sptere direkte
     Untersttzung 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 wrden
     nach einer Konvertierung in den IBM-Zeichensatz nicht mehr richtig
     dargestellt werden knnen.
  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 tatschlichen und
  aus dem Header "U-Content-Type:" klar ersichtlichen Subtyps pauschal
  als "text/plain" deklariert, und der MIME-Typ message/* wurde gleich
  vllig ignoriert und daher ebenfalls als "text/plain" deklariert.
  Ergebnis waren gnadenlos kaputtkonvertierte und grundfalsch dekla-
  rierte Nachrichten. :-(
  Zur Ehrenrettung mu man zwar hinzufgen, 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 Grnden fr eine RFC=>ZC=>RFC-Konvertierung einsetzen
  (solche Flle sind aus der Realitt bekannt) und Gatebetreiber wurden
  mit defekten Nachrichten "belohnt".
  Es wurden daher folgende Gegenmanahmen 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 mglich,
       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 Erlu-
       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 fr
       FreeXP, dann knnten 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 wrde normalerweise der Standardkonvertierung in
       den Zeichensatz ISO-8859-1 unterzogen werden. Dieses wird jetzt
       ebenfalls gezielt verhindert, denn auch solche Nachrichten knnen
       natrlich 8bit-Zeichen enthalten, die bei einer Konvertierung
       zerstrt wrden. 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 fr 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 ueren
       "Content-Type:"-Header ist hier irrelevant und drfte gar nicht
       vorkommen).
  UUZ.PAS, UUZ0.PAS

MY:
- Optik-Fix (-uz): Bei der im Falle eines nicht untersttzten 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 erfllt ist (MIME-Multipart
  o..) wird der Header erst gar nicht mehr erzeugt.
  UUZ0.PAS

MY:
- Fix (-uz): Der Enhanced UUZ fngt jetzt unzulssige Deklarationen im
  Header "Content-Transfer-Encoding:" ab: Da bei den "Composite Media
  Types" multipart/* und message/* nur "7bit", "8bit" und "binary" als
  Transportcodierung im ueren "Content-Transfer-Encoding:"-Header
  zulssig sind, wird jede unzulssige 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 zufllig mit der im ueren
  "Content-Transfer-Encoding:"-Header deklarierten Codierung identisch
  war, flschlicherweise decodiert).
  Fr einzelne Subtypes des MIME-Typs message/* existieren noch restrik-
  tivere Einschrnkungen hinsichtlich der zulssigen Codierungen; da UUZ
  "7bit", "8bit" und "binary" aber ohnehin gleichbehandelt (nmlich nur
  liest und nicht decodiert), mssen diese nicht gesondert bercksich-
  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 auerhalb an zwei verschiedenen Stellen). 'binaer' ist
  jetzt wieder true, wenn typ='B' (nicht wenn typ<>'T').
  UUZ.PAS, UUZ0.PAS

MY:
- Bei Binrnachrichten wird jetzt auch fr Singleparts (= Schalter
  "Binrnachrichten 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 Dateigre ("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 Binrnachrichten 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 spterer 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): Lnge des MIME-Boundaries im Record
  'header' von 70 auf 100 Zeichen erhht und damit an die Lnge im
  Record 'mimedata' angepat.
  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 ueren "Content-
  Type:"-Header geschrieben.
  UUZ.PAS, UUZ0.PAS, XPMAKEHD.INC

MY:
- Fix (-zu): Beim Schreiben des ueren "Content-Type:"-Headers von
  Multipart-Nachrichten wird jetzt die Lnge des Typs, des Boundary-
  Delimiters und weiterer etwaiger Parameter beachtet und der Header bei
  Bedarf (d.h. wenn er lnger als 78 Zeichen wrde) gefaltet. Bisher
  wurden alle Parameter ungeachtet der Gesamtlnge grundstzlich in eine
  einzige Zeile geschrieben (was auch zu Zeichenverlust fhren konnte).
  Da der Header "Content-Type:" samt seiner vielfltigen Parameter in
  einer eigenen Routine verarbeitet wird, luft er nicht wie andere
  Header durch die Routine 'EncodeFoldQuote', die diese Behandlung auto-
  matisch vorgenommen htte.
  UUZ.PAS

MY:
- Bezeichnung des Schalters "-gate" (-zu) in "-chkbody" gendert:
  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 prft und dabei fehlerhafte
  Deklarationen von Zeichensatz und Transportcodierung repariert, seine
  ursprngliche, 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 irrefhrende Bezeichnung "-gate" in die wesentlich
  treffendere und aussagekrftigere Bezeichnung "-chkbody" gendert (im
  Sinne der Abwrtskompatibilitt funktioniert die Angabe von "-gate"
  aber nach wie vor).
  Alle frheren Referenzen in diesem Dokument auf den Schalter "-gate"
  wurden in "-chkbody" gendert.
  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") abhngig gemacht,
  sondern als Merkmal fr echten Gatebetrieb dient jetzt ausschlielich
  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 wrden dann
  speziell bei ausgehenden RFC-Nachrichten vllig 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
  gehrte, 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 fr den UUZ eingefhrt, 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
  zwangslufig synchron verlaufen, lassen sich so die jeweiligen UUZ-
  Versionen besser voneinander unterscheiden (statt wie bisher nur am
  Dateidatum identifiziert werden zu knnen).
  UUZ0.PAS

MY:
- Aufgrund der Flle 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
  Vorgnger (z.B. in Newsgroup-Diskussionen o..) in "Enhanced UUZ/II"
  gendert (abgekrzt "E-UUZ/II").
  UUZ0.PAS


- Beteiligte Entwickler an diesen UUZ-Version(en):
  ----------------------------------------------------------------------
  MY - Michael Heydekamp (Programmierung und Dokumentation)


- Credits fr 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-Zeichenstzen (UTF-7/8)
  Joachim Merkel     - Analysen im Zusammenhang mit dem gemeinsamen
                       Betrieb von Enhanced UUZ und UKA_PPP
  Hans-Jrgen Tnzer - Erkennung diverser Bugs und Anregung, den echten
                       Compilierungszeitpunkt fest zu verdrahten
                    
  Uwe Morgener      
  Franklin Schiftan  Testen der Kompatibilitt mit XP2
  Jrg Tewes        
                    
  Und alle hier nicht namentlich genannten Anwender des Enhanced UUZ,
  die durch ihr Feedback zu einer weiteren Verbesserung des Programms
  beigetragen haben.


+------------------------------+
|  30.08.2003  (FreeXP v3.40)  |
+------------------------------+

MY:
- Versionsmeldung auf "FreeXP" gendert und mit aktuellen Units
  neu compiliert. Keine weiteren inhaltlichen nderungen.


+--------------------------------------------+
|  09.07.2002-24.05.2003  (OpenXP/16 v3.40)  |
+--------------------------------------------+

MY:
- Umfassendes Redesign und zu wesentlichen Teilen Rewrite des
  RFC-Konvertierers UUZ (=> "Enhanced UUZ")
========================================================================

  1.   Euro-Support
  -----------------

  1.1. Eingehende Nachrichten  (RFC => ZConnect)
  ----------------------------------------------

  JG+MY:
  - Bei Nachrichten, die ein Euro-Symbol enthalten, wird dieses in
    Headern und Body jetzt in das CP437-Zeichen "" (kleines griechi-
    sches Epsilon, #238) konvertiert, statt wie bisher als Zeichenwert
    1:1 durchgereicht zu werden (wodurch man je nach Zeichensatz ein
    "", "", "" oder "x" beim Lesen im Lister sah).
    Dabei werden die folgenden Euro-fhigen Zeichenstze bzw.
    Codierungen untersttzt:
      ISO-8859-15   (Euro-Symbol auf Pos. #164)
      Windows-1252  (Euro-Symbol auf Pos. #128)
      CP858         (Euro-Symbol auf Pos. #213)
      UTF-7         (Unicode-Zeichen)
      UTF-8         (Unicode-Zeichen)

  JG+MY:
  - Manche Mail-/Newsreader (speziell Outlook Express) deklarieren
    mitunter gar keinen oder den Zeichensatz ISO-8859-1, verwenden in
    Wirklichkeit aber den Zeichensatz Windows-1252 und daher den Euro
    dort auch auf Pos. 128. Daher wird auch bei Nachrichten ohne
    Zeichensatzdeklaration oder im Zeichensatz ISO-8859-1 das dort
    eigentlich reservierte Zeichen #128 in das griechische Epsilon
    konvertiert, obwohl dieses Vorgehen strenggenommen nicht 100%ig
    korrekt ist. UUZ hatte aber im Sinne der Fehlertoleranz schon immer
    "OjE-Fixes" dieser Art, insofern ist dieses Vorgehen nur konsequent.

  In allen nach diesem "Enhanced UUZ" erscheinenden FreeXP-Versionen
  wird das griechische Epsilon im Vollbild und im DOS-Fenster optional
  als echtes Euro-Symbol dargestellt werden knnen. Selbst wenn man
  diese Option nicht aktiviert oder den UUZ gar nicht zusammen mit XP
  einsetzt, ist das griechische Epsilon einem Euro-Symbol (das auf Basis
  eben dieses Epsilon entwickelt wurde) sehr viel hnlicher als ein "",
  "", "" oder "x" und diese genderte Konvertierung des Euro-Symbols
  im Sinne einer korrekteren Transliteration daher letztlich als Bugfix
  zu werten.

  1.2. Ausgehende Nachrichten  (ZConnect => RFC)
  ----------------------------------------------

  JG+MY:
  - Das Zeichen #238 in CP437 (kleines griechisches Epsilon) wird als
    Euro-Symbol interpretiert und in das Zeichen #164 im Zeichensatz
    ISO-8859-15 konvertiert; der Zeichensatz wird mittels des von XP
    erzeugten Headers "X-Charset: ISO-8859-15" automatisch korrekt im
    entsprechenden MIME-Header "Content-Type:" deklariert.

  MY:
  - Da dies bei einer "extern" (= nicht im Betrieb mit XP) stattfinden-
    den Konvertierung von Nachrichten, die nicht von XP erzeugt wurden
    und bei denen mangels eines "X-Charset:"-Headers auch eine fehler-
    hafte Zeichensatz-Deklaration erfolgen wrde, evtl. nicht gewnscht
    ist, kann diese Euro-Untersttzung mit dem neuen Schalter "-noEuro"
    deaktiviert werden. Das kleine Epsilon wird dann entsprechend der
    IBM=>ISO1-Tabelle in ein "e" konvertiert. Dabei wird auch ein
    "falsch" deklarierter Zeichensatz ISO-8859-15 in einem eventuellen
    "X-Charset:"-Header nach ISO-8859-1 korrigiert.
    Wenn die Euro-Untersttzung fr ausgehende Nachrichten im Extern-
    betrieb jedoch gewnscht ist, sollte unbedingt die Kommandozeilen-
    option "-chkbody" gesetzt werden (siehe weiter unten). Nur dann ist
    sichergestellt, da der Zeichensatz auch dann korrekt deklariert
    wird, wenn die Nachricht das als Euro-Symbol interpretierte Epsilon
    "" enthlt.
    Hinweis: Der Schalter "-noEuro" kann nicht von XP aus gesetzt werden
             und ist daher nur im Externbetrieb nutzbar.

  2.   Allgemeine nderungen und Korrekturen
  ------------------------------------------

  2.1. Eingehende Nachrichten  (RFC => ZConnect)
  ----------------------------------------------

  MY:
  - Fix: Zeichensatz-Konvertiertabellen ISO=>IBM komplett berarbeitet,
    nderungen und Korrekturen bei fast 50 Zeichen vorgenommen (siehe
    Tabellen in MIMEDEC.PAS):
    1. Prinzipiell werden Zeichen, die im IBM-Zeichensatz nicht existie-
       ren, statt nach optischen Kriterien jetzt danach konvertiert, wie
       sie ausgesprochen werden bzw. welche Bedeutung ein Symbol hat. So
       werden z.B. die Zeichen #222 und #254 in ISO-8859-1 (groer und
       kleiner Buchstabe "Thorn") nicht mehr in ein "P" bzw. "p" konver-
       tiert, nur weil das mit viel Phantasie halbwegs hnlich aussieht,
       sondern in ein "T" bzw. "t".
    2. Unkonvertierbare Zeichen, fr die es keine sinnvolle Translitera-
       tion im IBM-Zeichensatz gibt, werden jetzt in das Blockgrafik-
       zeichen #177 konvertiert, statt als Zeichenwert 1:1 durchgereicht
       zu werden. So mu man nicht mehr rtseln, ob es sich bei dem
       Zeichen, das man sieht, wirklich um ein korrekt konvertiertes
       oder doch nur um ein nicht konvertierbares Zeichen handelt.
    ToDo: "Multichar-Konvertierung" fr bestimmte Zeichen und Symbole
    ----- implementieren (z.B. Trademark-Symbol => "tm", Thorn => "Th")

  JG:
  - Unicode-Untersttzung (UTF-7 und UTF-8) fr den von XP lokal verwen-
    deten Zeichensatz CP437 erweitert: Alle 75 Zeichen, die in CP437,
    nicht aber in ISO-8859-1 existieren (z.B. Block- und Rahmengrafik-
    zeichen), werden jetzt von UTF-7/8 direkt in das entsprechende
    Zeichen aus CP437 korrekt konvertiert, statt wie bisher durch ein
    Fragezeichen reprsentiert zu werden.

  JG+MY:
  - Untersttzung des Zeichensatzes ISO-8859-15 (ISO-8859-1 mit Euro-
    Symbol und einigen anderen Abweichungen) implementiert.

  MY:
  - Untersttzung weiterer Zeichenstze implementiert:
      ISO-8859-2 (osteuropische Variante von ISO-8859-1)
      ISO-8859-9 (trkische Variante von ISO-8859-1)
      CP850      (DOS-Codepage 850)
      CP858      (DOS-Codepage 850 mit Euro-Symbol)
    Es werden alle bei der IANA registrierten Aliasnamen dieser Zeichen-
    stze untersttzt.

  MY:
  - Einige IANA-Aliasnamen fr die vom UUZ untersttzten Zeichenstze
    ergnzt und auf den neuesten Stand gebracht.

  MY:
  - Fix: Header mit einer Lnge von mehr als 253 Zeichen, die kein Leer-
    zeichen und kein anderes Trennzeichen (Komma, Semikolon) enthalten,
    werden nicht mehr vernichtet (bisher erzeugte UUZ dann einen leeren
    Header!).

  MY:
  - Untersttzung des Envelope-Headers "Delivered-To:" verbessert und an
    qmail-Praxis angepat: Es wird nicht mehr zwingend der letzte
    "Delivered-To:"-Header als Envelope-Empfnger betrachtet, sondern
    entweder der erste, der eine Adresse enthlt, die mit "alias-"
    beginnt, oder, falls eine solche Adresse nicht vorkommt, der zweite
    von allen "Delivered-To:"-Headern (falls mehrere existieren). Bei
    nur einem "Delivered-To:"-Header wird dieser genommen (logisch).

  MY:
  - Fix: Der Envelope-Header "Delivered-To:" wird jetzt auch bei Mails
    im UUCP-Format beachtet (bisher nur bei Mails im SMTP-Format).

  MY:
  - Wie schon bisher bei Mails im SMTP-Format, werden Envelope-Header
    ("Envelope-To:", "X-Envelope-To:", "Delivered-To:") jetzt auch bei
    Mails im UUCP-Format nicht mehr zwangsweise ausgewertet, sondern nur
    noch dann, wenn der Kommandozeilenschalter "-UseEnvTo" gesetzt ist.
    ToDo: Entsprechenden Schalter im UUCP-Boxen-Dialog von XP
    ----- nachrsten.

  MY:
  - Der Schalter "-UseEnvTo" rumt bei gleichzeitigem Vorhandensein
    eines "(X-)Envelope-To:"-Headers und eines "Delivered-To:"-Headers
    dem "(X-)Envelope-To:"-Header hhere Prioritt ein und ignoriert den
    "Delivered-To:"-Header.

  MY:
  - Fix: Die Umwandlung der sog. "Bang-Adressierung" in eine nach
    heutigen Regeln RFC-konforme Adresse erfolgt jetzt bei *allen*
    Adressen (bisher nur beim "To:"-Header). Dieser Fix ist eher von
    akademischem Nutzen, weil Bang-Adressierung so gut wie nicht mehr
    vorkommt.

  MY:
  - Das Lo-ASCII-Zeichen #26 (Ctrl-Z) wird beim Einlesen des RFC-Puffers
    jetzt durch ein ">" (statt durch ein Fragezeichen) ersetzt.

  MY:
  - Auswertung folgender zustzlicher/alternativer RFC-Header
    implementiert:
      "Mailer:"              (RFC2076)
      "Mail-System-Version:" (RFC2076)
      "Originating-Client:"  (RFC2076)
      "X-Reader:"            (offenbar Mozilla-Praxis)
      "Obsoletes:"           (RFC2076, quivalent zu "Supersedes:")
      "Organisation:"        (RFC2076, US-Schreibweise von
                              "Organization:")
      "Importance:"          (RFC2076/1327/1911, quivalent zu
                              "Priority:")

  MY:
  - Bei "Priority:" bzw. "Importance:" wird jetzt "non-urgent"
    (= niedrig) als weiterer mglicher Wert interpretiert
    (RFC2076/1327).

  MY:
  - Fix: Ein Envelope-Empfnger wird jetzt mit *allen* EMP:-Headern
    abgeglichen (bisher nur mit dem ersten). Konkrete Folge: Nur wenn
    sich der Envelope-Empfnger in *keinem* der EMP:-Header befindet
    (z.B. bei BCCs), werden die Empfnger in den EMP:-Headern nach OEM:
    geschrieben. Bisher passierte das auch dann, wenn sich der Envelope-
    Empfnger zwar nicht im ersten, dafr aber in einem der folgenden
    EMP:-Header befand.

  MY:
  - Der RFC-Header "Sender:" hat jetzt Prioritt vor einem evtl. aus den
    SMTP/UUCP-Protokoll-Headern herausoperierten "Envelope-Absender".
    Es wird daher jetzt immer der "Sender:"-Header statt des Envelope-
    Absenders nach WAB: geschrieben, sofern vorhanden.

  MY:
  - Bei "Reply-To:"- und "Sender:"-Headern wird ein evtl. vorhandener
    Realname jetzt nicht mehr vernichtet, sondern in den Antwort-an:-
    bzw. WAB:-Header geschrieben.
    ToDo: Realname in Antwort-an:-Headern im XP-Listerkopf anzeigen.
    -----
    (Eine entsprechende nderung fr Realnames in To:- und Envelope-
    Headern ist geplant, scheitert aber momentan noch daran, da dafr
    eine nderung in XP selbst erforderlich ist, da im Moment PM-Bretter
    mit Namen angelegt wrden, die ebenfalls den Realname enthalten).

  MY:
  - Fix: Bei eingehenden Nachrichten mit einem Content-Type-Header
    *ohne* Charset-Parameter geht der UUZ jetzt genau wie bei Nach-
    richten, die gar keinen Content-Type-Header haben, vom Zeichensatz
    ISO-8859-1 aus und fhrt eine entsprechende Konvertierung in den
    IBM-Zeichensatz durch (bisher wurde der Zeichensatz als US-ASCII
    gewertet und die Nachricht daher nicht konvertiert).

  MY:
  - Folgende RFC-Header werden jetzt mit dem Prefix "X-Orig-" als
    Backup-Header im unvernderten (d.h. auch undecodierten) Original-
    RFC-Format und in voller Lnge in den ZC-Header geschrieben:
      "From:"        => "X-Orig-From:"
      "Sender:"      => "X-Orig-Sender:"
      "Reply-To:"    => "X-Orig-Reply-To:"
      "To:"          => "X-Orig-To:"
      "Cc:"          => "X-Orig-Cc:"
      "Newsgroups:"  => "X-Orig-Newsgroups:"
      "Followup-To:" => "X-Orig-Followup-To:"
      "Subject:"     => "X-Orig-Subject:" (nur wenn MIME-codiert)
    Die einzigen nderungen, die UUZ an diesen Headern vornimmt, sind,
    gefaltete Header zu entfalten und Mehrfach-Leerzeichen gem RFC2822
    durch ein Leerzeichen zu ersetzen (letzteres nicht bei "Subject:").
    Das Schreiben dieser Header dient im Moment primr dem Zweck, die
    Mglichkeit der Kontrolle darber zu haben, ob bzw. wie diese Header
    in das ZConnect-Format konvertiert wurden, auch wenn die originale
    RFC-Nachricht nicht mehr vorliegt.
    Ob das Schreiben dieser Header auf Dauer beibehalten wird, wird die
    Praxis und die Reaktion der XP-User ergeben.

  MY:
  - Workaround: Der Header LEN: wird jetzt immer als letzter ZConnect-
    Header geschrieben, weil sich empirisch erwiesen hat, da das
    Programm "PktXCode" hufiger Probleme hat, Dateien korrekt aus der
    Mail zu extrahieren, wenn danach noch weitere Header folgen.

  MH[+MY]:
  - Neuen Schalter "-bBoxname" implementiert (Vorbereitung fr eine
    evtl. Kompatibilitt des FreeXP-UUZ mit XP2 und eine sptere
    Verwendung auch in FreeXP). Der bergebene Boxname wird in den
    ZC-Header "X-XP-BOX:" geschrieben.

  RB[+MY]:
  - Untersttzung des Headers "X-XP-Mode:" implementiert (Vorbereitung
    fr eine evtl. Kompatibilitt des FreeXP-UUZ mit XP2 sowie die
    sptere Implementierung von "HdrOnly" in FreeXP).

  2.2. Ausgehende Nachrichten  (ZConnect => RFC)
  ----------------------------------------------

  MY:
  - Fix: MIME-Singlepart-Nachrichten mit einem anderen Zeichensatz als
    ISO-8859-1 (z.B. ISO-8859-15) im X-Charset-Header und ohne ZConnect-
    Charset-Header "ISOx" (x=1-15) wurden nach der Konvertierung durch
    den UUZ hufig dennoch mit der Zeichensatzdeklaration ISO-8859-1
    versandt. Variable 'convibm' wurde in der Routine 'SetMimeData'
    geprft, bevor sie gesetzt wurde und hatte dadurch einen zuflligen
    Wert - als Folge dieses Fixes mute das Setzen der Variable 'mpart'
    bei ausgehenden Nachrichten nach 'SetMimeData' verlegt werden, weil
    ansonsten Multipart-Nachrichten einer Zeichensatzkonvertierung
    unterzogen worden wren.

  MY:
  - Vorbereitung fr zuknftige ZConnect-Zeichensatzerweiterungen:
    Beim Betrieb eines externen Clients in einer ZConnect-Box wird bei
    der Konvertierung von ISO-Nachrichten jetzt nicht mehr stur der
    Zeichensatz ISO-8859-1 deklariert, sondern die Deklaration richtet
    sich nach der jeweiligen Bezeichnung im ZConnect-Charset-Header
    ("ISO15" wird zu "ISO-8859-15"). Die Existenz eines ZConnect-Headers
    "CHARSET: ISOx" (x=1-15) verhindert nach wie vor eine (nochmalige)
    Zeichensatzkonvertierung (die Nachricht liegt bereits in einem
    ISO-Zeichensatz vor).

  MY:
  - Fix: Zeichensatz-Konvertiertabellen IBM=>ISO komplett berarbeitet,
    nderungen und Korrekturen bei fast 20 Zeichen vorgenommen (siehe
    Tabellen in MIMEDEC.PAS):
    1. Prinzipiell werden Zeichen, die im ISO-Zeichensatz nicht existie-
       ren, statt nach optischen Kriterien jetzt danach konvertiert, wie
       sie ausgesprochen werden bzw. welche Bedeutung ein Symbol hat. So
       wird z.B. das Zeichen #233 in CP437 (groer Buchstabe "Theta")
       nicht mehr in ein "O" konvertiert, nur weil das mit viel
       Phantasie halbwegs hnlich aussieht, sondern in ein "T".
    2. Unkonvertierbare Zeichen, fr die es keine sinnvolle Translitera-
       tion im ISO-Zeichensatz gibt, werden jetzt in einen Punkt (#46)
       statt wie bisher in ein Leerzeichen konvertiert, damit keine
       unsinnigen Zeilenumbrche entstehen.
    3. Steuerzeichen im Bereich #0-#31 werden entweder ebenfalls in
       einen Punkt oder in ein sinnvolles Ersetzungszeichen konvertiert,
       mit Ausnahme der Zeichen #9 (HT), #10 (LF), #12 (FF) und #13
       (CR), die unverndert durchgereicht werden, sowie dem Zeichen #0,
       das in ein Leerzeichen konvertiert wird. (Anmerkung: Es ist zu
       berlegen, Steuerzeichen 1:1 durchzureichen, da sie im Unter-
       schied zu ZConnect bei RFC prinzipiell erlaubt sind.)
    4. Eine "Multichar-Konvertierung" fr bestimmte Zeichen und Symbole
       (z.B. Peseten-Symbol "" => "ESP") fhrt der UUZ nicht durch,
       weil diese bereits in XP stattfindet, bevor die Nachricht an den
       UUZ bergeben wird.

  MY:
  - Der Schalter "-client" impliziert jetzt den Schalter "-SMTP", so da
    die zustzliche Angabe von "-SMTP" bei "-client" nicht mehr erfor-
    derlich ist (es werden bei "-client" also jetzt *immer* Nachrichten
    im SMTP-Format erstellt).

  MY:
  - Neuer Schalter "-chkbody" fr die ZC=>RFC-Konvertierung von Nach-
    richten, die nicht von einer RFC-Box in XP erzeugt wurden und daher
    nicht zwingend ber einen "X-Charset:"-Header verfgen, in dem
    bereits der korrekte Zeichensatz deklariert ist:
    UUZ prft bei Verwendung dieses Schalters den Body darauf, ob dieser
    *nach* einer Konvertierung in den ISO1-Zeichensatz noch 8bit-Zeichen
    enthalten wrde. In Abhngigkeit vom Ergebnis dieser Prfung werden
    dann automatisch der Zeichensatz und die Transportcodierung in den
    entsprechenden RFC-Headern "Content-Type:" und "Content-Transfer-
    Encoding:" korrekt deklariert:
    1. Nachrichten, deren Body keine 8bit-Zeichen enthalten, werden
       ausnahmslos mit dem Zeichensatz "US-ASCII" und der Transport-
       codierung "7bit" deklariert.
    2. Nachrichten mit 8bit-Zeichen im Body werden nach ISO konvertiert
       und mit dem entsprechenden Zeichensatz (i.d.R. "ISO-8859-1")
       sowie der gewhlten Transportcodierung ("8bit" oder "quoted-
       printable") deklariert. Ein evtl. vorhandener Header "X-Charset:"
       wird ignoriert. Wenn die Nachricht das als Euro-Symbol interpre-
       tierte Zeichen #238 ("") in CP437 enthlt und der Schalter
       "-noEuro" nicht gesetzt ist, wird automatisch der Zeichensatz
       "ISO-8859-15" deklariert und das Zeichen nach #164 (Euro-Symbol
       in ISO15) konvertiert (siehe auch "Euro-Support" weiter oben).
    3. Bei Nachrichten, die bereits im ISO-Zeichensatz vorliegen und die
       8bit-Zeichen enthalten, wird der ZConnect-Header "CHARSET: ISOx"
       beachtet und der ZConnect-spezifische Name des Zeichensatzes
       (z.B. "ISO9") in die offizielle Bezeichnung (in diesem Fall
       "ISO-8859-9") umgewandelt.
    4. MIME-Multipart-Nachrichten werden - genau wie bisher - weder
       geprft noch konvertiert.
    UUZ ist mit dem Schalter "-chkbody" auch als universeller externer
    RFC-Konvertierer einsetzbar. Er ist aber auch fr User interessant
    und von Bedeutung, die einen externen Client wie UKA_PPP oder eine
    der lteren UKAW-Versionen in einer ZConnect-Box einsetzen, weil
    dadurch der Aufruf des Hilfsprogramms "X_SPOOL.EXE" mit dem Schalter
    "/xc" unmittelbar vor der UUZ-Konvertierung entbehrlich wird. Dieser
    Aufruf erzeugte bisher eine oft fehlerhafte Deklaration von Zeichen-
    satz und Codierung, da X_SPOOL.EXE keine Prfung des Nachrichten-
    textes durchfhrt, blind "8bit" und "ISO-8859-1" deklariert und auch
    keine Rcksicht auf andere in einem eventuellen CHARSET:-Header
    deklarierten Zeichenstze nimmt.
    [Detailliertere Erluterungen zum Einsatz des Enhanced UUZ mit
     UKA_PPP folgen im Teil der Dokumentation zum "Enhanced UUZ/II" an
     an einer spteren Stelle in diesem Dokument.]
    Hinweis: Der Schalter "-chkbody" kann nicht von XP aus gesetzt
    -------- werden und ist daher nur im Externbetrieb nutzbar.

  MY:
  - Fix: Bei der ZC=>RFC-Konvertierung wird ein evtl. vorhandener Header
    "U-Content-Transfer-Encoding:" jetzt ignoriert. Bisher wurde
    *sowohl* ein neuer Header "Content-Transfer-Encoding:" generiert
    *als auch* durch das Entfernen des Prefixes "U-" bei einem evtl.
    bereits vorhandenen Header mit ansonsten identischer Bezeichnung ein
    unzulssiges Duplikat dieses Headers (mit u.U. abweichendem Inhalt)
    erzeugt.

  MY:
  - Fix: Bei Singlepart-Nachrichten im Zeichensatz "US-ASCII" werden
    jetzt Zeichensatz und Transportcodierung korrekt mit "US-ASCII" und
    "7bit" deklariert (bisher: "iso-8859-1" und "8bit").

  MY:
  - Fix: Bei MIME-Multipart-Nachrichten wird im Top-Level-Header jetzt
    immer eine Transportcodierung im Header "Content-Transfer-Encoding:"
    deklariert, und zwar generell "8bit". Bisher wurde im Top-Level-
    Header gar keine Transportcodierung deklariert, was gleichbedeutend
    mit "7bit" ist und daher bei Text-Anhngen mit 8bit-Zeichen dazu
    fhrte, da manche Mail-/Newsreader diese Zeichen nicht richtig
    darstellen konnten.
    Zwar wre es technisch mglich, den Body der Nachricht auf das
    Vorkommen von 8bit-Zeichen zu prfen und im Top-Level-Header ggf.
    auch "7bit" zu deklarieren, dies wrde aber bei groen Attachments
    mit mehreren MB die Performance bei der Konvertierung zu drastisch
    beeintrchtigen.

  MY:
  - Die ZConnect-Header "Post:" und "Telefon:" werden jetzt (und mangels
    "echter" RFC-Header fr diese Informationen) in die experimentellen
    RFC-Header "X-ZC-Post:" und "X-ZC-Telefon:" geschrieben und kommen
    zumindest bei XP-Anwendern daher jetzt auch verlustfrei an.

  MY:
  - Im "Subject:"-Header werden "falsche" Prefixe wie "RE: ", "re:",
    "AW: " und "Sv: " sowie alle Inkarnationen davon jetzt durch das
    korrekte "Re: " ersetzt.

  MY:
  - Fix: Der "Lines:"-Header enthlt jetzt auch dann die korrekte
    Zeilenanzahl, wenn die Nachricht "quoted-printable"-codiert wird und
    durch den dabei evtl. erforderlichen Zeilenumbruch nach 76 Zeichen
    zustzliche Zeilen erzeugt werden mssen.

  MY:
  - Fix: Es werden jetzt auch bei ausgehenden Nachrichten bis zu 160
    Zeichen lange Message-IDs verarbeitet (bisher 120 Zeichen ausgehend
    und 160 Zeichen eingehend, relevant fr MID:- und BEZ:-Header).

  MY:
  - Temporr-Fix: Bei "gemischten" Nachrichten (Mail- und Brettempfnger
    gleichzeitig, kann im Betrieb mit XP nicht auftreten und ist daher
    nur fr den Externbetrieb relevant) werden keine Brettempfnger mehr
    in "RCPT TO:"- und "Cc:"-Header geschrieben - die Brettnachricht
    geht also verloren. Anderenfalls wrde die Nachricht aber gar nicht
    versandt werden, weil sie ungltige Mail-Adressen enthlt.

  MY:
  - Es wird jetzt ein Header "X-RFC-Converter:" erzeugt, der Dateidatum
    und -uhrzeit der verwendeten UUZ-Version enthlt.

  MY:
  - Am Ende der Verarbeitung gibt der UUZ jetzt eine Art Performance-
    Statistik aus (verarbeitete Daten in Kilobyte, Dauer der Verarbei-
    tung, Kilobyte/Sekunde und Nachrichten/Sekunde).


  3.   Korrekturen, nderungen und Erweiterungen im Zusammenhang mit der
       Anpassung an aktuell gltige RFC-Standards
       ((son-of-)1036/2045/2047/2822)
  ----------------------------------------------------------------------

  3.1.  Eingehende Nachrichten  (RFC => ZConnect)
  -----------------------------------------------

  MY:
  - Das Lo-ASCII-Zeichen #0 wird beim Einlesen des RFC-Puffers jetzt
    durch ein Leerzeichen ersetzt (ASCII #0 ist gem RFC2822 nicht mehr
    erlaubt).

  MY:
  - Fix: Untersttzung mehrerer Adressen im "From:"-Header.
    Gem RFC2822 kann der "From:"-Header mehrere Adressen enthalten (es
    mu dann ein "Sender:"-Header vorhanden sein). Dies war XP bisher
    nicht bekannt, deshalb hat es die komplette komma-separierte Liste
    der Adressen im "From:"-Header bisher als einen einzigen Absender
    betrachtet, diese auch so in den ABS:-Header bernommen und einen
    entsprechenden User angelegt ("abs1@test.de, abs2@test.de,
    abs3@test.de") - argh...
    Die neue Vorgehensweise ist wie folgt:
    1. Zunchst werden evtl. vorhandene Dupes aus dem "From:"-Header
       entfernt.
    2. Danach wird die erste nicht-leere Adresse im "From:"-Header in
       den ABS:-Header bernommen. Existiert nach dem Entfernen von
       Dupes keine nicht-leere Adresse im "From:"-Header mehr, wird
       anders als bisher ein evtl. vorhandener "Envelope-Absender" (WAB)
       *nicht* mehr in den ABS:-Header bernommen. Dies dient der
       Vermeidung der "Flschung" von Headerinformationen.
    3. Leeren Adressen wird die Adresse "unknown@sender" verpat, ein
       evtl. vorhandener Realname wird beibehalten (Absender wie
       "Theo Tester <>" kommen in der Tat vor).
    4. Da ZConnect mehrere ABS:-Header nicht zult, werden die brigen
       Absender in ANTWORT-AN:-Header geschrieben, damit sie nicht ganz
       verlorengehen. Die Groschreibung von "ANTWORT-AN:" dient einer
       spteren mglichen Unterscheidung in XP von "echten" Antwort-an:-
       Headern in Gro-/Kleinschreibung (= "Reply-To:").
    ToDo: Untersttzung mehrerer Antwort-an:-Header in XP selbst,
    ----- speziell bei RTA und Anzeige im Listerkopf.

  MY:
  - Fix: Untersttzung mehrerer Adressen im "Reply-To:"-Header. Es wird
    jetzt fr jede im "Reply-To:"-Header vorhandene Adresse ein
    Antwort-an:-Header erzeugt. Bisher wurden wie beim "From:"-Header
    mehrere Adressen im "Reply-To:"-Header als eine einzige Adresse
    betrachtet und auch so in den Antwort-an:-Header bernommen. Beim
    Beantworten wurde der gesamte Header dann vollstndig verworfen,
    weil "reply1@test.de, reply2@test.de" als ungltige Adresse erkannt
    wurde.
    ToDo: Untersttzung mehrerer Antwort-an:-Header in XP selbst,
    ----- speziell bei RTA und Anzeige im Listerkopf.

  MY:
  - Fix: Beim Schreiben der Antwort-an:-Header wird ein Dupeabgleich
    jetzt mit *allen* Absenderadressen vorgenommen und daher nur fr die
    Adressen ein Antwort-an:-Header erzeugt, die nicht auch gleichzeitig
    Absender sind.

  MY:
  - Fix: Ein WAB:-Header (Weiterleiter/Envelope-Absender) wird entfernt,
    wenn er mit einer der Absenderadressen identisch ist. Bei mehreren
    Absenderadressen ist der mit dem WAB: identische Absender dann in
    jedem Fall derjenige, der in den ABS:-Header bernommen wird, die
    brigen Absender werden in ANTWORT-AN:-Header geschrieben (s.o.).

  MY:
  - RFC-Parser (MIME-Decodierung, Erkennung/Unterscheidung/Behandlung
    von Adressen, Realnames und Message-IDs sowie darin enthaltenen
    Kommentaren, Phrasen, quoted-strings und quoted-pairs) komplett
    neugeschrieben. Details:
     1. Die MIME-Decodierung ist im Sinne des "robustness principle"
        jetzt extrem fehlertolerant und decodiert anders als bisher z.B.
        auch 'encoded words', die Leerzeichen enthalten (was laut
        RFC2047 unzulssig ist, in der Praxis aber vorkommt), oder die
        anderweitig und RFC-widrig verunstaltet sind.
     2. Mit dem neuen Kommandozeilenschalter "-rfcMime" kann man das
        "robustness principle" in sein Gegenteil verkehren und eine
        MIME-Decodierung erzwingen, die streng nach RFC2047 decodiert,
        und so den UUZ als "Checkbot" benutzen: Was dann nicht decodiert
        wird, ist nicht korrekt codiert. :-)
        UUZ bercksichtigt in Headerzeilen dann die im jeweiligen
        Kontext (strukturierter/unstrukturierter Header, quoted-string,
        Kommentar) geltenden unterschiedlichen Regeln und decodiert nur
        noch Zeichenfolgen, die im jeweiligen Kontext auch ein gltiges
        'encoded word' bilden. Zeichenfolgen, die nur so hnlich
        aussehen wie ein 'encoded word' (weil sie vom Absender bewut so
        gestaltet oder weil sie von fehlerhafter Software fehlerhaft
        codiert wurden), werden dann nicht mehr decodiert.
        Hinweis: Der Schalter "-rfcMime" kann derzeit nicht von XP aus
                 gesetzt werden und ist daher nur im Externbetrieb
                 nutzbar.
     3. Fix: Nachrichtentexte und Header, die in einem ungltigen oder
        von XP nicht untersttzten Zeichensatz vorliegen (ISO-8859-5
        Kyrillisch, ISO-8859-6 Arabisch o.a.), werden jetzt nicht mehr
        blind auf Basis der in diesen Fllen unzutreffenden ISO1-Tabelle
        "kaputtkonvertiert", sondern im Originalzustand belassen. So
        knnen sie notfalls noch manuell dechiffriert werden (bei
        Headern war bisher nicht einmal mehr erkennbar, welcher Zeichen-
        satz vom Autor ursprnglich verwendet wurde).
     4. Fix: Die gesamte Prfung auf gltige 'encoded words', gltige
        bzw. untersttzte Zeichenstze usw. findet jetzt statt, *bevor*
        die Decodierroutine den Header verndert. Bisher wurden generell
        zuerst smtliche Merkmale eines codierten Headers (MIME-
        Delimiter, Zeichensatz-/Codierungsdeklaration) entfernt, und
        erst anschlieend stellte sich u.U. heraus, da eine Decodierung
        gar nicht mglich bzw. sinnvoll ist.
     5. Fix: Nach erfolgter MIME-Decodierung eines Headers werden im
        decodierten String nicht mehr alle vorhandenen Lo-ASCII-Zeichen
        ersetzt, sondern nur noch #0, #9 (<TAB>), #10 (LF) und #13 (CR)
        durch Leerzeichen sowie #26 (<Ctrl-Z>) durch ">".
     6. Fix: Die Regeln fr das Entfernen bzw. Nicht-Entfernen von
        Leerzeichen zwischen mehreren 'encoded words' bzw. zwischen
        'encoded words' und uncodiertem Text werden jetzt in allen
        Fllen korrekt beachtet. Des weiteren werden nicht codierte
        Mehrfach-Leerzeichen nur noch dort durch eines ersetzt, wo dies
        auch zulssig bzw. Pflicht ist (nmlich in strukturierten
        Headern wie "From:" und "To:", nicht aber in unstrukturierten
        Headern wie "Subject:" und "Summary:").
     7. Workaround: Wenn der "In-Reply-To:"-Header mehrere Message-IDs
        enthlt, wird jetzt die letzte (statt bisher der ersten)
        Message-ID in den BEZ:-Header bernommen. Diese Manahme
        kompensiert das Verhalten der von ZConnect<=>RFC-Gates hufig
        eingesetzten Software "DUUCP", mehrere BEZ:-Header bei ausgehen-
        den Mails nicht nach "References:", sondern in eine komma-
        separierte Liste nach "In-Reply-To:" zu bernehmen, sowie das
        dadurch verursachte Problem, da bei einem Reply auf eine Mail
        in einem AM-Brett mit eingetragenem PM-Vertreter - hufige
        Konstellation bei Mailinglisten - bisher eine falsche Bezugs-
        verkettung beim Empfnger des Replies hergestellt wird.
     8. Fix: Bei allen Headern, die Adressen enthalten, findet die
        Erkennung von bzw. die Aufteilung in Adresse und Realname jetzt
        *vor* der MIME-Decodierung statt. Bisher konnte es in besonders
        trickreich gelagerten Fllen sogar zu einer Verwechslung von
        Absender und Realname kommen.
        (Beispiel: "=?UTF-8?B?PGdvdEBjaGE+?= <an@other.example>")
     9. Fix: Adressen werden generell nicht mehr MIME-decodiert, weil
        sie per RFC-Definition gar nicht MIME-codiert sein knnen/drfen
        und daher jede einer MIME-Codierung hnliche Zeichenfolge in
        einer Adresse nicht als solche interpretiert werden darf.
    10. Fix: Group-Adressierung ("A Group: a@b.de, c@d.de;") wird jetzt
        erkannt und die Group-Bezeichnung entfernt. Leere Groups wie
        "Undisclosed Recipients:;" werden dabei aufgelst zu
        "!Empty_group@Undisclosed_Recipients" und sind daher zuknftig
        allesamt an einer zentralen Stelle unter "!Empty_group@..." in
        der User-bersicht aufzufinden und knnen dort bequem gelscht
        werden, falls sie durch die automatische User-Aufnahme angelegt
        worden sein sollten.
    11. Fix: Route-Adressierung ("<@pc1.tld,@pc2.tld:theo@test.de>")
        wird jetzt in allen Fllen korrekt erkannt und entfernt (beim
        obigen Beispiel lautet die aufgelste Adresse somit
        "theo@test.de"). Bisher wurden z.B. Mehrfach-Routes nicht
        korrekt aufgelst.
    12. Fix: Behandlung von Kommentaren, quoted-pairs/strings und
        Leerzeichen in Adressen und Realnames deutlich verbessert und
        jetzt RFC-konform implementiert:
        - Kommentare in Adressen werden jetzt korrekt erkannt und
          entfernt. Bisher hielt XP alles, was hinter der ersten
          ffnenden Klammer folgte, fr einen Realname, und zerstrte
          damit Adresse wie Realname.
        - Kommentare, Anfhrungszeichen und quoted-pairs im Realname
          werden jetzt korrekt und vollstndig erkannt und den Regeln
          entsprechend (!) entfernt (d.h., sie werden jetzt dort auch
          nicht entfernt, wo sie den Regeln nach nicht entfernt werden
          drfen).
        - Bei Adressen, deren local part unntigerweise als quoted-
          string vorliegt und/oder berflssige quoted-pairs enthlt,
          werden diese jetzt entfernt. Korrekt gesetzte und notwendige
          quoted-pairs/strings bleiben erhalten.
        - Leerzeichen in Adressen werden jetzt entfernt, sofern sie sich
          nicht im quoted-string eines local part befinden (dort sind
          sie zulssig).
        Drei Beispiele fr die obigen Flle mit RFC-konformen Headern:
        a) Der Header    : From: theo(ah!)@test(oh!).de
           - wurde bisher:  ABS: theo (ah!)@test(oh!).d)
           - wird  jetzt :  ABS: theo@test.de
        b) Der Header    : From: t. "te\st"@test.de (T. \("T"\) Tester)
           - wurde bisher:  ABS: t. "te\st"@test.de (T. \("T"\) Tester)
           - wird  jetzt :  ABS: t.test@test.de (T. ("T") Tester)
        c) Der Header    : From: "Theo Tes\ter"@test.de
           - wurde bisher:  ABS: "Theo Tes\ter"@test.de
           - wird  jetzt :  ABS: "Theo Tester"@test.de
    13. Fix: Adressen in Envelope-Headern werden jetzt derselben
        Prozedur unterzogen wie Adressen in allen anderen Headern auch
        (spitze Klammern, Kommentare, quoted-pairs/strings usw.
        behandeln).
    14. Alle oben beschriebenen Verfahren funktionieren sowohl mit der
        "neuen" Form der Adressierung ("Real Name <user@do.main>") als
        auch mit der "alten" Form ("user@do.main (Real Name)").
    15. Fix: Innerhalb jeder einzelnen und zwischen mehreren Message-IDs
        (wie bei "In-Reply-To:" und "References:") werden Kommentare,
        Phrasen, quoted-pairs/strings und Leerzeichen jetzt (korrekt)
        entfernt. Damit ist sichergestellt, da syntaktisch unterschied-
        liche, aber semantisch identische Message-IDs in XP auch iden-
        tisch behandelt werden (diese Form der Message-ID-Behandlung
        sollte langfristig allerdings besser in XP selbst stattfinden,
        da die Syntax von Message-IDs idealerweise nicht verndert
        werden sollte).
        Gleichzeitig ist dadurch jetzt gewhrleistet, da keine Phrasen
        bzw. quoted-strings zwischen mehreren Message-IDs mehr flsch-
        licherweise als Message-ID interpretiert werden. Bei nicht RFC-
        konformen Message-IDs wie "In-Reply-To: mid1@fqdn, mid2@fqdn"
        (spitze Klammern fehlen, Liste ist komma-separiert) wird per
        Brute-Force-Methode die letzte Message-ID korrekt erkannt statt
        entweder den gesamten Header flschlicherweise als eine einzige
        Message-ID zu interpretieren oder ihn alternativ vollstndig zu
        vernichten.
    16. Fix: Bei der Konvertierung des "Keywords:"-Headers (RFC) in
        mehrere "Stichwort:"-Header (ZC) werden jetzt sowohl Phrasen
        (mehrere Worte mit Leerzeichen) und quoted-strings korrekt
        behandelt (bisher: gar nicht) sowie quoted-pairs korrekt
        entfernt (bisher: gar nicht).
        Des weiteren wird der Header jetzt *zuerst* in einzelne Keywords
        bzw. Phrasen zerlegt und erst *dann* MIME-decodiert, so da als
        Bestandteil einer Phrase bewut codierte Kommata nicht mehr als
        Trennzeichen zwischen mehreren Keywords fehlinterpretiert
        werden.
    17. Fix: Bei der Auswertung der Header "References:" und
        "In-Reply-To:" hat "References:" jetzt immer Prioritt, sofern
        vorhanden. Bisher konnten sowohl bei News als auch bei Mail
        Mehrfach-Bezge verlorengehen, wenn ein "In-Reply-To:"-Header
        vorhanden war.
    18. Workaround: Da manche Mailreader (speziell Eudora) sowohl
        doppelte Message-IDs in Headern als auch inkonsistente
        "In-Reply-To:"- und "References:"-Header erzeugen (die
        Message-ID aus "In-Reply-To:" fehlt in "References:"), wird der
        "References:"-Header jetzt auf Dupes geprft und die letzte
        Message-ID aus dem "In-Reply-To:"-Header in den letzten BEZ:-
        Header geschrieben, sofern sie nicht bereits in einem anderen
        BEZ:-Header vorkommt.
    Smtliche Korrekturen und nderungen hinsichtlich der damit jetzt
    RFC-konformen Behandlung bzw. Entfernung von Kommentaren, Phrasen
    und quoted-pairs/strings schlagen, soweit im Einzelfall zutreffend,
    auch auf alle brigen - und hier nicht ausdrcklich erwhnten -
    strukturierten Header durch.

  MK:
  - Fix: News-Batches, deren Zeilenenden (EOL) aus CRLF statt nur aus
    CR bzw. LF bestehen und deren "rnews"-Header eine RFC-konforme
    Lngenangabe enthlt (ein EOL wird gem (son-of)RFC1036 unabhngig
    von der tatschlichen Lnge als 1 Byte gezhlt), werden jetzt
    korrekt und verlustfrei konvertiert. Bisher zhlte der UUZ ein CRLF
    (oder jedes andere EOL wie CRCRLF) mit exakt soviel Bytes wie das
    EOL tatschlich Bytes hatte, was zu Datenverlust bei solchen RFC-
    konformen Postings mit CRLF-Zeilenabschlssen gefhrt hat.
    Warnung: Umgekehrt werden durch diesen Fix jetzt User, die einen
    -------- Client einsetzen, der RFC-widrige Lngenangaben im "rnews"-
             Header erzeugt, von Datenverlust betroffen sein! Es wird
             daher dringend empfohlen, nur Clients einzusetzen, die RFC-
             konforme Lngenangaben erzeugen (was am einfachsten und
             sinnvollsten durch reine LF-Zeilenabschlsse gewhrleistet
             ist). RFC-widrige Lngenangaben erzeugen alle XPNews-
             Versionen bis v1.2.2 sowie einige ltere UKAW-Versionen
             (z.B. v1.37g). Um Datenverlust zu vermeiden, mssen XPNews-
             User auf die inzwischen zur Verfgung stehende Version
             1.2.3 oder hher updaten, bei den betroffenen UKAW-
             Versionen ist in der Datei <Server>.RC der Defaulteintrag
             "$newline: crlf" in "$newline: lf" zu ndern.
             Nicht negativ betroffen von diesem Fix sind hingegen
             aktuelle UKAW/UKAD-Versionen oder UKA_PPP, da diese ohnehin
             reine LF-Zeilenenden erzeugen.

  3.2. Ausgehende Nachrichten  (ZConnect => RFC)
  ----------------------------------------------

  MY:
  - Fix: Die Erzeugung RFC-widriger Header mit uncodierten Sonderzeichen
    ist jetzt nicht mehr mglich: Die UUZ-Schalter "-MIME" und "-1522"
    (entsprechen den Optionen "MIME in News" und "MIME in Headerzeilen
    verwenden" unter C/O/E/V) sind ersatzlos gestrichen. Der UUZ codiert
    Headerzeilen jetzt bei Mail *und* News *immer* nach RFC2047 (dem
    Nachfolger von RFC1522). Durch den Wegfall wird das Erzeugen fehler-
    hafter Mails und Postings bei Usern verhindert, die lediglich
    vergessen haben, diese Schalter zu aktivieren und/oder sich ber
    ihre Bedeutung nicht im klaren waren.

  MY:
  - Alle "U-Header" werden bei Bedarf nach den Regeln fr strukturierte
    Header MIME-codiert (weil das auch bei unstrukturierten Headern nie
    falsch sein kann und wir bei U-Headern nicht wissen, ob es sich um
    einen strukturierten oder unstrukturierten Header handelt). Bisher
    wurden U-Header nicht MIME-codiert und damit u.U. RFC-widrige Header
    mit 8bit-Zeichen erzeugt.

  MY:
  - MIME-Codierung, "Folden" (Falten) und "Quoten" von Headern durch
    neue Routine 'EncodeFoldQuote' drastisch optimiert/korrigiert/erwei-
    tert und an RFC2045/2047 angepat:
     1. Die Codierung erfolgt jetzt prinzipiell "minimal invasiv", d.h.
        es werden nur noch die Worte codiert, die im jeweiligen Kontext
        auch zu codierende Zeichen enthalten (bisher wurde alles vom
        ersten bis zum letzten Wort, das zu codierende Zeichen enthlt,
        codiert). Dabei wird fr jedes zu codierende Wort der zu verwen-
        dende Zeichensatz separat ermittelt. Mehrere zu codierende Worte
        hintereinander, auf die derselbe Zeichensatz angewandt werden
        kann, werden zusammengefat und gemeinsam codiert.
     2. Fix: Strukturierte Header bzw. Teile davon, die Zeichen enthal-
        ten, die als quoted-string dargestellt werden mssen, werden
        jetzt "gequotet" (d.h. in Anfhrungszeichen eingeschlossen und
        darin enthaltene Anfhrungszeichen als "quoted-pairs" darge-
        stellt). Wenn ein Header MIME-codiert werden mu, werden solche
        eigentlich zu quotenden Zeichen codiert und folgerichtig nicht
        zustzlich gequotet.
     3. Fix: Der jeweilige Kontext (strukturierter/unstrukturierter
        Header) und die sich daraus ergebenden unterschiedlichen Regeln
        fr die MIME-Codierung werden jetzt beachtet (bisher wurden alle
        Header nach den Regeln fr unstrukturierte Header codiert und
        somit u.U. fehlerhafte und RFC-widrige Header erzeugt).
     4. Fix: 'encoded words', die im Zeichensatz "US-ASCII" codiert
        werden (das kann bei strukturierten Headern, die bestimmte
        Zeichen enthalten, vorkommen) werden jetzt auch mit diesem
        Zeichensatz deklariert (statt mit "ISO-8859-1").
     5. Fix: Es werden jetzt die max. zulssigen Lngen (75 Zeichen fr
        'encoded words' und 76 Zeichen fr codierte Zeilen) beachtet.
        Bisher konnten u.U. auch lngere 'encoded words' und/oder
        codierte Zeilen erzeugt werden. Codierte Header, die lnger sind
        als 76 Zeichen, werden bei Mails (und jetzt auch korrekt, s.u.)
        gefaltet.
     6. Bei Mails wird jetzt die SOLL-Bestimmung, da auch eine
        uncodierte Headerzeile generell nicht lnger als 78 Zeichen sein
        soll, bei allen relevanten Headern beachtet und entsprechend
        gefaltet (bisher wurden nur die Header "Summary:" und einige vom
        UUZ selbst erzeugte Header wie "Received:" - und speziell bei
        Postings noch "References:" - gefaltet, nicht aber z.B. der
        "Subject:"-Header).
     7. Im Unterschied zu Mails werden bei Postings/Artikeln (AMs) nur
        noch Header gefaltet, die lnger als 998 Zeichen sind. Einer-
        seits ist Folding bei News immer noch nicht blich und erwnscht
        und kann zu Problemen bei bestimmten Funktionen ("NOV") mit
        manchen News-Servern und -Clients fhren, andererseits ist bei
        Zeilen, die lnger als 998 Zeichen sind, u.U. der sichere
        Transport nicht mehr gewhrleistet.
     8. Fix: Beim Falten von langen unstrukturierten Headern
        ("Subject:", "Summary:") bleiben Mehrfach-Leerzeichen jetzt
        in allen Fllen und in der richtigen Anzahl erhalten (bisher
        wurden sie mitunter ganz oder teilweise vernichtet).
     9. Fix: Mehrfach-Leerzeichen in strukturierten Headern (also fast
        allen auer "Subject:" und "Summary:") werden jetzt im ganzen
        String durch ein Leerzeichen ersetzt (statt wie bisher nur an
        der Stelle, an der der Header ggf. gefaltet wurde).
    10. Fix: Der Header "Keywords:" ("Stichwort:") wird jetzt korrekt
        codiert und ggf. gequotet (bisher: gar nicht) und es werden
        jetzt auch "Phrasen" (mehrere Worte mit Leerzeichen und ggf.
        Kommata) korrekt behandelt (bisher: gar nicht).
    Die neue Routine 'EncodeFoldQuote' wird aktuell bei folgenden
    RFC-Headern verwendet:
      "From:"           (ZConnect: "ABS:")
      "Sender:"         (ZConnect: "WAB:")
      "Cc:"             (ZConnect: "EMP:")
      "Keywords:"       (ZConnect: "Stichwort:")
      "Subject:"        (ZConnect: "BET:")
      "Summary:"        (ZConnect: "Zusammenfassung:")
      "X-Mailer:"       (ZConnect: "MAILER:")
      "X-Newsreader:"   (ZConnect: "MAILER:")
      "Organization:"   (ZConnect: "Organisation:")
      "X-ZC-Post:"      (ZConnect: "Post:")
      "X-ZC-Telefon:"   (ZConnect: "Telefon:")
      "X-XP-Version:"   (ZConnect: "X-XP-Version:")
      Alle 'U'-Header (z.B. "U-Received:", "U-Comments:")

  MY:
  - Fix: Bei allen Headern, die Adressen und evtl. zustzlich Realnames
    enthalten, werden diese jetzt im "neuen" (seit mindestens 1982
    definierten und seit 2001 strikt empfohlenen) RFC-Format "Real Name
    <local.part@do.main>" erzeugt. Dabei greifen in vollem Umfang die
    oben beschriebenen Korrekturen, nderungen und Erweiterungen fr
    MIME-Codierung und Quoting (relevant fr Realname!) sowie das Falten
    von Headern.

  MY:
  - Fix: Wenn eine Mail mehrere Kopienempfnger hat, werden diese jetzt
    komma-separiert in einen einzigen "Cc:"-Header geschrieben (und ggf.
    gefaltet). Bisher wurde fr jeden Kopienempfnger ein eigener "Cc:"-
    Header erzeugt, was laut RFC2822 nicht mehr zulssig ist.

  MY:
  - Fix: Bei Mails werden jetzt immer der Header "In-Reply-To:" *und*
    der Header "References:" erzeugt, wenn die Nachricht einen oder
    mehrere Bezge hat. In "In-Reply-To:" steht die Message-ID des
    letzten oder einzigen BEZ:-Headers, in "References:" stehen wie
    bisher die erste und die letzten drei Message-IDs aller BEZ:-Header.
    Dadurch bleiben Mehrfachbezge - z.B. bei Mailinglisten - jetzt
    erhalten.
    ToDo: In XP bei mehr als vier BEZ:-Headern das Krzen auf die erste
    ----- und die letzten drei Message-IDs evtl. verhindern.

  MY:
  - Fix: Bei News wird der Header "References:" nicht mehr gefaltet
    (manche News-Server und -Reader haben damit u.U. Probleme) und bei
    Bedarf jetzt auf max. 998 (statt wie bisher auf max. 980) Zeichen
    gekrzt. Beim Krzen werden - wie bisher - keine Message-IDs
    abgeschnitten, sondern solange vollstndige Message-IDs aus dem
    Header entfernt, bis die max. Lnge unterschritten ist.

  MY:
  - Fix: Wenn die Nachricht einen leeren Betreff enthlt, wird nur noch
    bei Postings (AMs) ein leerer "Subject:"-Header erzeugt (bei Mails
    ist er nicht Pflicht).


  4.   Untersttzung langer Zeilen > 253 Zeichen in Header und Body
       Diverse Variablen vergrert
  -----------------------------------------------------------------

  4.1. Eingehende Nachrichten  (RFC => ZConnect)
  ----------------------------------------------

  Prinzipiell werden jetzt alle Headerzeilen in voller Lnge ("volle
  Lnge" bedeutet: 65500 Zeichen) lesend und in vielen Fllen auch
  schreibend verarbeitet:

  MY:
  - Die gesamte Behandlung eines Headers nach RFC1036/2045/2047/2822
    (MIME-Decodierung, Erkennung von Adresse/Realname/Newsgroup und
    Message-IDs, Entfernen von Kommentaren, Behandlung von quoted-
    pairs/strings und Leerzeichen) erfolgt bei *allen* Headern jetzt
    ber die gesamte eingelesene Lnge von 65500 Zeichen.
    Selbst wenn ein Header bei der weiteren UUZ- oder XP-internen
    Verarbeitung in seiner Lnge nach wie vor auf eine bestimmte Lnge
    begrenzt sein sollte, wird damit verhindert, da Verluste nur
    deswegen entstehen, weil der Header schon von vorneherein nicht
    vollstndig gelesen und interpretiert wird. Ein MIME-codierter
    Header konnte bisher mitunter nicht vollstndig decodiert werden,
    wenn sich das Ende der Codierung jenseits einer je nach Header
    unterschiedlich definierten Grenze zwischen 253 und 3825 Zeichen
    befand, und/oder der Header wurde unntig gekrzt:
    1. Bei einem unstrukturierten Header wie z.B. "Subject:", der aus
       248 MIME-codierten "" besteht (wofr in codierter Form 995
       Zeichen bentigt werden) und der im UUZ auch auf 248 Zeichen
       begrenzt ist, wurden bisher trotzdem nur 54 decodierte "" an den
       BET:-Header zurckgegeben, weil der Header "gefaltet" war
       (gefaltet sein mute) und nur die ersten drei gefalteten Zeilen
       interpretiert wurden. Jetzt wrden alle 248 "" an den BET:-
       Header zurckgegeben werden (wobei in diesem Fall selbst bei noch
       lngeren "Subject:"-Headern ohnehin die *volle* Lnge geschrieben
       wird, Nheres dazu weiter unten).
    2. Strukturierte Header, die z.B. Empfnger ("Newsgroups:", "To:",
       "Cc:"), Message-IDs ("References:", "In-Reply-To:") oder sonstige
       wesentliche Informationen enthalten, wurden bisher je nach Header
       irgendwo zwischen Zeichen 254 und 3825 vernichtet. Jetzt wird
       auch eine Adresse oder Message-ID, die z.B. erst an Pos. 65347 im
       Header beginnt, korrekt erkannt und kann weiterverarbeitet und
       z.B. in einen BEZ:- oder EMP:-Header geschrieben werden.
    3. Die MIME-Decodierung verarbeitet jetzt beliebig lange 'encoded
       words', obwohl diese gem RFC2047 nur 75 Zeichen lang sein
       drfen. Manche Mail-/Newsreader erzeugen jedoch unter bestimmten
       Umstnden auch lngere und somit RFC-widrige 'encoded words'
       (z.B. OpenXP/32 und bisher auch alle 16bit-Versionen von XP).

  MY:
  - Folgende unstrukturierte Header werden nicht nur in voller Lnge
    interpretiert, sondern auch in voller Lnge in den ZConnect-Puffer
    geschrieben:
      BET:             (RFC: "Subject:")
      ROT:             (RFC: "Path:" bei News bzw. bei Mail der aus den
                        einzelnen "Received:"-Headern herausoperierte
                        und zusammengesetzte Pfad)
      MAILER:          (RFC: verschiedene Header, z.B. "X-Mailer:" oder
                        "X-Newsreader:"
      ORG:             (RFC: "Organization:")
      Post:            (RFC: "X-Z-Post:", "X-ZC-Post:")
      Telefon:         (RFC: "X-Z-Telefon:", "X-ZC-Telefon:")
      U-X-Homepage:    (RFC: "X-Homepage:")
      Stichwort:       (RFC: "Keywords:")
      Zusammenfassung: (RFC: "Summary:")
      X-Gateway:       (RFC: "X-Gateway:")
    Bei den brigen ZConnect-Headern wie z.B. EDA: (Erstellungsdatum)
    stellt sich das Problem langer Header meist nicht, daher wurden sie
    hier nicht einbezogen. Eine Erweiterung dieser Liste ist evtl. noch
    geplant fr File: und X-XP-Boundary:, sowie fr Header, die Message-
    IDs enthalten (letztere sind momentan auf 160 Zeichen je Message-ID
    begrenzt, was in der Praxis ausreicht).

  MY:
  - RFC-Header, die mit dem Prefix "U-" oder "X-" im ZConnect-Header
    abgelegt werden (z.B. "U-Received:", "X-Orig-To:"), werden jetzt
    ebenfalls immer mit der vollen Lnge geschrieben. Die Anzahl ist
    nicht mehr wie bisher auf 60 Zeilen begrenzt, sondern nur noch durch
    den verfgbaren Speicher. Ein "Backdoor" fr diese Header existiert
    nicht, da weder notwendig noch sinnvoll.

  MY:
  - Da bei extrem vielen extrem langen Headern theoretisch der Speicher
    knapp werden knnte (100 Header mit je 6500 Zeichen z.B. passen
    nicht mehr in den verfgbaren unteren Speicher) und somit Header-
    verlust drohen wrde, existiert fr jeden der obigen Header, der mit
    voller Lnge geschrieben wird, fr den Fall von Speichermangel ein
    "Backdoor": Der Header wird dann wie bisher in der Lnge geschrie-
    ben, wie sie in der Variablendeklaration im Header-Record fr den
    jeweiligen Header definiert ist (max. 253 Zeichen inkl. Bezeichner).
    Bei Headern, die gekrzt werden muten, weil sie lnger als 65500
    Zeichen sind (oder die wegen Speichermangels ohnehin gekrzt werden
    muten), wird dies durch das Anhngen der Zeichenfolge "[...]"
    kenntlich gemacht.

  MY:
  - Fr alle Header, die in voller Lnge geschrieben werden, sowie fr
    die Adressen-Header wird der Speicher dynamisch und in genau der
    Menge angefordert und belegt, die jeweils bentigt wird (Ausnahme:
    fr die Absender wird immer die maximal definierte Lnge belegt).
    Dadurch wird es in der Realitt so gut wie nie passieren, da Header
    gekrzt werden mssen oder (im Falle von U/X-Headern) wegen
    Speichermangel verlorengehen.

  MY:
  - Fr alle Adressen-Header wird beim UUZ-Start ein Speicherminimum
    reserviert, durch das garantiert ist, da fr eine definierte
    Mindestanzahl von Adressen mit max. theoretisch mglicher Lnge
    immer ausreichend Speicher zur Verfgung steht:
      EMP:           20 Adressen/Newsgroups
      OEM:            1 Adresse
      KOP:           20 Adressen + 20 Realnames
      ABS:            5 Adressen +  5 Realnames
      WAB:            1 Adresse  +  1 Realname
      Antwort-an:     5 Adressen +  5 Realnames
      Diskussion-in: 20 Adressen/Newsgroups
    Steht dieses Speicherminimum (derzeit 26.480 Bytes) schon beim
    Programmstart nicht zur Verfgung, bricht der UUZ die Verarbeitung
    unmittelbar ab.

  MY:
  - Folgende Variablenwerte wurden gendert:
      AdrLen     (Lnge Adressen)             : 238 (bisher: 120)
      RealnLen   (Lnge Realnames)            : 160 (bisher: 120)
      MaxEmp     (max. Anzahl Empfnger)      : 125 (bisher:  50)
      MaxKop     (max. Anzahl Kopienempfnger): 125 (bisher:  60)
      MaxAbs     (max. Anzahl Absender)       :  50 (bisher:   1)
      MaxReplyTo (max. Anzahl Antwort-an)     :  50 (bisher:   1)
      MaxFollow  (max. Anzahl Followup-NGs)   :  50 (bisher:  10)
      Keywords   (Lnge Stichworte)           : 242 (bisher:  60)
      Summary    (Lnge Zusammenfassung)      : 236 (bisher: 200)
      BetreffLen (Lnge Betreff)              : 248 (bisher: 250)
    Die Werte fr Keywords, Summary und BetreffLen spielen bei ein-
    gehenden Nachrichten allerdings keine Rolle, da diese Header ohnehin
    in voller Lnge geschrieben werden (siehe oben).

  4.2. Ausgehende Nachrichten  (ZConnect => RFC)
  ----------------------------------------------

  MY:
  - Fix: Beim Schreiben von Headern, bei denen durch MIME-Codierung oder
    Quoting und die damit verbundene Verlngerung der Headerzeile die
    bisherige Lngenbeschrnkung von 254 Zeichen zwangslufig zu einem
    Zeichenverlust und/oder defekten Headern gefhrt hat, ist die aus
    der Codierung bzw. dem Quoten resultierende Lnge jetzt nicht mehr
    begrenzt (ein Betreff aus z.B. 200 "" erzeugt jetzt ber die neue
    Routine 'EncodeFoldQuote einen 806 Zeichen langen und korrekt
    codierten/gefalteten "Subject:"-Header).
    Damit ist jetzt gewhrleistet, da keine von XP erzeugten Header
    mehr gekrzt oder defekte MIME-Header produziert werden.

  MY:
  - Umfassende nderungen und Korrekturen bzgl. der Erstellung des
    Nachrichten-Body:
    1. Fix: Lange Zeilen mit mehr als 253 Zeichen in uncodierten Nach-
       richten werden jetzt nicht mehr willkrlich nach 253 Zeichen
       umbrochen, sondern bis 998 Zeichen in voller Lnge geschrieben
       (998 Zeichen ist die RFC-seitig und in der Praxis definierte
       Zeilenlnge, bis zu der ein sicherer Transport der Nachricht
       sichergestellt ist).
       Zeilen mit mehr als 998 Zeichen werden an Position 998 bzw. vor
       dem letzten davor befindlichen "white space" sinnvoll umbrochen
       ("sinnvoll" heit: Wenn das nchste Wort so lang ist, da es
       mangels Leerzeichen nicht vollstndig in die nchste Zeile pat
       und daher ohnehin auseinandergerissen werden mu, dann wird der
       Anfang dieses Worts noch an das Ende der aktuellen Zeile
       angehngt und an Position 998 umbrochen).
    2. Fix: Bei "quoted-printable"-codierten Nachrichten entsteht jetzt
       kein Zeichenverlust mehr, wenn die codierte Zeile lnger als 254
       Zeichen wird (bisher wurden Zeichen jenseits dieser Grenze durch
       die qp-Codierung und die damit verbundene Verlngerung der Zeile
       nach rechts ins Nirwana rausgeschoben und damit vernichtet).
    3. Fix: Wenn in SMTP-Mails eine uncodierte Zeile mit mehr als 998
       Zeichen umbrochen oder eine qp-codierte Zeile mit mehr als 76
       Zeichen nach einem "soft line break" in der nchsten Zeile fort-
       gesetzt wird, wird jetzt auch in diesen Fllen der erforderliche
       zustzliche Punkt "." am Zeilenanfang der folgenden Zeile hinzu-
       gefgt, wenn diese mit einem Punkt beginnt. Bisher geschah das
       nicht, der einzelne Punkt am Zeilenanfang wurde beim Empfnger
       RFC-konform entfernt und fehlte somit dann dort (bld z.B. bei
       URLs).
       Bei via NNTP versandten Postings gelten diesbezglich zwar
       dieselben Regeln wie bei SMTP-Mails, dort wird das Hinzufgen
       bzw. Entfernen von Punkten am Zeilenanfang aber vom Client
       bernommen. Deshalb fgt der UUZ dort zwar keinen Punkt hinzu,
       bercksichtigt das nachtrgliche Hinzufgen seitens des Clients
       aber insofern, als da er in den jeweiligen Fllen eine um ein
       Zeichen krzere Zeile erzeugt, damit keine unzulssig langen
       Zeilen (mit -qp max. 76 Zeichen, ohne -qp max. 998 Zeichen)
       entstehen knnen.
    4. Fix: Bei "quoted-printable"-codierten Nachrichten wird das Leer-
       zeichen hinter dem Signaturtrenner "--" jetzt gem RFC2045 als
       "=20" codiert und dadurch beim Empfnger nicht mehr vernichtet.
    5. Fix: Lo-ASCIIs in "quoted-printable"-codierten Nachrichten werden
       jetzt gem RFC2045 ebenfalls codiert.
    6. Wenn schon quoted-printable, dann richtig: Die EBCDIC-kritischen
       Zeichen !"#$@[\]^`{|}~ werden jetzt gem RFC2045 ebenfalls
       codiert.
    7. Fix: Auer bei Signaturtrennern werden die XP-typischen Leer-
       zeichen am Zeilenende (entstehen durch den internen XP-Editor und
       kennzeichnen dort einen "fortlaufend umbrochenen" Absatz) jetzt
       bei allen Nachrichten entfernt, weil sie schlicht berflssig
       sind und bei "quoted-printable"-codierten Nachrichten auerdem
       codiert werden mten (was bisher entgegen der qp-Definition in
       RFC2045 nicht der Fall war). Nebenbei wird damit auch vermieden,
       da beim Quoten von XP-Nachrichten zustzliche Leerzeichen
       entstehen knnen.


  5.   Beteiligte Entwickler und genderte Dateien
  ------------------------------------------------

  MY - Michael Heydekamp (Redesign/Rewrite des UUZ, Dokumentation)
  SV - Stefan Vinke      (Anlaufstelle fr programmiertechnische
                          Detailfragen whrend der Entwicklung)
  JM - Joachim Merkel    (Profiling / Performance-Optimierung)
  JG - Jochen Gehring    (Euro-Support, erweiterter Unicode-Support)

  Des weiteren wurden der EOL-Bugfix fr News-Batches von MK (Markus
  Kmmerer) aus OpenXP/32 sowie die Untersttzung des Parameters
  "-bBoxname" von MH (Max Huckenbeck) und des Headers "X-XP-Mode:" von
  RB (Robert Bck) aus XP2 bernommen.

  UUZ.PAS, UUZ0.PAS (neue Unit mit ausgelagerten Routinen wegen
  berschreitung der Codesegment-Grenzen in UUZ.PAS), MIMEDEC.PAS,
  XP0.PAS, XPMAKEHD.INC, XPOVL.PAS


  6.   Credits
  ------------

  Die oben beschriebenen Arbeiten am "Enhanced UUZ" htten ohne die
  wertvolle Hilfe folgender direkt oder indirekt Beteiligter nicht
  erfolgreich abgeschlossen werden knnen (Reihenfolge alphabetisch und
  ohne Anspruch auf Vollstndigkeit):

  Johann Addicks   - Tests, ZC/Gate-Konformitt
  Frank Ellermann  - RFC-Recherche und -Interpretation (Mail)
  Urs Janen       - RFC-Recherche und -Interpretation (News)
  Joachim Merkel   - RFC/ZC-Konformitt, Tests, Designfragen
  Dirk Nimmich     - RFC-Recherche und -Interpretation (Mail/News)
  Sebastian Weiser - RFC-Recherche und -Interpretation (Mail)

  FreeXP bedankt sich bei allen genannten und nicht genannten
  Beteiligten.
