Joachim Merkel <[EMAIL PROTECTED]> wrote on 03.07.04:
[Ich biege das jetzt mal um nach c.f.dev]
> Michael Heydekamp ([EMAIL PROTECTED]) schrieb:
>> Das Ignorieren des �u�eren CTE-Headers w�rde au�erdem das Problem
>> mit den derzeit fehlenden CRLFs bereits l�sen, aber da ist noch zu
>> pr�fen,
> Scheint mir eine realistische Herangehensweise, wenn man XP als
> Ende der Empfangskette betrachtet. Ob sich f�r den Weiterversand
> als Original daraus m�gliche Folgen ergeben scheint mir insofern
> nicht erheblich, da XP den CTE-Header sowieso immer schon
> selbst setzt.
Zumal sich auch gar keine ergeben. "Ignorieren" hei�t ja nicht, da� er
weggeworfen wird, sondern da� sich aus dem Inhalt des Headers keine
Konsequenzen ergeben. 7/8bit und binary werden hinsichtlich der
Konvertierung einfach gleichbehandelt, da es "binary" im eigentlichen
Sinne (noch) gar nicht gibt und der UUZ ohnehin nur zeilenorientiert
arbeiten kann.
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.).
2. Alle mit CTE "7bit", "8bit" oder "quoted-printable" deklarierten
Singlepart-Nachrichten, die nicht dem Content-Type text/* oder
message/* angeh�ren.
3. Alle mit CTE "binary" deklarierten Single- und Multipart-Nachrichten,
die nicht dem Content-Type text/* angeh�ren.
Irgendwie kommt mir der Code etwas wirre vor, ich bin noch nicht sicher,
ob ich gedanklich alle F�lle richtig erfa�t habe.
Und da� in 1. nur auf base64 und nicht auf qp gepr�ft wird, ist im
Grunde doch auch nicht richtig. Die Art der Codierung spielt f�r die
Frage, ob es sich um eine (codierte) Bin�rnachricht handelt, doch
�berhaupt keine Rolle. qp-codierte Bin�rmails w�ren also bisher nicht
als "TYP: BIN" geflagged worden.
Eigentlich wollte ich schon den ge�nderten Code posten, aber ich will
das doch lieber nochmal �berdenken und vor allem testen.
>> ob es z.B. Multiparts geben kann (bzw. ob sie standardkonform w�ren),
>> deren kompletter Body base64-codiert ist (inkl. der Boundaries und
>> allem, was zu einer Multipart geh�rt). So da� die einzelnen Teile
>> erst nach einer b64-Decodierung zum Vorschein k�men... In diesem Fall
>> k�nnte man den Header nicht einfach ignorieren.
> Mime ohne Header im Body gibts nicht.
Na ja, die w�ren nach der base64-Decodierung ja da...
Aber schon richtig, der Fall ist ohnehin nicht zul�ssig:
----------8<----------
[...] If an entity is of type "multipart" the Content-Transfer-
Encoding is not permitted to have any value other than "7bit", "8bit"
or "binary". Even more severe restrictions apply to some subtypes of
the "message" type.
----------8<----------
>> Des weiteren mu� ich pr�fen, ob der das Problem verursachende Fix
>> �berhaupt und wirklich OK ist. Bei base64-Binaries ist klar, wie
>> die Daten decodiert werden m�ssen, bei qp-Binaries bin ich jetzt gar
>> nicht (mehr) sicher, wie *uncodierte* Zeilenumbr�che behandelt
>> werden m��ten.
> [...]
> 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.
Letzte Bemerkung f�r den Moment: Mir ist eingefallen, da� wir uns �ber
die Behandlung "echter" Binaries im UUZ schon deshalb keine Gedanken
machen m�ssen, weil schon die Clients da nicht mitspielen:
Im Bem�hen, dem UUZ eine UUCP-gerechte Nachricht vorzulegen, ver�ndert
mindestens UKAW n�mlich ebenfalls EOLs (es konvertiert CRLF nach LF, die
der UUZ anschlie�end wieder nach CRLF umwandelt).
Das w�rde es dann wohl auch bei Bin�rdaten machen...
Und zuguterletzt habe ich noch einen Bug bei dem Ganzen gefunden:
Irgendwie habe ich es - unabsichtlich nat�rlich - hinbekommen, da� der
UUZ bei ausgehenden Singlepart-Binaries ("i" auf Userbrett, Schalter
"Bin�rnachrichten als "MIME-Attachments" unter C/O/E/V deaktiviert)
keine MIME-Header mehr setzt.
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
