Michael Heydekamp <[EMAIL PROTECTED]> wrote on 04.07.04:
[...]
> Im Grunde dreht sich, wenn ich es richtig sehe, alles um das Setzen
> des Typs in diesen Anweisungen in 'MimeAuswerten':
> ----------8<----------
> qprint:=ismime and (encoding=encQP);
> b64:=ismime and (encoding=encBase64);
> binary:=ismime and (not (ctype in [tText,tMultipart,tMessage]) or
> ((encoding=encBinary) and (ctype<>tText)));
> hd.typ:=iifc((binary or b64) and (ctype<>tText),'B','T');
> ----------8<----------
> D.h. �bersetzt, da� folgende Nachrichten derzeit als "TYP: BIN"
> geflagged und entsprechend behandelt werden (wobei "entsprechend
> behandelt" hei�t: keine Charset-Konvertierung, kein Anh�ngen von
> CRLF):
> 1. Alle mit CTE "base64" deklarierten Singlepart-Nachrichten, die
> nicht dem Content-Type text/* angeh�ren (message/*, application/*,
> image/* usw.).
Hier ist IMO die Bedingung "base64" mindestens unvollst�ndig (qp geh�rt
auch dazu), besser w�re aber, dies zuk�nftig gar nicht mehr von der
Codierung, sondern nur noch vom Content-Type abh�ngig zu machen.
Rein theoretisch - jedenfalls habe ich nichts gefunden, was dagegen
spr�che - k�nnte man uncodierte Bin�rdaten auch als "7bit" oder "8bit"
deklarieren, falls das Binary eben nur solche Daten (und weder EOLs noch
NUL) enth�lt sowie entsprechend kurz ist (bei mehr als 76 Bytes sollte
schon wegen der Zeilenl�nge codiert werden).
Das 'B'-Flag in XP bedeutet, da� die Nachricht echte Bin�rdaten enth�lt,
also sollten auch alle (aber eben auch *nur* die) Nachrichten als 'B'
geflagged werden, die eben solche enthalten.
> 2. Alle mit CTE "7bit", "8bit" oder "quoted-printable" deklarierten
> Singlepart-Nachrichten, die nicht dem Content-Type text/* oder
> message/* angeh�ren.
Steht bzgl. message/* etwas im Widerspruch zu 1. und ist zudem
�berfl�ssig, wenn zuk�nftig ohnehin nur noch der Content-Type ma�gebend
w�re.
> 3. Alle mit CTE "binary" deklarierten Single- und Multipart-Nachrichten,
> die nicht dem Content-Type text/* angeh�ren.
Bzgl. Multipart-Nachrichten gro�er K�se, und bei Singlepart-Nachrichten
w�rde sich auch hier die Pr�fung auf CTE er�brigen, wenn der Content-
Type alleiniger Ma�stab w�re.
> Eigentlich wollte ich schon den ge�nderten Code posten, aber ich will
> das doch lieber nochmal �berdenken und vor allem testen.
Getestet habe ich zwar noch nichts, aber RFC2045 nochmal komplett und
RFC2046 in Teilen gelesen, mir meine Gedanken dazu gemacht und schlage
daher folgende Vorgehensweise im Hinblick auf das Setzen des TYP:-
Headers, der Decodierung, der Behandlung von EOLs sowie der Charset-
Konvertierung vor. Dies stellt gleichzeitig eine nahezu vollst�ndige
Dokumentation des Handlings eingehender MIME-Nachrichten im UUZ dar.
Ich mache das auch deswegen so bewu�t ausf�hrlich, weil die bisherigen
Routinen �berwiegend "geerbt" sind, ich mich mit diesen Detailfragen
erstmals n�her besch�ftige, demzufolge darin noch nicht 100% sattelfest
bin und es f�r sinnvoll halte, wenn das nochmal gegengepr�ft wird.
1. (TYP:-Header und CTE-Decodierung) Es erhalten nur noch die
Nachrichten den Header "TYP: BIN", die die folgenden Kriterien
gleichzeitig erf�llen:
- Singlepart-Nachricht (Content-Type <> multipart/* und message/*).
- Content-Type <> text/*
Es verbleiben also die Typen image/*, audio/*, video/* und
application/*, die unabh�ngig von der Codierung den Header "TYP: BIN"
erhielten und somit in XP als 'B' geflagged w�rden.
Sind sie codiert (CTE "base64" oder "quoted-printable"), werden sie
decodiert - der resultierende ZConnect-Puffer enth�lt also echte
Bin�rdaten. Sind sie nicht codiert (CTE "7bit", "8bit" oder
"binary"), enth�lt die RFC-Nachricht und somit auch der resultierende
ZC-Puffer per Definition bereits Bin�rdaten (was aber ein in der
Praxis und laut RFC2045 nicht vorkommender Fall sein d�rfte).
Nicht als 'B' geflagged werden hingegen - und anders als bisher -
Multiparts mit CTE "binary". Diese erhalten keinen TYP:-Header und
erscheinen daher in XP mit dem Flag 'M'. In der Praxis f�hrt das
dazu, da� bei multipart/alternative automatisch der Textteil in den
Lister geladen werden sollte (was anscheinend nicht immer
funktioniert, aber das ist ein anderes Thema und vor allem keines den
UUZ betreffendes) und beim Beantworten die unpassende R�ckfrage, ob
man die Bin�rnachricht wirklich quoten wolle, entf�llt.
Gleichzeitig w�rde dadurch das diesen Thread ausl�sende Problem
fehlender CRLFs bei als "binary" deklarierten Multiparts behoben
werden, aber dazu im n�chsten Punkt mehr.
2. (Behandlung von EOLs) An den aktuellen Lese- und Schreibroutinen
sowie der Decodierung von base64- oder qp-codierten Daten �ndert sich
im Vergleich zur aktuellen UUZ-Testversion prinzipiell nichts, mit
einer Ausnahme:
Der "Fix" im aktuellen Test-UUZ, bei (uncodierten oder qp-codierten)
Bin�rdaten kein EOL aka CRLF an die Zeile anzuh�ngen, wird auf den
urspr�nglichen Zustand zur�ckgebaut, da er aufgrund einer Fehlinter-
pretation von Absatz 6.5 in RFC2045 f�lschlicherweise davon ausgegan-
gen ist, bei qp-codierten Bin�rdaten sei hinsichtlich der CRLF-
Behandlung genauso zu verfahren wie bei base64-codierten Bin�rdaten.
Dies ist falsch, denn qp-codierte Bin�rdaten sind mit "soft line
breaks" zu codieren, wenn die Datenmenge die max. zul�ssige Zeilen-
l�nge von 76 Zeichen �berschreitet - uncodierte Zeilenumbr�che d�rfen
dort also schlicht nicht vorkommen (und wenn sie doch vorkommen,
k�nnen sie nicht einfach ersatzlos entsorgt werden).
Uncodierte Bin�rdaten hingegen (die laut RFC2045 eigentlich gar nicht
vorkommen d�rften) k�nnen im Falle ihres Vorkommens eben solche
uncodierten EOLs enthalten, und diese d�rfen schon mal gar nicht
ersatzlos entsorgt werden.
Es ist allerdings darauf hinzuweisen, da� uncodierte oder qp-codierte
Bin�rdaten, die uncodierte EOLs (CR, LF, CRLF) enthalten, sehr
wahrscheinlich ohnehin defekt sind, weil sie schon beim Transport
ver�ndert worden sein k�nnen (und von externen Clients wie UKAW
definitiv ver�ndert werden, bei Mailservern und Gates d�rfte es nicht
viel anders aussehen).
Es w�rde daher derzeit keinen Sinn machen, mit hohem Aufwand die
bisherigen zeilenorientierten Lese- und Schreibroutinen im UUZ auf
nicht-zeilenorientierte Routinen umzubauen, um die Umwandlung alleine
vorkommender CR oder LFs nach CRLF zu verhindern - es ist schlicht
ungewi�, in welcher Form die vermeintlichen Zeilenumbr�che im
Original vorgelegen haben.
3. (Charset-Konvertierung) Bisher wurden von der Charset-Konvertierung
folgende *nicht-bin�ren* MIME-Typen ausgenommen:
- Content-Type multipart/* (eben alle Multipart-Nachrichten, deren
einzelne Teile beim Laden in den Lister von XP konvertiert werden)
- Content-Type */html (Singlepart, wobei mir f�r "*" nur "text" aus
der Praxis bekannt ist)
Beides ist richtig und sinnvoll und wird sich daher auch nicht
�ndern. Es wird aber vorgeschlagen, die Liste der MIME-Typen, die
keiner Zeichensatzkonvertierung unterzogen werden, zu erweitern auf:
- message/*
- text/enriched (oder */enriched) - siehe RFC1896
Bei message/* halte ich das f�r ganz selbstverst�ndlich, denn das ist
als der zweite von zwei composite-types �hnlich zu bewerten wie
multipart/*. Jede Zeichensatzkonvertierung w�rde u.U. Datenverlust
in der originalen RFC-Nachricht bedeuten.
Bei dem bisher gar nicht ber�cksichtigten Typ text/enriched oder
*/enriched handelt es sich um einen �hnlichen Fall wie bei text/html
oder */html: Das Format wird von XP nicht selbst interpretiert und
wird daher zur Darstellung i.d.R. an ein externes Programm �bergeben
werden (m�ssen) - eine vorherige Zeichensatzkonvertierung w�rde
die Darstellung von Umlauten und anderen 8bit-Zeichen verf�lschen
(so, wie es fr�her bei */html auch der Fall war, bis es ge�ndert
wurde).
4. (Offene Punkte) Es gibt ein paar noch offene und/oder nicht ganz
gekl�rte Punkte:
- Der UUZ wertet einen discrete-type namens "model" aus, den ich in
der MIME-Reihe (RFC2045-2049) gar nicht finden kann. Evtl. ist er
in den Vorl�ufern RFC1521/1522 spezifiziert - das w�re zu pr�fen
und ggf. k�nnte dieser Typ entsorgt werden.
- RFC2046 w�re daraufhin zu pr�fen, ob es weitere - bisher nicht
ber�cksichtigte - Subtypes gibt, die einer Sonderbehandlung (z.B.
Verhindern der Charset-Konvertierung) unterzogen werden sollten.
- [... wem noch was ein- und auff�llt, m�ge dies erg�nzen...]
Ich werde das, was oben beschrieben ist, in den n�chsten Tagen in eine
neue Testversion des UUZ implementieren und zum Download zur Verf�gung
stellen. Je nach Verlauf und Ergebnis der Diskussion dar�ber sowie der
Ergebnisse aus der Praxis ist nicht ausgeschlossen, da� danach nochmals
Ver�nderungen stattfinden.
>> Wie Du bereits angedeutet hast, sind nur Softbreaks zul�ssig,
>> ansonst sind hard line-breaks so wie sie auftauchen codiert und
>> decodiert, also =D0=0A (bzw. umgekehrt) oder nur =0D oder nur =DA,
>> damit der Inhalt unabh�ngig von den Regeln des Empfangssystem auf
>> einem anderen System angezeigt werden kann oder sonstwas eben.
> Wird vermutlich so sein, aber ich will trotzdem mal versuchen, einen
> Beleg daf�r zu finden.
Ich habe zwar keine explizite Regel gefunden, die besagt, da� bei
qp-codierten Binaries nur soft line breaks zul�ssig w�ren, aber der
gesamte Inhalt aller MIME-RFCs zum Thema qp-Codierung und CRLF-
Behandlung l��t IMO keinen anderen logischen Schlu� zu.
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
