Re: ROT / Received-Header

2006-01-01 Diskussionsfäden Hans-Juergen Taenzer
Joachim Merkel ([EMAIL PROTECTED]) wrote:

  Hans-Juergen Taenzer ([EMAIL PROTECTED]) schreibt:

  Die beiden Systemnamen werden an den bisher aufgebauten
  ROT-Header angehängt.

  Nur der erste, sonst wird umgekehrt vorangestellt, also in der
  Reihenfolge der Weiterleitung hinter ROT: vor den anderen
  Stationen eingefügt:

  Insofern Hans--Jürgen den nachträglichen String-Aufbau
  beschreibt, hat er es natürlich korrekt beschrieben.

Und so war es von mir gemeint. ;)

Der UUZ bearbeitet alle Received-Header in der Reihenfolge des Auftretens
in der Mail, und so ergibt sich diese Reihenfolge automatisch (wenn jedes
routende System sich jeweils mit seinem Received-Header vor die bereits
vorhandenen setzt, und das muss wohl so sein).

Hans-Jürgen

FreeXP Entwickler-Mailingliste
Dev-List@freexp.de
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list


Re: ROT / Received-Header

2006-01-01 Diskussionsfäden Michael Heydekamp
Hans-Juergen Taenzer [EMAIL PROTECTED] wrote on 01.01.06:

 Michael Heydekamp ([EMAIL PROTECTED]) wrote:

 Ich weiß nicht, wie ich hier geeignet kürzen könnte (vielleicht auch
 zu faul heute ;) ), deshalb größtenteils als Fullquote.

Zum Ausgleich die Antwort dafür um so kürzer:

 [...] Aber wie dem auch sei, da ROT für XP keine technische Relevanz
 hat, kann man aufs Rätselraten verzichten, und ein eventuell aus
 ZConnect-Sicht nicht nötiges System trotzdem aufnehmen.  Entsprechend
 kann man mit dem Dupecheck vor der Aufname eines Systems in den ROT-
 Header verfahren.  Also wie bisher lediglich prüfen, ob der gerade
 aufzunehmende Systemname als letzter bereits im ROT vorhanden ist
 (also nicht im kompletten bisher aufgebauten ROT).  Zusätzlich würde
 ich diesen Dupecheck auch auf from-Systeme ausdehnen.  Und from-
 Systeme aufnehmen. ;)

ACK.  So hätte ich's auch vorgeschlagen und so wird's gemacht. :)  (Test
auf Server mit dem Namen by nicht vergessen!)


Michael

FreeXP Entwickler-Mailingliste
Dev-List@freexp.de
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list


Re: ROT / Received-Header

2006-01-01 Diskussionsfäden Joachim Merkel
Hans-Juergen Taenzer ([EMAIL PROTECTED]) schreibt:

 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.  Ich habe da nur ein Beispiel (gekürzt):

Ich habe noch ein anderes angehangen, wo ein Eintrag hinter
from nicht im ROT: erscheint.

 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.

Offensichtlich halten die Anwender von duucp das für ausreichend.
Mehr kann ich dazu leider auch nichts beitragen. 
Wäre vielleicht mal interessant zu sehen, was UnixConnect aus
Received:-Headern rausliest.

Da gab's oder gibt es noch den SysOp Udo aus Dresden, der
UnixConnect einsetzte:
udo (at) elektron-bbs.de
udo (at) elektron.east.de

Oder von den Gatebauern antwortete früher immer:
mandree (at) dosis.uni-dortmund.de
matthias.andree (at) stud.uni-dortmund.de

Ob die Adressen noch stimmen, weiß ich nicht. Aus dem
Anhang muß jedenfalls nichts anonymisiert werden, meine
Adresse besteht da nicht mehr.
-- 
Salut
 _)oachim

TESTPUF
Description: Binary data

FreeXP Entwickler-Mailingliste
Dev-List@freexp.de
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list

Re: ROT / Received-Header

2005-12-31 Diskussionsfäden Martin Wodrich
Michael Heydekamp [EMAIL PROTECTED] schrieb am 30.12.05 um 23:52:

 Ja, es gibt leider durchaus ziemlich seltsame Received-Zeilen.
 Neben solchem Bloedsinn wie localhost, verewigen sich auch
 manche Mailer mit einer Extrazeile (z.B. qmail).
 Solche server-spezifischen Strings stehen meist (immer?) in Kommentaren,
 die werden als allererstes eliminiert.

Gut. Wobei bei qmail noch das Problem auftuacht, das niemand ein
Standard-qmail aufsetzt, sondern alle mehr oder weniger gepatcht
sind (ganz im Gegensatz zu Exim, Sendmail oder Procmail, welche jeweils
ausser Sicherheitsfixe meist keinerlei Patche erfahren). Es ist also
bei qmail im Speziellen so das du nur die haeufigsten Unsinnszeilen
ignorieren kannst, nicht aber alle die vorkommen koennten.
-- 
Mit freundlichen Gruessen,
Martin Wodrich

FreeXP Entwickler-Mailingliste
Dev-List@freexp.de
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list


Re: ROT / Received-Header

2005-12-30 Diskussionsfäden Joachim Merkel
Hans-Juergen Taenzer ([EMAIL PROTECTED]) schreibt:

 Die beiden Systemnamen werden an den bisher aufgebauten ROT-Header
 angehängt.
  
Nur der erste, sonst wird umgekehrt vorangestellt, also in der
Reihenfolge der Weiterleitung hinter ROT: vor den anderen
Stationen eingefügt:

Der letzte Eintrag rechts ist also die erste Station.
In ZConnect der Versender, im RFC-Raum meist das erste
weiterleitende System.

Der erste Received: im Header ist somit die letzte weitersende
Stelle und damit meist der erste oder zweite Eintrag links
hinter ROT:. Der erste hinter ROT: ist meist die Mailbox aus
deren Postfach der Empfänger seine Nachricht holt.

Davon abgesehen, ändert das an Deinen Fragen nichts, ob es nicht
einfach reicht, lediglich die Einträge hinter by einzutragen.

-- 
Salut
 _)oachim


FreeXP Entwickler-Mailingliste
Dev-List@freexp.de
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list


Re: ROT / Received-Header

2005-12-30 Diskussionsfäden Joachim Merkel
Joachim Merkel ([EMAIL PROTECTED]) schreibt:

 Hans-Juergen Taenzer ([EMAIL PROTECTED]) schreibt:

 Die beiden Systemnamen werden an den bisher aufgebauten ROT-Header
 angehängt.

 Nur der erste, sonst wird umgekehrt vorangestellt, also in der
 Reihenfolge der Weiterleitung hinter ROT: vor den anderen
 Stationen eingefügt:

Insofern Hans--Jürgen den nachträglichen String-Aufbau
beschreibt, hat er es natürlich korrekt beschrieben.

-- 
Salut
 _)oachim


FreeXP Entwickler-Mailingliste
Dev-List@freexp.de
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list


Re: ROT / Received-Header

2005-12-30 Diskussionsfäden Michael Heydekamp
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 yy for
 U-Received: by sqlserver02.syrius.de (Postfix, from userid x)

 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