Helmut G�tschow <[EMAIL PROTECTED]> wrote on 15.07.04:
> Am 15.07.04 haute <[EMAIL PROTECTED]> auf die Tasten:
>> Deine daraus extrahierte Mail liegt aber auch als M0001.MSG in dem
>> an meiner Nachricht von eben (MsgID <[EMAIL PROTECTED]>)
>> anh�ngenden convert.zip.
> Ja stimmt, base64.
Wie "Ja stimmt, base64"?? Wo siehst Du in M0001.MSG was von base64?
Da steht eben *nichts* von base64, darum geht es doch.
>> Hast Du die originale RFC-Mail noch? Wenn ja, bitte mal an die Liste
>> schicken, wenn nein, bitte mal den kompletten ZConnect-Puffer an die
>> Liste schicken.
> H�ngen beide dran, weiss im Moment leider nicht warum im RFC-Puffer
> der Body verhunzt ist,
Das ist nicht "verhunzt", sondern so sieht nun mal base64 aus.
Womit der UUZ keine Probleme hat, deshalb ist das au�er Joachim, der die
Mail undecodiert �ber eine ZConnect-Box empfangen hat, keinem
aufgefallen.
Nat�rlich ist das ein Fehler der ZConnect-Box, die die Mail decodieren
m��te, aber andererseits gibt es keinen zwingenden Grund f�r base64
(normalerweise w�rde man qp nehmen, um Text zu codieren) und man soll es
den Empf�ngern nicht schwieriger machen als unbedingt notwendig.
> aber wichtig ist wohl eh nur der Header.
Kann ich leider auch nix Hilfreiches draus lesen (ich hatte gehofft,
einen Header "X-MIME-Autoconverted" oder sowas zu finden).
Au�er, da� qmail am Transport beteiligt ist, dem ich jede Sauerei
zutraue. Bis auf weiteres Ursache also ungekl�rt.
Was man mal zum Test machen k�nnte, wenn Du Lust hast: Du kriegst einen
Temp-Account bei freexp.de und schickst die Mail mal direkt an unseren
Mailserver (mit solchen Zeichen wie Omega, die CS verwendet). Dann
schauen wir mal, was dann ankommt. Zumindest k�nnten wir dann evtl.
ausschlie�en, da� das Problem bei uns liegt.
Auf jeden Fall wei� ich jetzt, da� solche Mails wirklich vorkommen
k�nnen. Als ich in den UUZ gerade f�r solche schr�gen Szenarien eine
Ladung Fixes eingebaut hatte, habe ich mich manchmal zwischendurch
gefragt, wozu ich das �berhaupt mache und ob das nicht l'art pour l'art
ist. ;)
[... etwas sp�ter ...]
Wenn man die RFC-Mail mal mit dem alten Enhanced UUZ vom 31.08.2003 und
dann im Vergleich mit der aktuellen Testversion des E-UUZ/II konvertiert
und sich das genauer ansieht, kann man zwei Fixes sehr sch�n sehen:
1. Der E-UUZ/II konvertiert auch Zeilenumbr�che *im* codierten base64-
String nach CRLF, mit dem alten E-UUZ (und allen anderen
existierenden UUZs) bleiben es LFs (an den LFs kann man allerdings
wiederum erkennen, da� die Mail nicht bereits base64-codiert gewesen
sein kann, als Du sie versandt hast, denn die LFs wurden vom UUZ bei
der ZC=>RFC-Konvertierung des Body erzeugt).
2. Am Ende des ZC-Puffers fehlt nach der base64-Decodierung bei der
RFC=>ZC-Konvertierung das abschlie�ende CRLF, was der E-UUZ/II
erkennt und daher eines anh�ngt.
Der Puffer ist also insgesamt "sauberer".
F�r technisch Interessierte packe ich die beiden Puffer mal in ein ZIP,
das folgt dann mit der n�chsten Nachricht.
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
