Michael Heydekamp <[EMAIL PROTECTED]> wrote on 08.05.04:
> Ralf Mueller <[EMAIL PROTECTED]> wrote on 08.05.04:
>>> 1. Da ich ohnehin gerade in den letzten Z�gen einer neuen
>>> E-UUZ-Fassung stecke, her mit der Testmail, und zwar schnell. :)
>>> Entweder per MIME-Attachment an mich per Mail oder nach
>>> crosspoint.freexp.bin (wenn's kleiner als 64KB ist, auch nach
>>> crosspoint.freexp.dev).
>> Geht gleich per mail an Dich raus.
> Danke, angekommen, sehe ich mir gleich an. Ich bin ja froh, da� Du
> das Problem noch rechtzeitig vor Erscheinen der neuen UUZ-Version
> gefunden hast - so es denn wirklich ein Problem ist, aber das werde
> ich gleich wissen.
Ach je, ich wei� gar nicht, wo ich anfangen soll, so vielschichtig ist
das mal wieder... Also, das wird wieder l�nger jetzt:
Erstens:
--------
Da� Dein alter UUZ �berhaupt die "richtige" Adresse aus den Received:-
Headern rausgeporkelt hat, ist pures Gl�ck bzw. Zufall und hast Du
ausschlie�lich einem Bug dieses UUZ zu verdanken, der Received:-Header
mitunter nicht vollst�ndig auswertet, weil er sie abschneidet bzw. nicht
komplett entfaltet.
Sieh Dir mal den allerersten Received:-Header in Deiner Mail an, der
besteht aus f�nf Zeilen (ist also viermal gefolded), und die f�nfte
Zeile enth�lt die g�ltige Mailadresse "[EMAIL PROTECTED]".
Das ist die Mailadresse, die eigentlich in Deinem EMP:-Header h�tte
landen m�ssen, und die w�re nat�rlich falsch gewesen. Hier kann man
schon gut die prinzipiellen Grenzen dieses Verfahrens erkennen.
Der alte UUZ - das kannst Du an dem erzeugten U-Received:-Header im
ZConnect-Puffer sehen, der mittendrin nach dem "for " abbricht, w�hrend
der Enhanced UUZ den kompletten Header auswertet und schreibt - wertet
nur die ersten vier Zeilen dieses Received:-Headers aus. Was nat�rlich
nicht korrekt ist, hier aber zuf�llig zu dem erw�nschten Effekt f�hrt,
da� die n�chste Adresse, die in einem der folgenden Received:-Header
gefunden wird, letztlich im EMP:-Header landet - und das ist zuf�llig
die, an die die Nachricht urspr�nglich auch gerichtet war.
Das vorweg: Ich werde sicher nicht wieder einen Bug einbauen, nur damit
Adressen unterschlagen werden, weil das bei dieser Konstellation mal
zuf�llig pa�t. ;)
BTW: �berhaupt sind die Header f�r meinen Geschmack v�llig krank
gefoldet und stellenweise mit riesigen Zwischenr�umen versehen, was dem
Enhanced UUZ nichts ausmacht. Ist aber ein Hinweis darauf, da� hier
MTAs beteiligt sein m�ssen, die nicht ganz sauber ticken.
Zweitens:
---------
In der Tat ist aber insofern trotzdem ein Bug im Enhanced UUZ, als da�
zwar die o.g. Adresse "[EMAIL PROTECTED]" gefunden und korrekt in
die entsprechende Variable geschrieben, anschlie�end aber wieder
verworfen wird, weil der Schalter "UseEnvTo" nicht gesetzt war (h�ttest
Du ihn gleichzeitig gesetzt, h�tte es prinzipiell funktioniert).
Das soll so nat�rlich nicht sein und ist gefixt. N�tzt Dir aber nix,
weil - siehe oben - jetzt eine v�llig falsche Adresse in den EMP:-Header
geschrieben w�rde.
Zur Erl�uterung und als Antwort auf eine Frage, die Du per Mail gestellt
hattest: Der Schalter -graberec nimmt einfach die erste Mailadresse nach
einem "for ", die er in irgendeinem Received:-Header finden kann. Wenn
schon im ersten Received:-Header eine vorhanden ist, dann halt die,
ansonsten die aus einem der n�chsten Header. Sobald eine Adresse
gefunden wurde, werden alle Adressen aus noch folgenden Headern
ignoriert.
Drittens:
---------
In der Mail hattest Du angesprochen, evtl. den Header
"Original-recipient:" auszuwerten, um an die richtige Adresse
ranzukommen.
Kann man evtl. machen, obwohl mir das �hnlich wie "Delivered-To:" so ein
propriet�rer Header zu sein scheint, der zudem mal wieder v�llig schr�g
gestaltet ist:
----------8<----------
> Original-recipient: rfc822;[EMAIL PROTECTED]
----------8<----------
Super, den mu� man also noch parsen, um das d�mliche "rfc822;"
(ausgerechnet, der Header hat mit RFC822 nun wirklich gar nix zu tun) da
wegzukriegen. Mal sehen, ob ich da die bereits existierende Routine
verwenden kann.
Ich w�rde das dann mit zu den Headern "(X)-Envelope-To" und "Delivered-
To" packen, d.h. man m��te "-UseEnvTo" angeben, um den UUZ zu einer
Auswertung dieses Headers zu bewegen.
Langfristig erscheint es mir aber sinnvoller, Du w�rdest die envelope-
f�hige L�sung f�r UKA_PPP verwenden, sobald sie existiert. Sobald ich
eine UUZ-Version habe, die mit diesem schr�gen "Original-recipient:"
klarkommt, schicke ich sie Dir aber auf jeden Fall zum Testen zu.
Ich mu� mir aber auch noch ein Vorgehen f�r den Fall �berlegen, falls
jemand "-graberec" und "UseEnvTo" gleichzeitig angibt *und* evtl. sogar
ein Envelope-Header vorhanden ist. Irgendwie mu� dann eine Priorit�t
definiert sein.
Anyway, es war definitiv ein Bug vorhanden und daher erstmal Danke f�rs
Finden. :) Auch wenn's mir jetzt wieder ungeplante zus�tzliche Arbeit
beschert.
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
