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 Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
