Content-Transfer-Encoding: binary

[Joachim Merkel]

Michael Heydekamp (my-news at freexp.de) 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.

> 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. Außerdem würde es die
Regel brechen, daß kein rekursives Encoding stattfinden darf,
was zur Folge hätte, daß eine - erneute - erforderliche
Decodierung von Body-parts erst nach einer Decodierung
festgestellt werden kann.

> 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.
Empfohlen wird aber base64, wenn's darauf wirklich ankommt. 

> Ob und wie Singleparts in punkto Auswertung des CTE-Headers anders
> zu behandeln sind als Multiparts, ist ein weiterer Punkt.

Das ist klar, man muß alles prüfen, aber es geht lediglich
um die Transport-Ebene und sollte nicht wesentlich anders
gewichtet sein als bei MIME-Multiparts.

>> Wenn ZConnect voll binärfähig ist, weil es bytecount - also
>> einen LEN:-Header hat, dann ist es bei RFC eben noch nicht so.

> Schau mal in die einzelnen Teile der von Alex geschickten Nachricht.
> Da sehe ich z.B. "Content-Length: 1832" (obwohl diese gar nicht als
> binary deklariert sind).

Da würde dann vermutlich auch application/octet-stream stehen. Wobei nur
entscheidend ist, daß es keine Vorschriften gibt, außer daß der Subtype
korrekt und ausführlich genug dokumentiert ist. Aber der zugrundeliegende
Transportmechanismus SMTP läßt keine allzu beliebigen Verrenkungen zu. Den
Content-Length haben sie entweder von http übernommen oder verwenden ihn
aus Sicherheitgründen. So genau kenne ich mich auch nicht aus.

Und die angegebene Länge stimmt beim HTML-part nicht, beim Textteil nur,
wenn das letzte LF nicht zählt.

> Aber das nur nebenbei, für die o.g. offenen Fragen ist das
> irrelevant.

Das sehe ich nach Deiner bisherigen Darstellung ebenso.