Hans-Juergen Taenzer <[EMAIL PROTECTED]> wrote on 07.07.04:
> Alfred Schroeder ([EMAIL PROTECTED]) wrote:
>> Es scheint in letzter Zeit Mode zu werden, dass Listserver
>> (hier: X-Mailer: Listserv for OMO 1.0) "Binary" als
>> Content-Transfer- Encoding angeben, obwohl -abgesehen von LF-
>> keinerlei Zeichen ausserhalb 7Bit vorkommen.
> Leider kein Einzelfall. Heute kam die n�chste Mail (von t-online) mit
> gleicher Charakteristik.
Alex' Mail war ja auch von T-Online.
Bin dabei, der Teil ist eigentlich fertig und auch schon dokumentiert
(wen's interessiert, siehe Anhang). Morgen oder �bermorgen vielleicht,
ich wollte noch ein bi�chen im Debugger tracen (um auszuschlie�en, da�
die Umbauten nur zuf�llig funktionieren).
MichaelNeue Fixes und �nderungen im Enhanced UUZ/II v3.40.1b (Testversion)
gegen�ber dem Enhanced UUZ vom 31.08.2003
===================================================================
MY:
- Fix (-uz): Erkennung von Text-/Bin�rnachrichten �berarbeitet
----------------------------------------------------------------------
Anl��lich einer ausschlie�lich aus Textteilen bestehenden, aber
dennoch im Header "Content-Transfer-Encoding:" als "binary" deklarier-
ten Multipart-Nachricht, die folgerichtig vom UUZ mit dem ZConnect-
Header "TYP: BIN" und daher in XP mit dem Flag "B" versehen und dort
auch als solche behandelt wurde, wird die Klassifizierung einer Nach-
richt als Text- oder Bin�rnachricht jetzt nur noch vom Inhalt des
Headers "Content-Type:" abh�ngig gemacht:
a) Alle Nachrichten vom "Media Type" text/*, multipart/* und 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 k�nnen, diese aber nicht vom UUZ, sondern erst sp�ter in
XP selbst beim �ffnen oder Extrahieren des jeweiligen Nachrichten-
teils behandelt und ggf. decodiert werden.
b) Demzufolge gelten als Bin�rnachrichten nur noch alle Singlepart-
Nachrichten vom "Media Type" application/*, image/*, audio/* und
video/* (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 vorkommen, da� einerseits qp-codierte Bin�rnach-
richten als Textnachrichten, andererseits aber base64-codierte oder
als "binary" deklarierte Text- oder Multipart-Nachrichten f�lsch-
licherweise 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 seit jeher zeilenorien-
tiert arbeitet, auf die korrekte Behandlung eingehender uncodierter
Bin�rdaten auch gar nicht ausgelegt und die Lese- und Schreibrouti-
nen m��ten komplett neugeschrieben werden, um die Ersetzung von
Zeilenumbr�chen (CR=>CRLF) und die damit verbundene Ver�nderung
uncodierter Bin�rdaten zu verhindern - aber selbst dann w�rden
diese Daten 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.
Die beschriebenen �nderungen f�hren in der Praxis z.B. dazu, da� beim
Beantworten einer f�lschlicherweise als Bin�rnachricht erkannten Text-
nachricht 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 wird jetzt bei Textnachrichten, die
bisher f�lschlicherweise als vermeintliche Bin�rnachricht erkannt
wurden, die erforderliche Zeichensatzkonvertierung durchgef�hrt, und
es ist jetzt sichergestellt, da� das weiter oben beschriebene Anh�ngen
von Zeilenumbr�chen (CRLF) an das Ende eines ZConnect-Puffers im
Bedarfsfall nur noch bei echten Textnachrichten (daf�r jetzt aber auch
bei *allen* Textnachrichten) erfolgt.
UUZ0.PAS
MY:
- Fix (-uz): Die bisherige Regel, da� Singlepart-Nachrichten vom
"Subtype" */html sowie Multipart-Nachrichten generell keiner Zeichen-
satzkonvertierung 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 XP vorgesehen.)
b) */richtext und */enriched (RTF) - �hnlich wie */html ein Format,
das von XP nicht selbst interpretiert und konvertiert wird und
daher zur korrekten Darstellung ebenfalls an ein externes Programms
�bergeben werden mu�. Umlaute und Sonderzeichen w�rden nach einer
Zeichensatzkonvertierung 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 verwendet wird (statt wie bisher die Entscheidung
mehrfach und jedes Mal neu - und teilweise nach unterschiedlichen
Kriterien - zu treffen).
UUZ0.PAS
MY:
- Diverse interne Code-Optimierungen und -Entr�mpelungen
----------------------------------------------------------------------
- Die bisher nur in zu-Richtung und jetzt auch in uz-Richtung (siehe
oben) verwendete globale Variable 'convibm' wurde nach 'convcharset'
umbenannt.
- (-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').
- (-uz): Die Variablen 'mpart' und 'binaer' werden jetzt nicht mehr an
drei verschiedenen Stellen gesetzt, sondern nur noch einmal zentral
in der Routine 'MimeAuswerten'.
UUZ.PAS, UUZ0.PAS
MY:
- MIME-Boundary an die in den MIME-Routinen von XP verwendete Fassung
angeglichen.
UUZ0.PAS
Fixes und �nderungen Enhanced UUZ/II v3.40.1b gegen�ber v3.40.1a
(Testversion) - nur Routinen betreffend, die in v3.40.1a gegen�ber dem
Enhanced UUZ vom 31.08.2003 bereits ge�ndert waren
======================================================================
MY:
- Fix (-uz): Das Anh�ngen eines CRLF an das Ende des ZConnect-Puffers im
Falle, da� der Puffer nach der Konvertierung nicht mit einem CRLF
endet, erfolgt jetzt nur noch bei Textnachrichten (und nicht mehr bei
Bin�rnachrichten, Abfrage auf 'binaer' war logisch fehlerhaft
implementiert).
UUZ0.PAS
MY:
- Fix (-uz): "Fix" r�ckg�ngig gemacht, der bei qp-codierten (oder gar
nicht codierten) Bin�rnachrichten kein CRLF mehr ans Ende jeder Zeile
anh�ngt (wobei das wegen der bisher geltenden Regeln f�r Bin�rnach-
richten auch als "binary" deklarierte Textnachrichten und Multiparts
betreffen konnte, siehe oben).
UUZ0.PAS------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
