+- UUZ_ENH.TXT ----------------------------------------------+
| |
| Vollständige Dokumentation aller Änderungen |
| des "Enhanced UUZ" seit dem 28.04.2002 |
| (c) 2003 FreeXP |
| 30.08.2003 |
+------------------------------------------------------------+
+-------------------------+
| 09.07.2002-24.05.2003 |
+-------------------------+
MY:
- Umfassendes Redesign und zu wesentlichen Teilen Rewrite des
RFC-Konvertierers UUZ (=> "Enhanced UUZ")
=============================================================
1. Euro-Support
-----------------
1.1. Eingehende Nachrichten (RFC => ZConnect)
----------------------------------------------
JG+MY:
- Bei Nachrichten, die ein Euro-Symbol enthalten, wird dieses in
Headern und Body jetzt in das CP437-Zeichen "ε" (kleines griechi-
sches Epsilon, #238) konvertiert, statt wie bisher als Zeichenwert
1:1 durchgereicht zu werden (wodurch man je nach Zeichensatz ein
"ñ", "Ç", "╒" oder "x" beim Lesen im Lister sah).
Dabei werden die folgenden Euro-fähigen Zeichensätze bzw.
Codierungen unterstützt:
ISO-8859-15 (Euro-Symbol auf Pos. #164)
Windows-1252 (Euro-Symbol auf Pos. #128)
CP858 (Euro-Symbol auf Pos. #213)
UTF-7 (Unicode-Zeichen)
UTF-8 (Unicode-Zeichen)
JG+MY:
- Manche Mail-/Newsreader (speziell Outlook Express) deklarieren
mitunter gar keinen oder den Zeichensatz ISO-8859-1, verwenden in
Wirklichkeit aber den Zeichensatz Windows-1252 und daher den Euro
dort auch auf Pos. 128. Daher wird auch bei Nachrichten ohne
Zeichensatzdeklaration oder im Zeichensatz ISO-8859-1 das dort
eigentlich reservierte Zeichen #128 in das griechische Epsilon
konvertiert, obwohl dieses Vorgehen strenggenommen nicht 100%ig
korrekt ist. UUZ hatte aber im Sinne der Fehlertoleranz schon immer
"OjE-Fixes" dieser Art, insofern ist dieses Vorgehen nur konsequent.
In allen nach diesem "Enhanced UUZ" erscheinenden FreeXP-Versionen
wird das griechische Epsilon im Vollbild und im DOS-Fenster optional
als echtes Euro-Symbol dargestellt werden können. Selbst wenn man
diese Option nicht aktiviert oder den UUZ gar nicht zusammen mit XP
einsetzt, ist das griechische Epsilon einem Euro-Symbol (das auf Basis
eben dieses Epsilon entwickelt wurde) sehr viel ähnlicher als ein "ñ",
"Ç", "╒" oder "x" und diese geänderte Konvertierung des Euro-Symbols
im Sinne einer korrekteren Transliteration daher letztlich als Bugfix
zu werten.
1.2. Ausgehende Nachrichten (ZConnect => RFC)
----------------------------------------------
JG+MY:
- Das Zeichen #238 in CP437 (kleines griechisches Epsilon) wird als
Euro-Symbol interpretiert und in das Zeichen #164 im Zeichensatz
ISO-8859-15 konvertiert; der Zeichensatz wird mittels des von XP
erzeugten Headers "X-Charset: ISO-8859-15" automatisch korrekt im
entsprechenden MIME-Header "Content-Type:" deklariert.
MY:
- Da dies bei einer "extern" (= nicht im Betrieb mit XP) stattfinden-
den Konvertierung von Nachrichten, die nicht von XP erzeugt wurden
und bei denen mangels eines "X-Charset:"-Headers auch eine fehler-
hafte Zeichensatz-Deklaration erfolgen würde, evtl. nicht gewünscht
ist, kann diese Euro-Unterstützung mit dem neuen Schalter "-noEuro"
deaktiviert werden. Das kleine Epsilon wird dann entsprechend der
IBM=>ISO1-Tabelle in ein "e" konvertiert. Dabei wird auch ein
"falsch" deklarierter Zeichensatz ISO-8859-15 in einem eventuellen
"X-Charset:"-Header nach ISO-8859-1 korrigiert.
Wenn die Euro-Unterstützung für ausgehende Nachrichten im Extern-
betrieb jedoch gewünscht ist, sollte unbedingt der Schalter "-gate"
gesetzt werden (siehe weiter unten). Nur dann ist sichergestellt,
daß der Zeichensatz auch dann korrekt deklariert wird, wenn die
Nachricht das als Euro-Symbol interpretierte Epsilon "ε" enthält.
Hinweis: Der Schalter "-noEuro" kann nicht von XP aus gesetzt werden
und ist daher nur im Externbetrieb nutzbar.
2. Allgemeine Änderungen und Korrekturen
------------------------------------------
2.1. Eingehende Nachrichten (RFC => ZConnect)
----------------------------------------------
MY:
- Fix: Zeichensatz-Konvertiertabellen ISO=>IBM komplett überarbeitet,
Änderungen und Korrekturen bei fast 50 Zeichen vorgenommen (siehe
Tabellen in MIMEDEC.PAS):
1. Prinzipiell werden Zeichen, die im IBM-Zeichensatz nicht existie-
ren, statt nach optischen Kriterien jetzt danach konvertiert, wie
sie ausgesprochen werden bzw. welche Bedeutung ein Symbol hat. So
werden z.B. die Zeichen #222 und #254 in ISO-8859-1 (großer und
kleiner Buchstabe "Thorn") nicht mehr in ein "P" bzw. "p" konver-
tiert, nur weil das mit viel Phantasie halbwegs ähnlich aussieht,
sondern in ein "T" bzw. "t".
2. Unkonvertierbare Zeichen, für die es keine sinnvolle Translitera-
tion im IBM-Zeichensatz gibt, werden jetzt in das Blockgrafik-
zeichen #177 konvertiert, statt als Zeichenwert 1:1 durchgereicht
zu werden. So muß man nicht mehr rätseln, ob es sich bei dem
Zeichen, das man sieht, wirklich um ein korrekt konvertiertes
oder doch nur um ein nicht konvertierbares Zeichen handelt.
ToDo: "Multichar-Konvertierung" für bestimmte Zeichen und Symbole
----- implementieren (z.B. Trademark-Symbol => "tm", Thorn => "Th")
JG:
- Unicode-Unterstützung (UTF-7 und UTF-8) für den von XP lokal verwen-
deten Zeichensatz CP437 erweitert: Alle 75 Zeichen, die in CP437,
nicht aber in ISO-8859-1 existieren (z.B. Block- und Rahmengrafik-
zeichen), werden jetzt von UTF-7/8 direkt in das entsprechende
Zeichen aus CP437 korrekt konvertiert, statt wie bisher durch ein
Fragezeichen repräsentiert zu werden.
JG+MY:
- Unterstützung des Zeichensatzes ISO-8859-15 (ISO-8859-1 mit Euro-
Symbol und einigen anderen Abweichungen) implementiert.
MY:
- Unterstützung weiterer Zeichensätze implementiert:
ISO-8859-2 (osteuropäische Variante von ISO-8859-1)
ISO-8859-9 (türkische Variante von ISO-8859-1)
CP850 (DOS-Codepage 850)
CP858 (DOS-Codepage 850 mit Euro-Symbol)
Es werden alle bei der IANA registrierten Aliasnamen dieser Zeichen-
sätze unterstützt.
MY:
- Einige IANA-Aliasnamen für die vom UUZ unterstützten Zeichensätze
ergänzt und auf den neuesten Stand gebracht.
MY:
- Fix: Header mit einer Länge von mehr als 253 Zeichen, die kein Leer-
zeichen und kein anderes Trennzeichen (Komma, Semikolon) enthalten,
werden nicht mehr vernichtet (bisher erzeugte UUZ dann einen leeren
Header!).
MY:
- Unterstützung des Envelope-Headers "Delivered-To:" verbessert und an
qmail-Praxis angepaßt: Es wird nicht mehr zwingend der letzte
"Delivered-To:"-Header als Envelope-Empfänger betrachtet, sondern
entweder der erste, der eine Adresse enthält, die mit "alias-"
beginnt, oder, falls eine solche Adresse nicht vorkommt, der zweite
von allen "Delivered-To:"-Headern (falls mehrere existieren). Bei
nur einem "Delivered-To:"-Header wird dieser genommen (logisch).
MY:
- Fix: Der Envelope-Header "Delivered-To:" wird jetzt auch bei Mails
im UUCP-Format beachtet (bisher nur bei Mails im SMTP-Format).
MY:
- Wie schon bisher bei Mails im SMTP-Format, werden Envelope-Header
("Envelope-To:", "X-Envelope-To:", "Delivered-To:") jetzt auch bei
Mails im UUCP-Format nicht mehr zwangsweise ausgewertet, sondern nur
noch dann, wenn der Kommandozeilenschalter "-UseEnvTo" gesetzt ist.
ToDo: Entsprechenden Schalter im UUCP-Boxen-Dialog von XP
----- nachrüsten.
MY:
- Der Schalter "-UseEnvTo" räumt bei gleichzeitigem Vorhandensein
eines "(X-)Envelope-To:"-Headers und eines "Delivered-To:"-Headers
dem "(X-)Envelope-To:"-Header höhere Priorität ein und ignoriert den
"Delivered-To:"-Header.
MY:
- Fix: Die Umwandlung der sog. "Bang-Adressierung" in eine nach
heutigen Regeln RFC-konforme Adresse erfolgt jetzt bei *allen*
Adressen (bisher nur beim "To:"-Header). Dieser Fix ist eher von
akademischem Nutzen, weil Bang-Adressierung so gut wie nicht mehr
vorkommt.
MY:
- Das Lo-ASCII-Zeichen #26 (Ctrl-Z) wird beim Einlesen des RFC-Puffers
jetzt durch ein ">" (statt durch ein Fragezeichen) ersetzt.
MY:
- Auswertung folgender zusätzlicher/alternativer RFC-Header
implementiert:
"Mailer:" (RFC2076)
"Mail-System-Version:" (RFC2076)
"Originating-Client:" (RFC2076)
"X-Reader:" (offenbar Mozilla-Praxis)
"Obsoletes:" (RFC2076, Äquivalent zu "Supersedes:")
"Organisation:" (RFC2076, US-Schreibweise von
"Organization:")
"Importance:" (RFC2076/1327/1911, Äquivalent zu
"Priority:")
MY:
- Bei "Priority:" bzw. "Importance:" wird jetzt "non-urgent"
(= niedrig) als weiterer möglicher Wert interpretiert
(RFC2076/1327).
MY:
- Fix: Ein Envelope-Empfänger wird jetzt mit *allen* EMP:-Headern
abgeglichen (bisher nur mit dem ersten). Konkrete Folge: Nur wenn
sich der Envelope-Empfänger in *keinem* der EMP:-Header befindet
(z.B. bei BCCs), werden die Empfänger in den EMP:-Headern nach OEM:
geschrieben. Bisher passierte das auch dann, wenn sich der Envelope-
Empfänger zwar nicht im ersten, dafür aber in einem der folgenden
EMP:-Header befand.
MY:
- Der RFC-Header "Sender:" hat jetzt Priorität vor einem evtl. aus den
SMTP/UUCP-Protokoll-Headern herausoperierten "Envelope-Absender".
Es wird daher jetzt immer der "Sender:"-Header statt des Envelope-
Absenders nach WAB: geschrieben, sofern vorhanden.
MY:
- Bei "Reply-To:"- und "Sender:"-Headern wird ein evtl. vorhandener
Realname jetzt nicht mehr vernichtet, sondern in den Antwort-an:-
bzw. WAB:-Header geschrieben.
ToDo: Realname in Antwort-an:-Headern im XP-Listerkopf anzeigen.
-----
(Eine entsprechende Änderung für Realnames in To:- und Envelope-
Headern ist geplant, scheitert aber momentan noch daran, daß dafür
eine Änderung in XP selbst erforderlich ist, da im Moment PM-Bretter
mit Namen angelegt würden, die ebenfalls den Realname enthalten).
MY:
- Fix: Bei eingehenden Nachrichten mit einem Content-Type-Header
*ohne* Charset-Parameter geht der UUZ jetzt genau wie bei Nach-
richten, die gar keinen Content-Type-Header haben, vom Zeichensatz
ISO-8859-1 aus und führt eine entsprechende Konvertierung in den
IBM-Zeichensatz durch (bisher wurde der Zeichensatz als US-ASCII
gewertet und die Nachricht daher nicht konvertiert).
MY:
- Folgende RFC-Header werden jetzt mit dem Prefix "X-Orig-" als
Backup-Header im unveränderten (d.h. auch undecodierten) Original-
RFC-Format und in voller Länge in den ZC-Header geschrieben:
"From:" => "X-Orig-From:"
"Sender:" => "X-Orig-Sender:"
"Reply-To:" => "X-Orig-Reply-To:"
"To:" => "X-Orig-To:"
"Cc:" => "X-Orig-Cc:"
"Newsgroups:" => "X-Orig-Newsgroups:"
"Followup-To:" => "X-Orig-Followup-To:"
"Subject:" => "X-Orig-Subject:" (nur wenn MIME-codiert)
Die einzigen Änderungen, die UUZ an diesen Headern vornimmt, sind,
gefaltete Header zu entfalten und Mehrfach-Leerzeichen gemäß RFC2822
durch ein Leerzeichen zu ersetzen (letzteres nicht bei "Subject:").
Das Schreiben dieser Header dient im Moment primär dem Zweck, die
Möglichkeit der Kontrolle darüber zu haben, ob bzw. wie diese Header
in das ZConnect-Format konvertiert wurden, auch wenn die originale
RFC-Nachricht nicht mehr vorliegt.
Ob das Schreiben dieser Header auf Dauer beibehalten wird, wird die
Praxis und die Reaktion der XP-User ergeben.
MY:
- Workaround: Der Header LEN: wird jetzt immer als letzter ZConnect-
Header geschrieben, weil sich empirisch erwiesen hat, daß das
Programm "PktXCode" häufiger Probleme hat, Dateien korrekt aus der
Mail zu extrahieren, wenn danach noch weitere Header folgen.
MH[+MY]:
- Neuen Schalter "-bBoxname" implementiert (Vorbereitung für eine
evtl. Kompatibilität des FreeXP-UUZ mit XP2 und eine spätere
Verwendung auch in FreeXP). Der übergebene Boxname wird in den
ZC-Header "X-XP-BOX:" geschrieben.
RB[+MY]:
- Unterstützung des Headers "X-XP-Mode:" implementiert (Vorbereitung
für eine evtl. Kompatibilität des FreeXP-UUZ mit XP2 sowie die
spätere Implementierung von "HdrOnly" in FreeXP).
2.2. Ausgehende Nachrichten (ZConnect => RFC)
----------------------------------------------
MY:
- Fix: MIME-Singlepart-Nachrichten mit einem anderen Zeichensatz als
ISO-8859-1 (z.B. ISO-8859-15) im X-Charset-Header und ohne ZConnect-
Charset-Header "ISOx" (x=1-15) wurden nach der Konvertierung durch
den UUZ häufig dennoch mit der Zeichensatzdeklaration ISO-8859-1
versandt. Variable 'convibm' wurde in der Routine 'SetMimeData'
geprüft, bevor sie gesetzt wurde und hatte dadurch einen zufälligen
Wert - als Folge dieses Fixes mußte das Setzen der Variable 'mpart'
bei ausgehenden Nachrichten nach 'SetMimeData' verlegt werden, weil
ansonsten Multipart-Nachrichten einer Zeichensatzkonvertierung
unterzogen worden wären.
MY:
- Vorbereitung für zukünftige ZConnect-Zeichensatzerweiterungen:
Beim Betrieb eines externen Clients in einer ZConnect-Box wird bei
der Konvertierung von ISO-Nachrichten jetzt nicht mehr stur der
Zeichensatz ISO-8859-1 deklariert, sondern die Deklaration richtet
sich nach der jeweiligen Bezeichnung im ZConnect-Charset-Header
("ISO15" wird zu "ISO-8859-15"). Die Existenz eines ZConnect-Headers
"CHARSET: ISOx" (x=1-15) verhindert nach wie vor eine (nochmalige)
Zeichensatzkonvertierung (die Nachricht liegt bereits in einem
ISO-Zeichensatz vor).
MY:
- Fix: Zeichensatz-Konvertiertabellen IBM=>ISO komplett überarbeitet,
Änderungen und Korrekturen bei fast 20 Zeichen vorgenommen (siehe
Tabellen in MIMEDEC.PAS):
1. Prinzipiell werden Zeichen, die im ISO-Zeichensatz nicht existie-
ren, statt nach optischen Kriterien jetzt danach konvertiert, wie
sie ausgesprochen werden bzw. welche Bedeutung ein Symbol hat. So
wird z.B. das Zeichen #233 in CP437 (großer Buchstabe "Theta")
nicht mehr in ein "O" konvertiert, nur weil das mit viel
Phantasie halbwegs ähnlich aussieht, sondern in ein "T".
2. Unkonvertierbare Zeichen, für die es keine sinnvolle Translitera-
tion im ISO-Zeichensatz gibt, werden jetzt in einen Punkt (#46)
statt wie bisher in ein Leerzeichen konvertiert, damit keine
unsinnigen Zeilenumbrüche entstehen.
3. Steuerzeichen im Bereich #0-#31 werden entweder ebenfalls in
einen Punkt oder in ein sinnvolles Ersetzungszeichen konvertiert,
mit Ausnahme der Zeichen #9 (HT), #10 (LF), #12 (FF) und #13
(CR), die unverändert durchgereicht werden, sowie dem Zeichen #0,
das in ein Leerzeichen konvertiert wird. (Anmerkung: Es ist zu
überlegen, Steuerzeichen 1:1 durchzureichen, da sie im Unter-
schied zu ZConnect bei RFC prinzipiell erlaubt sind.)
4. Eine "Multichar-Konvertierung" für bestimmte Zeichen und Symbole
(z.B. Peseten-Symbol "₧" => "ESP") führt der UUZ nicht durch,
weil diese bereits in XP stattfindet, bevor die Nachricht an den
UUZ übergeben wird.
MY:
- Der Schalter "-client" impliziert jetzt den Schalter "-SMTP", so daß
die zusätzliche Angabe von "-SMTP" bei "-client" nicht mehr erfor-
derlich ist (es werden bei "-client" also jetzt *immer* Nachrichten
im SMTP-Format erstellt).
MY:
- Neuer Schalter "-gate" für die ZC=>RFC-Konvertierung von Nachrich-
ten, die nicht von einer RFC-Box in XP erzeugt wurden und daher
nicht zwingend über einen "X-Charset:"-Header verfügen, in dem
bereits der korrekte Zeichensatz deklariert ist:
UUZ prüft bei Verwendung dieses Schalters den Body darauf, ob dieser
*nach* einer Konvertierung in den ISO1-Zeichensatz noch 8bit-Zeichen
enthalten würde. In Abhängigkeit vom Ergebnis dieser Prüfung werden
dann automatisch der Zeichensatz und die Transportcodierung in den
entsprechenden RFC-Headern "Content-Type:" und "Content-Transfer-
Encoding:" korrekt deklariert:
1. Nachrichten, deren Body keine 8bit-Zeichen enthalten, werden
ausnahmslos mit dem Zeichensatz "US-ASCII" und der Transport-
codierung "7bit" deklariert.
2. Nachrichten mit 8bit-Zeichen im Body werden nach ISO konvertiert
und mit dem entsprechenden Zeichensatz (i.d.R. "ISO-8859-1")
sowie der gewählten Transportcodierung ("8bit" oder "quoted-
printable") deklariert. Ein evtl. vorhandener Header "X-Charset:"
wird ignoriert. Wenn die Nachricht das als Euro-Symbol interpre-
tierte Zeichen #238 ("ε") in CP437 enthält und der Schalter
"-noEuro" nicht gesetzt ist, wird automatisch der Zeichensatz
"ISO-8859-15" deklariert und das Zeichen nach #164 (Euro-Symbol
in ISO15) konvertiert (siehe auch "Euro-Support" weiter oben).
3. Bei Nachrichten, die bereits im ISO-Zeichensatz vorliegen und die
8bit-Zeichen enthalten, wird der ZConnect-Header "CHARSET: ISOx"
beachtet und der ZConnect-spezifische Name des Zeichensatzes
(z.B. "ISO9") in die offizielle Bezeichnung (in diesem Fall
"ISO-8859-9") umgewandelt.
4. MIME-Multipart-Nachrichten werden - genau wie bisher - weder
geprüft noch konvertiert.
UUZ ist mit dem Schalter "-gate" auch als universeller externer RFC-
Konvertierer einsetzbar. Er ist aber auch für User interessant und
von Bedeutung, die einen externen Client wie UKA_PPP oder eine der
älteren UKAW-Versionen in einer ZConnect-Box einsetzen, weil dadurch
der Aufruf des Hilfsprogramms "X_SPOOL.EXE" mit dem Schalter "/xc"
unmittelbar vor der UUZ-Konvertierung entbehrlich wird. Dieser
Aufruf erzeugte bisher eine oft fehlerhafte Deklaration von Zeichen-
satz und Codierung, da X_SPOOL.EXE keine Prüfung des Nachrichten-
textes durchführt, blind "8bit" und "ISO-8859-1" deklariert und auch
keine Rücksicht auf andere in einem eventuellen CHARSET:-Header
deklarierten Zeichensätze nimmt.
(Der Einsatzbereich von X_SPOOL.EXE an anderen Stellen in den
Script- und Batch-Dateien ist hiervon nicht betroffen und kann auch
nicht durch den UUZ abgedeckt werden.)
Hinweis: Der Schalter "-gate" kann nicht von XP aus gesetzt werden
und ist daher nur im Externbetrieb nutzbar.
MY:
- Fix: Bei der ZC=>RFC-Konvertierung wird ein evtl. vorhandener Header
"U-Content-Transfer-Encoding:" jetzt ignoriert. Bisher wurde
*sowohl* ein neuer Header "Content-Transfer-Encoding:" generiert
*als auch* durch das Entfernen des Prefixes "U-" bei einem evtl.
bereits vorhandenen Header mit ansonsten identischer Bezeichnung ein
unzulässiges Duplikat dieses Headers (mit u.U. abweichendem Inhalt)
erzeugt.
MY:
- Fix: Bei Singlepart-Nachrichten im Zeichensatz "US-ASCII" werden
jetzt Zeichensatz und Transportcodierung korrekt mit "US-ASCII" und
"7bit" deklariert (bisher: "iso-8859-1" und "8bit").
MY:
- Fix: Bei MIME-Multipart-Nachrichten wird im Top-Level-Header jetzt
immer eine Transportcodierung im Header "Content-Transfer-Encoding:"
deklariert, und zwar generell "8bit". Bisher wurde im Top-Level-
Header gar keine Transportcodierung deklariert, was gleichbedeutend
mit "7bit" ist und daher bei Text-Anhängen mit 8bit-Zeichen dazu
führte, daß manche Mail-/Newsreader diese Zeichen nicht richtig
darstellen konnten.
Zwar wäre es technisch möglich, den Body der Nachricht auf das
Vorkommen von 8bit-Zeichen zu prüfen und im Top-Level-Header ggf.
auch "7bit" zu deklarieren, dies würde aber bei großen Attachments
mit mehreren MB die Performance bei der Konvertierung zu drastisch
beeinträchtigen.
MY:
- Die ZConnect-Header "Post:" und "Telefon:" werden jetzt (und mangels
"echter" RFC-Header für diese Informationen) in die experimentellen
RFC-Header "X-ZC-Post:" und "X-ZC-Telefon:" geschrieben und kommen
zumindest bei XP-Anwendern daher jetzt auch verlustfrei an.
MY:
- Im "Subject:"-Header werden "falsche" Prefixe wie "RE: ", "re:",
"AW: " und "Sv: " sowie alle Inkarnationen davon jetzt durch das
korrekte "Re: " ersetzt.
MY:
- Fix: Der "Lines:"-Header enthält jetzt auch dann die korrekte
Zeilenanzahl, wenn die Nachricht "quoted-printable"-codiert wird und
durch den dabei evtl. erforderlichen Zeilenumbruch nach 76 Zeichen
zusätzliche Zeilen erzeugt werden müssen.
MY:
- Fix: Es werden jetzt auch bei ausgehenden Nachrichten bis zu 160
Zeichen lange Message-IDs verarbeitet (bisher 120 Zeichen ausgehend
und 160 Zeichen eingehend, relevant für MID:- und BEZ:-Header).
MY:
- Temporär-Fix: Bei "gemischten" Nachrichten (Mail- und Brettempfänger
gleichzeitig, kann im Betrieb mit XP nicht auftreten und ist daher
nur für den Externbetrieb relevant) werden keine Brettempfänger mehr
in "RCPT TO:"- und "Cc:"-Header geschrieben - die Brettnachricht
geht also verloren. Anderenfalls würde die Nachricht aber gar nicht
versandt werden, weil sie ungültige Mail-Adressen enthält.
MY:
- Es wird jetzt ein Header "X-RFC-Converter:" erzeugt, der Dateidatum
und -uhrzeit der verwendeten UUZ-Version enthält.
MY:
- Am Ende der Verarbeitung gibt der UUZ jetzt eine Art Performance-
Statistik aus (verarbeitete Daten in Kilobyte, Dauer der Verarbei-
tung, Kilobyte/Sekunde und Nachrichten/Sekunde).
3. Korrekturen, Änderungen und Erweiterungen im Zusammenhang mit der
Anpassung an aktuell gültige RFC-Standards
((son-of-)1036/2045/2047/2822)
----------------------------------------------------------------------
3.1. Eingehende Nachrichten (RFC => ZConnect)
-----------------------------------------------
MY:
- Das Lo-ASCII-Zeichen #0 wird beim Einlesen des RFC-Puffers jetzt
durch ein Leerzeichen ersetzt (ASCII #0 ist gemäß RFC2822 nicht mehr
erlaubt).
MY:
- Fix: Unterstützung mehrerer Adressen im "From:"-Header.
Gemäß RFC2822 kann der "From:"-Header mehrere Adressen enthalten (es
muß dann ein "Sender:"-Header vorhanden sein). Dies war XP bisher
nicht bekannt, deshalb hat es die komplette komma-separierte Liste
der Adressen im "From:"-Header bisher als einen einzigen Absender
betrachtet, diese auch so in den ABS:-Header übernommen und einen
entsprechenden User angelegt ("abs1@test.de, abs2@test.de,
abs3@test.de") - argh...
Die neue Vorgehensweise ist wie folgt:
1. Zunächst werden evtl. vorhandene Dupes aus dem "From:"-Header
entfernt.
2. Danach wird die erste nicht-leere Adresse im "From:"-Header in
den ABS:-Header übernommen. Existiert nach dem Entfernen von
Dupes keine nicht-leere Adresse im "From:"-Header mehr, wird
anders als bisher ein evtl. vorhandener "Envelope-Absender" (WAB)
*nicht* mehr in den ABS:-Header übernommen. Dies dient der
Vermeidung der "Fälschung" von Headerinformationen.
3. Leeren Adressen wird die Adresse "unknown@sender" verpaßt, ein
evtl. vorhandener Realname wird beibehalten (Absender wie
"Theo Tester <>" kommen in der Tat vor).
4. Da ZConnect mehrere ABS:-Header nicht zuläßt, werden die übrigen
Absender in ANTWORT-AN:-Header geschrieben, damit sie nicht ganz
verlorengehen. Die Großschreibung von "ANTWORT-AN:" dient einer
späteren möglichen Unterscheidung in XP von "echten" Antwort-an:-
Headern in Groß-/Kleinschreibung (= "Reply-To:").
ToDo: Unterstützung mehrerer Antwort-an:-Header in XP selbst,
----- speziell bei RTA und Anzeige im Listerkopf.
MY:
- Fix: Unterstützung mehrerer Adressen im "Reply-To:"-Header. Es wird
jetzt für jede im "Reply-To:"-Header vorhandene Adresse ein
Antwort-an:-Header erzeugt. Bisher wurden wie beim "From:"-Header
mehrere Adressen im "Reply-To:"-Header als eine einzige Adresse
betrachtet und auch so in den Antwort-an:-Header übernommen. Beim
Beantworten wurde der gesamte Header dann vollständig verworfen,
weil "reply1@test.de, reply2@test.de" als ungültige Adresse erkannt
wurde.
ToDo: Unterstützung mehrerer Antwort-an:-Header in XP selbst,
----- speziell bei RTA und Anzeige im Listerkopf.
MY:
- Fix: Beim Schreiben der Antwort-an:-Header wird ein Dupeabgleich
jetzt mit *allen* Absenderadressen vorgenommen und daher nur für die
Adressen ein Antwort-an:-Header erzeugt, die nicht auch gleichzeitig
Absender sind.
MY:
- Fix: Ein WAB:-Header (Weiterleiter/Envelope-Absender) wird entfernt,
wenn er mit einer der Absenderadressen identisch ist. Bei mehreren
Absenderadressen ist der mit dem WAB: identische Absender dann in
jedem Fall derjenige, der in den ABS:-Header übernommen wird, die
übrigen Absender werden in ANTWORT-AN:-Header geschrieben (s.o.).
MY:
- RFC-Parser (MIME-Decodierung, Erkennung/Unterscheidung/Behandlung
von Adressen, Realnames und Message-IDs sowie darin enthaltenen
Kommentaren, Phrasen, quoted-strings und quoted-pairs) komplett
neugeschrieben. Details:
1. Die MIME-Decodierung ist im Sinne des "robustness principle"
jetzt extrem fehlertolerant und decodiert anders als bisher z.B.
auch 'encoded words', die Leerzeichen enthalten (was laut
RFC2047 unzulässig ist, in der Praxis aber vorkommt), oder die
anderweitig und RFC-widrig verunstaltet sind.
2. Mit dem neuen Kommandozeilenschalter "-rfcMime" kann man das
"robustness principle" in sein Gegenteil verkehren und eine
MIME-Decodierung erzwingen, die streng nach RFC2047 decodiert,
und so den UUZ als "Checkbot" benutzen: Was dann nicht decodiert
wird, ist nicht korrekt codiert. :-)
UUZ berücksichtigt in Headerzeilen dann die im jeweiligen
Kontext (strukturierter/unstrukturierter Header, quoted-string,
Kommentar) geltenden unterschiedlichen Regeln und decodiert nur
noch Zeichenfolgen, die im jeweiligen Kontext auch ein gültiges
'encoded word' bilden. Zeichenfolgen, die nur so ähnlich
aussehen wie ein 'encoded word' (weil sie vom Absender bewußt so
gestaltet oder weil sie von fehlerhafter Software fehlerhaft
codiert wurden), werden dann nicht mehr decodiert.
Hinweis: Der Schalter "-rfcMime" kann derzeit nicht von XP aus
gesetzt werden und ist daher nur im Externbetrieb
nutzbar.
3. Fix: Nachrichtentexte und Header, die in einem ungültigen oder
von XP nicht unterstützten Zeichensatz vorliegen (ISO-8859-5
Kyrillisch, ISO-8859-6 Arabisch o.a.), werden jetzt nicht mehr
blind auf Basis der in diesen Fällen unzutreffenden ISO1-Tabelle
"kaputtkonvertiert", sondern im Originalzustand belassen. So
können sie notfalls noch manuell dechiffriert werden (bei
Headern war bisher nicht einmal mehr erkennbar, welcher Zeichen-
satz vom Autor ursprünglich verwendet wurde).
4. Fix: Die gesamte Prüfung auf gültige 'encoded words', gültige
bzw. unterstützte Zeichensätze usw. findet jetzt statt, *bevor*
die Decodierroutine den Header verändert. Bisher wurden generell
zuerst sämtliche Merkmale eines codierten Headers (MIME-
Delimiter, Zeichensatz-/Codierungsdeklaration) entfernt, und
erst anschließend stellte sich u.U. heraus, daß eine Decodierung
gar nicht möglich bzw. sinnvoll ist.
5. Fix: Nach erfolgter MIME-Decodierung eines Headers werden im
decodierten String nicht mehr alle vorhandenen Lo-ASCII-Zeichen
ersetzt, sondern nur noch #0, #9 (<TAB>), #10 (LF) und #13 (CR)
durch Leerzeichen sowie #26 (<Ctrl-Z>) durch ">".
6. Fix: Die Regeln für das Entfernen bzw. Nicht-Entfernen von
Leerzeichen zwischen mehreren 'encoded words' bzw. zwischen
'encoded words' und uncodiertem Text werden jetzt in allen
Fällen korrekt beachtet. Des weiteren werden nicht codierte
Mehrfach-Leerzeichen nur noch dort durch eines ersetzt, wo dies
auch zulässig bzw. Pflicht ist (nämlich in strukturierten
Headern wie "From:" und "To:", nicht aber in unstrukturierten
Headern wie "Subject:" und "Summary:").
7. Workaround: Wenn der "In-Reply-To:"-Header mehrere Message-IDs
enthält, wird jetzt die letzte (statt bisher der ersten)
Message-ID in den BEZ:-Header übernommen. Diese Maßnahme
kompensiert das Verhalten der von ZConnect<=>RFC-Gates häufig
eingesetzten Software "DUUCP", mehrere BEZ:-Header bei ausgehen-
den Mails nicht nach "References:", sondern in eine komma-
separierte Liste nach "In-Reply-To:" zu übernehmen, sowie das
dadurch verursachte Problem, daß bei einem Reply auf eine Mail
in einem AM-Brett mit eingetragenem PM-Vertreter - häufige
Konstellation bei Mailinglisten - bisher eine falsche Bezugs-
verkettung beim Empfänger des Replies hergestellt wird.
8. Fix: Bei allen Headern, die Adressen enthalten, findet die
Erkennung von bzw. die Aufteilung in Adresse und Realname jetzt
*vor* der MIME-Decodierung statt. Bisher konnte es in besonders
trickreich gelagerten Fällen sogar zu einer Verwechslung von
Absender und Realname kommen.
(Beispiel: "=?UTF-8?B?PGdvdEBjaGE+?= <an@other.example>")
9. Fix: Adressen werden generell nicht mehr MIME-decodiert, weil
sie per RFC-Definition gar nicht MIME-codiert sein können/dürfen
und daher jede einer MIME-Codierung ähnliche Zeichenfolge in
einer Adresse nicht als solche interpretiert werden darf.
10. Fix: Group-Adressierung ("A Group: a@b.de, c@d.de;") wird jetzt
erkannt und die Group-Bezeichnung entfernt. Leere Groups wie
"Undisclosed Recipients:;" werden dabei aufgelöst zu
"!Empty_group@Undisclosed_Recipients" und sind daher zukünftig
allesamt an einer zentralen Stelle unter "!Empty_group@..." in
der User-Übersicht aufzufinden und können dort bequem gelöscht
werden, falls sie durch die automatische User-Aufnahme angelegt
worden sein sollten.
11. Fix: Route-Adressierung ("<@pc1.tld,@pc2.tld:theo@test.de>")
wird jetzt in allen Fällen korrekt erkannt und entfernt (beim
obigen Beispiel lautet die aufgelöste Adresse somit
"theo@test.de"). Bisher wurden z.B. Mehrfach-Routes nicht
korrekt aufgelöst.
12. Fix: Behandlung von Kommentaren, quoted-pairs/strings und
Leerzeichen in Adressen und Realnames deutlich verbessert und
jetzt RFC-konform implementiert:
- Kommentare in Adressen werden jetzt korrekt erkannt und
entfernt. Bisher hielt XP alles, was hinter der ersten
öffnenden Klammer folgte, für einen Realname, und zerstörte
damit Adresse wie Realname.
- Kommentare, Anführungszeichen und quoted-pairs im Realname
werden jetzt korrekt und vollständig erkannt und den Regeln
entsprechend (!) entfernt (d.h., sie werden jetzt dort auch
nicht entfernt, wo sie den Regeln nach nicht entfernt werden
dürfen).
- Bei Adressen, deren local part unnötigerweise als quoted-
string vorliegt und/oder überflüssige quoted-pairs enthält,
werden diese jetzt entfernt. Korrekt gesetzte und notwendige
quoted-pairs/strings bleiben erhalten.
- Leerzeichen in Adressen werden jetzt entfernt, sofern sie sich
nicht im quoted-string eines local part befinden (dort sind
sie zulässig).
Drei Beispiele für die obigen Fälle mit RFC-konformen Headern:
a) Der Header : From: theo(ah!)@test(oh!).de
- wurde bisher: ABS: theo (ah!)@test(oh!).d)
- wird jetzt : ABS: theo@test.de
b) Der Header : From: t. "te\st"@test.de (T. \("T"\) Tester)
- wurde bisher: ABS: t. "te\st"@test.de (T. \("T"\) Tester)
- wird jetzt : ABS: t.test@test.de (T. ("T") Tester)
c) Der Header : From: "Theo Tes\ter"@test.de
- wurde bisher: ABS: "Theo Tes\ter"@test.de
- wird jetzt : ABS: "Theo Tester"@test.de
13. Fix: Adressen in Envelope-Headern werden jetzt derselben
Prozedur unterzogen wie Adressen in allen anderen Headern auch
(spitze Klammern, Kommentare, quoted-pairs/strings usw.
behandeln).
14. Alle oben beschriebenen Verfahren funktionieren sowohl mit der
"neuen" Form der Adressierung ("Real Name <user@do.main>") als
auch mit der "alten" Form ("user@do.main (Real Name)").
15. Fix: Innerhalb jeder einzelnen und zwischen mehreren Message-IDs
(wie bei "In-Reply-To:" und "References:") werden Kommentare,
Phrasen, quoted-pairs/strings und Leerzeichen jetzt (korrekt)
entfernt. Damit ist sichergestellt, daß syntaktisch unterschied-
liche, aber semantisch identische Message-IDs in XP auch iden-
tisch behandelt werden (diese Form der Message-ID-Behandlung
sollte langfristig allerdings besser in XP selbst stattfinden,
da die Syntax von Message-IDs idealerweise nicht verändert
werden sollte).
Gleichzeitig ist dadurch jetzt gewährleistet, daß keine Phrasen
bzw. quoted-strings zwischen mehreren Message-IDs mehr fälsch-
licherweise als Message-ID interpretiert werden. Bei nicht RFC-
konformen Message-IDs wie "In-Reply-To: mid1@fqdn, mid2@fqdn"
(spitze Klammern fehlen, Liste ist komma-separiert) wird per
Brute-Force-Methode die letzte Message-ID korrekt erkannt statt
entweder den gesamten Header fälschlicherweise als eine einzige
Message-ID zu interpretieren oder ihn alternativ vollständig zu
vernichten.
16. Fix: Bei der Konvertierung des "Keywords:"-Headers (RFC) in
mehrere "Stichwort:"-Header (ZC) werden jetzt sowohl Phrasen
(mehrere Worte mit Leerzeichen) und quoted-strings korrekt
behandelt (bisher: gar nicht) sowie quoted-pairs korrekt
entfernt (bisher: gar nicht).
Des weiteren wird der Header jetzt *zuerst* in einzelne Keywords
bzw. Phrasen zerlegt und erst *dann* MIME-decodiert, so daß als
Bestandteil einer Phrase bewußt codierte Kommata nicht mehr als
Trennzeichen zwischen mehreren Keywords fehlinterpretiert
werden.
17. Fix: Bei der Auswertung der Header "References:" und
"In-Reply-To:" hat "References:" jetzt immer Priorität, sofern
vorhanden. Bisher konnten sowohl bei News als auch bei Mail
Mehrfach-Bezüge verlorengehen, wenn ein "In-Reply-To:"-Header
vorhanden war.
18. Workaround: Da manche Mailreader (speziell Eudora) sowohl
doppelte Message-IDs in Headern als auch inkonsistente
"In-Reply-To:"- und "References:"-Header erzeugen (die
Message-ID aus "In-Reply-To:" fehlt in "References:"), wird der
"References:"-Header jetzt auf Dupes geprüft und die letzte
Message-ID aus dem "In-Reply-To:"-Header in den letzten BEZ:-
Header geschrieben, sofern sie nicht bereits in einem anderen
BEZ:-Header vorkommt.
Sämtliche Korrekturen und Änderungen hinsichtlich der damit jetzt
RFC-konformen Behandlung bzw. Entfernung von Kommentaren, Phrasen
und quoted-pairs/strings schlagen, soweit im Einzelfall zutreffend,
auch auf alle übrigen - und hier nicht ausdrücklich erwähnten -
strukturierten Header durch.
MK:
- Fix: News-Batches, deren Zeilenenden (EOL) aus CRLF statt nur aus
CR bzw. LF bestehen und deren "rnews"-Header eine RFC-konforme
Längenangabe enthält (ein EOL wird gemäß (son-of)RFC1036 unabhängig
von der tatsächlichen Länge als 1 Byte gezählt), werden jetzt
korrekt und verlustfrei konvertiert. Bisher zählte der UUZ ein CRLF
(oder jedes andere EOL wie CRCRLF) mit exakt soviel Bytes wie das
EOL tatsächlich Bytes hatte, was zu Datenverlust bei solchen RFC-
konformen Postings mit CRLF-Zeilenabschlüssen geführt hat.
Warnung: Umgekehrt werden durch diesen Fix jetzt User, die einen
-------- Client einsetzen, der RFC-widrige Längenangaben im "rnews"-
Header erzeugt, von Datenverlust betroffen sein! Es wird
daher dringend empfohlen, nur Clients einzusetzen, die RFC-
konforme Längenangaben erzeugen (was am einfachsten und
sinnvollsten durch reine LF-Zeilenabschlüsse gewährleistet
ist). RFC-widrige Längenangaben erzeugen alle XPNews-
Versionen bis v1.2.2 sowie einige ältere UKAW-Versionen
(z.B. v1.37g). Um Datenverlust zu vermeiden, müssen XPNews-
User auf die inzwischen zur Verfügung stehende Version
1.2.3 oder höher updaten, bei den betroffenen UKAW-
Versionen ist in der Datei <Server>.RC der Defaulteintrag
"$newline: crlf" in "$newline: lf" zu ändern.
Nicht negativ betroffen von diesem Fix sind hingegen
aktuelle UKAW/UKAD-Versionen oder UKA_PPP, da diese ohnehin
reine LF-Zeilenenden erzeugen.
3.2. Ausgehende Nachrichten (ZConnect => RFC)
----------------------------------------------
MY:
- Fix: Die Erzeugung RFC-widriger Header mit uncodierten Sonderzeichen
ist jetzt nicht mehr möglich: Die UUZ-Schalter "-MIME" und "-1522"
(entsprechen den Optionen "MIME in News" und "MIME in Headerzeilen
verwenden" unter C/O/E/V) sind ersatzlos gestrichen. Der UUZ codiert
Headerzeilen jetzt bei Mail *und* News *immer* nach RFC2047 (dem
Nachfolger von RFC1522). Durch den Wegfall wird das Erzeugen fehler-
hafter Mails und Postings bei Usern verhindert, die lediglich
vergessen haben, diese Schalter zu aktivieren und/oder sich über
ihre Bedeutung nicht im klaren waren.
MY:
- Alle "U-Header" werden bei Bedarf nach den Regeln für strukturierte
Header MIME-codiert (weil das auch bei unstrukturierten Headern nie
falsch sein kann und wir bei U-Headern nicht wissen, ob es sich um
einen strukturierten oder unstrukturierten Header handelt). Bisher
wurden U-Header nicht MIME-codiert und damit u.U. RFC-widrige Header
mit 8bit-Zeichen erzeugt.
MY:
- MIME-Codierung, "Folden" (Falten) und "Quoten" von Headern durch
neue Routine 'EncodeFoldQuote' drastisch optimiert/korrigiert/erwei-
tert und an RFC2045/2047 angepaßt:
1. Die Codierung erfolgt jetzt prinzipiell "minimal invasiv", d.h.
es werden nur noch die Worte codiert, die im jeweiligen Kontext
auch zu codierende Zeichen enthalten (bisher wurde alles vom
ersten bis zum letzten Wort, das zu codierende Zeichen enthält,
codiert). Dabei wird für jedes zu codierende Wort der zu verwen-
dende Zeichensatz separat ermittelt. Mehrere zu codierende Worte
hintereinander, auf die derselbe Zeichensatz angewandt werden
kann, werden zusammengefaßt und gemeinsam codiert.
2. Fix: Strukturierte Header bzw. Teile davon, die Zeichen enthal-
ten, die als quoted-string dargestellt werden müssen, werden
jetzt "gequotet" (d.h. in Anführungszeichen eingeschlossen und
darin enthaltene Anführungszeichen als "quoted-pairs" darge-
stellt). Wenn ein Header MIME-codiert werden muß, werden solche
eigentlich zu quotenden Zeichen codiert und folgerichtig nicht
zusätzlich gequotet.
3. Fix: Der jeweilige Kontext (strukturierter/unstrukturierter
Header) und die sich daraus ergebenden unterschiedlichen Regeln
für die MIME-Codierung werden jetzt beachtet (bisher wurden alle
Header nach den Regeln für unstrukturierte Header codiert und
somit u.U. fehlerhafte und RFC-widrige Header erzeugt).
4. Fix: 'encoded words', die im Zeichensatz "US-ASCII" codiert
werden (das kann bei strukturierten Headern, die bestimmte
Zeichen enthalten, vorkommen) werden jetzt auch mit diesem
Zeichensatz deklariert (statt mit "ISO-8859-1").
5. Fix: Es werden jetzt die max. zulässigen Längen (75 Zeichen für
'encoded words' und 76 Zeichen für codierte Zeilen) beachtet.
Bisher konnten u.U. auch längere 'encoded words' und/oder
codierte Zeilen erzeugt werden. Codierte Header, die länger sind
als 76 Zeichen, werden bei Mails (und jetzt auch korrekt, s.u.)
gefaltet.
6. Bei Mails wird jetzt die SOLL-Bestimmung, daß auch eine
uncodierte Headerzeile generell nicht länger als 78 Zeichen sein
soll, bei allen relevanten Headern beachtet und entsprechend
gefaltet (bisher wurden nur die Header "Summary:" und einige vom
UUZ selbst erzeugte Header wie "Received:" - und speziell bei
Postings noch "References:" - gefaltet, nicht aber z.B. der
"Subject:"-Header).
7. Im Unterschied zu Mails werden bei Postings/Artikeln (AMs) nur
noch Header gefaltet, die länger als 998 Zeichen sind. Einer-
seits ist Folding bei News immer noch nicht üblich und erwünscht
und kann zu Problemen bei bestimmten Funktionen ("NOV") mit
manchen News-Servern und -Clients führen, andererseits ist bei
Zeilen, die länger als 998 Zeichen sind, u.U. der sichere
Transport nicht mehr gewährleistet.
8. Fix: Beim Falten von langen unstrukturierten Headern
("Subject:", "Summary:") bleiben Mehrfach-Leerzeichen jetzt
in allen Fällen und in der richtigen Anzahl erhalten (bisher
wurden sie mitunter ganz oder teilweise vernichtet).
9. Fix: Mehrfach-Leerzeichen in strukturierten Headern (also fast
allen außer "Subject:" und "Summary:") werden jetzt im ganzen
String durch ein Leerzeichen ersetzt (statt wie bisher nur an
der Stelle, an der der Header ggf. gefaltet wurde).
10. Fix: Der Header "Keywords:" ("Stichwort:") wird jetzt korrekt
codiert und ggf. gequotet (bisher: gar nicht) und es werden
jetzt auch "Phrasen" (mehrere Worte mit Leerzeichen und ggf.
Kommata) korrekt behandelt (bisher: gar nicht).
Die neue Routine 'EncodeFoldQuote' wird aktuell bei folgenden
RFC-Headern verwendet:
"From:" (ZConnect: "ABS:")
"Sender:" (ZConnect: "WAB:")
"Cc:" (ZConnect: "EMP:")
"Keywords:" (ZConnect: "Stichwort:")
"Subject:" (ZConnect: "BET:")
"Summary:" (ZConnect: "Zusammenfassung:")
"X-Mailer:" (ZConnect: "MAILER:")
"X-Newsreader:" (ZConnect: "MAILER:")
"Organization:" (ZConnect: "Organisation:")
"X-ZC-Post:" (ZConnect: "Post:")
"X-ZC-Telefon:" (ZConnect: "Telefon:")
"X-XP-Version:" (ZConnect: "X-XP-Version:")
Alle 'U'-Header (z.B. "U-Received:", "U-Comments:")
MY:
- Fix: Bei allen Headern, die Adressen und evtl. zusätzlich Realnames
enthalten, werden diese jetzt im "neuen" (seit mindestens 1982
definierten und seit 2001 strikt empfohlenen) RFC-Format "Real Name
<local.part@do.main>" erzeugt. Dabei greifen in vollem Umfang die
oben beschriebenen Korrekturen, Änderungen und Erweiterungen für
MIME-Codierung und Quoting (relevant für Realname!) sowie das Falten
von Headern.
MY:
- Fix: Wenn eine Mail mehrere Kopienempfänger hat, werden diese jetzt
komma-separiert in einen einzigen "Cc:"-Header geschrieben (und ggf.
gefaltet). Bisher wurde für jeden Kopienempfänger ein eigener "Cc:"-
Header erzeugt, was laut RFC2822 nicht mehr zulässig ist.
MY:
- Fix: Bei Mails werden jetzt immer der Header "In-Reply-To:" *und*
der Header "References:" erzeugt, wenn die Nachricht einen oder
mehrere Bezüge hat. In "In-Reply-To:" steht die Message-ID des
letzten oder einzigen BEZ:-Headers, in "References:" stehen wie
bisher die erste und die letzten drei Message-IDs aller BEZ:-Header.
Dadurch bleiben Mehrfachbezüge - z.B. bei Mailinglisten - jetzt
erhalten.
ToDo: In XP bei mehr als vier BEZ:-Headern das Kürzen auf die erste
----- und die letzten drei Message-IDs evtl. verhindern.
MY:
- Fix: Bei News wird der Header "References:" nicht mehr gefaltet
(manche News-Server und -Reader haben damit u.U. Probleme) und bei
Bedarf jetzt auf max. 998 (statt wie bisher auf max. 980) Zeichen
gekürzt. Beim Kürzen werden - wie bisher - keine Message-IDs
abgeschnitten, sondern solange vollständige Message-IDs aus dem
Header entfernt, bis die max. Länge unterschritten ist.
MY:
- Fix: Wenn die Nachricht einen leeren Betreff enthält, wird nur noch
bei Postings (AMs) ein leerer "Subject:"-Header erzeugt (bei Mails
ist er nicht Pflicht).
4. Unterstützung langer Zeilen > 253 Zeichen in Header und Body
Diverse Variablen vergrößert
-----------------------------------------------------------------
4.1. Eingehende Nachrichten (RFC => ZConnect)
----------------------------------------------
Prinzipiell werden jetzt alle Headerzeilen in voller Länge ("volle
Länge" bedeutet: 65500 Zeichen) lesend und in vielen Fällen auch
schreibend verarbeitet:
MY:
- Die gesamte Behandlung eines Headers nach RFC1036/2045/2047/2822
(MIME-Decodierung, Erkennung von Adresse/Realname/Newsgroup und
Message-IDs, Entfernen von Kommentaren, Behandlung von quoted-
pairs/strings und Leerzeichen) erfolgt bei *allen* Headern jetzt
über die gesamte eingelesene Länge von 65500 Zeichen.
Selbst wenn ein Header bei der weiteren UUZ- oder XP-internen
Verarbeitung in seiner Länge nach wie vor auf eine bestimmte Länge
begrenzt sein sollte, wird damit verhindert, daß Verluste nur
deswegen entstehen, weil der Header schon von vorneherein nicht
vollständig gelesen und interpretiert wird. Ein MIME-codierter
Header konnte bisher mitunter nicht vollständig decodiert werden,
wenn sich das Ende der Codierung jenseits einer je nach Header
unterschiedlich definierten Grenze zwischen 253 und 3825 Zeichen
befand, und/oder der Header wurde unnötig gekürzt:
1. Bei einem unstrukturierten Header wie z.B. "Subject:", der aus
248 MIME-codierten "ä" besteht (wofür in codierter Form 995
Zeichen benötigt werden) und der im UUZ auch auf 248 Zeichen
begrenzt ist, wurden bisher trotzdem nur 54 decodierte "ä" an den
BET:-Header zurückgegeben, weil der Header "gefaltet" war
(gefaltet sein mußte) und nur die ersten drei gefalteten Zeilen
interpretiert wurden. Jetzt würden alle 248 "ä" an den BET:-
Header zurückgegeben werden (wobei in diesem Fall selbst bei noch
längeren "Subject:"-Headern ohnehin die *volle* Länge geschrieben
wird, Näheres dazu weiter unten).
2. Strukturierte Header, die z.B. Empfänger ("Newsgroups:", "To:",
"Cc:"), Message-IDs ("References:", "In-Reply-To:") oder sonstige
wesentliche Informationen enthalten, wurden bisher je nach Header
irgendwo zwischen Zeichen 254 und 3825 vernichtet. Jetzt wird
auch eine Adresse oder Message-ID, die z.B. erst an Pos. 65347 im
Header beginnt, korrekt erkannt und kann weiterverarbeitet und
z.B. in einen BEZ:- oder EMP:-Header geschrieben werden.
3. Die MIME-Decodierung verarbeitet jetzt beliebig lange 'encoded
words', obwohl diese gemäß RFC2047 nur 75 Zeichen lang sein
dürfen. Manche Mail-/Newsreader erzeugen jedoch unter bestimmten
Umständen auch längere und somit RFC-widrige 'encoded words'
(z.B. OpenXP/32 und bisher auch alle 16bit-Versionen von XP).
MY:
- Folgende unstrukturierte Header werden nicht nur in voller Länge
interpretiert, sondern auch in voller Länge in den ZConnect-Puffer
geschrieben:
BET: (RFC: "Subject:")
ROT: (RFC: "Path:" bei News bzw. bei Mail der aus den
einzelnen "Received:"-Headern herausoperierte
und zusammengesetzte Pfad)
MAILER: (RFC: verschiedene Header, z.B. "X-Mailer:" oder
"X-Newsreader:"
ORG: (RFC: "Organization:")
Post: (RFC: "X-Z-Post:", "X-ZC-Post:")
Telefon: (RFC: "X-Z-Telefon:", "X-ZC-Telefon:")
U-X-Homepage: (RFC: "X-Homepage:")
Stichwort: (RFC: "Keywords:")
Zusammenfassung: (RFC: "Summary:")
X-Gateway: (RFC: "X-Gateway:")
Bei den übrigen ZConnect-Headern wie z.B. EDA: (Erstellungsdatum)
stellt sich das Problem langer Header meist nicht, daher wurden sie
hier nicht einbezogen. Eine Erweiterung dieser Liste ist evtl. noch
geplant für File: und X-XP-Boundary:, sowie für Header, die Message-
IDs enthalten (letztere sind momentan auf 160 Zeichen je Message-ID
begrenzt, was in der Praxis ausreicht).
MY:
- RFC-Header, die mit dem Prefix "U-" oder "X-" im ZConnect-Header
abgelegt werden (z.B. "U-Received:", "X-Orig-To:"), werden jetzt
ebenfalls immer mit der vollen Länge geschrieben. Die Anzahl ist
nicht mehr wie bisher auf 60 Zeilen begrenzt, sondern nur noch durch
den verfügbaren Speicher. Ein "Backdoor" für diese Header existiert
nicht, da weder notwendig noch sinnvoll.
MY:
- Da bei extrem vielen extrem langen Headern theoretisch der Speicher
knapp werden könnte (100 Header mit je 6500 Zeichen z.B. passen
nicht mehr in den verfügbaren unteren Speicher) und somit Header-
verlust drohen würde, existiert für jeden der obigen Header, der mit
voller Länge geschrieben wird, für den Fall von Speichermangel ein
"Backdoor": Der Header wird dann wie bisher in der Länge geschrie-
ben, wie sie in der Variablendeklaration im Header-Record für den
jeweiligen Header definiert ist (max. 253 Zeichen inkl. Bezeichner).
Bei Headern, die gekürzt werden mußten, weil sie länger als 65500
Zeichen sind (oder die wegen Speichermangels ohnehin gekürzt werden
mußten), wird dies durch das Anhängen der Zeichenfolge "[...]"
kenntlich gemacht.
MY:
- Für alle Header, die in voller Länge geschrieben werden, sowie für
die Adressen-Header wird der Speicher dynamisch und in genau der
Menge angefordert und belegt, die jeweils benötigt wird (Ausnahme:
für die Absender wird immer die maximal definierte Länge belegt).
Dadurch wird es in der Realität so gut wie nie passieren, daß Header
gekürzt werden müssen oder (im Falle von U/X-Headern) wegen
Speichermangel verlorengehen.
MY:
- Für alle Adressen-Header wird beim UUZ-Start ein Speicherminimum
reserviert, durch das garantiert ist, daß für eine definierte
Mindestanzahl von Adressen mit max. theoretisch möglicher Länge
immer ausreichend Speicher zur Verfügung steht:
EMP: 20 Adressen/Newsgroups
OEM: 1 Adresse
KOP: 20 Adressen + 20 Realnames
ABS: 5 Adressen + 5 Realnames
WAB: 1 Adresse + 1 Realname
Antwort-an: 5 Adressen + 5 Realnames
Diskussion-in: 20 Adressen/Newsgroups
Steht dieses Speicherminimum (derzeit 26.480 Bytes) schon beim
Programmstart nicht zur Verfügung, bricht der UUZ die Verarbeitung
unmittelbar ab.
MY:
- Folgende Variablenwerte wurden geändert:
AdrLen (Länge Adressen) : 238 (bisher: 120)
RealnLen (Länge Realnames) : 160 (bisher: 120)
MaxEmp (max. Anzahl Empfänger) : 125 (bisher: 50)
MaxKop (max. Anzahl Kopienempfänger): 125 (bisher: 60)
MaxAbs (max. Anzahl Absender) : 50 (bisher: 1)
MaxReplyTo (max. Anzahl Antwort-an) : 50 (bisher: 1)
MaxFollow (max. Anzahl Followup-NGs) : 50 (bisher: 10)
Keywords (Länge Stichworte) : 242 (bisher: 60)
Summary (Länge Zusammenfassung) : 236 (bisher: 200)
BetreffLen (Länge Betreff) : 248 (bisher: 250)
Die Werte für Keywords, Summary und BetreffLen spielen bei ein-
gehenden Nachrichten allerdings keine Rolle, da diese Header ohnehin
in voller Länge geschrieben werden (siehe oben).
4.2. Ausgehende Nachrichten (ZConnect => RFC)
----------------------------------------------
MY:
- Fix: Beim Schreiben von Headern, bei denen durch MIME-Codierung oder
Quoting und die damit verbundene Verlängerung der Headerzeile die
bisherige Längenbeschränkung von 254 Zeichen zwangsläufig zu einem
Zeichenverlust und/oder defekten Headern geführt hat, ist die aus
der Codierung bzw. dem Quoten resultierende Länge jetzt nicht mehr
begrenzt (ein Betreff aus z.B. 200 "ä" erzeugt jetzt über die neue
Routine 'EncodeFoldQuote einen 806 Zeichen langen und korrekt
codierten/gefalteten "Subject:"-Header).
Damit ist jetzt gewährleistet, daß keine von XP erzeugten Header
mehr gekürzt oder defekte MIME-Header produziert werden.
MY:
- Umfassende Änderungen und Korrekturen bzgl. der Erstellung des
Nachrichten-Body:
1. Fix: Lange Zeilen mit mehr als 253 Zeichen in uncodierten Nach-
richten werden jetzt nicht mehr willkürlich nach 253 Zeichen
umbrochen, sondern bis 998 Zeichen in voller Länge geschrieben
(998 Zeichen ist die RFC-seitig und in der Praxis definierte
Zeilenlänge, bis zu der ein sicherer Transport der Nachricht
sichergestellt ist).
Zeilen mit mehr als 998 Zeichen werden an Position 998 bzw. vor
dem letzten davor befindlichen "white space" sinnvoll umbrochen
("sinnvoll" heißt: Wenn das nächste Wort so lang ist, daß es
mangels Leerzeichen nicht vollständig in die nächste Zeile paßt
und daher ohnehin auseinandergerissen werden muß, dann wird der
Anfang dieses Worts noch an das Ende der aktuellen Zeile
angehängt und an Position 998 umbrochen).
2. Fix: Bei "quoted-printable"-codierten Nachrichten entsteht jetzt
kein Zeichenverlust mehr, wenn die codierte Zeile länger als 254
Zeichen wird (bisher wurden Zeichen jenseits dieser Grenze durch
die qp-Codierung und die damit verbundene Verlängerung der Zeile
nach rechts ins Nirwana rausgeschoben und damit vernichtet).
3. Fix: Wenn in SMTP-Mails eine uncodierte Zeile mit mehr als 998
Zeichen umbrochen oder eine qp-codierte Zeile mit mehr als 76
Zeichen nach einem "soft line break" in der nächsten Zeile fort-
gesetzt wird, wird jetzt auch in diesen Fällen der erforderliche
zusätzliche Punkt "." am Zeilenanfang der folgenden Zeile hinzu-
gefügt, wenn diese mit einem Punkt beginnt. Bisher geschah das
nicht, der einzelne Punkt am Zeilenanfang wurde beim Empfänger
RFC-konform entfernt und fehlte somit dann dort (blöd z.B. bei
URLs).
Bei via NNTP versandten Postings gelten diesbezüglich zwar
dieselben Regeln wie bei SMTP-Mails, dort wird das Hinzufügen
bzw. Entfernen von Punkten am Zeilenanfang aber vom Client
übernommen. Deshalb fügt der UUZ dort zwar keinen Punkt hinzu,
berücksichtigt das nachträgliche Hinzufügen seitens des Clients
aber insofern, als daß er in den jeweiligen Fällen eine um ein
Zeichen kürzere Zeile erzeugt, damit keine unzulässig langen
Zeilen (mit -qp max. 76 Zeichen, ohne -qp max. 998 Zeichen)
entstehen können.
4. Fix: Bei "quoted-printable"-codierten Nachrichten wird das Leer-
zeichen hinter dem Signaturtrenner "--" jetzt gemäß RFC2045 als
"=20" codiert und dadurch beim Empfänger nicht mehr vernichtet.
5. Fix: Lo-ASCIIs in "quoted-printable"-codierten Nachrichten werden
jetzt gemäß RFC2045 ebenfalls codiert.
6. Wenn schon quoted-printable, dann richtig: Die EBCDIC-kritischen
Zeichen !"#$@[\]^`{|}~ werden jetzt gemäß RFC2045 ebenfalls
codiert.
7. Fix: Außer bei Signaturtrennern werden die XP-typischen Leer-
zeichen am Zeilenende (entstehen durch den internen XP-Editor und
kennzeichnen dort einen "fortlaufend umbrochenen" Absatz) jetzt
bei allen Nachrichten entfernt, weil sie schlicht überflüssig
sind und bei "quoted-printable"-codierten Nachrichten außerdem
codiert werden müßten (was bisher entgegen der qp-Definition in
RFC2045 nicht der Fall war). Nebenbei wird damit auch vermieden,
daß beim Quoten von XP-Nachrichten zusätzliche Leerzeichen
entstehen können.
5. Beteiligte Entwickler und geänderte Dateien
------------------------------------------------
MY - Michael Heydekamp (Redesign/Rewrite des UUZ)
SV - Stefan Vinke (Anlaufstelle für programmiertechnische
Detailfragen während der Entwicklung)
JM - Joachim Merkel (Profiling / Performance-Optimierung)
JG - Jochen Gehring (Euro-Support, erweiterter Unicode-Support)
Des weiteren wurden der EOL-Bugfix für News-Batches von MK (Markus
Kämmerer) aus OpenXP/32 sowie die Unterstützung des Parameters
"-bBoxname" von MH (Max Huckenbeck) und des Headers "X-XP-Mode:" von
RB (Robert Böck) aus XP2 übernommen.
UUZ.PAS, UUZ0.PAS (neue Unit mit ausgelagerten Routinen wegen
Überschreitung der Codesegment-Grenzen in UUZ.PAS), MIMEDEC.PAS,
XP0.PAS, XPMAKEHD.INC, XPOVL.PAS
6. Credits
------------
Die oben beschriebenen Arbeiten am "Enhanced UUZ" hätten ohne die
wertvolle Hilfe folgender direkt oder indirekt Beteiligter nicht
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)
FreeXP bedankt sich bei allen genannten und nicht genannten
Beteiligten.
+--------------+
| 30.08.2003 |
+--------------+
MY:
- Versionsmeldung auf "FreeXP" geändert und mit aktuellen Units
neu compiliert. Keine weiteren inhaltlichen Änderungen.