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