Hans-Juergen Taenzer <[EMAIL PROTECTED]> wrote on 30.12.05:
> Michael Heydekamp ([EMAIL PROTECTED]) wrote:
>> Hans-Juergen Taenzer <[EMAIL PROTECTED]> wrote on 29.12.05:
>>> 2. Wenn ja, macht es Sinn, "from"-Systeme aus den
>>> Received-Headern in den ROT-Header zu übernehmen?
>>> ZConnect-Systeme, die über RFC-Routen, scheinen beim
>>> Erstellen des ROT-Headers die "from"-Systeme (immer?) zu
>>> ignorieren.
>> Dazu hatte ich ja schon per Mail gefragt: Woran kann man erkennen,
>> ob ein Server aus dem "by" oder dem "from" herausoperiert wurde?
>> Was dem einen Header sein "by", ist dem anderen sein "from".
> Ich sprach von ZC-Systemen.
Ist mir klar, darauf bezog sich auch meine Frage.
> Ich habe da nur ein Beispiel (gekürzt):
> U-Received: from genius by tbx.berlinet.de (2.38) with ZCONNECT;
> U-Received: from zelator.berlinet.de(really [xx.x.xxx.x])
> by genius.berlinet.de via smtpd with esmtpid
> U-Received: from by localhost (amavisd-new, port )
> U-Received: from sqlserver02.syrius.de (unknown [xxx.xxx.xxx.xxx])
> by zelator.berlinet.de (Postfix) with ESMTP id yyyyyyyyyy for
> U-Received: by sqlserver02.syrius.de (Postfix, from userid xxxxx)
> ROT:tbx.berlinet.de!genius.berlinet.de!localhost!zelator.berlinet.de
> !sqlserver02.syrius.de
Ok, so wird es etwas plastischer. Was ich da erkennen kann, ist, daß
die hinter "from" in den beiden ersten (aka letzten) Received:-Headern
stehenden Server "genius" und "zelator.berlinet.de" fehlen.
Wobei "zelator.berlinet.de" ja vorher schon mal vorkommt, was mich
wieder zu der Frage führt, die ich schon mal per Mail gestellt hatte:
Wenn ich den ZC-Draft richtig lese, müßte man im Grunde nicht nur einen
Dupecheck mit dem letzten, sondern mit allen vorherigen Systemen machen?
Aber dann wäre der Routingweg wieder nicht komplett.
Und ob und warum man den/die letzten Server hinter "from" jetzt
prinzipiell unterschlagen sollte -- keine Ahnung. Scheint mir mehr
Faulheit als ein wirklicher Sinn dahinter zu stecken.
> Inwieweit das tatsächlich Standard ist, weiß ich nicht, dazu müste
> jemand mit mehr ZConnect-Kenntnissen was sagen.
> Vielleicht äußert sich sich ja jha oder jm dazu.
Schaumerma.
> Nur am Rande, durchgängig scheint die by/from/by-Systematik auch
> unter RFC-Systemen nicht zu sein.
Wenn sie das wäre und man sich darauf verlassen könnte, daß der "by" des
letzten Headers immer identisch mit dem "from" des nächsten Headers
wäre, dann bräuchten wir nicht so eine aufwendige from-by-Routine mit
Duepcheck, sondern könnten wirklich immer den "by" -- und beim letzten
(aka ersten) Header zusätzlich auch den "from" -- nehmen. ;)
>>> 3. Wenn ja, müsste vor Aufnahme des "from"-Systems in den
>>> ROT-Header nicht genauso wie vor der Aufnahme des
>>> "by"-Systems geprüft werden, ob dieser nicht bereits im ROT
>>> vorhanden ist (und sei es das "by"-System, das aus dem gerade
>>> bearbeiteten Received-Header übernommen wurde)?
>> Wenn Dein Beispiel ein echter und kein konstruierter Header ist
>> und sowas also offenbar vorkommt: Auf jeden Fall.
> Das Beispiel war echt, bei Bedarf kann ich die Message-Id
> heraussuchen.
Acxh Quatsch... Hatte das nur nochmal gefragt, weil ich sichergehen
wollte und auf meine gleichlautende Frage per Mail bisher keine Antwort
kam.
> Zu meinem 4.ten Punkt hast Du nichts geschrieben. Er war für mich
> eigentlich der wichtigste, da hier gegebenenfalls Systemnamen
> verlorengehen.
Dazu hatte ich nichts mehr gesagt, weil wir das schon ausführlich per
Mail hatten und da ja schon nicht weiterkamen. Meine letzte Einlassung
vom 14.12. dazu war:
----------8<----------
>>> In meiner letzten Mail hatte ich noch gefragt, ob der seit jeher
>>> fehlerhafte Stringvergleich vielleicht sogar Absicht gewesen sein
>>> könnte. Was meinst Du?
>> Mir war der Unterschied zwischen OXP und FXP natürlich auch
>> aufgefallen. Da ich die ZC-Regeln nicht kenne,
An die dachte ich weniger, AFAIK sagen die dazu auch nix. Hätte ja nur
sein können, daß jemand meinte, xxx.mail.freexp.de und mail.freexp.de
seien letztlich ja sowieso derselbe Server, da kann man den einen auch
gleich weglassen... Oder irgendeine mir sich nicht erschließende UUCP-
spezifische Logik.
Denke jedenfalls, es kann nicht falsch sein, wirklich nur echte Dupes zu
entfernen.
----------8<----------
Das ist nach wie vor mein Standpunkt, bis mich jemand eines Besseren
belehrt.
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
Dev-List@freexp.de
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
