Michael Heydekamp <[EMAIL PROTECTED]> wrote on 23.10.04:
[...]
> Siehe das Changelog der aktuellen UUZ-Testversion, den Stand der
> danach erfolgten (und noch nicht ver�ffentlichten, weil noch nicht
> fertigen) �nderungen h�nge ich mal an, damit man sich mal ein
> plastisches Bild machen kann (siehe n�chstes Posting).
H�ngt dran.
MichaelHinweis:
--------
Dieses Dokument beschreibt zur besseren �bersicht f�r die Tester nur die
Unterschiede zwischen der aktuellen und der vorherigen Testversion des
Enhanced UUZ/II. Die Texte aus Teil I. sind ebenfalls in UUZ_TEST.TXT
enthalten, die Texte aus Teil II. nicht (sie beschreiben die Behebung
von mit der vorherigen Testversion neu eingef�hrten Bugs bzw. erneute
�nderungen von erst mit der vorherigen Testversion eingef�hrten �nde-
rungen).
Michael Heydekamp <[EMAIL PROTECTED]>
I. Neue mit Enhanced UUZ/II v3.40.1c (Testversion) eingef�hrte Fixes
und �nderungen gegen�ber dem Enhanced UUZ vom 31.08.2003
=======================================================================
MY:
- Fix (-uz): Logik-Bug in der MIME-Decodierung behoben
----------------------------------------------------------------------
In dem in der t�glichen Praxis bisher nicht eingetretenen Fall, da�
bei zwei unmittelbar aufeinanderfolgenden 'encoded words' die Anzahl
der sich zwischen diesen 'encoded words' befindlichen (und daher zu
entfernenden) Leerzeichen gr��er/gleich der Anzahl der f�r die MIME-
Delimiter (z.B. "=?US-ASCII?Q?...?=") des ersten 'encoded word'
verwendeten Zeichen war, entstand ein Arithmetik-�berlauf, in dessen
Folge es nicht nur zu einem fehlerhaft decodierten Header, sondern zu
allen erdenklichen und unkalkulierbaren Folgen bis hin zu einer v�llig
unbrauchbaren Nachricht oder gar einem (theoretischen, weil bisher
nicht konkret beobachteten) Absturz kommen konnte.
Der Bug wurde vom Autor rein zuf�llig anl��lich eines von ihm selbst
zu Testzwecken im Bereich Headerfolding erstellten Postings entdeckt
(siehe Message-ID <[EMAIL PROTECTED]> in der Newsgroup
de.comm.software.newsserver).
MIMEDEC.PAS
MY:
- Diverse Erweiterungen, Anpassungen und Korrekturen bei RFC-Headern,
die Datums-/Uhrzeit-/Zeitzonenangaben enthalten (-zu):
----------------------------------------------------------------------
1. Die Header "Date:", "Received:", "From_" (nur UUCP-Mails) und der
MIME-Parameter "modification-date=" enthalten neben Datum, Uhrzeit
und Zeitzone jetzt auch den Wochentag in dem in RFC2822 definierten
Format ("Mon, ", "Tue, " usw.).
2. Der "Date:"-Header wird nicht mehr als allererster Header, sondern
im Anschlu� an den "Subject:"-Header geschrieben (Anpassung an
�bliche Gepflogenheiten).
3. Die "From_"-Zeile von UUCP-Mails enth�lt nicht mehr Erstellungs-
datum und -uhrzeit der Nachricht im RFC-Format (wie es im "Date:"-
Header steht), sondern es wird eine Zeile mit dem *aktuellen*
Datum/Uhrzeit im sog. "asctime"-Format erzeugt:
- Bisher: From my 06 Oct 2004 19:08:33 +0200 remote from freexp.de
- Jetzt : From my Wed Oct 6 19:09:24 2004 remote from freexp.de
Das RFC-Format ist sowohl laut der Beispiele in RFC976 als auch in
der Praxis beim UUCP-Austausch an dieser Stelle zumindest un�blich,
m�glicherweise sogar falsch.
Unklar (weil in RFC976 nicht geregelt) ist bisher, ob dort Lokal-
zeit oder UTC erwartet wird. Momentan verwendet der UUZ dort die
Lokalzeit, wie es auch aus einigen Praxisbeispielen ersichtlich
war.
4. Bei Headern, die das aktuelle Datum/Uhrzeit enthalten ("Received:",
"From_"-Zeile bei UUCP-Mails), wird die Zeitzone nicht mehr blind
aus dem Erstellungsdatum im EDA:-Header der Nachricht �bernommen,
da dies im Fall, da� Erstellungs- und Konvertierdatum in unter-
schiedlichen Zeitperioden liegen (Beispiel: Nachricht wird am Abend
des letzten Tages der Sommerperiode erzeugt, aber erst in der Nacht
oder am n�chsten Morgen konvertiert und versandt), zu einer falsch
deklarierten Zeitzone f�hren w�rde - bzw. in der Vergangenheit auch
konkret dazu gef�hrt hat.
Stattdessen wird die aktuelle Zeitzone jetzt mit zwei alternativen
Verfahren ermittelt:
a) Wenn die TZ-Variable - wie es im Normalbetrieb mit XP der Fall
ist - nicht (oder nicht im korrekten Format) gesetzt ist, ist
die im EDA:-Header deklarierte Zeitzone des Erstellungsdatums
zwar nach wie vor die entscheidende Grundlage, jedoch wird jetzt
zus�tzlich gepr�ft, ob Erstellungs- und aktuelles Datum in der-
selben Zeitperiode liegen. Ist dies nicht der Fall, wird die
Zeitzone des aktuellen Datums aus der Zeitzone des Erstellungs-
datums errechnet, indem je nach Konstellation 1 Stunde addiert
(Winter => Sommer) bzw. subtrahiert (Sommer => Winter) wird.
Liegen Erstellungs- und aktuelles Datum in derselben Zeit-
periode, wird die Zeitzone wie bisher aus dem Erstellungsdatum
unver�ndert �bernommen.
Ma�gebend f�r die Definition der Zeitperiode ist ausschlie�lich
die aktuell f�r die EU geltende Regelung, deren Algorithmus auch
bei der automatischen Zeitzonenumstellung in FreeXP verwendet
wird. Die Angabe "S" bzw. "W" im ZConnect-Header ist unzuverl�s-
sig und wird wie bisher ignoriert.
Das obige Verfahren funktioniert daher in allen F�llen zuverl�s-
sig, in denen die Konvertierung in einem Land stattfindet, in
dem a) eine mit der in der EU geltenden Regelung identische
Winter-/Sommerzeitregelung angewandt wird, und b) dessen Zeit-
zone identisch ist mit dem Land, in dem die Nachricht erstellt
wurde (was nahezu immer der Fall sein d�rfte). Mit anderen
Worten: Bisher stimmte die Zeitzonenangabe im geschilderten Fall
praktisch nie, jetzt stimmt sie praktisch immer.
b) Durch das Setzen der Umgebungsvariablen "TZ" im Format
set TZ=CET-1CEST,3,-1,0,7200,10,-1,0,10800,3600
kann das in a) beschriebene Verfahren neutralisiert werden;
stattdessen wird dann die in der TZ-Variablen deklarierte Zeit-
zone in jedem Fall und v�llig unabh�ngig von der im EDA:-Header
deklarierten Zeitzone des Erstellungsdatums �bernommen.
Das obige Beispiel gilt f�r Mitteleuropa und w�rde in der
Winterperiode die Zeitzone "+0100" (ZConnect: W+1) und in der
Sommerperiode die Zeitzone "+0200" (ZConnect: S+2) zur�ckgeben.
F�r andere L�nder sind die Werte entsprechend anzupassen, eine
ausf�hrliche Erl�uterung zur TZ-Variablen befindet sich in der
FreeXP-Hilfe zum Men�punkt C/O/N/Umstellung.
Durch die Verwendung der TZ-Variablen ist der UUZ daher in der
Lage, in allen L�ndern mit einer beliebigen (oder gar keiner)
Winter-/Sommerzeitregelung die korrekte Zeitzone des aktuellen
Datums zu deklarieren.
Zwingend erforderlich ist die Verwendung der TZ-Variablen im
Grunde dann, wenn der UUZ als Gate-Konvertierer eingesetzt wird:
Dort k�nnen Nachrichten aus beliebigen Zeitzonen vorkommen (aus
denen ohne TZ-Variable unterschiedliche lokale Zeitzonen berech-
net w�rden), w�hrend dem UUZ im Standardbetrieb mit XP nur Nach-
richten aus einer einzigen Zeitzone (n�mlich der des Users)
vorgelegt werden.
5. Enth�lt der EDA:-Header keine Zeitzonenangabe, gelten automatisch
jetzt MEZ (=CET, =UTC+1, Winter) bzw. MESZ (=CEST, =UTC+2, Sommer)
als Defaultwerte, da die Angabe einer Zeitzone im "Date:"-Header
gem�� RFC2822 Pflicht ist und die bisherige Angabe von "?0000" (mit
einem beliebigen und zufallsabh�ngigen Zeichen als "Vorzeichen")
unbrauchbar war.
6. Ist der EDA:-Header leer bzw. existiert �berhaupt nicht, wird statt
eines ung�ltigen "Date:"-Headers mit dem Inhalt " Jan :: 0000"
jetzt ein g�ltiger Header mit dem aktuellen Datum/Uhrzeit und der
Zeitzone MEZ/MESZ im korrekten Format erzeugt (da der Header
Pflicht ist, war der totale Verzicht keine Option).
7. Bei der Datums-/Zeitangabe von Dateien (Quelle: DDA:-Header) im
MIME-Parameter "modification-date=" wird als Zeitzone nicht mehr
"+0000", sondern "-0000" deklariert. Das negative Vorzeichen signa-
lisiert gem�� RFC2822, da� keine Information �ber eine Zeitzone
vorliegt, w�hrend "+0000" signalisiert, da� es sich exakt um die
Zeitzone "UTC" handelt.
8. Bei allen anderen Zeitzonenangaben wird eine evtl. als "W-0" oder
"S-0" im EDA:-Header deklarierte Zeitzone zu "+0000" korrigiert und
konvertiert.
9. (Zu sp�ter) Y2K-Fix: Bei einer Nachricht, die am ersten Tag eines
neuen Jahrhunderts zu einer Uhrzeit erzeugt wurde, zu der das kor-
respondierende Datum in UTC-Zeitrechnung noch im alten Jahrhundert
lag (in unserer Zeitzone also am 01.01.2000 zwischen 00:00 und
00:59 Uhr, in Australien zwischen 00:00 und 11:59 Uhr), dann wurde
bei der Konvertierung - und zwar unabh�ngig davon, wann und wo
diese stattfand - f�lschlicherweise das Jahr "1900" statt "2000"
deklariert, weil aus der den lokalen Zeitstempel (und eine nur
zweistellige Jahresangabe) enthaltenden Variable 'hd.datum' das
Jahrzehnt "00" und aus der den UTC-Zeitstempel (sowie ein vierstel-
liges Jahr) enthaltenden Variable 'hd.zdatum' das Jahrhundert �ber-
nommen und so zu "1900" zusammengesetzt wurde. Dieser Fall wird
jetzt korrekt behandelt, was sich in der Praxis aber erst wieder in
gut 95 Jahren positiv bemerkbar machen wird, wenn der letzte noch
aktive FreeXP-User kurz nach Silvester tapfer seine Neujahrsgr��e
verfa�t. ;-)
UUZ.PAS, UUZ0.PAS
MY:
- �nderung (-uz): Bei der ZC=>RFC-Konvertierung von Postings mit dem
Schalter "-client" (= NNTP-Betrieb) wird - sofern nicht durch die
Existenz der Datei 'ADDGATE' gleichzeitig ein Gatebetrieb signalisiert
wird - kein "Path:"-Header mehr erzeugt. Gr�nde:
1. Der Header wird von den gro�en Newsservern (news.t-online.de,
news.individual.de) ohnehin mit "not-for-mail" �berschrieben und
ist i.d.R. schon von daher �berfl�ssig.
2. Es besteht beim clientseitigen Einliefern eines Postings beim
Newsserver keine technische Notwendigkeit f�r diesen Header; er
wird daher auch von keinem (dem Autor bekannten) Newsreader
generiert.
3. Der Header enth�lt die Mailadresse im Format "do.main!user". Usern,
die zum Zweck der Spam-Vermeidung ihre Absenderadresse bei Postings
mittels eines Ausgangsfilters �ndern, wird i.d.R. nicht bewu�t
sein, da� sie den ZConnect-Header "ROT:" ebenfalls anpassen
m�ssten, wenn sie �ber einen Server posten, der den "Path:"-Header
nicht �berschreibt (wie z.B. news.freexp.de). Es w�rde daher
unbewu�t und ungewollt �ber den "Path:"-Header eine Mailadresse
preisgeben werden, was mit dem �ndern der Absenderadresse gerade
vermieden werden soll.
4. Beim Posten von vom UUZ erzeugten RFC-Postings in technische
Newsgroups kommt es seitens der Teilnehmer bisweilen zu Fehlinter-
pretationen und Mi�verst�ndnissen hinsichtlich des "Path:"-Headers
und infolgedessen zu Fragen an den User, die oft nicht (oder nicht
korrekt) beantwortet werden k�nnen.
UUCP-Postings sind von der �nderung nicht betroffen.
UUZ.PAS
MY:
- �nderung (-zu): Bei der RFC=>ZC-Konvertierung von UUCP-Mails mit einer
mit dem String "From_" beginnenden ersten Zeile wird die Bildschirm-
ausgabe des Envelope-Absenders "from [EMAIL PROTECTED]" hinter dem Datei-
namen dann nicht mehr erzeugt, wenn ein solcher aus der "From_"-Zeile
gar nicht ermittelt werden konnte (bisher wurde in diesem Fall dennoch
"from_" ohne Adresse ausgegeben, was "broken" wirkte).
UUZ.PAS
MY:
- Interne �nderung: Anzahl der Zeichen, die sich nach dem Aufruf von
'ReadString' mindestens noch im Puffer befinden m�ssen, von 4 auf 5
erh�ht (Vorbereitung f�r mbox-Unterst�tzung).
UUZ0.PAS
MY:
- Anpassungen und Korrekturen in der Routine 'ReadRFCheader' (auch im
Vorgriff auf mbox-Unterst�tzung, siehe n�chster Abschnitt):
----------------------------------------------------------------------
1. Die Routine pr�ft jetzt - �hnlich wie bisher schon 'ReadRfcBody' -
bei der RFC=>ZC-Konvertierung von SMTP- und mbox-Mails anhand der
einschl�gigen Merkmale (".", "From_") "vorausschauend" auf das Ende
der Nachricht. Wird festgestellt, da� die Mail in der n�chsten
Zeile beendet ist (bzw. im Falle mbox, da� mit der n�chsten Zeile
eine neue Mail beginnt), wird das Lesen des Headers abgebrochen.
2. Ung�ltige RFC-Headerzeilen mit einem Bezeichner, der Leerzeichen
enth�lt, werden jetzt verworfen (die eine mbox-Nachricht einleiten-
de "From_"-Zeile enth�lt oft Doppelpunkte in einer Uhrzeitangabe
und w�rde daher sonst mit RFC-Headern verwechselt werden).
3. Nicht mehr verworfen hingegen werden Zeilen mit/ohne Leerzeichen
oder Doppelpunkten, die sich *nach* einer *unmittelbar* auf den
SMTP-Header "DATA" bzw. die eine mbox-Mail einleitende "From_"-
Zeile folgenden Leerzeile befinden. Diese Zeilen werden jetzt als
Body betrachtet, obwohl (bzw. weil) eine so beschaffene Mail per
Definition gar keinen RFC-Header enth�lt. Es wird dann eine Nach-
richt mit den (�berwiegend leeren) ZConnect-Pflichtheadern und
einem Body erzeugt.
4. ASM-Routine 'LoZZ' entsorgt und durch 'LoString(zz)' ersetzt.
'LoZZ' konnte zu einem RTE 204 oder zu defekten Nachrichten f�hren,
wenn der �bergebene String leer war (was z.B. vorkommt, wenn eine
Zeile im Header keinen Doppelpunkt - und also keinen Bezeichner -
hat).
Alle beschriebenen Ma�nahmen dienen dazu,
a) auch dann formal halbwegs korrekte und sauber lesbare Resultate zu
produzieren, wenn der zu konvertierende RFC-Puffer fehlerhaft ist
(SMTP/mbox-Mail ohne RFC-Header, mit oder ohne Body), statt wie
bisher in solchen F�llen zu mitunter (zuf�lligen) fatalen Folgen
wie Abst�rzen, Endlosschleifen oder defekten ZConnect-Puffern zu
f�hren, und
b) Anfang und Ende jeder SMTP/mbox-Mail in Puffern mit mehreren Nach-
richten unter allen (un)denkbaren Umst�nden sicher und korrekt zu
erkennen, auch wenn der Bereich zwischen den jeweiligen Schl�ssel-
zeilen ("DATA" und "." bei SMTP-Mails, mit "From_" beginnende
Zeilen bei mbox-Nachrichten) nicht den erwarteten standardkonformen
(oder auch gar keinen) Inhalt hat. Damit werden jetzt auch bei
einem BSMTP-Puffer wie ...
----------------------------
HELO freexp.de
MAIL FROM:<[EMAIL PROTECTED]>
RCPT TO:<[EMAIL PROTECTED]>
DATA
.
QUIT
HELO freexp.de
MAIL FROM:<[EMAIL PROTECTED]>
RCPT TO:<[EMAIL PROTECTED]>
DATA
.
QUIT
----------------------------
... trotz des Fehlens aller Header und des Body zwei (nat�rlich
leere) Nachrichten erzeugt. Ein mbox-Puffer wie ...
---------------------------------
From - Sun Sep 26 08:04:46 2004
From - Sun Sep 27 09:05:47 2004
From - Sun Sep 28 10:06:48 2004
---------------------------------
... wird zu drei (ebenfalls leeren) Nachrichten konvertiert.
Im Zusammenhang mit der neu implementierten mbox-Unterst�tzung war ein
Teil dieser Ma�nahmen ohnehin schlicht notwendig, da mbox-Mails anders
als (B)SMTP-Mails kein definiertes Ende (sondern nur einen definierten
Anfang) haben.
UUZ.PAS, UUZ0.PAS
MY:
- Neue Importschnittstelle "mbox" implementiert (-uz):
----------------------------------------------------------------------
1. Der Enhanced UUZ/II unterst�tzt neben UUCP- und (B)SMTP-Mails jetzt
auch Mailpuffer im mbox-Format. Damit k�nnen mbox-Puffer, die von
den meisten Mailreadern beim Export erzeugt werden und beliebig
viele Nachrichten enthalten k�nnen, in das ZConnect-Format konver-
tiert und anschlie�end nach XP importiert werden. Das erleichtert
den Datenaustausch mit diesen Programmen erheblich und es lassen
sich damit auch Mailinglistenarchive, die im mbox-Format zum Down-
load angeboten werden (z.B. Pipermail), komfortabel konvertieren.
2. Von den insgesamt vier existierenden mbox-Formaten werden die
beiden g�ngigsten explizit unterst�tzt:
- mboxo (irreversibles ">From_ quoting")
- mboxrd (reversibles ">From_ quoting")
Da der Anfang jeder mbox-Mail ausschlie�lich an einer mit "From_"
(wobei der Unterstrich f�r ein Leerzeichen steht) beginnenden Zeile
zu erkennen ist, wird beim mbox-Format allen Zeilen in Header und
Body, die ebenfalls mit "From_" beginnen, das Quotezeichen ">"
vorangestellt, damit diese nicht mit dem Beginn einer neuen Mail
verwechselt werden k�nnen.
Bei einer Konvertierung sind diese Quotezeichen daher wieder zu
entfernen. Der Unterschied beider Formate liegt darin, da� bei
"mboxo" nur mit "From_" beginnenden Zeilen ein ">" vorangestellt
wird, w�hrend dies bei "mboxrd" auch bei den Zeilen geschieht, die
vor dem "From_" bereits eine beliebige Anzahl von Quotezeichen
(ohne jedes Leerzeichen dazwischen!) besitzen.
Entsprechend unterschiedlich ist beim Ent-Quoten zu verfahren:
- mboxo: Das ">From_ quoting" des mboxo-Formates ist nicht voll-
st�ndig reversibel, weil Zeilen, die schon von vornehe-
rein mit ">From_" beginnen, nicht von denen zu unter-
scheiden sind, die mit "From_" begannen und erst beim
Schreiben des Formats mit einem Quotezeichen versehen
wurden. Es kann also bei mboxo-Mails im Unterschied zum
mboxrd-Format im Einzelfall vorkommen, da� Quotezeichen
vor Zeilen entfernt werden, bei denen sie eigentlich
nicht h�tten entfernt werden sollen. Dies ist prinzip-
bedingt nicht zu vermeiden.
- mboxrd: Die meisten Mailreader d�rften allerdings inzwischen das
mboxrd-Format verwenden. Dort existiert dieses Problem
nicht, weil eine urspr�nglich mit ">From_" beginnende
Zeile beim Schreiben des mbox-Puffers zu ">>From_" umge-
wandelt (und vom UUZ wieder zu ">From_" zur�ckgewandelt)
wird. Da sich beim mboxrd-Format theoretisch beliebig
viele ">" vor einer mit "From_" beginnenden Zeile befin-
den k�nnen, wird auch der Fall abgefangen, da� die Anzahl
der ">" gr��er ist als die maximale L�nge eines Pascal-
Strings. Auch wenn dem String "From_" z.B. 741 Quote-
zeichen ">" vorangehen sollten und/oder sich die String-
grenze mitten in einem "From_" befindet, wird dies
korrekt erkannt und genau ein ">" entfernt.
Leider geben die meisten Programme keinerlei Auskunft dar�ber,
welches mbox-Format sie unterst�tzen bzw. generieren, so da� im
Zweifel nur Ausprobieren (d.h. gezielter Export von Testmails, die
entsprechende Zeilen enthalten) hilft.
Wem das zu aufwendig ist oder wer keine M�glichkeit dazu hat,
sollte vom mboxo-Format als kleinstem gemeinsamen Nenner ausgehen.
3. Da auch der Anfang einer UUCP-Mail an einer mit "From_" beginnenden
Zeile zu erkennen ist, gibt es leider keine M�glichkeit, UUCP-Mails
programmseitig sicher und zuverl�ssig von mbox-Mailpuffern zu
unterscheiden. Zwar k�nnen sich nie mehrere UUCP-Mails in einer
Datei befinden und es findet dort auch kein ">From_ quoting" statt,
aber weder mu� ein mbox-Mailpuffer mehrere Mails enthalten noch ist
die Existenz von weiteren mit "From_" beginnenden Zeilen nach der
einleitenden "From_"-Zeile garantiert (sondern man kann eher meist
vom Gegenteil ausgehen). Eine Erkennung �ber den in der ersten
"From_"-Zeile von UUCP-Mails meistens vorkommenden String "remote
from" ist nicht zuverl�ssig genug, au�erdem l�ge selbst dann immer
noch keine Information dar�ber vor, *welches* mbox-Format konver-
tiert werden soll.
Es war daher nicht zu vermeiden, f�r die jeweiligen mbox-Formate
eigene Kommandozeilenschalter zur Verf�gung zu stellen und die
Verantwortung f�r deren korrekte Verwendung dem User zu �bertragen:
- Schalter "-mboxo" f�r das mboxo-Format;
- Schalter "-mboxrd" bzw. schlicht "-mbox" (weil Quasi-Standard)
f�r das mboxrd-Format.
Bei beiden Formaten wird als Netztyp "41" (= RFC/Client) in den
XP-Header "X-XP-NTP:" geschrieben. Der Dateiname ist wie bei allen
anderen Nachrichtenformaten beliebig.
4. Die letzte Leerzeile am Ende einer mbox-Mail wird entfernt, da sie
beim Schreiben des mbox-Mailpuffers zus�tzlich erzeugt wurde (bzw.
erzeugt worden sein sollte - das Format sieht vor, da� sich vor
jeder eine Mail einleitenden "From_"-Zeile eine Leerzeile befindet,
worauf man sich aber hinsichtlich der Erkennung des Anfangs einer
Mail nicht verlassen kann).
5. Infolge der im vorherigen Abschnitt beschriebenen Anpassungen in
der Routine 'ReadRFCheader' sowie der prinzipiellen Gleichbehand-
lung von (B)SMTP- und mbox-Nachrichten beim Lesen des Body in der
Routine 'ReadRfcBody' ist gew�hrleistet, da� alle in diesem
Dokument an anderer Stelle ausf�hrlich beschriebenen Fixes und
Korrekturen f�r die Decodierung und Konvertierung von qp/base64-
und/oder UTF-7/8-codierten Nachrichten (Stichworte 'start_of_UTF',
'end_of_UTF' und 'maxUTFLen') in gleicher Weise auch f�r Mails im
mbox-Format gelten und dort greifen.
6. Eine Envelope-From-Adresse in der "From_"-Zeile wird erkannt und in
den WAB:-Header �bernommen. (Dazu wird die im Zuge dieser �nderun-
gen ebenfalls deutlich verbesserte Routine 'mailstring' aus
XPOVL.PAS verwendet, die jetzt auch Kommentare, quoted-strings,
quoted-pairs und Domain-Literale gem�� RFC2822 unterst�tzt).
7. Die Formate "mboxcl" und "mboxcl2", die sich von den obigen durch
die Existenz eines Content-Length-Headers unterscheiden, werden
zwar nicht explizit unterst�tzt, k�nnen aber - mit kleinen Ein-
schr�nkungen - dennoch mit der vorliegenden Fassung des Enhanced
UUZ/II konvertiert werden (bei beiden Formaten ist *ausschlie�lich*
der Schalter "-mboxo" zu verwenden!):
- mboxcl: Verwendet dasselbe irreversible ">From_ quoting" wie das
mboxo-Format und daher gelten hierf�r auch dieselben
Hinweise. Obwohl der Content-Length-Header vom UUZ nicht
ausgewertet wird, sollte die Konvertierung ansonsten
genauso fehlerfrei sein wie beim mboxo-Format.
- mboxcl2: Verwendet (leider) gar kein ">From_ quoting" und verl��t
sich stattdessen ganz auf die - wenn man den verwendeten
Quellen glauben darf, allerdings unzuverl�ssige -
Gr��enangabe im Content-Length-Header. Es kann daher
passieren, da� bei der Konvertierung f�lschlicherweise
der Beginn einer neuen Nachricht erkannt wird, wenn im
Body eine mit "From_" beginnende Zeile vorkommen sollte.
Sorry, nicht zu vermeiden - allerdings wird das Format
zum Gl�ck auch selten bis gar nicht benutzt.
Der Aufwand f�r eine "richtige" Unterst�tzung f�r diese seltenen
mbox-Formate w�re momentan nicht zu rechtfertigen.
8. Die mbox-Unterst�tzung wurde mit gro�er Sorgfalt entwickelt und
so intensiv wie m�glich getestet. Zum Abschlu� wurde ein 5,5MB
gro�er mbox-Puffer der Support-Mailingliste von FreeXP (siehe
http://www.freexp.de/pipermail/support-list.mbox/support-list.mbox)
mit insgesamt 1.502 Mails fehlerfrei konvertiert. :-)
Des weiteren wurde sichergestellt, da� die vorgenommenen �nderungen
im Source nicht zu neuen Problemen bei der Konvertierung "normaler"
Mails und Postings in den schon bisher unterst�tzten Formaten
f�hren k�nnen.
9. Quellen, die f�r die Entwicklung der mbox-Unterst�tzung als Grund-
lage dienten:
http://www.qmail.org/qmail-manual-html/man5/mbox.html
http://homepages.tesco.net/~J.deBoynePollard/FGA/mail-mbox-formats.html
UUZ.PAS, UUZ0.PAS
II. Fixes und �nderungen Enhanced UUZ/II v3.40.1c gegen�ber v3.40.1b
(Testversion) - nur Routinen betreffend, die in v3.40.1b gegen�ber
v3.40.1a bereits ge�ndert waren und/oder durch die neue Bugs
erzeugt wurden
======================================================================
(keine)
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
