FreeXP

CVS daily diff

FreeXP CVS-Server cvs-list at freexp.de
Sam Okt 29 00:00:21 CEST 2005


Index: freexp/file_id.diz
===================================================================
RCS file: /server/cvs/freexp/file_id.diz,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- freexp/file_id.diz	9 Jan 2004 16:19:02 -0000	1.8
+++ freexp/file_id.diz	28 Oct 2005 12:11:31 -0000	1.9
@@ -1,29 +1,17 @@
 ╔════════════════════════════════════╗
-║ FreeXP v3.40 RC3   (Komplettpaket) ║
+║ FreeXP v3.40 RC4   (Komplettpaket) ║
 ╟────────────────────────────────────╢
-║ Entwickler-Snapshot vom 31.08.2003 ║
+║ Release-Candidate 4 vom 31.10.2005 ║
 ╟────────────────────────────────────╢
-║ Erste "echte" FreeXP-Version mit   ║
-║ Freeware-Status ohne Registrie-    ║
-║ rungspflicht für alle Netztypen!   ║
-║                                    ║
-║ Unzählige Bugfixes, Korrekturen,   ║
-║ Erweiterungen und Anpassungen.     ║
-║ Stark verbesserte Unterstützung    ║
-║ von Windows NT/2000/XP, speziell   ║
-║ im Bereich der Erkennung von Fest- ║
-║ plattengrößen und freier Platten-  ║
-║ kapazität. Komplett überarbeitete  ║
-║ Node- und Pointlistenverwaltung,   ║
-║ u.a. neuer Nodelist-Browser und    ║
-║ fehlerfreie Verarbeitung der neuen ║
-║ Pointliste R24PNT im FD-Format.    ║
-║ Verbesserte Speicherverwaltung,    ║
-║ u.a. kann der Nachrichtenlister    ║
-║ jetzt Dateien bis 64 MB unter      ║
-║ Windows 95/98/Me anzeigen (bisher  ║
-║ nur 2 MB).                         ║
+║ Die erste "echte" FreeXP-Release   ║
+║ ist im kommen. Nach langem Warten  ║
+║ ist es jetzt so weit:              ║
+║ Der erste echte Release-Candidate  ║
+║ zur Version 3.40 ist da.           ║
+║ Nach dieser letzten Testversion    ║
+║ erfolgt zeitnah die Release noch   ║
+║ in diesem Jahr.                    ║
 ║ ---------------------------------- ║
-║ (c) 2003 by FreeXP   www.freexp.de ║
+║ (c) 2005 by FreeXP   www.freexp.de ║
 ╚════════════════════════════════════╝
 
Index: freexp/xpdefine.inc
===================================================================
RCS file: /server/cvs/freexp/xpdefine.inc,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- freexp/xpdefine.inc	1 Jan 2005 11:16:27 -0000	1.42
+++ freexp/xpdefine.inc	28 Oct 2005 12:06:43 -0000	1.43
@@ -9,7 +9,7 @@
 {                                                                 }
 { Compilerdirektiven für CrossPoint (FreeXP)                      }
 { --------------------------------------------------------------- }
-{ $Id: xpdefine.inc,v 1.42 2005/01/01 11:16:27 mw Exp $ }
+{ $Id: xpdefine.inc,v 1.43 2005/10/28 12:06:43 mw Exp $ }
 
 { Wenn gesetzt, werden erweiterte Checks in der EXE-Datei durchgeführt
   (Rangecheck) usw. }
@@ -22,7 +22,7 @@
   Unter Virtual Pascal werden Informationen über die Zeilennummern
   gespeichert, vergrößert die EXE-Datei etwas. }
 
-{$DEFINE DebugInfo }
+{.$DEFINE DebugInfo }
 
 { Wenn gesetzt, werden erweiterte Infos zu FIDO-Nodelisten ausgegeben
   u.a. $USERIDX.TXT im Verz. \FIDO }
@@ -34,12 +34,12 @@
 {.$DEFINE NOASM }
 
 { Ist definiert, wenn Beta-Informationen anzeigt werden sollen }
-{$DEFINE Beta }
+{.$DEFINE Beta }
 
 { Ist in Snapshot-Versionen definiert }
-{$DEFINE Snapshot}
+{.$DEFINE Snapshot}
 
-{ XP benötigt immer eine 386er CPU }
+{ FreeXP v3.40 benötigt immer eine 386er CPU }
 
 { Wenn dieser Schalter definiert ist, wird eine Version mit CAPI-
   Unterstüzung compiliert }
@@ -78,6 +78,9 @@
 {$ENDIF }
 {
   $Log: xpdefine.inc,v $
+  Revision 1.43  2005/10/28 12:06:43  mw
+  MW: - Preparation für den RC4
+
   Revision 1.42  2005/01/01 11:16:27  mw
   MW: - Willkommen im Jahr 2005
 
Index: freexp/xpglobal.pas
===================================================================
RCS file: /server/cvs/freexp/xpglobal.pas,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- freexp/xpglobal.pas	12 Sep 2005 07:43:23 -0000	1.42
+++ freexp/xpglobal.pas	28 Oct 2005 12:04:16 -0000	1.43
@@ -8,7 +8,7 @@
 { Die Nutzungsbedingungen fuer diesen Quelltext finden Sie in der }
 { Datei SLIZENZ.TXT oder auf www.crosspoint.de/oldlicense.html.   }
 { --------------------------------------------------------------- }
-{ $Id: xpglobal.pas,v 1.42 2005/09/12 07:43:23 mw Exp $ }
+{ $Id: xpglobal.pas,v 1.43 2005/10/28 12:04:16 mw Exp $ }
 
 { Globale Konstanten/Variablen (FreeXP) und Tools }
 
@@ -21,7 +21,7 @@
 
 const
   verstr      = 'v3.40';     { Versionsnr. - steht nur an dieser Stelle }
-  betastr     = ' RC3';      { '' oder ' beta', ' RCn' usw. }
+  betastr     = ' RC4 (Halloween)';      { '' oder ' beta', ' RCn' usw. }
 
 { Die folgenden drei Konstanten müssen Sie ergänzen, bevor Sie      }
 { CrossPoint compilieren können. Falls Die das compilierte Programm }
@@ -123,6 +123,9 @@
 
 {
   $Log: xpglobal.pas,v $
+  Revision 1.43  2005/10/28 12:04:16  mw
+  MW: - Die Halloween-Edition wird RC4 heißen.
+
   Revision 1.42  2005/09/12 07:43:23  mw
   MW: - Vervollständigung der Variablenumsetzungstabelle (Umdefinieren
         zu größensicheren Variablentypen).
Index: freexp/binaries/UUZ.EXE
===================================================================
RCS file: /server/cvs/freexp/binaries/UUZ.EXE,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
Binary files /tmp/cvsEyH9WX and /tmp/cvswx6qcw differ
Index: freexp/doc/snapshot.dq
===================================================================
RCS file: /server/cvs/freexp/doc/snapshot.dq,v
retrieving revision 1.50
retrieving revision 1.51
diff -u -r1.50 -r1.51
--- freexp/doc/snapshot.dq	21 Oct 2005 15:31:29 -0000	1.50
+++ freexp/doc/snapshot.dq	28 Oct 2005 11:58:46 -0000	1.51
@@ -28,7 +28,7 @@
 
 ╔═ SNAPSHOT.TXT ════════════════════════════════════════╗
 ║                                                       ║
-║  An die Benutzer dieses FreeXP-Snapshots (v3.40 RC3)  ║
+║  An die Benutzer dieser FreeXP-Version (v3.40 RC4)    ║
 ║                                                       ║
 ╚═══════════════════════════════════════════════════════╝
 
@@ -66,7 +66,7 @@
 L.   Inoffizelle Extented-Command-Edition vom 06.07.2005, 18:00 Uhr
 M.   Inoffizelle Bezugsverkettungs-Edition vom 21.08.2005, 13:00 Uhr
 N.   2. Inoffizelle Bezugsverkettungs-Edition vom 27.09.2005, 14:00 Uhr
-O.   Snapshot vom xx.xx.2005, xx:xx Uhr
+O.   Release Candidate 4 vom 31.10.2005, xx:xx Uhr (Halloween)
 ###
 
 1. FreeXP - Support und Kontakte
@@ -136,14 +136,10 @@
 Wem z.B. der Umgang mit einer Usenet-Newsgroup eher zusagt als der  mit einer Mailingliste,
 kann stattdessen auch die Newsgroup  abonnieren. Jedes Posting, das in die Newsgroup
 abgesetzt wird, wird an die entsprechende Liste weitergeleitet und umgekehrt. Dasselbe
-gilt sinngemäß für die Fido-Area und das Webforum.
+gilt sinngemäß auch für die Fido-Area.
 
-Das Webforum zu FreeXP (PHPBB2) bietet dieselben Inhalte an. Sie finden es unter der URL:
 
-     o   http://www.freexp.de/forum/
-
-Es steht Ihnen also völlig frei, ob Sie lieber Webforum, Newsgroup oder Mailingliste
-nutzen wollen.
+Es steht Ihnen also völlig frei, ob Sie lieber Newsgroup oder Mailingliste nutzen wollen.
 
 --2 ■ Die Zugangswege sind gleichwertig ausgelegt, da alle Beiträge in allen Foren
 *identisch* gehalten werden.
@@ -4830,10 +4826,10 @@
 
 %
 %
-%Snapshot vom xx.xx.2005, xx:xx Uhr
-%----------------------------------
-O.   Snapshot vom xx.xx.2005, xx:xx Uhr
----------------------------------------
+%Release Candidate 4 vom 31.10.2005, xx:xx Uhr (Halloween)
+%---------------------------------------------------------
+O.   Release Candidate 4 vom 31.10.2005, xx:xx Uhr (Halloween)
+--------------------------------------------------------------
 ■  21.10.2005
 -------------
 HJT:
@@ -4843,4 +4839,16 @@
   am UUZ nicht mehr aus, wenn WAB (Sender) und ABS (From)
   nicht übereinstimmen.
 
+■  28.10.2005
+-------------
+MW+MY:
+%*  Ersetzen des E-UUZ vom 30.08.2003 durch die Testversion
+%   vom 7.08.2004.
+- E-UUZ ersetzt um die Kompatibilität im Netz zu verbessern.
 
+■  24.10.-31.10.2005
+--------------------
+MW:
+%*  Dokumentation überarbeitet
+- Dokumentation überarbeitet um die vorliegende Version
+  von FreeXP in einen releasefähigigen Zustand zu bringen. 
Index: freexp/doc/uuz_enh.txt
===================================================================
RCS file: /server/cvs/freexp/doc/uuz_enh.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- freexp/doc/uuz_enh.txt	30 Aug 2003 21:58:30 -0000	1.1
+++ freexp/doc/uuz_enh.txt	28 Oct 2005 11:41:10 -0000	1.2
@@ -2,8 +2,8 @@
 ║                                                            ║
 ║  Vollständige Dokumentation aller Änderungen               ║
 ║  des "Enhanced UUZ" seit dem 28.04.2002                    ║
-║  (c) 2003 FreeXP                                           ║
-║                                                30.08.2003  ║
+║  (c) 2003-2004 FreeXP                                      ║
+║                                                07.08.2004  ║
 ╚════════════════════════════════════════════════════════════╝
 
 +-------------------------+
@@ -1052,6 +1052,1719 @@
        daß beim Quoten von XP-Nachrichten zusätzliche Leerzeichen
        entstehen können.
 
++-------------------------+
+|  26.09.2003-07.08.2004  |
++-------------------------+
+
+MY:
+- Erneut umfassende Umbauten, Änderungen, Fixes und Erweiterungen,
+  speziell in den Bereichen Zeichensatzunterstützung und Decodierung
+  (base64, quoted-printable, UTF-7/8) von Nachrichtentexten und
+  teilweise Headern sowie der Auswertung und Deklaration von
+  MIME-Nachrichten ("Enhanced UUZ" => "Enhanced UUZ/II")
+====================================================================
+
+MY:
+- Neue Zeichensätze implementiert:
+  ----------------------------------------------------------------------
+  Da FreeXP bzw. der Enhanced UUZ seit Erscheinen der letzten Version
+  nur noch explizit unterstützte Zeichensätze konvertiert (statt wie
+  früher *alle* ISO-Zeichensätze blind auf Basis der mitunter unzutref-
+  fenden Tabelle für ISO-8859-1 "kaputtzukonvertieren"), wurden zu den
+  bisherigen neun die folgenden zehn zusätzlichen Zeichensätze imple-
+  mentiert:
+   1. ISO-8859-3   (alias "Latin 3",     Süd-Europa/Türkei)
+   2. ISO-8859-4   (alias "Latin 4",     Nord-Europa/Baltikum)
+   3. ISO-8859-10  (alias "Latin 6",     Nord-Europa)
+   4. ISO-8859-13  (alias "Latin 7",     Nord-Europa/Baltikum)
+   5. ISO-8859-14  (alias "Latin 8",     West-Europa/Gälisch)
+   6. ISO-8859-16  (alias "Latin 10",    Ost-Europa, mit Euro)
+   7. Windows-1250 (alias "Win Latin 2", Ost-Europa, mit Euro)
+   8. Windows-1254 (alias "Win Turkish", Türkei, mit Euro)
+   9. Windows-1257 (alias "Win Baltic",  Nord-Europa/Baltikum, mit Euro)
+  10. Mac OS Roman (alias "MacRoman",    West/Nord-Europa, mit Euro)
+  Diese Zeichensätze kommen in Mails und auch in den de.* Newsgruppen
+  tatsächlich vor (vermutlich nicht selten infolge einer fehlerhaften
+  Konfiguration). Es werden wie schon bei den bisherigen alle bei der
+  IANA registrierten Aliasnamen dieser neu implementierten Zeichensätze
+  unterstützt.
+  Damit unterstützt FreeXP jetzt *alle* Latin-Zeichensätze der ISO-8859-
+  Reihe (einschließlich der erst jüngst zugelassenen wie ISO-8859-16),
+  alle vier in den USA und Europa gängigen Win-Latin-Codepages, die
+  Macintosh-Codepage (ab Mac OS 8.5 mit Euro-Symbol), die DOS-Codepages
+  850 und 858 sowie die Unicode-Codierungen UTF-7/8.
+  Immerhin 10 dieser nunmehr insgesamt 19 unterstützten Zeichensätze
+  bzw. Codierungen enthalten das Euro-Symbol.
+  MIMEDEC.PAS
+
+MY:
+- Detailkorrekturen bei der Konvertierung einzelner Zeichen:
+  ----------------------------------------------------------------------
+  1. CP437 => ISO-8859-1:
+     Das Steuerzeichen #7 (BEL, optisch identisch mit einem "Bullet")
+     wird jetzt in ein "*" konvertiert (bisher: "Middle Dot" #183).
+  2. ISO-8859-2 => CP437:
+     Zeichen #208 wird jetzt nach "D" konvertiert (bisher: "T"). Es
+     handelt sich hier nicht wie in ISO-8859-1 um das an derselben
+     Position befindliche und identisch aussehende Zeichen "Latin
+     Capital Letter Eth" (Unicode U+00D0), sondern um das Zeichen "Latin
+     Capital Letter D with Stroke" (Unicode U+0110).
+  3. ISO-8859-9 => CP437:
+     a) Zeichen #208 wird jetzt nach "G" konvertiert (bisher: "T").
+     b) Zeichen #221 wird jetzt nach "I" konvertiert (bisher: "Y").
+     c) Zeichen #254 wird jetzt nach "s" konvertiert (bisher: "t").
+  4. Windows-1252/1250/1254/1257 => CP437:
+     a) Nicht definierte Zeichen werden jetzt in ein Leerzeichen
+        konvertiert (statt in das Zeichen #177, das als Platzhalter
+        für unkonvertierbare Zeichen verwendet wird).
+     b) Zeichen #130 ("single low-9 quotation mark") wird jetzt in einen
+        Apostroph #39 konvertiert (bisher: Komma #44).
+     c) Das Zeichen #149 ("Bullet") wird jetzt in das Zeichen "*" #42
+        konvertiert (bisher: "Black Square" #254).
+  5. Mac OS Roman => CP437:
+     Tabelle komplett überarbeitet und an die schon seit der letzten
+     Version umfassend geänderten Konvertierregeln der ISO- und Win-
+     Zeichensätze angeglichen. (Anmerkung: Eine Konvertiertabelle für
+     Mac OS Roman war schon immer in XP enthalten, wurde aber bisher nur
+     bei Fido-Nachrichten verwendet).
+  6. UTF-7/8 => CP437 (Sonderfall):
+     Das Unicode-Zeichen U+03B5 (kleines griechiches Epsilon, identisch
+     mit dem Zeichen #238 "ε" in CP437) wird *nicht* in das eigentlich
+     richtige Zeichen "ε" konvertiert, sondern in ein "e". Da das
+     Zeichen "ε" zukünftig für das Euro-Symbol reserviert ist, würde
+     FreeXP sonst bei UTF-7/8-codierten Nachrichten, die das Zeichen "ε"
+     enthalten, dieses nicht von einem Euro-Symbol unterscheiden können
+     und daher beide miteinander verwechseln. Diese Vorsichtsmaßnahme
+     ist allerdings eher theoretischer Natur, denn im wirklichen Leben
+     wird das Zeichen "ε" - im Unterschied zum Euro-Symbol - so gut wie
+     nie verwendet.
+  7. Bei allen Zeichensätzen, die das Zeichen "Macron" enthalten (ein
+     hochstehender waagerechter Strich, der ähnlich wie die Umlautpunkte
+     oberhalb von Zeichen stehen kann und eigentlich nicht einzeln vor-
+     kommt), wird dieses jetzt in einen Bindestrich #45 konvertiert
+     (bisher: Rahmengrafikzeichen #196).
+  MIMEDEC.PAS
+
+MY:
+- Unterstützung von Zeichensatz-Aliasnamen erweitert:
+  ----------------------------------------------------------------------
+  Zusätzlich zu den offiziell bei der IANA registrierten (und somit für
+  MIME-Nachrichten einzig zulässigen) Zeichensatz-Aliasnamen werden
+  jetzt auch die Aliasnamen aus der primär auf Linux-Systemen verwende-
+  ten Library "GNU libc iconv" unterstützt. Es tauchten immer wieder
+  Postings in Newsgruppen sowie Mails auf, die den Zeichensatz mit
+  einem dieser eigentlich nicht zulässigen Aliasnamen wie "iso8859-1"
+  (richtig wäre z.B. "iso-8859-1") deklarierten; diese Nachrichten
+  wurden dann nicht konvertiert, was jetzt trotz fehlerhafter Deklara-
+  tion der Fall ist.
+  MIMEDEC.PAS
+
+MY:
+- UTF-7/8-Konvertierung nochmals erweitert:
+  ----------------------------------------------------------------------
+  Alle 165 Zeichen, die außerhalb von ISO-8859-1 in einem der übrigen
+  von FreeXP unterstützten ISO-, Win-, Mac- oder DOS-Latin-Zeichensätze,
+  nicht aber in CP437 enthalten sind (z.B. typographische Anführungs-
+  zeichen, große und kleine Zeichen mit "Macron", "Ogonek" usw.), wurden
+  bisher nur dann konvertiert bzw. transliteriert, wenn die Nachricht
+  auch in einem dieser Zeichensätze vorlag und deklariert war. Kamen
+  dieselben Zeichen jedoch in einer UTF-7/8-codierten Nachricht vor,
+  wurden sie inkonsequenterweise durch das Zeichen #177 als unkonver-
+  tierbar repräsentiert. Jetzt umfaßt die UTF-7/8-Decodierung exakt
+  denselben Zeichenvorrat wie die Summe aller von FreeXP unterstützten
+  Latin-Zeichensätze.
+  MIMEDEC.PAS
+
+MY:
+- Header-Variablen 'charset' (= Inhalt des ZC-Headers CHARSET:) und
+  'ccharset' von bisher 7 Zeichen auf jetzt 30 Zeichen vergrößert, um
+  zukünftig auch beliebige und nicht ZC-konforme Charset-Bezeichner
+  in zu-Richtung unterstützen und auswerten zu können.
+  UUZ0.PAS
+
+MY:
+- Bei defekten ausgehenden Newspuffern ohne oder mit leerem EMP:-Header
+  (i.d.R. verursacht durch einen fehlerhaften Eingabepuffer) wird jetzt
+  keine zweckfreie (eben weil defekte) Ausgangsdatei *.OUT mehr erzeugt.
+  UUZ.PAS
+
+MY:
+- Fix (-zu): Bei einem fehlerhaften Eingabepuffer wird eine zwischen-
+  zeitlich bereits angelegte Temporärdatei 'UUZ.TMP' nach der Erkennung
+  des Fehlers jetzt gelöscht.
+  UUZ.PAS
+
+MY:
+- Interne Änderung: Das Setzen der MIME-Information bei ausgehenden
+  Nachrichten über 'SetMimeData' erfolgt bei Mails jetzt nicht mehr
+  doppelt. Dies verbessert geringfügig die Performance, war aber vor
+  allem wegen der verbesserten Zeichensatzbehandlung im Externbetrieb
+  und der Behandlung des Headers "U-Content-Type:" (siehe weiter unten)
+  schlicht notwendig.
+  UUZ.PAS, UUZ0.PAS
+
+MY:
+- Umfassende Fixes, Änderungen und Erweiterungen bei der ZC=>RFC-Konver-
+  tierung von Nachrichten, die einen oder mehrere der Header "CHARSET:",
+  "X-Charset:" und/oder "U-Content-Type:" enthalten:
+  ----------------------------------------------------------------------
+  1. Fix: Bei der Konvertierung von Nachrichten, die einen Header
+     "U-Content-Type:", jedoch keinen Header CHARSET: oder X-Charset:
+     enthielten, wurde bei gleichzeitiger Nichtverwendung des Schalters
+     "-chkbody" (der sich von XP aus nicht setzen läßt) die Nachricht
+     zwar IBM=>ISO-konvertiert, aber statt des korrekten Zeichensatzes
+     ISO-8859-1/15 der Zeichensatz deklariert, der sich im Header
+     "U-Content-Type:" befand (das konnte z.B. auch "UTF-8" sein). Dies
+     führte nicht selten zu einer fehlerhaften Deklaration, denn dabei
+     handelte es sich zwar um den Zeichensatz, in dem sich die originale
+     RFC-Nachricht vor der Konvertierung in den IBM-Zeichensatz befunden
+     hatte, nicht aber zwingend um den Zeichensatz, in den sie danach
+     beim Versand wieder rekonvertiert wurde (nämlich ISO-8859-1/15).
+     Bei Nachrichten, die sich im Originalzustand ohnehin bereits im
+     Zeichensatz ISO-8859-1/15 befunden hatten, wirkte sich dieser
+     Fehler nicht aus. Darüber hinaus waren FreeXP-User von dem Problem
+     ohnehin nicht betroffen, weil von FreeXP erzeugte Nachrichten immer
+     einen Header CHARSET: oder X-Charset: enthalten, der dem UUZ mit-
+     teilt, in welchem Zeichensatz sich die Nachricht bereits befindet
+     und daher nicht konvertiert werden darf (CHARSET:) bzw. in welchen
+     Zeichensatz sie konvertiert werden soll, mit dem sie dann auch zu
+     deklarieren ist (X-Charset:).
+     Das Problem konnte also nur im Externbetrieb bei gate-typischen
+     Szenarien entstehen, bei denen eine RFC=>ZC-Konvertierung und
+     unmittelbar anschließend eine ZC=>RFC-Konvertierung durchgeführt
+     wurde. Bei Verwendung des in diesen Fällen ohnehin zu empfehlenden
+     Parameters "-chkbody" wurde der Fehler schon bisher vermieden.
+     Der "charset"-Parameter im Header "U-Content-Type:" wird jetzt in
+     allen Fällen ignoriert. Ist weder der Header X-Charset: noch der
+     Header CHARSET: enthalten, setzt der UUZ mangels Charset-Angabe
+     jetzt intern den Schalter "-chkbody", prüft somit den Nachrichten-
+     text auf das Vorkommen von 8bit-Zeichen und erzeugt eine korrekt
+     konvertierte und deklarierte Nachricht (wobei er per Definition wie
+     bisher davon ausgeht, daß die Nachricht im IBM-Zeichensatz vorliegt
+     und nach ISO-8859-1/15 zu konvertieren ist). Die Deklaration der
+     Transportcodierung im neu erzeugten RFC-Header "Content-Transfer-
+     Encoding:" (7/8bit) richtet sich dabei wie bisher nach dem ermit-
+     telten Zeichensatz.
+  2. ZC-Nachrichten, die einen Header CHARSET: enthalten (mit XP kann so
+     eine Konstellation in einer ZConnect-Box erzeugt werden, indem der
+     Schalter "ZConnect: ISO-Zeichensatz" unter C/O/E/V aktiviert wird),
+     fand auch bisher schon keine Zeichensatzkonvertierung statt, wenn
+     der Header eine ZC-konforme Zeichensatzbezeichnung ("ISO1" bis
+     "ISO9") enthielt - das ist beabsichtigt und korrekt und wird daher
+     auch so bleiben.
+     Da inzwischen aber unkonvertierte ZConnect-Puffer aufgetaucht sind
+     (offenbar von Gates erzeugt oder aus OpenXP exportiert), die nicht
+     im IBM-Zeichensatz vorliegen und deren im Header CHARSET: dekla-
+     rierter Zeichensatz sowohl hinsichtlich des verwendeten Zeichen-
+     satzes selbst ("UTF-8") als auch hinsichtlich der Bezeichnung
+     ("ISO-8859-15") nicht mehr den ZConnect-Spezifikationen entspre-
+     chen, wurde dieses Verhalten für alle vom Enhanced UUZ unterstütz-
+     ten und nicht unterstützten Zeichensätze erweitert, ohne dabei die
+     Kompatibilität mit anderen XP-Versionen aufzugeben:
+     a) Existiert ein Header CHARSET:, wird die Nachricht ungeachtet
+        der verwendeten Zeichensatzbezeichnung nicht konvertiert - mit
+        einer Ausnahme: Wenn ein im Sinne von XP lokaler Zeichensatz
+        enthalten ist (also US-ASCII oder IBM437), wird die Nachricht
+        trotzdem in den entsprechenden ISO-Zeichensatz konvertiert.
+     b) Bei allen vom Enhanced UUZ eingehend unterstützten Latin-
+        Zeichensätzen (inkl. UTF-7/8) sowie bei den nicht unterstützten
+        Non-Latin-Zeichensätzen der ISO-8859-Reihe (ISO-8859-5 bis -8
+        und -11) wird dabei jeder IANA-registrierte oder in der weiter
+        oben erwähnten iconv-Library enthaltene Aliasname in den
+        jeweiligen "preferred MIME name" übersetzt ("IBM819" wird zu
+        "ISO-8859-1", "csIsoLatinArabic" zu "ISO-8859-6"). Bei der
+        Erkennung lokaler Charsets (siehe Punkt 2. a)) werden ebenfalls
+        alle Aliasnamen (wie z.B. "cspc8codepage437") unterstützt und
+        ausgewertet.
+     c) Gehört der deklarierte Zeichensatz weder zu einem der vom UUZ
+        unterstützten noch zu einem der fünf nicht unterstützten Non-
+        Latin-Zeichensätze aus der ISO-8859-Reihe und ist daher gänzlich
+        unbekannt, wird die Zeichensatzbezeichnung aus dem CHARSET:-
+        Header 1:1 übernommen.
+     d) Eine automatische Überprüfung des Nachrichtentextes findet bei
+        Existenz des CHARSET:-Headers wie bisher nicht statt. Diese läßt
+        sich aber nach wie vor im Externbetrieb mit der Kommandozeilen-
+        option "-chkbody" erzwingen; dabei würde dann ein evtl. 8bit-
+        Zeichensatz nach "US-ASCII" korrigiert werden, wenn die Nach-
+        richt nur 7bit-Zeichen enthält.
+     e) Eine angeblich im Zeichensatz "UTF-7" vorliegende Nachricht wird
+        per Definition immer mit "7bit" deklariert - selbst dann, wenn
+        der Schalter "-chkbody" verwendet und die Nachricht 8bit-Zeichen
+        enthalten sollte. Der Enhanced UUZ kann dann nicht entscheiden,
+        welches der tatsächliche Zeichensatz ist und hält sich daher
+        strikt an die Angabe im CHARSET:-Header, obwohl damit eine ein-
+        deutig fehlerhaft deklarierte Nachricht erzeugt wird (weil schon
+        der Eingabepuffer eindeutig fehlerhaft ist). Man kann halt nicht
+        alles reparieren, eine halbwegs seriöse Heuristik für diesen
+        Fall existiert nicht, und auch die sonst recht treffsichere
+        Glaskugel des Enhanced UUZ hat ihre Grenzen.
+  3. Nachrichten mit dem Header X-Charset: (zulässig sind hier nur die
+     Zeichensätze US-ASCII, ISO-8859-1 und ISO-8859-15, aber jetzt auch
+     mitsamt aller ihrer registrierten und unregistrierten Aliasnamen)
+     liegen per Definition im IBM-Zeichensatz vor und werden daher wie
+     bisher in den angegebenen ISO-Zeichensatz konvertiert und mit
+     diesem Zeichensatz deklariert.
+     a) Mit dem Schalter "-chkbody" läßt sich extern nach wie vor eine
+        Überprüfung des Body erzwingen und so ggf. eine Korrektur eines
+        fehlerhaft deklarierten Zeichensatzes herbeiführen (z.B. bei
+        Nachrichten, die fälschlicherweise als US-ASCII deklariert sind,
+        aber wie im Falle des Paragraphenzeichens "" nach der ISO-Kon-
+        vertierung 8bit-Zeichen enthalten - siehe auch den Abschnitt
+        weiter unten zur Kompatibilität des Enhanced UUZ mit XP2).
+     b) Sollte der Header X-Charset: einen "unerwünschten" lokalen
+        Zeichensatz (z.B. IBM437, kann im Betrieb mit FreeXP nicht
+        vorkommen) enthalten, wird er ignoriert, intern der Schalter
+        "-chkbody" gesetzt und so eine korrekt konvertierte und dekla-
+        rierte Nachricht im entsprechenden ISO-Zeichensatz erzeugt.
+  4. Im rein theoretischen Fall, daß sowohl ein Header CHARSET: als auch
+     ein Header X-Charset: existieren, besitzt der Header CHARSET:
+     Priorität.
+  Alle beschriebenen Änderungen gelten ausschließlich für die Behandlung
+  des Nachrichtentextes (Header liegen per Definition immer im IBM-Zei-
+  chensatz vor und sind daher immer zu konvertieren).
+  MIMEDEC.PAS, UUZ.PAS, UUZ0.PAS, XPMAKEHD.INC
+
+MY:
+- Konvertierung von Nachrichten mit nicht unterstützten Zeichensätzen
+  verbessert (-uz):
+  ----------------------------------------------------------------------
+  Bei Nachrichten in einem von FreeXP eingehend nicht unterstützten
+  Zeichensatz wird dieser jetzt in den ZConnect-Header CHARSET:
+  geschrieben (und die Nachricht wie bisher *nicht* konvertiert). Dabei
+  wird, soweit möglich und vorhanden, der Name des Zeichensatzes in die
+  ZConnect-spezifische Bezeichnung ("ISO1" bis "ISO9") oder alternativ
+  in den "preferred MIME name" gemäß IANA umgewandelt. Ist beides nicht
+  möglich, wird der Name des Zeichensatzes, wie er im Header "Content-
+  Type:" deklariert ist, unverändert übernommen.
+  Dieses Vorgehen hat in Verbindung mit den oben beschriebenen Änderun-
+  gen, durch die es überhaupt erst ermöglicht und sinnvoll wird, den
+  Vorteil, daß bei einer unmittelbar anschließenden Konvertierung in
+  zu-Richtung a) der korrekte Zeichensatz deklariert und b) die Nach-
+  richt 1:1 und ohne Zeichenverlust weiterversandt werden kann.
+  Es ist weniger für XP-User, sondern eher für Anwender interessant und
+  von Bedeutung, die den Enhanced UUZ im Gate- oder Externbetrieb ein-
+  setzen und ist für diesen Fall deshalb gerechtfertigt und notwendig,
+  weil ansonsten keine Möglichkeit bestünde, Nachrichten mit nicht
+  unterstützten Zeichensätzen unmittelbar hintereinander in beide
+  Richtungen korrekt zu konvertieren und weiterzuversenden.
+  Die neue Verfahrensweise unterscheidet sich zu der von OpenXP insbe-
+  sondere dadurch, daß *unterstützte* Zeichensätze nach wie vor nach
+  CP437 konvertiert werden. Daher ist sie auch mit früheren XP-Versionen
+  (die genau wie alle aktuellen XP-Versionen Nachrichten in nicht unter-
+  stützten Zeichensätzen weder konvertiert noch unkonvertiert lesbar
+  darstellen können) 100%ig kompatibel, während OpenXP sich offenbar
+  dazu entschlossen hat, diese Kompatibilität aufzugeben und den Zei-
+  chensatz von RFC-Nachrichten überhaupt nicht mehr zu konvertieren,
+  wodurch die von OpenXP erzeugten ZConnect-Puffer für andere XP-
+  Versionen, sofern sie 8bit-Zeichen enthalten, mitunter unbrauchbar
+  sind (FreeXP wird jedoch in einer der nächsten Versionen - möglicher-
+  weise sogar in der nächsten - ebenfalls solche unkonvertierten Single-
+  part-Nachrichten mit beliebigen unterstützten Zeichensätzen im
+  CHARSET:-Header korrekt darstellen können).
+  UUZ0.PAS
+
+MY:
+- Fix für einen relativ kapitalen Bug bei der ZC=>RFC-Konvertierung, der
+  erstaunlicherweise bisher entweder nicht aufgetreten oder nicht
+  aufgefallen ist:
+  Wenn die Nachricht zwar einen CHARSET:-Header, jedoch *keine* Header
+  "U-Content-Type:" und "U-Content-Transfer-Encoding:" enthielt (absolut
+  realistisches Szenario, das in einer ZConnect-Box auftreten kann, wenn
+  der Schalter "ZConnect: ISO-Zeichensatz" unter C/O/E/V gesetzt ist),
+  dann wurde die Nachricht nicht konvertiert (was korrekt ist), aber es
+  wurden auch nicht die zwingend erforderlichen Header "Content-Type:"
+  und "Content-Transfer-Encoding:" neu erzeugt. Bisher wurde nur auf den
+  Header X-Charset: geprüft und nicht berücksichtigt, daß auch Nachrich-
+  ten, die wegen des CHARSET:-Headers nicht konvertiert werden dürfen,
+  diese Header trotzdem benötigen.
+  Bei in einer RFC-Box erstellten Nachrichten oder bei Verwendung des
+  Parameters "-chkbody" trat der Bug nicht zutage.
+  UUZ0.PAS
+
+MY:
+- Fix: Wenn ein Header Zeichen enthielt, die durch die IBM=>ISO-Konver-
+  tierung von einem 8bit- in ein 7bit-Zeichen transliteriert wurden
+  (z.B. Gamma "Γ" => "G") und gleichzeitig keine weiteren 8bit-Zeichen
+  enthielt, aufgrund derer der Header hätte MIME-codiert werden müssen,
+  dann hat der Enhanced UUZ zwar korrekt erkannt, daß keine Codierung
+  erforderlich ist, hat dann aber nicht den nach ISO-8859-x konvertier-
+  ten 7bit-String in den Header geschrieben, sondern den unkonvertierten
+  8bit-String im IBM-Zeichensatz. :-(
+  In dieser seltenen Konstellation konnten also theoretisch uncodierte
+  8bit-Zeichen in Header gelangen. Der Fall konnte nur bei Rahmengrafik-
+  und einigen griechischen Zeichen aus CP437 eintreten, die in der
+  Praxis so gut wie nie in Headern verwendet werden - vermutlich deshalb
+  ist der Bug auch nie aufgetreten und gemeldet worden.
+  UUZ.PAS
+
+MY:
+- Charset-Fallback implementiert (-uz):
+  ----------------------------------------------------------------------
+  Es kommt nicht selten vor, daß Nachrichten im Zeichensatz ISO-8859-x
+  deklariert sind, in Wirklichkeit aber im Zeichensatz Windows-125x
+  vorliegen (typischer Fehler von OjE). Bei den meisten Zeichen ist das
+  kein Problem (speziell nicht im Fall ISO-8859-1 und Windows-1252, weil
+  diese Zeichensätze im Bereich 0xA0 bis 0xFF identisch sind), aber wenn
+  die Nachricht Zeichen aus dem Bereich 0x80 bis 0x9F enthielt, wurden
+  diese bisher nicht korrekt (bzw. gar nicht) konvertiert, weil dieser
+  Bereich bei allen ISO-Zeichensätzen für Steuerzeichen reserviert ist.
+  Bei Windows-Zeichensätzen hingegen liegen dort z.B. typographische
+  Anführungszeichen, verlängerte Bindestriche, das Euro-Symbol usw.,
+  also durchaus Zeichen, die auch oft Verwendung finden und konvertier-
+  bar sind.
+  Der Enhanced UUZ prüft jetzt bei allen Nachrichten, die mit einem der
+  unterstützten ISO-Zeichensätze deklariert sind, ob sie Zeichen aus dem
+  Bereich 0x80 bis 0x9F enthalten. Ist das der Fall, schließt der UUZ
+  daraus, daß die Deklaration "ISO-8859-x" offenbar falsch ist und nimmt
+  ein "Fallback" auf den verwandtesten Windows-Zeichensatz vor (das ist
+  der, der in der Region, wo der ursprünglich deklarierte ISO-Charset am
+  ehesten verwendet wird, Standard ist). Dabei gilt folgende Zuordnung:
+    ISO-8859-1  => Windows-1252  (West-Europa)
+    ISO-8859-2  => Windows-1250  (Ost-Europa)
+    ISO-8859-3  => Windows-1254  (Süd-Europa/Türkei)
+    ISO-8859-4  => Windows-1257  (Nord-Europa/Baltikum)
+    ISO-8859-9  => Windows-1254  (Türkei)
+    ISO-8859-10 => Windows-1257  (Nord-Europa)
+    ISO-8859-13 => Windows-1257  (Nord-Europa/Baltikum)
+    ISO-8859-14 => Windows-1252  (West-Europa/Gälisch)
+    ISO-8859-15 => Windows-1252  (West-Europa)
+    ISO-8859-16 => Windows-1250  (Ost-Europa)
+  Da die Zeichensätze ISO-8859-1 und Windows-1252 sowie ISO-8859-9 und
+  Windows-1254 im Bereich 0xA0 bis 0xFF jeweils identisch sind, wurden
+  sie jeweils zu einer einzigen Tabelle zusammengefaßt (da passiert das
+  Fallback also quasi automatisch).
+  Sofern der UUZ ein Charset-Fallback für den Nachrichtentext vorgenom-
+  men hat, vermerkt er das im Header "X-Fallback-Charset:", läßt aber
+  die originale Charset-Deklaration im Header "U-Content-Type:" unange-
+  tastet.
+  Außer im Nachrichtentext funktioniert das Fallback auch in MIME-
+  codierten Headern beliebiger Länge (bis 65500 Zeichen). Allerdings
+  wird dann *kein* gesonderter Header "X-Fallback-Charset:" erzeugt,
+  weil in Headern mehrere Zeichensätze gleichzeitig vorkommen können und
+  man nicht für jedes einzelne encoded word einen eigenen Header erzeu-
+  gen kann, bei dem zudem die Zuordnung zum jeweiligen encoded word
+  nicht eindeutig wäre.
+  UUZ0.PAS, MIMEDEC.PAS
+
+MY:
+- Decodierungsroutinen für Header und Body (UTF-8, UTF-7, base64,
+  quoted-printable) anläßlich eines Bugreports komplett renoviert,
+  gefixt, erweitert und robuster gestaltet.
+  Während der für das Beheben des gemeldeten Bugs notwendigen Tests
+  stellten sich so viele weitere - bisher unbemerkte - Fehler heraus,
+  daß umfassende und grundlegende Änderungen erforderlich waren. Die
+  bisherigen Routinen für die Decodierung/Konvertierung speziell des
+  Nachrichtentextes (Body) waren auf eine Multibyte-Decodierung teil-
+  weise gar nicht oder unzureichend ausgelegt und gingen des weiteren
+  davon aus, daß codierte Zeilen nie länger sein können als es in den
+  einschlägigen RFCs vorgesehen ist bzw. als es die Längenbeschränkung
+  von Pascal zuläßt - was aber nicht immer der Praxis entspricht (bei
+  Headern bestand der größte Teil der Probleme seit Erscheinen der
+  ersten Fassung des Enhanced UUZ nicht mehr, auch wenn der Auslöser im
+  konkreten Fall ein Header war).
+  Dieser Text richtet sich primär an Entwickler und interessierte
+  Anwender und ist daher entsprechend ausführlich, weil das Verständnis
+  der Materie für zukünftige Arbeiten am UUZ unerläßlich ist.
+  ----------------------------------------------------------------------
+  1. (Bugfixes für Decodierung ungültiger UTF-8-Sequenzen)
+     Ein über 2 Jahre alter Bugfix in der UTF-8-Decodierung, der dazu
+     diente, auch umbrochene bzw. sich über mehrere Teilstrings
+     erstreckende Multibyte-Sequenzen decodieren zu können (so etwas
+     kann z.B. bei zusätzlich base64- oder quoted-printable-codierten
+     Zeilen vorkommen, aber auch bei Zeilen mit mehr als 253 Zeichen),
+     führte im konkreten Fall, daß eine Nachricht im Zeichensatz
+     ISO-8859-x vorlag, aber fälschlicherweise als UTF-8 deklariert war,
+     dazu, daß ein falscher LEN:-Header erzeugt wurde. Der defekte
+     Puffer wurde von FreeXP zwar problemlos eingelesen, konnte aber von
+     externen Tools wie XPFILTER und XPBMF, die auf einen gültigen
+     ZConnect-Puffer angewiesen sind, nicht mehr korrekt bearbeitet
+     werden. Bei genauerer Prüfung stellte sich heraus, daß der besagte
+     Fix weitere Probleme (möglicher Zeichenverlust, bei entsprechenden
+     Konstellationen wurden sogar korrekt codierte Zeichen gar nicht
+     mehr decodiert) verursachen konnte.
+     Das grundlegende Problem des Fixes bestand darin, daß er keinerlei
+     Fehler- und Plausibilitätsprüfungen vornahm und nur dann korrekt
+     funktionieren konnte, wenn die zu decodierende UTF-8-Sequenz gültig
+     war - was bei Nachrichten, die in Wirklichkeit gar nicht UTF-8-
+     codiert sind, nicht der Fall ist (z.B. kann eine UTF-8-Sequenz nie
+     7bit-Zeichen enthalten). Die Routine unterlag dann mitunter dem
+     Irrtum, es müßten noch weitere Zeichen folgen, die zur aktuellen
+     (angeblichen) UTF-8-Sequenz gehören, merkte sich die bereits
+     empfangenen Zeichen in der lokalen Variablen 'sc_rest' und wartete
+     auf den vermeintlich noch fehlenden Rest der Sequenz.
+     Wenn man sich aber z.B. ohnehin bereits am Ende eines Headers
+     befunden hatte, erfolgte der nächste Eintritt in die Routine u.U.
+     erst dann, wenn man sich inzwischen bereits im Body derselben oder
+     sogar irgendwo in einer der folgenden Nachrichten befand, ohne daß
+     der Variableninhalt zwischenzeitlich zurückgesetzt worden wäre. In
+     der Folge wurden "fremde" Bytesequenzen mit dem alten Variablen-
+     inhalt verquickt und völlig unsinnig "decodiert" - es entstand eine
+     Art "Bytesalat".
+     Zur Entstehung des falschen LEN:-Headers kam es deshalb, weil genau
+     so eine Konstellation vorlag und der Body jeder RFC-Nachricht zwei-
+     mal gelesen wird - einmal, um die Länge des Nachrichtentextes für
+     den LEN:-Header ermitteln und danach den ZConnect-Header komplett
+     schreiben zu können, ein zweites Mal, um den Body selbst zu
+     schreiben. Beim ersten Lesen wurde die sich noch aus dem fehlerhaft
+     als "UTF-8" deklarierten Subject:-Header in der Variablen 'sc_rest'
+     befindliche Sequenz aus 4 Bytes mit den ersten 2 Zeichen des Nach-
+     richtentextes verquickt und "decodiert" - dies führte zum für eine
+     Multibyte-Decodierung typischen Entfernen eines Zeichens und somit
+     zur Ermittlung einer um 1 Byte zu geringen Länge. Bei dieser
+     "Decodierung" wurde der Inhalt von 'sc_rest' zurückgesetzt, so daß
+     beim zweiten Lesen keine fehlerhafte Decodierung mehr stattfand,
+     somit auch kein Zeichen mehr entfernt und der Body daher in der
+     korrekten Länge geschrieben wurde => tatsächliche und vorher
+     ermittelte Länge stimmten nicht mehr überein. (Daß die Differenz im
+     konkreten Fall genau 1 Byte betrug, war Zufall, es hätten in
+     anderen Fällen auch bis zu 4 Bytes sein können.)
+     Zur Vermeidung dieses sowie aller anderen in diesem Zusammenhang
+     existierenden theoretischen und praktischen Probleme wurden daher
+     folgende umfassende Gegenmaßnahmen ergriffen:
+     a) Es werden nur noch UTF-8-Sequenzen decodiert, die nach den in
+        "The Unicode Standard, Version 4.0" und RFC3629 von November
+        2003 (das den bisher gültigen Standard RFC2279 von Januar 1998
+        ersetzt) niedergelegten Regeln eine gültige UTF-8-Sequenz
+        bilden. Das hat automatisch zur Folge, daß auch Sequenzen mit
+        7bit-Zeichen, wie sie bei ISO-8859-x oder allen anderen Latin-
+        Zeichensätzen zwangsläufig vorkommen, nicht mehr blind kaputt-
+        decodiert und auch keine vermeintlich unvollständigen Sequenzen
+        in der Variablen 'sc_rest' mehr abgelegt werden.
+     b) Stattdessen werden 8bit-Zeichen, die sich in einer angeblichen
+        und/oder ungültigen UTF-8-Sequenz befinden, der Standardkonver-
+        tierung von Windows-1252 in den IBM-Zeichensatz CP437 unterzo-
+        gen. Dadurch werden in den allermeisten Fällen die Zeichen in
+        fälschlicherweise als UTF-8 deklarierten Nachrichten korrekt
+        "erraten" und bei einer Antwort auf eine solche Nachricht
+        korrekt wiedergegeben.
+        Das Durchführen dieser Standardkonvertierung folgt demselben
+        "robustness principle" wie es für Nachrichten gilt, bei denen
+        gar kein Zeichensatz deklariert ist. Selbst wenn das "erratene"
+        Zeichen ausnahmsweise falsch sein sollte (weil die Nachricht in
+        einem völlig anderen Zeichensatz als Windows-1252 vorliegt), ist
+        es innerhalb von XP immer genauso richtig wie ein gar nicht kon-
+        vertiertes Zeichen (nämlich falsch ;-)).
+     c) Um nicht fälschlicherweise zufällig gültige, aber unvollständige
+        UTF-8-Bytesequenzen am Ende eines Teilstrings vom einen Header
+        zum anderen bzw. bis zum Body oder gar vom Body zu einem Header
+        der nächsten Nachricht mitzuschleppen und dort mit - zufällig
+        ebenfalls gültigen - UTF-8-Bytesequenzen am Anfang des jeweils
+        nächsten Headers oder Body zu verquicken und damit eine zwar
+        technisch gültige, aber inhaltlich fehlerhafte Decodierung
+        durchzuführen, werden jetzt alle in Headern vorkommenden encoded
+        words, alle einzelnen RFC-Headerzeilen, Gesamtheader und Body
+        sowie die einzelnen Zeilen im Nachrichtentext über die globale
+        Variable 'start_of_UTF' streng voneinander abgegrenzt. In allen
+        diesen Fällen wird eine etwaige Restsequenz in 'sc_rest' jetzt
+        verworfen.
+        (Multibyte-Sequenzen dürfen sich gemäß RFC2047 weder über mehre-
+        re encoded words noch über mehrere Zeilen im Body erstrecken und
+        es sind aus der Praxis auch keine solchen Fälle bekannt. Wenn
+        UTF-8-codierte Nachrichten zusätzlich base64/qp-codiert sind,
+        dann können und dürfen sich Multibyte-Sequenzen hingegen durch-
+        aus über mehrere codierte Zeilen erstrecken. Dies wird von der
+        neuen Routine korrekt behandelt und unterstützt, siehe dazu auch
+        Punkt 3.)
+     d) So ein zu verwerfender Rest kann darüber hinaus jetzt aber gar
+        nicht mehr entstehen, da über die an den entsprechenden Stellen
+        gesetzte globale Variable 'end_of_UTF' geprüft wird, ob man sich
+        am Ende eines encoded word, Headers oder einer Zeile im Body
+        befindet. Sollte sich dort der gültige Anfang einer unvollstän-
+        digen UTF-8-Bytesequenz befinden, wird diese trotzdem nicht in
+        'sc_rest' abgelegt, weil keine zu dieser Sequenz gehörenden
+        Daten mehr folgen können.
+     e) Bei der Decodierung von Headern und Body werden jetzt nur noch
+        Teilstrings mit einer Länge von max. 248 Zeichen (bisher: 253
+        Zeichen) an die UTF-8-Routine übergeben. Damit wird verhindert,
+        daß durch die Stringaddition der max. 3 Zeichen (bisher: 5
+        Zeichen) langen Bytesequenz in 'sc_rest' ein Überlauf und damit
+        Zeichenverlust entstehen kann (Variable 'maxUTFLen' in
+        MIMEDEC.PAS eingeführt).
+  2. (Erweiterung der UTF-7-Decodierung für beliebig lange Zeilen und
+     Sequenzen)
+     Die UTF-7-Decodierung besaß einen solchen Fix für die Decodierung
+     umbrochener bzw. sich über mehrere Teilstrings erstreckender
+     Sequenzen bisher nicht - vermutlich, weil es dort wegen der belie-
+     bigen und undefinierten Länge der Sequenz (UTF-7 ist eine Variante
+     der base64-Codierung) noch erheblich schwieriger zu implementieren
+     gewesen wäre als bei UTF-8. ;)
+     Dadurch konnte dort zwar das für UTF-8 beschriebene Problem mit der
+     Erzeugung eines ungültigen LEN-Headers auch nicht auftreten, dafür
+     kam es aber eben bei der Decodierung von gleichzeitig base64/qp-
+     codierten Nachrichten oder bei Zeilen mit mehr als 253 Zeichen zu
+     möglichen Problemen (je nachdem, ob sich die Schnittstelle zweier
+     Teilstrings inmitten einer UTF-7-codierten Sequenz befunden hat
+     und/oder das Ende der zu decodierenden Sequenz im aktuellen Teil-
+     string nicht vorhanden war).
+     Die UTF-7-Decodierung ist jetzt ebenfalls für beliebig lange
+     Zeilen und Sequenzen in Headern und im Body ausgelegt (bisher:
+     253 Zeichen) und berücksichtigt die Regeln und Besonderheiten der
+     base64-Codierung (siehe auch Punkt 5.)
+     Alle unter Punkt 1. a) bis e) für UTF-8 beschriebenen Maßnahmen
+     gelten sinngemäß auch für die UTF-7-Decodierung, wobei die Prüfung
+     auf ungültige Bytesequenzen dort gänzlich anderen (und weniger
+     präzisen) Regeln unterliegt: Wenn nach dem eine UTF-7-Sequenz
+     einleitenden "+" nicht mindestens 3 gültige 7bit-Zeichen folgen,
+     wird die Decodierung der aktuellen Sequenz abgebrochen und das "+"
+     sowie ein ggf. abschließendes "-" bleiben erhalten (bisher wären
+     sie entfernt worden).
+  3. (Berücksichtigung von Zeilenumbrüchen in base64/qp-decodierten
+     Teilstrings)
+     Als "Zeilen" im Sinne der vorhergehenden Punkte 1. und 2. gelten
+     alle Zeichen in unbegrenzter Anzahl zwischen zwei Zeilenumbrüchen
+     (CR/LF/CRLF, siehe auch Punkt 4.) bzw. in einem encoded word in
+     einem RFC-Header *nach* einer etwaigen base64/qp-Decodierung.
+     Daher mußte die base64/qp-Decodierung des Nachrichtentextes so
+     angepaßt werden, daß Zeilenumbrüche im decodierten String sicher
+     erkannt und nur Strings an eine evtl. nachfolgende UTF-7/8-Decodie-
+     rungsroutine übergeben werden, die nicht über einen Zeilenumbruch
+     hinausgehen (bisher konnten sich Zeilenumbrüche mitten im zu
+     decodierenden String befinden). Anderenfalls wäre eine saubere
+     Abgrenzung einzelner Zeilen im Nachrichtentext (und damit das
+     korrekte Setzen der Variablen 'start_of_UTF' und 'end_of_UTF' für
+     eine unmittelbar anschließende UTF-7/8-Decodierung) nicht möglich
+     gewesen.
+  4. Bei der Decodierung von base64/qp-codierten Texten (Content-Type
+     text/*) werden einzelne im decodierten String vorkommende CR und LF
+     jetzt durch CRLF ersetzt (bereits vorhandene CRLF bleiben unverän-
+     dert erhalten).
+  5. (Erweiterung der Transportdecodierung für beliebig lange Zeilen
+     (Body) unter Berücksichtigung einer ggf. anschließenden Zeichen-
+     satzdecodierung (UTF-7/8) für darin enthaltene, ebenfalls beliebig
+     lange Zeilen, die wiederum beliebig lange codierte Bytesequenzen
+     enthalten können (Header und Body))
+     Bei der Decodierung der im Header "Content-Transfer-Encoding:"
+     für den Nachrichtentext deklarierten Transportcodierung ("base64"
+     oder "quoted-printable") wie auch bei der Zeichensatzdecodierung
+     ("UTF-7" oder "UTF-8") von Headern und Body werden nur gültige und
+     in sich abgeschlossene Teilstrings an die jeweiligen Subroutinen
+     übergeben bzw. in diesen Subroutinen decodiert:
+     "base64"           (Transport): Übergebene Stringlänge ist durch 4
+                                     teilbar oder kleiner 4 (am Ende des
+                                     Gesamtstrings).
+     "quoted-printable" (Transport): Übergebener String endet mit einem
+                                     uncodierten oder mit einem voll-
+                                     ständigen codierten Zeichen wie
+                                     "=E4" (nicht aber mit unvollstän-
+                                     dig codierten wie "=E4=E").
+     UTF-7            (Zeichensatz): Bearbeiteter String endet mit einem
+                                     uncodierten Zeichen oder mit einer
+                                     codierten Bytesequenz, deren Länge
+                                     kleiner 4 oder durch 4 teilbar ist.
+     UTF-8            (Zeichensatz): Bearbeiteter String endet mit einem
+                                     uncodierten Zeichen oder mit einer
+                                     codierten Bytesequenz, deren Länge
+                                     durch das erste Zeichen der Sequenz
+                                     definiert wird.
+     Evtl. überhängende Reststrings, Restbytes oder unvollständige Byte-
+     sequenzen, wie sie bei Zeilen > 248 Zeichen oder nach einer
+     base64/qp-Decodierung entstehen können, werden zwischengespeichert
+     und anschließend gemeinsam mit dem nachfolgenden Teilstring
+     decodiert.
+     Dies funktioniert auch bei doppelt codierten Headern oder Zeilen in
+     Headern oder im Body (Transportcodierung "quoted-printable" oder
+     "base64" im Body bzw. "Q" oder "B" im Header sowie Zeichensatz-
+     deklaration "UTF-7" oder "UTF-8").
+     Erst und nur durch dieses Verfahren ist es überhaupt möglich,
+     beliebig lange und ggf. doppelt codierte Zeilen und Sequenzen
+     trotz der Längenbeschränkungen von Pascal korrekt zu decodieren. Es
+     erfordert allerdings ein peinlich genaues Vorgehen und die Berück-
+     sichtigung aller (un)denkbaren Szenarien, um korrekt und robust
+     funktionieren zu können.
+     Bisher war speziell die Transportdecodierung des Nachrichtentextes
+     - im Unterschied zu der von RFC-Headern - nicht für längere Zeilen
+     ausgelegt (laut RFC2045 sind bei base64- und qp-Codierung max. 76
+     Zeichen pro Zeile erlaubt, aber in der Praxis kommen auch deutlich
+     längere Zeilen von mehreren hundert Zeichen vor) und arbeitete
+     daher zwar meistens, aber eben nicht immer korrekt und robust.
+     Eine ggf. anschließende Zeichensatzdecodierung funktionierte prak-
+     tisch nur bei UTF-8-codierten Headern halbwegs zuverlässig, in
+     allen anderen Fällen (UTF-8 im Body, UTF-7 in Header und Body) war
+     das Ergebnis mitunter teilweise oder gänzlich unbrauchbar.
+     Damit ist der Enhanced UUZ für alle sinnvollen und unsinnigen sowie
+     zulässigen und unzulässigen Formen und Kombinationen von Transport-
+     und Zeichensatzcodierung gerüstet und decodiert diese jetzt korrekt
+     und robust:
+     Auch eine durchgehende, z.B. 3.852 Zeichen lange und base64-codier-
+     te Zeile im Nachrichtentext, aus der nach der base64-Decodierung
+     eine ebenfalls durchgehende, 2.889 Zeichen lange und UTF-7-codierte
+     Zeile resultiert, die ihrerseits aus einer einzigen durchgehenden
+     UTF-7-Sequenz besteht (was wegen der doppelten base64-Codierung ein
+     ebenso unsinniges wie aufgrund der Länge der Ursprungszeile unzu-
+     lässiges Szenario wäre), bereitet dem Enhanced UUZ jetzt keinerlei
+     Schwierigkeiten mehr.
+  6. Bei der qp-Decodierung von Zeilen im Body mit mehr als 253 - bzw.
+     jetzt 248 - Zeichen (die laut RFC2045 unzulässig sind, in der
+     Praxis aber öfter als selten vorkommen) wurden u.U. Leerzeichen
+     aus dem Text entfernt, weil die Routine als allererste Maßnahme
+     alle rechten Leerzeichen im String entfernt hat. Zwar fordert
+     RFC2045 genau das, aber das darf man natürlich auch nur am echten
+     Zeilenende und nicht am Ende jedes einzelnen Teilstrings einer
+     überlangen qp-codierten Zeile machen...
+  7. Bei der qp-Decodierung wird das Zeichen 0x00 in Headern und Body
+     jetzt decodiert (bisher behielt es die codierte Form "=00" bei).
+     Offenbar wurde bisher angenommen, es könne sich bei qp-codierten
+     Nachrichten nur um Textnachrichten handeln, die kein 0x00 enthalten
+     können bzw. dürfen - aber auch Binärdaten können theoretisch
+     qp-codiert sein, denn das ergibt sich nicht aus der Art der Codie-
+     rung, sondern ausschließlich aus dem Header "Content-Type:" ...
+     (siehe dazu auch weiter unten).
+  8. Wie bisher schon bei Headerzeilen oder wenn sie uncodiert vorkamen,
+     werden in Textnachrichten die codierten Zeichen 0x00 und 0x1A (#26,
+     Ctrl-Z) nach der b64/qp- und Zeichensatz-Decodierung/Konvertierung
+     jetzt durch ein Leerzeichen bzw. ein ">" ersetzt. Das Zeichen 0x1A
+     würde sonst an einigen Stellen im Programm (z.B. im Editor) als EOF
+     (Dateiende) fehlinterpretiert werden.
+  ToDo: Da die Routinen für die UTF-7/8-Decodierung auch bei der Anzeige
+        von MIME-Multiparts im Lister verwendet werden, sind diese neuen
+        Änderungen noch auf Kompatibilität mit den bereits vorgenommenen
+        Bugfixes für die Anzeige langer Zeilen > 255 Zeichen zu prüfen
+        und die älteren Fixes ggf. anzupassen und/oder zu erweitern.
+  UUZ.PAS, UUZ0.PAS, MIMEDEC.PAS, TYPEFORM.PAS
+
+MY:
+- Redundanten Code für das Lesen des Body aller Nachrichtentypen (UUCP-
+  Mail, SMTP-Mail, Newsbatch) entrümpelt, in der neuen Routine
+  'ReadRfcBody' zusammengefaßt und optimiert.
+  UUZ.PAS, UUZ0.PAS
+
+MY:
+- Diverse notwendige Fixes für die zentrale Routine 'ReadString':
+  ----------------------------------------------------------------------
+  1. Die Routine liefert jetzt am Zeilenende für die Variable 'eol'
+     (= Zeilenende erreicht) immer einen Wert von 2 zurück, und zwar
+     jetzt auch dann, wenn die Zeile zufällig genauso lang ist wie die
+     max. an die Stringvariable zurückzugebende Zeilenlänge (248 Zeichen
+     eingehend, 253 Zeichen ausgehend). Bisher wurde in solchen Fällen
+     ein Wert von 0 zurückgegeben (und daraus mitunter falsche Schlüsse
+     gezogen).
+  2. Am Dateiende wird jetzt ein Wert von 3 an 'eol' übergeben (auch,
+     wenn dort kein Zeilenumbruch (CR/LF) vorhanden sein sollte). Diese
+     Änderung hat den positiven Nebeneffekt, daß jetzt auch ZConnect-
+     Puffer in zu-Richtung ohne abschließenden Zeilenumbruch korrekt
+     konvertiert werden (bisher fehlte dann die letzte Zeile fast voll-
+     ständig, lediglich das erste Zeichen dieser Zeile wurde nahtlos an
+     das letzte Zeichen der vorherigen Zeile angehängt).
+  Damit können Routinen, die 'ReadString' aufrufen, jetzt sicher davon
+  ausgehen, daß bei 'eol=0' noch weitere Zeichen außer CR/LF in dersel-
+  ben Zeile folgen werden. Diese Änderung ist wichtig sowohl für die
+  oben im Zusammenhang mit UTF/base64/qp-Decodierung beschriebenen
+  Fixes als auch für das korrekte Lesen und Schreiben von Puffern
+  allgemein.
+  3. Endlosschleife bei der Konvertierung von News-Puffern, die als
+     Zeilenabschluß CR statt CRLF oder LF verwenden, behoben (zufällig
+     beim Testen entdeckt und in der Praxis noch nicht aufgetreten,
+     betrifft alle existierenden UUZs aller XP-Versionen). Der Enhanced
+     UUZ akzeptiert jetzt auch alleinstehende CR als Zeilenabschluß.
+  4. 'ReadString' hat schon bisher nur Teilstrings übergeben, die sauber
+     an einer Wortgrenze getrennt waren. Dabei wird neben Leerzeichen,
+     Komma und Semikolon jetzt auch das Tabulatorzeichen #9 als Trenn-
+     zeichen akzeptiert.
+  5. Damit Routinen, die 'ReadString' aufrufen, auch die nächsten im
+     Lesepuffer, aber wegen des Erreichens der max. Stringlänge nicht
+     mehr im aktuellen Teilstring befindlichen Zeichen prüfen können,
+     stellt 'ReadString' jetzt sicher, daß immer mindestens vier Zeichen
+     im Lesepuffer zur Verfügung stehen (sofern vorhanden). Ist das
+     zufällig nicht der Fall, obwohl das Dateiende noch nicht erreicht
+     ist, lädt 'ReadString' diese Zeichen nach. Diese Änderung ist
+     relevant z.B. für die vorzeitige Erkennung des Endes einer SMTP-
+     Mail (was wiederum notwendig für eine korrekte UTF-7/8-Decodierung
+     ist) als auch für das korrekte Entfernen der XP-typischen zwei
+     Leerzeichen am Ende jeder Zeile (siehe weiter unten), sowie für
+     alle anderen (zukünftigen) Routinen, die einen "look ahead" auf die
+     max. nächsten 4 Zeichen machen müssen.
+  UUZ0.PAS
+
+MY:
+- Fix: Wenn sich nach der RFC=>ZC-Konvertierung einer eingegangenen
+  Textnachricht (nicht bei Binärnachrichten!) kein Zeilenumbruch (CRLF)
+  am Ende des Puffers befindet, wird dieser jetzt hinzugefügt (kann
+  insbesondere bei base64-codierten Texten im Body vorkommen). Bisher
+  wurde der EMP:-Header einer nachfolgenden Nachricht in diesem Fall
+  nahtlos an das letzte Zeichen der vorherigen Nachricht angehängt. Der
+  Fall, daß der Puffer nur mit einem einzelnen CR oder LF abgeschlossen
+  ist, wird ebenfalls behandelt. Im Falle von SMTP-Mails (die mit den
+  Zeilen "." und "QUIT" enden) mußte hierfür die Logik beim Lesen des
+  Body dahingehend angepaßt werden, daß die Routine bereits den Inhalt
+  der nächsten Zeile prüft, während die aktuelle Zeile noch bearbeitet
+  wird (ansonsten könnte das Ende der Nachricht nicht "vorhergesehen"
+  und außerdem auch nicht die für die UTF-7/8-Decodierung notwendigen
+  Variablen 'start_of_UTF' und 'end_of_UTF' korrekt gesetzt werden,
+  siehe weiter oben).
+  UUZ0.PAS
+
+MY:
+- Fix (-uz): Zwei theoretisch mögliche (in der Praxis bisher nicht auf-
+  getretene) Endlosschleifen bei unvollständig/defekt base64-codierten
+  RFC-Headern, bei denen sowohl Header als auch das betreffende encoded
+  word länger als 255 Zeichen waren, in 'UTF8ToIBM' und 'DecodeEW' beho-
+  ben (letztere Schleife verbunden mit einem Crash, insofern nicht ganz
+  "endlos" ;-)).
+  In solchen Fällen wird der unvollständige Header jetzt soweit codiert
+  wie möglich und die übrigbleibende Restsequenz verworfen.
+  MIMEDEC.PAS
+
+MY:
+- Ausgehende Nachrichten (-zu) werden jetzt auch dann qp-codiert, wenn
+  sie keine 8bit-Zeichen enthalten. Sinnvoll, um die max. Zeilenlänge im
+  Body für den Transport einerseits auf 76 Zeichen begrenzen zu können
+  und andererseits zu verhindern, daß extrem lange Zeilen nach der von
+  RFC2822 definierten Grenze von 998 Zeichen - bzw. beim letzten Wort
+  davor - zwangsumbrochen werden müssen (lange qp-codierte Zeilen
+  enthalten 'soft line breaks', die Zeile wird bei der Decodierung
+  wieder zusammengesetzt; daher sind qp-codierte Zeilen in decodierter
+  Form prinzipiell nie längenbegrenzt).
+  UUZ.PAS
+
+MY:
+- Fix (-uz): Wenn ein RFC-Header mit mehr als 255 Zeichen an der letzten
+  Position des ersten zu decodierenden Teilstrings einen codierten
+  Zeilenumbruch (CR oder LF) enthielt (der durch ein Leerzeichen ersetzt
+  wurde) und der nächste Teilstring ebenfalls mit einem codierten
+  Zeilenumbruch oder mit einem Leerzeichen begann, dann entstanden zwei
+  Leerzeichen, obwohl ansonsten mehrere CR/LF hintereinander nur durch
+  ein einziges Leerzeichen ersetzt bzw. ganz entfernt wurden, wenn sich
+  links oder rechts davon bereits ein Leerzeichen befand. Dies ist ein
+  Fix für ein ebenfalls theoretisches und bisher in der Praxis nicht
+  aufgetretenes Szenario, weil Header keine codierten Zeilenumbrüche
+  enthalten (dürfen) und die Entscheidung, mehrere CR/LF hintereinander
+  durch nur ein Leerzeichen zu ersetzen bzw. ganz zu entfernen, ohnehin
+  völlig willkürlich ist (*daß* sie in irgendeiner Form entfernt werden
+  müssen, ist bei Headern allerdings zwingend und liegt in der Natur der
+  Sache).
+  MIMEDEC.PAS
+
+MY:
+- Fix (-uz): Der Header "X-XP-Version:", der bisher Priorität gegenüber
+  allen anderen Software-Headern besaß, verliert diese jetzt, wenn ein
+  anderer Software-Header existiert, dessen Beginn identisch mit dem
+  Inhalt von "X-XP-Version:" ist und der darüber hinaus weitere Zeichen
+  enthält. Damit bleiben Header, die Anhänge wie "via UKA_PPP x.xx",
+  "via XPNews" o.ä. enthalten, aber gegenüber "X-XP-Version:" ansonsten
+  unverändert sind, jetzt wieder erhalten.
+  UUZ.PAS
+
+MY:
+- Workaround für UKA_PPP-Software-Header bei Usenet-Postings: UKA_PPP
+  hat in einigen (allen?) Versionen beim Versenden von Postings die Ei-
+  genschaft, dem vom UUZ erzeugten Header "X-Newsreader:" einen weiteren
+  Header "X-Mailer:" mit dem Inhalt "NOS-BOX x.xx" oder "UKA_PPP x.xx"
+  hinzuzufügen. Da der UUZ bei der Konvertierung eingehender Nachrichten
+  im Falle mehrerer Software-Header immer den jeweils letzten in den
+  ZConnect-Header MAILER: geschrieben hat, konnten die Empfänger dieser
+  Postings oft nur den jeweiligen UKA_PPP-Eintrag sehen, nicht aber die
+  verwendete CrossPoint-Version.
+  Wenn ein Header "X-Mailer:" vorhanden ist, der mit "UKA_PPP" oder
+  "NOS-BOX" beginnt, dann wird dieser jetzt an einen etwaig zusätzlich
+  vorhandenen Software-Header mit dem Wort "via" angefügt, statt einen
+  bereits gelesenen Header zu ersetzen oder durch einen nachfolgenden
+  Haeder überschrieben zu werden. Damit wird derselbe String erzeugt,
+  den auch UKA_PPP selbst bei Mails im UUCP-Format (nicht aber bei Mails
+  im SMTP-Format) generiert.
+  Obwohl UKA_PPP den Header "X-Mailer:" am Ende des Gesamtheaders hinzu-
+  fügt und dieser daher immer erst *nach* dem Header "X-Newsreader:"
+  vorkommen sollte, ist nicht ausgeschlossen (und in der Praxis auch
+  schon vorgekommen), daß Clients oder Server die Reihenfolge der Header
+  ändern. Daher wurde der Workaround so konzipiert, daß die Reihenfolge
+  der Header in diesem Fall keine Rolle spielt.
+  Dieser Workaround unterstützt *keine* beliebig langen Zeilen. Wenn die
+  Summe aus dem UKA_PPP-Header und dem eigentlichen Software-Header
+  länger ist als ein Pascal-String, wird der UKA_PPP-Header verworfen
+  (wird aber in der Praxis nie vorkommen). Der Workaround ist zu unwich-
+  tig und das Eintreten des Szenarios zu unwahrscheinlich, als daß ein
+  höherer Aufwand zu rechtfertigen wäre.
+  UUZ.PAS
+
+MY:
+- Workaround für Endlosschleife bei der ZC=>RFC-Konvertierung von
+  defekten ZConnect-Puffern mit zu großem LEN:-Header: Alle bisher
+  existierenden UUZ-Versionen laufen in eine Endlosschleife, wenn der
+  LEN:-Header der einzigen oder letzten Nachricht im Puffer einen zu
+  hohen Wert enthielt. In diesem Fall liest der Enhanced UUZ jetzt die
+  Nachricht bis zum Dateiende und konvertiert sie somit korrekt.
+  Enthalten auch etwaige vorherige Nachrichten im Puffer LEN:-Header mit
+  zu hohen Werten, werden sie zwar konvertiert, aber wie bisher nicht
+  korrekt. Ziel des Workarounds war nicht die Reparatur defekter LEN-
+  Header (dafür gibt es den Puffer-Reparierer ZPR), sondern lediglich
+  das Vermeiden der Endlosschleife.
+  UUZ.PAS
+
+MY:
+- Behandlung von Leerzeichen am Zeilenende beim Schreiben des Nachrich-
+  tentextes (Body) ausgehender RFC-Nachrichten komplett überarbeitet:
+  ----------------------------------------------------------------------
+  1. Es werden jetzt nur noch die XP-typischen zwei Leerzeichen am
+     Zeilenende bei fortlaufend umbrochenen Absätzen entfernt, jedoch
+     nicht mehr einzelne bzw. mehr als zwei Leerzeichen oder nur aus
+     Leerzeichen bestehende Zeilen (der Signaturtrenner war davon ohne-
+     hin auch bisher schon ausgenommen). Als "Zeile" gilt wie bisher
+     jede Zeile beliebiger Länge.
+  2. Dafür funktioniert das Entfernen der zwei Leerzeichen jetzt auch
+     in allen Fällen korrekt (befanden sich die Leerzeichen an Pos. 253
+     und 254, funktionierte es bisher z.B. nicht).
+  3. Wird die Nachricht qp-codiert, wird das letzte Leerzeichen am
+     absoluten Ende einer Zeile jetzt gemäß RFC2045 ebenfalls codiert
+     (bisher ging der UUZ davon aus, daß gar keine Leerzeichen vorhanden
+     sein können, was aber im Falle mehrerer Leerzeichen am Zeilenende
+     ab Pos. 252/253 hintereinander auch bisher schon nicht gewährlei-
+     stet war). Beim Signaturtrenner bestand dieses Problem aufgrund
+     einer Sonderbehandlung nicht, diese ist durch die generelle
+     Änderung jetzt aber überflüssig geworden und wurde daher entfernt.
+  UUZ.PAS
+
+MY:
+- Der für den Transport von SMTP-Mails am Zeilenanfang im Body hinzuzu-
+  fügende Punkt, wenn die Zeile selbst ebenfalls mit einem Punkt beginnt
+  ("dot stuffing"), wird bei der Berechnung der max. zu schreibenden
+  Zeichen pro Zeile (998 ohne Codierung, 76 bei qp-Codierung) jetzt
+  ignoriert - die Zeilen können also in diesem Fall jetzt um jeweils 1
+  Zeichen länger werden, da der Punkt beim Transport ohnehin entfernt
+  wird.
+  Dasselbe gilt für News-Postings, bei denen der Punkt vom Client hinzu-
+  gefügt wird: Dort hat der UUZ deshalb bisher immer ein Zeichen Reserve
+  gelassen, dies passiert jetzt nicht mehr.
+  Das bisherige (und mit der ersten Fassung des Enhanced UUZ eingeführ-
+  te) Vorgehen war nicht wirklich falsch oder schädlich, aber unnötig
+  und ungewöhnlich.
+  UUZ.PAS
+
+MY:
+- Fix: Als Seiteneffekt der oben beschriebenen Bugfixes wurde ein Bug
+  behoben, der ebenfalls bisher weder aufgefallen noch aufgetreten ist:
+  Beim Schreiben der ohnehin nur informativen Header mit dem Prefix
+  "X-Orig-" (Kopie der jeweiligen originalen RFC-Headerzeile im
+  ZConnect-Header) konnte es unter seltenen Umständen passieren, daß ein
+  Leerzeichen zwischen zwei Worten entfernt wurde (die Decodierung des
+  Headers und somit das Resultat im BET:-Header waren trotzdem korrekt).
+  Unter welchen Umständen das genau passierte, wurde genauso wenig näher
+  untersucht wie die Frage, welchem der o.a. Fixes die Behebung dieses
+  Bugs zu verdanken ist. ;-)
+  Beobachtet wurde das Verhalten jedenfalls bei zwei encoded words,
+  wovon das erste exakt 254 Zeichen lang war (was in der Praxis ohnehin
+  nur bei von OpenXP produzierten Headern vorkommen kann und zudem
+  unzulässig ist).
+  ???.PAS
+
+MY:
+- Logik beim Lesen des RFC-Headers etwas geändert, u.a. mit der konkre-
+  ten - in der Praxis aber kaum relevanten - Folge, daß bei Headern, die
+  mit einer beliebigen Anzahl vorlaufender Leerzeichen beginnen, diese
+  jetzt unter allen Umständen vollständig entfernt würden (bisher nur
+  die bis Pos. 253). Des weiteren hätte es in bestimmten - in der Praxis
+  ebenfalls noch nicht aufgetretenen - Szenarien passieren können, daß
+  die Routine falsche Schlüsse zieht und glaubt, sie befände sich am
+  Anfang des nächsten Headers, obwohl sie sich noch in der Fortsetzung
+  des aktuellen Headers befindet. Reine Vorsichtsmaßnahme.
+  UUZ.PAS
+
+MY:
+- Fix (-uz): Bei Nachrichten mit einem "Content-Type:"-Header, dessen
+  mehrere Parameter mit Semikolon, aber ohne anschließendes Leerzeichen
+  separiert waren, wurde bisher der Zeichensatz nicht korrekt ausge-
+  wertet, weil der unmittelbar nachfolgende Parameter für einen Teil des
+  Zeichensatznamens gehalten wurde (Fehlermeldung "ERR: Unsupported
+  character set: iso-8859-1;format=flowed"). In der Folge wurde der
+  Nachrichtentext dann auch nicht konvertiert. :-(
+  UUZ0.PAS
+
+MY:
+- Workaround: Einige Mail<=>News-Gates setzen offenbar Header in der
+  "neuen" Form 'Real Name <local.part at do.main>' in die auch intern von
+  XP verwendete "alte" Form 'local.part at do.main (Real Name)' um, verges-
+  sen dabei aber mitunter, die auch bei der neuen Form oft ohnehin über-
+  flüssig gesetzten Anführungszeichen vor und hinter dem Realname zu
+  entfernen. Die Routine des UUZ entfernt daher diese Anführungszeichen
+  gemäß RFC2822 bisher ebenfalls nicht (weil sog. quoted-strings in
+  Kommentaren - ein Realname in Klammern ist technisch betrachtet ein
+  Kommentar - eigentlich nicht als quoted-strings gelten).
+  Bei Headern, die in der alten Form vorliegen, werden etwaige Anfüh-
+  rungszeichen vor und hinter dem Realname jetzt trotzdem entfernt, wenn
+  sie sich wirklich am Anfang und Ende des Realname befinden und wenn
+  der Realname aus mindestens zwei Worten besteht (bei nur einem in
+  Anführungszeichen eingeschlossenen Wort wird davon ausgegangen, daß es
+  sich um einen "Nickname" o.ä. handelt, bei dem sie bewußt gesetzt
+  wurden).
+  MIMEDEC.PAS
+
+MY:
+- Geänderte Behandlung des ZConnect-Headers "Antwort-an:":
+  ----------------------------------------------------------------------
+  -uz: Seit dem Erscheinen des ersten Enhanced UUZ wurden mehrere
+       Absender im From:-Header in mehrere ZConnect-Header ANTWORT-AN:
+       geschrieben (weil mehrere ABS:-Header laut ZConnect-Spezifikation
+       nicht zulässig sind, mehrere ANTWORT-AN:-Header aber schon). Die
+       Großschreibung sollte zur späteren Unterscheidung in FreeXP von
+       den "echten" Headern für Reply-To-Adressen in der bisherigen
+       Schreibweise "Antwort-an" dienen und erreichen, daß nach der noch
+       vorzunehmenden Erweiterung der Reply-To-All-Routine die Adressen
+       in den Headern ANTWORT-AN: als Absender erkannt und angezeigt
+       werden können. Da ANTWORT-AN: aber ausgerechnet der Standard-
+       schreibweise im ZConnect-Raum entspricht, hätte das nicht korrekt
+       funktioniert, wenn ZConnect-Puffer anderer Programme (z.B. von
+       OpenXP) in FreeXP eingelesen worden wären, die diese Standard-
+       schreibweise verwenden. FreeXP verwendet daher jetzt ebenfalls
+       die Standardschreibweise "ANTWORT-AN:" für "echte" Reply-To-
+       Adressen, für mehrere Adressen aus dem From:-Header jedoch jetzt
+       stattdessen die Schreibweise "antwort-An:", die mit an Sicherheit
+       grenzender Wahrscheinlichkeit von keinem anderen ZConnect-
+       Programm verwendet wird. Die zukünftige Reply-To-All-Routine muß
+       daher die genaue Schreibweise des Headers prüfen, um Absender-
+       und Reply-To-Adressen voneinander unterscheiden zu können (d.h.
+       auch, daß die frühere Schreibweise "Antwort-an:" und die aktuelle
+       Schreibweise "ANTWORT-AN:" gleichbehandelt werden, was im Sinne
+       der Abwärtskompatibilität sinnvoll und notwendig ist).
+  -zu: Folgerichtig prüft der UUZ bei der Konvertierung in zu-Richtung
+       jetzt die Schreibweise des Headers ANTWORT-AN: und erzeugt bei
+       Headern in der Schreibweise "antwort-An:" nicht mehr einen Header
+       "Reply-To:", sondern fügt die im Header enthaltene Adresse dem
+       Header "From:" hinzu (i.d.R. ist durch den ZConnect-Header ABS:
+       ja eine Absenderadresse bereits vorhanden), ein evtl. vorhandener
+       Realname wird dabei übernommen. Dies funktioniert mit so vielen
+       "antwort-An:"-Headern, wie in der Konstanten 'maxabs' als max.
+       Anzahl von Absendern definiert ist (derzeit 50).
+       Damit ist gewährleistet, daß sich nach einer unmittelbar aufein-
+       anderfolgenden RFC=>ZC=>RFC-Konvertierung (typisches Gate-
+       Szenario, das aber auch von XP-Anwendern praktiziert wird), sich
+       die Adressen aus dem ursprünglichen From:-Header auch wieder im
+       neu erzeugten From:-Header befinden.
+  UUZ0.PAS, XPMAKEHD.INC
+
+MY:
+- Variable 'control' von 150 auf midlen+9 vergrößert: 'midlen' (max.
+  Länge der Message-ID) hatte inzwischen eine Größe von 160 Zeichen,
+  daher wäre beim Versuch, eine Nachricht mit einer Message-ID von mehr
+  als 141 Zeichen Länge zu canceln, durch das Hinzufügen des Strings
+  'cancel' und der beiden spitzen Klammern ein unvollständiger Subject:-
+  Header erzeugt worden (in der Praxis ist dieser Fall offenbar bisher
+  nicht vorgekommen).
+  UUZ0.PAS
+
+MY:
+- Zeitzone "CEST" ergänzt (ausgerechnet die einzige korrekte Schreib-
+  weise für die Mitteleuropäische Sommerzeit - "Central European Summer
+  Time" - fehlte, falsche wie "MEST" hingegen wurden ausgewertet).
+  UUZ0.PAS
+
+MY:
+- Bei Zeitzonenangaben im "Date:"-Header, die die Zeitzone nicht direkt
+  über ein numerisches Offset, sondern über eine Abkürzung wie "CET"
+  angeben, kann es zudem vorkommen, daß die Sommerzeit mit dem Zusatz
+  "DST" (= "Daylight Saving Time") deklariert wird (scheint speziell bei
+  älteren unixoiden Systemen häufiger vorzukommen). Bisher wurde diese
+  Angabe ignoriert, jetzt erhöht der Enhanced UUZ das Offset in diesem
+  Fall um +1 und errechnet so die korrekte Lokalzeit.
+  UUZ0.PAS
+
+MY:
+- Fix (-uz): Der Kommandozeilenschalter "-graberec" (Adresse des
+  Envelope-Empfängers aus "Received:"-Headern auslesen) funktionierte
+  zwar intern noch, war aber nach außen ohne konkrete Wirkung, weil die
+  die Adresse enthaltende Variable nur dann ausgewertet wurde, wenn
+  gleichzeitig auch der Schalter "-UseEnvTo" angegeben worden war.
+  "-graberec" ist jetzt auch wieder ohne "-UseEnvTo" benutzbar; darüber
+  hinaus wird die aus dem "Received:"-Header ausgelesene Adresse jetzt
+  auf Plausibilität geprüft und anschließend derselben Behandlung
+  unterzogen (spitze Klammern, Kommentare usw. entfernen) wie alle
+  anderen Header, die Mail-Adressen enthalten. Dadurch werden etwaige
+  Strings nach dem Schlüsselwort "for", die gar keine Adressen sind
+  (kein "@" enthalten), jetzt sofort verworfen und in den folgenden
+  Received:-Headern weiter nach einer Adresse gesucht, statt nach dem
+  ersten gefundenen String die Suche abzubrechen und erst später
+  festzustellen, daß es sich gar nicht um eine Adresse handelt.
+  Werden "-graberec" und "-UseEnvTo" gleichzeitig angegeben, besitzt
+  "-graberec" jetzt niedrigere Priorität (auch, weil das Verfahren
+  ohnehin recht fragwürdig ist). In diesem Fall würden die "echten"
+  Envelope-Header (siehe Beschreibung der nächsten Änderung) Vorzug
+  genießen, aber so ist es immerhin möglich, beide Schalter sinnvoll
+  miteinander zu kombinieren und nur dann die aus den "Received:"-
+  Headern ausgelesene Adresse zu verwenden, wenn keiner der übrigen vom
+  UUZ unterstützten Envelope-Header vorhanden ist.
+  UUZ.PAS, UUZ0.PAS, MIMEDEC.PAS
+
+MY:
+- Zusätzlich zu den bisher schon unterstützten RFC-Headern für Envelope-
+  Empfänger ("Envelope-To:", "X-Envelope-To:", "Delivered-To:") werden
+  jetzt noch "X-Original-To:" (Postfix) und "Original-Recipient:" (gemäß
+  RFC2298) unterstützt. Bei letzterem wird ein etwaig vor der Adresse
+  angegebener Adresstyp (z.B. "rfc822;") entfernt.
+  Es "gewinnt" bei mehreren Headern immer der jeweils letzte vorkommen-
+  de. Lediglich der Header "Delivered-To:" besitzt wie bisher eine
+  niedrigere Priorität als die übrigen und wird nur verwendet, wenn
+  kein anderer der unterstützten Envelope-Header vorkommt (hat aber
+  immer noch Priorität gegenüber "-graberec", siehe oben).
+  UUZ.PAS
+
+MY:
+- Hinweise für Benutzer von UKA_PPP:
+  Die bisherigen Erfahrungen mit dem Zusammenspiel von Enhanced UUZ und
+  UKA_PPP haben zu einigen Empfehlungen geführt, die nachfolgend zusam-
+  mengefaßt sind und denen man folgen sollte:
+  ----------------------------------------------------------------------
+  1. Wie schon in der Dokumentation zur ersten Fassung des Enhanced UUZ
+     erwähnt, sollte der Aufruf des Programms X_SPOOL.EXE mit dem
+     Schalter "/xc" unmittelbar vor dem UUZ-Aufruf im Netcall-Script
+     (i.d.R. heißt diese Datei "XPNEWS") entfernt bzw. auskommentiert
+     werden. Damit wird die bisher mitunter fehlerhafte Deklaration von
+     Zeichensatz und deren Codierung vermieden, da die Funktion von
+     X_SPOOL.EXE nun stellvertretend und sehr viel besser vom Enhanced
+     UUZ (über den Schalter "-chkbody", siehe auch Punkt 2. b)) übernom-
+     men wird.
+  2. a) Der UUZ-Aufruf im Netcall-Script sollte dann wie folgt aussehen:
+          exec $homedir+"\uuz.exe -zu -client -chkbody outfile.z .\"
+        Damit garantiert der Enhanced UUZ, daß Headerzeilen mit 8bit-
+        Zeichen korrekt MIME-codiert werden (die früheren Schalter
+        "-MIME" und "-1522" sind Default, nicht mehr abschaltbar und
+        daher überflüssig).
+        Bisher fehlte im Standardaufruf des UUZ im UKA_PPP-Script
+        schlicht der Schalter "-1522", so daß bei Verwendung älterer
+        UUZ-Versionen permanent Header mit uncodierten 8bit-Zeichen
+        erzeugt und versandt wurden (sog. "Hullen-Syndrom"). :-(
+     b) Der Schalter "-chkbody" (siehe auch Punkt 1.) stellt sicher, daß
+        der Body der Nachricht auf das Vorkommen von 8bit-Zeichen unter-
+        sucht und daher sowohl Zeichensatz als auch dessen Codierung
+        jetzt immer korrekt deklariert werden.
+     c) Zuguterletzt ist durch den Schalter "-client" gewährleistet, daß
+        Mails im SMTP-Format erstellt werden, die UKA_PPP unverändert
+        und korrekt versendet.
+        Zum Hintergrund:
+        Bei den bisher im UUCP-Format erstellten Mails hat UKA_PPP bei
+        der internen Umwandlung in das SMTP-Format im Falle von Mails
+        mit Kopienempfängern Änderungen an der Adressierung der Nach-
+        richten vornehmen müssen, um den Versand von Dupes zu vermeiden
+        (zudem wurde durch die etwas sonderbare, bei UUCP-Mails aber
+        notwendige Gestaltung der "To:"- und "Cc:"-Header seitens des
+        UUZ jedem der Cc:-Empfänger der falsche Eindruck vermittelt, er
+        selbst sei To:- und die übrigen Adressaten die Cc:-Empfänger).
+        Bei dieser Umwandlung hat UKA_PPP aber stellenweise nicht
+        berücksichtigt, daß Headerzeilen gefaltet sein können, was im
+        Betrieb mit dem Enhanced UUZ sogar zum Verlust von Kopienempfän-
+        gern ("Cc:") und/oder zur Kürzung des Subjects führen konnte.
+        Der Enhanced UUZ trägt insofern mit dazu bei, als daß er gemäß
+        RFC2822 Kopienempfänger kommasepariert in einen einzigen
+        "Cc:"-Header schreibt (statt mehrere einzelne "Cc:"-Header zu
+        erzeugen) und sowohl diesen wie auch den "Subject:"-Header bei
+        Bedarf faltet. Beides war beim "alten" UUZ nicht der Fall, aber
+        von dem bisherigen Verhalten gehen die Routinen in UKA_PPP aus.
+        Diese möglichen Probleme sind durch die direkte Erstellung von
+        SMTP-Mails über den Schalter "-client" automatisch behoben, da
+        UKA_PPP die Nachrichten nun nicht mehr umformatieren muß, dies
+        daher auch nicht tut und die Nachrichten 1:1 versendet.
+        Voraussetzung ist allerdings, daß die letzte aktuelle UKA_PPP-
+        Version v1.7x2 vom 25.04.2000 verwendet wird, alle vorherigen
+        Versionen sind für den direkten Versand von Mails im SMTP-Format
+        nicht geeignet.
+  Diese Hinweise gelten nicht für das noch zu veröffentlichende Add-On
+  für den Betrieb von UKA_PPP in einer RFC/Client-Box, denn dort werden
+  sie schon von vorneherein berücksichtigt sein.
+
+MY:
+- Der Enhanced UUZ ist jetzt kompatibel mit XP2. :-)
+  XP2-Anwender, die den Enhanced UUZ einsetzen möchten (was zu empfehlen
+  ist), sollten unbedingt folgende Hinweise beachten:
+  ----------------------------------------------------------------------
+  1. Unter Edit/Boxen/<Box>/Edit/Clients/UUZ-In kann folgende Aufruf-
+     zeile eingetragen werden:
+       UUZ.EXE -uz -ppp $SPOOL $PUFFER              [bis v3.30.020 Beta]
+       UUZ.EXE -uz $SCREENLINES -ppp $SPOOL $PUFFER $BOX [ab v3.30pre..]
+     Dabei handelt es sich um den Default-Eintrag von XP2, der mit <F2>
+     vorgeschlagen wird und nicht angepaßt werden muß. Der Eintrag kann
+     aber auch ganz entfallen, dann wird der ebenfalls funktionierende
+     Standardaufruf von XP2 verwendet.
+  2. Unter Edit/Boxen/<Box>/Edit/Clients/UUZ-Out ist folgende Aufruf-
+     zeile einzutragen:
+       UUZ.EXE -zu -ppp $PUFFER $SPOOL              [bis v3.30.020 Beta]
+       UUZ.EXE -zu $SCREENLINES -ppp $PUFFER $SPOOL      [ab v3.30pre..]
+     Diesen Eintrag sollte man vornehmen, aber auch hier würde der weit
+     umfangreichere Standardaufruf von XP2 funktionieren (die Parameter
+     "MIME" und "-1522" sind beim Enhanced UUZ Default, nicht mehr
+     abschaltbar und daher überflüssig, und der Parameter "-SMTP" ist
+     durch "-ppp" bereits impliziert).
+     Ebenfalls überflüssig und auch wirkungslos ist der XP2-spezifische
+     Parameter "-absnsstyle", der dazu führen soll, daß Absenderadressen
+     in der "neuen" Form 'Real Name <local.part at do.main>' erzeugt werden
+     (statt in der alten Form 'local.part at do.main (Real Name)'). Das
+     macht der Enhanced UUZ ohnehin per Default, nur codiert er dabei
+     die Headerzeile im Unterschied zum XP2-UUZ auch in allen Fällen
+     korrekt.
+  3. Wer seine ausgehenden Nachrichten einer quoted-printable-Codierung
+     unterziehen möchte (was beim UUZ von XP2 unbedingt zu vermeiden -
+     weil gnadenlos kaputt -, beim Enhanced UUZ aber sogar zu empfehlen
+     ist), muß, wenn ein manueller Eintrag im Feld "UUZ-Out" vorhanden
+     ist, dort den Parameter "-qp" ergänzen.
+     Ist kein manueller Eintrag vorhanden, reicht es, den Schalter
+     "MIME: quoted-printable verwenden" unter C/O/E/V zu aktivieren.
+  4. Der Enhanced UUZ erkennt im Betrieb mit XP2 automatisch, daß er
+     sich XP2-kompatibel zu verhalten hat. :-)  Dazu liest er die erste
+     Zeile der XPOINT.CFG ein und prüft auf das Vorkommen des Strings
+     "XP2".
+     Wer dieser Automatik nicht traut oder den Enhanced UUZ im Extern-
+     betrieb zu einem XP2-kompatiblen Verhalten zwingen möchte, kann/muß
+     zusätzlich den Parameter "-xp2" im UUZ-Aufruf angeben.
+  5. Wenn man den Enhanced UUZ nur mit "uuz" aufruft, wird man auf der
+     Hilfeseite einen weiteren Parameter "-chkbody" entdecken. Dieser
+     Parameter ist im XP2-Modus automatisch aktiviert, muß daher nicht
+     mit angegeben werden und hat zur Folge, daß der UUZ den Body jeder
+     Nachricht auf das Vorkommen von 8bit-Zeichen prüft und in der Folge
+     selbständig und korrekt den Zeichensatz und dessen Codierung in den
+     RFC-Headern "Content-Type:" und "Content-Transfer-Encoding:"
+     deklariert.
+     Diese Maßnahme war notwendig, um die Gefahr fehlerhaft deklarierter
+     Nachrichten zu eliminieren, denn die Deklaration, die XP2 dem UUZ
+     über den selbst generierten Header "X-Charset:" mitteilt und die
+     dieser ansonsten übernehmen würde, ist mitunter fehlerhaft.
+     Beispiel: Ein Text, der das Paragraphenzeichen "", aber ansonsten
+     nur 7bit-Zeichen enthält, würde von XP2 im Header "X-Charset:"
+     nicht als ISO-8859-1, sondern gar nicht deklariert werden. Das
+     Zeichen "" wird aber bei der IBM=>ISO-Konvertierung vom ursprüng-
+     lichen Wert #21 (Steuerzeichen in CP437) in das 8bit-Zeichen #167
+     in ISO-8859-1 konvertiert. Mangels korrekter Deklaration seitens
+     XP2 würde also eine 8bit-Nachricht, aber ohne bzw. mit falscher
+     Zeichensatz-/Codierungsdeklaration "US-ASCII" und "7bit" erzeugt
+     werden (kein deklarierter Zeichensatz ist immer gleichbedeutend mit
+     US-ASCII und 7bit). Dasselbe Resultat entsteht, wenn man z.B. über
+     das Clipboard oder per Taste <Alt-nnn> 8bit-Zeichen, die keine
+     Umlaute (äöüßÄÖÜ) *und* in ISO-8859-1 enthalten sind (also z.B.
+     Akzentzeichen wie "áéíóú") in eine Nachricht einfügt, für die über
+     die Brettgruppe oder den User der ASCII-Zeichensatz definiert wurde
+     - diese Zeichen konvertiert XP2 eben nicht nach ASCII (sondern in
+     das entsprechende Zeichen in ISO-8859-1) und erzeugt so eine 8bit-
+     Nachricht, ohne dies entsprechend zu deklarieren.
+     Umgekehrt deklariert XP2 mitunter bei Nachrichten an Nicht-ASCII-
+     Bretter/-User als Zeichensatz ISO-8859-1, obwohl US-ASCII richtig
+     und ausreichend wäre (nämlich bei Zeichen wie #224 "α" (kleines
+     alpha), die, weil sie in ISO-8859-1 nicht vorhanden sind, in ein
+     7bit-Zeichen - in diesem Fall "a" - transliteriert werden), da es
+     nicht den Ziel-, sondern den Quellzeichensatz auf das Vorkommen von
+     8bit-Zeichen prüft (übrigens ein genereller Fehler aller früheren
+     XP-Versionen).
+     Alle diese Fehler werden durch den im XP2-Modus automatisch akti-
+     vierten Parameter "-chkbody" korrigiert.
+  6. Die Kompatibilität des Enhanced UUZ mit XP2 besteht im einzelnen
+     aus folgenden Komponenten:
+     a) Bei der RFC=>ZC-Konvertierung eingehender Nachrichten werden
+        diese an einen evtl. bereits (oder noch) vorhandenen ZC-Puffer
+        "3PPUFFER" angehängt. In einer FreeXP-Umgebung wird ein bereits
+        existierender ZC-Puffer mit der Endung .BAK versehen und in
+        jedem Fall ein neuer erzeugt. Dieses Verhalten würde bei XP2
+        mitunter - speziell bei Multiserver-Netcalls - zu Datenverlust
+        führen.
+     b) Die Behandlung ausgehender und eingehender Cancel-Nachrichten
+        entspricht dem (auch schon bei früheren XP-Versionen üblichen)
+        Verfahren über ausschließlich den Betreff-Header.  Bei FreeXP
+        wird dies zusätzlich über die ZC-konformen Header "STAT: CTL"
+        und "CONTROL: cancel [MsgID]" geregelt (wodurch auch ZConnect-
+        User canceln können), die aber von XP2 nicht unterstützt
+        werden.
+     c) Alle XP2-spezifischen Funktionen (Header "X-XP-Mode" für HdrOnly
+        und MsgID-Request, Parameter "-bBoxname" für die Auswertung des
+        Boxnamens bei der Konvertierung eingehender Nachrichten) werden
+        vom Enhanced UUZ unterstützt. :-)
+     d) Darüber hinaus gelten alle in dieser Dokumentation beschriebenen
+        Fixes, Änderungen und Erweiterungen für XP2 in gleichem Maße wie
+        für FreeXP.
+        Es ist allerdings darauf hinzuweisen, daß sich die vielfältigen
+        Änderungen, Korrekturen und Erweiterungen im Bereich der Deco-
+        dierung und Konvertierung von Zeichensätzen nur bei Singlepart-
+        Nachrichten auswirken, da Multipart-Nachrichten nicht vom UUZ,
+        sondern von XP selbst decodiert/konvertiert werden. Es kann
+        daher in Einzelfällen zu Inkonsistenzen kommen (d.h. derselbe
+        Text würde vom Enhanced UUZ u.U. anders und richtiger decodiert
+        und/oder konvertiert werden als er von XP2 in einer Multipart-
+        Nachricht decodiert/konvertiert wird).
+     e) Der Enhanced UUZ wurde mit folgenden XP2-Versionen erfolgreich
+        getestet:
+        CrossPoint [XP2] v3.30.020 Beta  (21.02.2001)
+        CrossPoint [XP2] v3.30.pre6      (27.12.2001)
+        CrossPoint [XP2] v3.30.pre7      (20.04.2002)
+        CrossPoint [XP2] v3.31.006       (20.04.2002)
+  UUZ.PAS, UUZ0.PAS
+
+MY+MW:
+- Zusätzlich zum Header "X-RFC-Converter:" werden Datum und Uhrzeit der
+  verwendeten UUZ-Version jetzt auch auf der Hilfeseite (Aufruf "uuz"
+  ohne Parameter) ausgegeben. In beiden Fällen wird dazu jetzt nicht
+  mehr der Zeitstempel der Datei verwendet (weil sich dieser durch
+  Entpack- und Kopiervorgänge verändern kann), sondern es wird der echte
+  Zeitpunkt der Compilierung fest eincompiliert, kann nicht mehr verän-
+  dert werden und erlaubt so eine sichere Indentifizierung der verwende-
+  ten UUZ-Version.
+  Dies geschieht über die neue Unit COMPDATE.PAS, die vom ebenfalls
+  neuen Hilfsprogramm GENDATE.PAS bei jeder via BUILD.BAT angestoßenen
+  Compilierung neu erzeugt wird und die aktuellen Datums- und Uhrzeit-
+  werte in Konstanten zur Verfügung stellt. Im Zuge dieser Änderung
+  wurde auch das Format des Datums umgestellt (von TT/MM/JJ auf
+  JJJJ/MM/TT).
+  Compilate, die aus der IDE der Entwicklungsumgebung von Borland Pascal
+  heraus erstellt wurden (z.B. zu Testzwecken), verwenden nach wie vor
+  den Zeitstempel der Datei, da dort das Verfahren mit der Unit
+  COMPDATE.PAS nicht funktionieren kann.
+  Das Eincompilieren des exakten Zeitpunkts der Compilierung wird später
+  auch bei anderen Programmen (XP, ZPR, ZFIDO, MAGGI usw.) Anwendung
+  finden.
+  UUZ0.PAS [+GENDATE.PAS, +COMPDATE.PAS]
+
+MY:
+- Optik-Fix: Da die Anzahl der verfügbaren UUZ-Optionen sowie ihre
+  Erläuterungen im Laufe der Zeit umfangreicher geworden sind und jetzt
+  auch der Compile-Timestamp in einer zusätzlichen Zeile ausgegeben wird
+  (siehe vorherige Änderung), passt die Ausgabe der Hilfeseite inklusive
+  des UUZ-Logos beim Standardwert von 25 Zeilen nicht mehr auf eine
+  Bildschirmseite. Die Ausgabe hält daher jetzt je nach aktueller
+  Zeilenanzahl rechtzeitig an und wartet auf einen Tastendruck.
+  UUZ0.PAS
+
+MY:
+- Fix (-zu): Bei der Übergabe des Zielverzeichnisses funktionierte die
+  Angabe eines relativen Pfades wie ".\" (= aktuelles Verzeichnis) oder
+  "..\" (= eine Verzeichnisebene höher) nicht, wenn dieser im Ergebnis
+  auf das Hauptverzeichnis des aktuellen Laufwerks verwies. Die Ursache
+  lag in der zentralen Routine 'IsPath()', die diesen Fall nicht geprüft
+  hat. Die Angabe relativer Pfade funktioniert jetzt in allen Fällen und
+  die Änderung wirkt sich auf alle Routinen in FreeXP insgesamt aus, die
+  'IsPath()' verwenden.
+  FILEIO.PAS
+
+MY:
+- Fix (-uz): Wenn beim manuellen Aufruf des UUZ (z.B. beim Testen) für
+  Quell- und Zieldatei versehentlich derselbe Dateiname angegeben wurde
+  und die Quelldatei existierte, wurde sie mit einer 0-Byte-Datei über-
+  schrieben und somit vernichtet (im XP2-Modus wurde hingegen der kon-
+  vertierte ZConnect-Puffer an die originale RFC-Nachricht angehängt,
+  was auch nicht zu einem viel sinnvolleren Ergebnis führt).
+  In beiden Fällen wird jetzt eine Fehlermeldung wegen einer "ungültigen
+  Zieldatei" ausgegeben. Der Test ist allerdings sehr simpel und prüft
+  nur auf Gleichheit der Strings - er läßt sich daher durch die Angabe
+  eines absoluten und eines relativen Pfades, die beide auf dasselbe
+  Verzeichnis verweisen, gewaltsam austricksen (wenn man das unbedingt
+  möchte). Mehr Aufwand ist an dieser Stelle nicht gerechtfertigt, weil
+  hier nur versehentliche Tippfehler im Test- oder Externbetrieb abge-
+  fangen werden sollen, die im Normalbetrieb mit FreeXP oder XP2 nicht
+  vorkommen können (und daher auch noch nie vorgekommen sind).
+  UUZ0.PAS
+
+MY:
+- Inkonsistenz beseitigt (-uz): Im Falle, daß ein Header mit identischer
+  Bedeutung in der RFC-Nachricht mehrfach existierte (sowas kommt z.B.
+  bei Software- oder Envelope-Headern schon mal vor), wurde per Design
+  der letzte vorkommende Header berücksichtigt. Handelte es sich dabei
+  jedoch um einen Header, der die max. Länge eines Pascal-Strings über-
+  schritt und daher im Array 'LongHdr' abgelegt werden mußte, hatte
+  jeweils der erste vorkommende Header "gewonnen" (Pointervariable wurde
+  in 'SaveLongHdr' nicht disposed, wenn sie bereits einen Wert hatte).
+  Jetzt wird in *beiden* Fällen der jeweils letzte vorkommende Header
+  berücksichtigt (außer, es gelten für den betreffenden Header irgend-
+  welche Sonderregeln).
+  UUZ0.PAS
+
+MY:
+- Unterstützung langer Header jetzt auch in zu-Richtung (ZConnect=>RFC):
+  ----------------------------------------------------------------------
+  Die bereits mit der ersten Fassung des Enhanced UUZ implementierte
+  Unterstützung für die verlustfreie Konvertierung beliebig langer Header
+  (bis 65500 Zeichen) in Richtung RFC=>ZConnect wurde jetzt auch auf die
+  umgekehrte Richtung ZConnect=>RFC erweitert. Derzeit werden folgende
+  Header unterstützt und sowohl in voller Länge gelesen als auch in die
+  RFC-Nachricht geschrieben:
+    Subject:      (ZConnect: "BET:")
+    Path:         (ZConnect: "ROT:")
+    X-Mailer:     (ZConnect: "MAILER:", "MAL:", "U-X-Mailer:",)
+    X-Newsreader: (ZConnect: "MAILER:", "U-X-Newsreader:",
+                             "U-User-Agent:")
+    Organisation: (ZConnect: "ORG:")
+    X-ZC-Post:    (ZConnect: "POST:")
+    X-ZC-Telefon: (ZConnect: "TELEFON:")
+    X-Homepage:   (ZConnect: "HOMEPAGE:", "U-X-Homepage:")
+    Summary:      (ZConnect: "ZUSAMMENFASSUNG:", "U-Summary:")
+    X-Gateway:    (ZConnect: "GATE:", "X-Gateway:")
+  Die Unterstützung beliebig langer Headerzeilen bezieht sich auf die
+  Länge des ZConnect-Quellheaders - Header, die bei ZConnect in mehrere
+  einzelne Zeilen aufgeteilt sind und bei RFC-Nachrichten in eine einzi-
+  ge (kommaseparierte) Headerzeile geschrieben werden müssen (z.B.
+  "EMP:"=>"To:", "KOP:"=>"Cc:", "STICHWORT:"=>"Keywords:"), waren hin-
+  sichtlich des Zielheaders in der RFC-Nachricht auch schon im bisheri-
+  gen Enhanced UUZ nicht mehr längenbegrenzt.
+  Im Zuge dieser Erweiterung bereitet die neue Routine 'WriteLongRfcHdr'
+  die Header für die schon bisher existierende Routine 'EncodeFoldQuote'
+  so auf und übergibt dieser den Header in einzelnen Teilstrings, daß
+  sie die nun beliebig langen Header in allen in der Praxis vorkommenden
+  Fällen korrekt codieren, falten und quoten kann (sofern erforderlich).
+  Dies ist allerdings nicht der Endzustand - 'EncodeFoldQuote' wird im
+  nächsten Schritt der UUZ-Entwicklung so erweitert werden, daß es die
+  Daten aus einem 64k-Array auch direkt verarbeiten kann, um auch die
+  theoretisch vorkommenden Fälle (z.B. Worte, die länger als 255 Zeichen
+  sind) korrekt behandeln zu können.
+  Aus diesem Grund werden hier auch einige - für die tägliche Praxis
+  völlig irrelevante - Temporärfixes in der Routine 'EncodeFoldQuote'
+  nicht näher dokumentiert.
+  Ebenfalls im Zuge dieser Erweiterung berücksichtigt wurde der - den
+  meisten Usern vermutlich gar nicht bekannte - Mechanismus, über die
+  erste Zeile einer Datei 'ADDPATH' im UUZ-Verzeichnis einen eigenen
+  Pfad erzeugen und in zu-Richtung dem "Path:"-Header voranstellen zu
+  können. Dies funktioniert jetzt auch mit beliebig langen Pfadzeilen im
+  ROT:-Header des zu konvertierenden ZConnect-Puffers.
+  UUZ.PAS, UUZ0.PAS, XPMAKEHD.INC
+
+MY:
+- Behandlung der Header "X-Gateway:" und "GATE:" geändert:
+  (Quelle zu diesem Thema:
+   http://www.dt.e-technik.uni-dortmund.de/~ma/gatebau97/Gb97/node2.html)
+  -uz: Der Header "X-Gateway:" wird in RFC=>ZC-Richtung jetzt in den
+       GateBau'97-konformen Header "GATE:" konvertiert (bisher behielt
+       er die ursprüngliche Bezeichnung aus der RFC-Nachricht bei).
+  -zu: Die Header "GATE:" und "X-Gateway:" werden in ZC=>RFC-Richtung
+       jetzt in den Header "X-Gateway:" konvertiert (bisher wurden sie
+       komplett ignoriert). Sollte eine ZConnect-Nachricht beide Header
+       enthalten, hat der Header "GATE:" Vorrang vor "X-Gateway:". Diese
+       Behandlung in zu-Richtung findet allerdings nur dann statt, wenn
+       die Datei 'ADDGATE' im UUZ-Verzeichnis existiert und ihre erste
+       Zeile nicht leer ist (siehe nächste Änderung unten). Sie ist nur
+       für echten Gatebetrieb von Bedeutung und für XP-User irrelevant;
+       im Normalbetrieb mit XP (und/oder wenn die Datei 'ADDGATE' nicht
+       existiert) werden die Header "GATE:" bzw. "X-Gateway:" in
+       zu-Richtung wie bisher ignoriert.
+  UUZ.PAS, UUZ0.PAS, XPMAKEHD.INC
+
+MY:
+- Über die erste Zeile der Datei 'ADDGATE' im UUZ-Verzeichnis kann jetzt
+  eine Gateway-Domain definiert werden, die in folgender Form dem Inhalt
+  eines etwaig existierenden Headers "X-Gateway:" (RFC=>ZC) bzw. "GATE:"
+  oder ebenfalls "X-Gateway:" (ZC=>RFC) vorangestellt wird:
+  - RFC=>ZC: "RFC1036/2822/2047 <Domain> [<UUZ-Version>]"
+  - ZC=>RFC: "ZCONNECT <Domain> [<UUZ-Version>]"
+  Existiert in der Quellnachricht kein Header "X-Gateway:" bzw. "GATE:",
+  wird er in der Zielnachricht neu erzeugt; anderenfalls wird der zu-
+  sätzliche Eintrag vom bereits existierenden Headerinhalt mit einem
+  Komma separiert.
+  Die Gesamtlänge des hinzuzufügenden Gateway-Strings ist derzeit auf
+  120 Zeichen begrenzt. Hinsichtlich der Header in Quell- und Zielnach-
+  richt werden jedoch beliebig lange Zeilen (bis 65500 Zeichen) unter-
+  stützt.
+  Diese Erweiterung ist nur für echten Gatebetrieb von Bedeutung und für
+  XP-Anwender daher irrelevant (genauer gesagt: XP-Anwender sollten die
+  Verwendung dieser Funktion unbedingt vermeiden, um keine unsinnigen
+  und falschen Gateway-Header zu erzeugen).
+  UUZ.PAS, UUZ0.PAS, XPMAKEHD.INC
+
+MY:
+- Fix (-uz): Erkennung von Text-/Binärnachrichten komplett überarbeitet
+  ----------------------------------------------------------------------
+  Anläßlich eines ausschließlich aus Textteilen bestehenden, aber
+  dennoch im Header "Content-Transfer-Encoding:" als "binary" deklarier-
+  ten Newsletters von T-Online im MIME-Multipart-Format, dessen konver-
+  tierter ZConnect-Puffer infolgedessen vom UUZ mit dem ZConnect-Header
+  "TYP: BIN" und daher in XP mit dem Flag "B" versehen und dort auch als
+  Binärnachricht behandelt wurde, wurde deutlich, daß die bisherigen
+  Regeln für die Klassifizierung als Text- oder Binärnachricht untaug-
+  lich bzw. schlicht falsch waren. Die Erkennung als Text- oder Binär-
+  nachricht wird daher jetzt nur noch ausschließlich vom Inhalt des
+  Headers "Content-Type:" abhängig gemacht:
+  a) Alle Nachrichten vom "Media Type" text/*, multipart/* und message/*
+     (ergänzt wurde message/*) gelten als Textnachrichten (UUZ erzeugt
+     keinen "TYP:"-Header). Im Falle der "Composite Media Types"
+     multipart/* und message/* ist das deswegen richtig, weil die
+     Nachricht bzw. ihre Bestandteile zwar (codierte) binäre Komponenten
+     - auch gemischt mit Textkomponenten - enthalten kann, diese aber
+     nicht vom UUZ, sondern erst später in XP selbst beim Öffnen oder
+     Extrahieren des jeweiligen Nachrichtenteils behandelt und ggf.
+     decodiert werden.
+  b) Demzufolge gelten als Binärnachrichten nur noch alle Singlepart-
+     Nachrichten vom "Media Type" application/*, image/*, audio/*,
+     video/* und model/* (UUZ erzeugt den Header "TYP: BIN").
+  c) Keinen Einfluß auf die Klassifizierung als Text- oder Binärnach-
+     richt mehr haben hingegen die Deklarationen "binary", "base64" oder
+     "quoted-printable" im Header "Content-Transfer-Encoding:": Es
+     handelt sich hierbei um die Transportcodierung, die keinerlei
+     Rückschlüsse auf den Typ der Nachricht (Text oder Binär) zuläßt.
+     Bisher konnte es aufgrund der unvollständigen Prüfung auf "base64"
+     und "binary" fälschlicherweise vorkommen, daß einerseits qp-codier-
+     te Binärnachrichten als Textnachrichten, andererseits aber base64-
+     codierte oder als "binary" deklarierte Text- oder Multipart-Nach-
+     richten als Binärnachrichten erkannt wurden.
+  d) Anmerkung zur Deklaration "Content-Transfer-Encoding: binary":
+     Obwohl der Header den Schluß nahelegt (und prinzipiell auch dafür
+     gedacht ist), es handele sich hierbei um uncodierte Binärdaten und
+     die Nachricht sei daher als Binärnachricht zu klassifizieren, ist
+     der Transport uncodierter Binärdaten im RFC-Raum bisher weder
+     standardisiert noch findet er in der Praxis statt (siehe Abschnitt
+     6.2. in RFC2045). Es gibt derzeit keine Umstände, unter denen die
+     Deklaration "binary" gültig wäre, daher ist sie zu ignorieren bzw.
+     wie "8bit" zu behandeln. Der UUZ ist, da er in uz-Richtung seit
+     jeher ausschließlich zeilenorientiert arbeitet, auf die korrekte
+     Behandlung eingehender uncodierter Binärdaten auch gar nicht ausge-
+     legt und die Lese- und Schreibroutinen müßten umfassenden Änderun-
+     gen unterzogen werden, um die (beabsichtigte) Ersetzung von Zeilen-
+     umbrüchen (LF=>CRLF) und die damit verbundene Veränderung uncodier-
+     ter Binärdaten zu verhindern - aber selbst dann würden diese Daten
+     immer noch und in gleicher Weise von SMTP/NNTP-Clients wie UKAW
+     unbrauchbar gemacht werden, noch bevor der UUZ sie überhaupt zu
+     Gesicht bekäme - ein Umbau des UUZ in dieser Hinsicht ist auf
+     absehbare Zukunft also weder notwendig noch sinnvoll.
+  e) Die Variablen 'mpart' und 'binaer' werden jetzt nicht mehr an drei
+     verschiedenen Stellen gesetzt, sondern nur noch einmal zentral in
+     der Routine 'MimeAuswerten'.
+  Die beschriebenen Änderungen führen in der Praxis u.a. dazu, daß beim
+  Beantworten von bisher fälschlicherweise als Binärnachricht erkannten
+  Textnachrichten keine überflüssige Rückfrage mehr erfolgt, ob man
+  die vermeintliche Binärnachricht wirklich quoten wolle (umgekehrt
+  erfolgt die Rückfrage jetzt bei qp-codierten Binärnachrichten, wo sie
+  bisher unterblieben wäre). Des weiteren findet bei bisher fälsch-
+  licherweise als Binärnachricht erkannten Singlepart-Textnachrichten
+  jetzt die erforderliche Zeichensatzkonvertierung statt, und es ist
+  sichergestellt, daß das weiter oben beschriebene Anhängen von Zeilen-
+  umbrüchen (CRLF) an das Ende eines ZConnect-Puffers im Bedarfsfall nur
+  noch bei echten (dafür jetzt aber auch bei *allen*) Textnachrichten
+  erfolgt.
+  Zwingend notwendig waren diese Änderungen aber auch noch aus einem
+  anderen Grund: Da der UUZ ZConnect-Nachrichten mit dem Header
+  "TYP: BIN" konsequent als Binärnachrichten betrachtet, hat er folge-
+  richtig bei einer ZC=>RFC-Konvertierung den kompletten Body der
+  erzeugten RFC-Nachricht base64-codiert. Im Falle von als "binary"
+  deklarierten Multipart-Nachrichten führte also eine unmittelbar auf-
+  einanderfolgende RFC=>ZC=>RFC-Konvertierung dazu, daß die Struktur der
+  Multipart-Nachricht vollständig zerstört wurde.
+  UUZ.PAS, UUZ0.PAS
+
+MY:
+- Interne Änderung: Die bisher nur in zu-Richtung und jetzt auch in
+  uz-Richtung (siehe unten) verwendete globale Variable 'convibm' wurde
+  nach 'convcharset' umbenannt.
+  UUZ.PAS, UUZ0.PAS
+
+MY:
+- Fix (-uz): Die bisherige Regel, daß alle Multipart-Nachrichten sowie
+  Singlepart-Nachrichten vom "Subtype" */html keiner Zeichensatzkonver-
+  tierung seitens des UUZ unterzogen werden, wurde auf folgende Content-
+  Types erweitert:
+  a) message/* - ähnlich wie multipart/* ein "Composite Media Type", der
+     eine RFC-Nachricht, die ihrerseits aus mehreren Teilen bestehen
+     kann, enthält. Die Zeichensatzkonvertierung würde das Original-
+     format der Nachricht zerstören. (Evtl. ist eine spätere direkte
+     Unterstützung dieses speziellen Content-Type in FreeXP vorgesehen.)
+  b) */richtext und */enriched (RTF, siehe RFC1896) - ähnlich wie */html
+     ein Format, das von XP nicht selbst interpretiert und konvertiert
+     wird und daher zur korrekten Darstellung ebenfalls an ein externes
+     Programm übergeben werden muß. Umlaute und Sonderzeichen würden
+     nach einer Konvertierung in den IBM-Zeichensatz nicht mehr richtig
+     dargestellt werden können.
+  Intern wird die Entscheidung über die Zeichensatzkonvertierung jetzt
+  einmal zentral in der Routine 'MimeAuswerten' getroffen und in der
+  globalen Variablen 'convcharset' gespeichert, die dann an den jewei-
+  ligen Stellen ausgewertet wird (statt wie bisher die Entscheidung
+  mehrfach und jedes Mal neu - und teilweise nach unterschiedlichen
+  Kriterien - zu treffen).
+  UUZ.PAS, UUZ0.PAS
+
+MY:
+- Weitere Fixes und Änderungen bei der Auswertung und Erzeugung des
+  Headers "(U-)Content-Type:":
+  ----------------------------------------------------------------------
+  Zwar wurden Singlepart-Nachrichten vom Subtyp */html bei der RFC=>ZC-
+  Konvertierung keiner Zeichensatzkonvertierung unterzogen, aber auf den
+  eigentlich zwingend logischen Gedanken, daß man solche Nachrichten in
+  ZC=>RFC-Richtung dann ebenfalls keiner Zeichensatzkonvertierung unter-
+  ziehen darf, schien bisher niemand gekommen zu sein.
+  Des weiteren wurden Textnachrichten ungeachtet des tatsächlichen und
+  aus dem Header "U-Content-Type:" klar ersichtlichen Subtyps pauschal
+  als "text/plain" deklariert, und der MIME-Typ message/* wurde gleich
+  völlig ignoriert und daher ebenfalls als "text/plain" deklariert.
+  Ergebnis waren gnadenlos kaputtkonvertierte und grundfalsch dekla-
+  rierte Nachrichten. :-(
+  Zur Ehrenrettung muß man zwar hinzufügen, daß sich dieses Verhalten im
+  Normalbetrieb mit XP nicht auswirkte, weil XP weder HTML-Nachrichten
+  noch den MIME-Typ message/* erzeugt, aber XP-Anwender, die den UUZ aus
+  verschiedensten Gründen für eine RFC=>ZC=>RFC-Konvertierung einsetzen
+  (solche Fälle sind aus der Realität bekannt) und Gatebetreiber wurden
+  mit defekten Nachrichten "belohnt".
+  Es wurden daher folgende Gegenmaßnahmen ergriffen:
+  -uz: Singlepart-Textnachrichten vom Subtyp */html, */richtext und
+       */enriched werden nicht nur wie oben beschrieben keiner Zeichen-
+       satzkonvertierung mehr unterzogen, sondern es wird auch ein ggf.
+       im Header "Content-Type:" deklarierter Zeichensatz in den
+       ZConnect-Header "CHARSET:" geschrieben (wobei, sofern möglich,
+       der Zeichensatzname in die ZConnect-typische Bezeichnung ("ISO1",
+       "ISO9" usw.) übersetzt wird). Dadurch alleine ist bei einer nach-
+       folgenden Konvertierung in ZC=>RFC-Richtung bereits garantiert,
+       daß keine Zeichensatzkonvertierung mehr stattfindet (siehe Erläu-
+       terungen weiter oben zu den umfassenden Änderungen und Erweite-
+       rungen zum Thema Zeichensatzauswertung und -behandlung von
+       ZConnect-Nachrichten).
+       Das Erzeugen des Headers "CHARSET:" hat übrigens auch den ange-
+       nehmen Nebeneffekt, daß beim Lesen solcher Nachrichten wenigstens
+       die im Text vorhandenen 8bit-Zeichen in den IBM-Zeichensatz kon-
+       vertiert und dadurch lesbar dargestellt werden - und vielleicht
+       spendiert ja doch nochmal jemand einen einfachen HTML-Parser für
+       FreeXP, dann könnten solche HTML-only-Nachrichten sogar dort
+       halbwegs brauchbar verarbeitet werden...
+  -zu: Sollte bei einer Singlepart-Nachricht vom Subtyp */html,
+       */richtext oder */enriched kein Zeichensatz deklariert gewesen
+       sein, existiert auch der ZConnect-Header "CHARSET:" nicht, und
+       die Nachricht würde normalerweise der Standardkonvertierung in
+       den Zeichensatz ISO-8859-1 unterzogen werden. Dieses wird jetzt
+       ebenfalls gezielt verhindert, denn auch solche Nachrichten können
+       natürlich 8bit-Zeichen enthalten, die bei einer Konvertierung
+       zerstört würden. Es wird allerdings trotz des Vorkommens von
+       8bit-Zeichen kein Zeichensatz deklariert (nicht einmal bei Ver-
+       wendung des Schalters "-chkbody"), weil dieser schlicht nicht
+       bekannt ist.
+       Gleichzeitig wird der Subtyp solcher Nachrichten jetzt korrekt
+       deklariert, eine Nachricht vom MIME-Typ "text/enriched" oder
+       "text/html" wird jetzt also nicht mehr kurzerhand zu "text/plain"
+       umdeklariert.
+       Dasselbe gilt folgerichtig jetzt auch für Nachrichten vom MIME-
+       Typ message/*: Es findet keine Zeichensatzkonvertierung mehr
+       statt und der MIME-Typ im Header "Content-Type:" wird korrekt
+       beibehalten (eine etwaige Zeichensatzdeklaration im äußeren
+       "Content-Type:"-Header ist hier irrelevant und dürfte gar nicht
+       vorkommen).
+  UUZ.PAS, UUZ0.PAS
+
+MY:
+- Optik-Fix (-uz): Bei der im Falle eines nicht unterstützten Zeichen-
+  satzes erzeugten Fehlermeldung "ERR: Unsupported character set:" wird
+  der Name des Zeichensatzes jetzt in der Schreibweise, wie sie im
+  Header "Content-Type:" der RFC-Nachricht verwendet wurde, wiedergege-
+  ben (statt wie bisher in Kleinschreibung).
+  Im Falle, daß ohnehin keine Zeichensatzkonvertierung stattfindet, weil
+  eines der oben beschriebenen Kriterien erfüllt ist (MIME-Multipart
+  o.ä.) wird der Header erst gar nicht mehr erzeugt.
+  UUZ0.PAS
+
+MY:
+- Fix (-uz): Der Enhanced UUZ fängt jetzt unzulässige Deklarationen im
+  Header "Content-Transfer-Encoding:" ab: Da bei den "Composite Media
+  Types" multipart/* und message/* nur "7bit", "8bit" und "binary" als
+  Transportcodierung im äußeren "Content-Transfer-Encoding:"-Header
+  zulässig sind, wird jede unzulässige Deklaration wie "base64" oder
+  "quoted-printable" jetzt ignoriert, die Nachricht wie "8bit" behandelt
+  und daher nicht decodiert (bisher wurden in diesem Fall einzelne
+  Nachrichtenteile im Body, deren Codierung zufällig mit der im äußeren
+  "Content-Transfer-Encoding:"-Header deklarierten Codierung identisch
+  war, fälschlicherweise decodiert).
+  Für einzelne Subtypes des MIME-Typs message/* existieren noch restrik-
+  tivere Einschränkungen hinsichtlich der zulässigen Codierungen; da UUZ
+  "7bit", "8bit" und "binary" aber ohnehin gleichbehandelt (nämlich nur
+  liest und nicht decodiert), müssen diese nicht gesondert berücksich-
+  tigt werden.
+  UUZ0.PAS
+
+MY:
+- Interne Änderung (-zu): Lokale Variable 'binmail' in 'ZtoU' entsorgt;
+  stattdessen wird jetzt die bisher nur in uz-Richtung verwendete
+  globale Variable 'binaer' eingesetzt und ebenso wie die Variable
+  'mpart' nun einmal zentral in der Routine 'SetMimeData' gesetzt (statt
+  wie bisher außerhalb an zwei verschiedenen Stellen). 'binaer' ist
+  jetzt wieder true, wenn typ='B' (nicht wenn typ<>'T').
+  UUZ.PAS, UUZ0.PAS
+
+MY:
+- Bei Binärnachrichten wird jetzt auch für Singleparts (= Schalter
+  "Binärnachrichten als 'MIME-Multipart-Attachments'" unter C/O/E/V
+  deaktiviert) der Header "Content-Disposition:" gemäß RFC2183 mit den
+  Parametern "attachment", Dateiname ("filename="), Dateidatum
+  ("modification-date=") und jetzt auch Dateigröße ("size=") erzeugt.
+  Daher entfallen die bisherigen (und nicht standardkonformen) Parameter
+  "name=" und "x-date" im Header "Content-Type:" sowohl bei Singlepart-
+  als auch bei Multipart-Attachments - bei letzteren waren diese Angaben
+  ohnehin redundant, da bei vom UUZ erzeugten Multipart-Binaries schon
+  immer ein innerer Header "Content-Disposition:" mit den genannten
+  Parametern - vom neuen Parameter "size=" abgesehen - erzeugt wurde.
+  UUZ.PAS
+
+MY:
+- (-zu): MIME-Boundary (wird bei der Konvertierung von mit "i" auf
+  Userbrett in XP erzeugten Binärnachrichten in eine Multipart-Nachricht
+  erzeugt) an die in den MIME-Multipart-Routinen von FreeXP verwendete
+  Fassung angeglichen und als eigene Funktion nach mimedec.pas verlagert
+  (zwecks späterer Verwendung auch in FreeXP). Das Boundary hat jetzt
+  die Form "-==_FreeXP_Next_MIME_Part_[Zufallsstring]_==-".
+  UUZ.PAS, UUZ0.PAS, MIMEDEC.PAS
+
+MY:
+- Interne Änderung (-zu/uz): Länge des MIME-Boundaries im Record
+  'header' von 70 auf 100 Zeichen erhöht und damit an die Länge im
+  Record 'mimedata' angepaßt.
+  UUZ0.PAS, XP0.PAS, XPMAKEHD.INC
+
+MY:
+- Fix (-zu): Bei MIME-Nachrichten vom Typ multipart/related werden jetzt
+  gemäß RFC2387 die bisher schlicht unterschlagenen Parameter "start="
+  und "start-info" beachtet und in den neu erzeugten äußeren "Content-
+  Type:"-Header geschrieben.
+  UUZ.PAS, UUZ0.PAS, XPMAKEHD.INC
+
+MY:
+- Fix (-zu): Beim Schreiben des äußeren "Content-Type:"-Headers von
+  Multipart-Nachrichten wird jetzt die Länge des Typs, des Boundary-
+  Delimiters und weiterer etwaiger Parameter beachtet und der Header bei
+  Bedarf (d.h. wenn er länger als 78 Zeichen würde) gefaltet. Bisher
+  wurden alle Parameter ungeachtet der Gesamtlänge grundsätzlich in eine
+  einzige Zeile geschrieben (was auch zu Zeichenverlust führen konnte).
+  Da der Header "Content-Type:" samt seiner vielfältigen Parameter in
+  einer eigenen Routine verarbeitet wird, läuft er nicht wie andere
+  Header durch die Routine 'EncodeFoldQuote', die diese Behandlung auto-
+  matisch vorgenommen hätte.
+  UUZ.PAS
+
+MY:
+- Bezeichnung des Schalters "-gate" (-zu) in "-chkbody" geändert:
+  Da im Verlaufe der Entwicklung und der praktischen Anwendung des
+  Enhanced UUZ der Schalter "-gate", der den Body von ZConnect-Nachrich-
+  ten auf das Vorkommen von 8bit-Zeichen prüft und dabei fehlerhafte
+  Deklarationen von Zeichensatz und Transportcodierung repariert, seine
+  ursprüngliche, rein gate-typische Bedeutung verloren hat und auch im
+  XP-Umfeld zum Einsatz kommt (speziell im Betrieb mit UKA_PPP, wo er
+  unbedingt zu empfehlen, sowie mit XP2, wo er ohnehin Default ist),
+  wurde die etwas irreführende Bezeichnung "-gate" in die wesentlich
+  treffendere und aussagekräftigere Bezeichnung "-chkbody" geändert (im
+  Sinne der Abwärtskompatibilität funktioniert die Angabe von "-gate"
+  aber nach wie vor).
+  Alle früheren Referenzen in diesem Dokument auf den Schalter "-gate"
+  wurden in "-chkbody" geändert.
+  UUZ.PAS, UUZ0.PAS
+
+MY:
+- Im Zusammenhang mit der vorstehenden Änderung wird die Erzeugung des
+  Headers "X-XP-Version:" bei der ZC=>RFC-Konvertierung jetzt auch nicht
+  mehr vom Schalter "-gate" (bzw. jetzt "-chkbody") abhängig gemacht,
+  sondern als Merkmal für echten Gatebetrieb dient jetzt ausschließlich
+  die Existenz einer nicht-leeren ersten Zeile in der Datei 'ADDGATE' im
+  UUZ-Verzeichnis (siehe dazu weiter oben). Nur wenn diese existiert,
+  wird der Header "X-XP-Version:" nicht mehr erzeugt.
+  Es ist absolut zu vermeiden, die Erzeugung des Headers "X-XP-Version:"
+  im Normalbetrieb mit XP damit verhindern zu wollen, daß man die Datei
+  'ADDGATE' mit einer nicht-leeren ersten Zeile erzeugt - es würden dann
+  speziell bei ausgehenden RFC-Nachrichten völlig falsche und unsinnige
+  Header "X-Gateway:" erzeugt werden.
+  Der Header "X-XP-Version:" wird in absehbarer Zeit voraussichtlich
+  ohnehin wieder eliminiert werden, sobald dessen Notwendigkeit nach
+  Lage der Dinge nicht mehr gegeben ist.
+  UUZ.PAS
+
+MY:
+- Fix (-uz): Wenn der allererste (auf die mit "From ..." beginnende
+  erste Zeile folgende) RFC-Header einer UUCP-Mail zu den Headern
+  gehörte, die mit dem Prefix "U-" in die ZConnect-Nachricht geschrieben
+  werden (z.B. "X-Envelope-To:" => "U-X-Envelope-To:"), dann wurde die
+  Headerbezeichnung - bis auf das erste Zeichen - in Kleinschreibung
+  übernommen. Jetzt wird die Originalschreibweise verwendet.
+  UUZ.PAS
+
+MY:
+- Sub-Versionsnummer für den UUZ eingeführt, die auf der UUZ-Hilfeseite
+  und im Header "X-RFC-Converter:" hinter der Hauptversionsnummer von XP
+  ausgegeben wird. Da die Entwicklung von FreeXP und des UUZ nicht
+  zwangsläufig synchron verlaufen, lassen sich so die jeweiligen UUZ-
+  Versionen besser voneinander unterscheiden (statt wie bisher nur am
+  Dateidatum identifiziert werden zu können).
+  UUZ0.PAS
+
+MY:
+- Aufgrund der Fülle und Relevanz der Änderungen, Fixes und Erweiterun-
+  gen dieser neuen Version (oder Generation?) des Enhanced UUZ wurde der
+  'Marketingname' des Programms zwecks leichterer Unterscheidung zum
+  Vorgänger (z.B. in Newsgroup-Diskussionen o.ä.) in "Enhanced UUZ/II"
+  geändert (abgekürzt "E-UUZ/II").
+  UUZ0.PAS
 
   5.   Beteiligte Entwickler und geänderte Dateien
   ------------------------------------------------
@@ -1080,12 +2793,28 @@
   erfolgreich abgeschlossen werden können (Reihenfolge alphabetisch und
   ohne Anspruch auf Vollständigkeit):
 
-  Johann Addicks   - Tests, ZC/Gate-Konformität
-  Frank Ellermann  - RFC-Recherche und -Interpretation (Mail)
-  Urs Janßen       - RFC-Recherche und -Interpretation (News)
-  Joachim Merkel   - RFC/ZC-Konformität, Tests, Designfragen
-  Dirk Nimmich     - RFC-Recherche und -Interpretation (Mail/News)
-  Sebastian Weiser - RFC-Recherche und -Interpretation (Mail)
+  Johann Addicks     - Tests, ZC/Gate-Konformität
+  Frank Ellermann    - RFC-Recherche und -Interpretation (Mail)
+  Urs Janßen         - RFC-Recherche und -Interpretation (News)
+  Joachim Merkel     - RFC/ZC-Konformität, Tests, Designfragen
+  Dirk Nimmich       - RFC-Recherche und -Interpretation (Mail/News)
+  Sebastian Weiser   - RFC-Recherche und -Interpretation (Mail)
+  Johann Addicks     - Diverse Anregungen (z.B. Charset-Fallback,
+                       Gateway-Header und -Domain)
+  Oliver Gampe       - Erstmalige Erkennung des Problems bei der Deco-
+                       dierung von Multibyte-Zeichensätzen (UTF-7/8)
+  Joachim Merkel     - Analysen im Zusammenhang mit dem gemeinsamen
+                       Betrieb von Enhanced UUZ und UKA_PPP
+  Hans-Jürgen Tänzer - Erkennung diverser Bugs und Anregung, den echten
+                       Compilierungszeitpunkt fest zu verdrahten
+                    ┐
+  Uwe Morgener      │
+  Franklin Schiftan ├─ Testen der Kompatibilität mit XP2
+  Jörg Tewes        │
+                    ┘
 
   FreeXP bedankt sich bei allen genannten und nicht genannten
-  Beteiligten.
+  Beteiligten. Und alle hier nicht namentlich genannten Anwender des
+  Enhanced UUZ, die durch ihr Feedback zu einer weiteren Verbesserung
+  des Programms beigetragen haben.
+
Index: freexp/doc/xpoint.dq
===================================================================
RCS file: /server/cvs/freexp/doc/xpoint.dq,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- freexp/doc/xpoint.dq	25 Oct 2005 12:27:10 -0000	1.13
+++ freexp/doc/xpoint.dq	28 Oct 2005 11:48:17 -0000	1.14
@@ -8308,6 +8308,20 @@
 Ein bei Config/Modem/... eingetragener Modem-Exit-Befehl wird bei Fido-Netcalls oder
 bei abgebrochenen Netcalls nicht ausgeführt.
 
+
+>>|
+■ Datenbankprobleme
+
+Unter Windows XP kommt es reproduzierbar bei der Benutzung von Nachricht/Direkt
+mit anschließendem Ändern des Empfängers (beide Empfänger sind noch nicht in der
+Datenbank enthalten) zu einem Crash des Programms. Die Fehlermeldung bei diesem
+Crash deutet auf einen Datenbankfehler hin, der allerdings nicht wirklich aufgetretten
+ist. Die genaue Problemursache ist unbekannt. Es ist aber bekannt das das Problem
+nicht unter allen Betriebsystemen gleichermassen auftritt (Windows 98/ME ist
+nicht betroffen).
+
+<<|
+
 >>FF
 K.  Versionsgeschichte
 ────────────────────────────────────────────────────────────────────



Mehr Informationen über die CVS-List Mailingliste