zu den DUPE-Problemen
sy...@kbbs.zer.sub.org
under the subject 'Re: Dupes durch Crossposting':
>
> Hallo,
>
> url...@smurf.sub.org (urlichs) writes:
> >in sub.gateways, artikel <25...@sol.ccc.de>,
> > schreibt te...@sol.ccc.de (Frank Simon):
> >nicht vernuenftig. Ich halte solche Einschraenkungen fuer undurchsetzbar:
> >es ist schlichtweg unmoeglich, feste "Zustaendigkeitsbereiche" fuer Gates
> >festzulegen, wenn sich die Netztopologie auf beiden Seiten staendig aendert
> >und (Subnetz) die Artikelpfade eh total verschlungen sind.
> Das sehe ich anders, aber eine andere Loesung ist mir auch recht. :-)
Das IST auch anders; nachdem sich die (IN.) Berliner geeinigt haben,
NICHT mehr sowohl von PERICONT als auch von SONSTWO Nachrichten zu
beziehen, kommen jedenfalls ueber _den_ Weg keine Dupe's mehr.
Dafuer aber massig via BI-LINK...
> >Das einzige, das das Problem loest, ist eine vernuenftige
> >Gate-Implementierung, die dafuer sorgt, dass
> >- Message-IDs eineindeutig vergeben werden
> >- Nachrichten zer->sub->zer und sub->zer->sub im wesentlichen unveraendert
> > bleiben.
>
> Gehen meine Artikel zwar ins Zerberus, aber in einen Teil des Zerberus
> steht da terra%sol.$uu...@uucp.zer und in einen anderen Teil dann mit
> te...@sol.zer (oder demnaechst dann auch frank...@sol.zer) ?
>
> Oder muss im Zerberus gar der Absender UND die MesageID gleich sein, dann
> gibt es weiter Dupes ? Irgendwie ist das zu teilen unklar.
Noch "schlimmer"...
Es gibt im Z-Netz Software, die nicht nur die ID und den Absender,
sondern _auch_ die Message-LAENGE auswertet. Das ist Volker Ulle schon
lange bekannt, aber er beharrt weiterhin auf der Fiktion, dass es mit
einer ID-Generierung schon klappen werde
M.HUS...@BI-LINK.ZER wrote on Tue, 12-31-1991 at 13:52 h
under the subject 'Re: Dupes durch Crossposting':
>
> a) das hat keinen Einfluss auf die Dupe Erkennung im Z-NETZ. Zumindest
> ZERBERUS benutzt dazu NUR die Message-ID. Wenn irgendein Z-NETZ
^^^^^^^^
Du meinst die 4.x-Version von Zerberus.
Abgesehen davon, dass diese Software sehr unzuverlaessig ist, und ein
_erkannter_ Bug (Fehler beim Netcall -> Absturz) nicht verbessert wird
> Programm das anders macht - selbst Schuld (und auch hier uninteressant,
> solange die meisten Server ZERBERUS benutzen).
so hat diese Programm-Version nur einen Markt-Anteil von 40% im Z-Netz,
und der Haupt-Server (INFINET) benutzt es nicht...
wieder TERRA:
>
> Aber unabhaengig davon, ob ich glaube ob ein Zustaendigskeitsbereich
> moeglich ist oder nicht (jede andere Loesung ist mir auch lieber), sind
> wir wohl einer Meinung. :-)
Der IST moeglich... Beispiel:
- KBBS gatet an KRISKI == toppoint. Dort werden einige _lokale_ Rechner
mitversorgt, aber eben nicht die ganze BRD
- TTB gatet an ARBI. Dort ist auch Schluss...
- OSGO (.SCHULE.de) haengt an einer Z-Box, aber nicht im SUB-Netz
Umgekehrt werden in einigen Z-Netz-Boxen auch SUB.* - Bretter gefuehrt.
Ich habe bisher aber noch von keiner Dupe-Welle in diesen Brettern ge-
hoert, wohl WEIL die Bretter nur lokal vorhanden sind...
Es ist nicht nur sinnvoll, DUPE's zu erkennen, sondern im Interesse
der Systembetreiber (und deren Geldbeutel) selbst _erkennbare_ Dupe's
gar nicht erst entstehen zu lassen.
Da beste (einzige) Rezept dafuer ist ein abgestimmtes Routing.
Gruss, Holger
PS: zum Problem "nichtregistrierte" == "unzulaessige" Domain:
Das ANTworten sollte doch innerhalb des uucp-Netzes duch
Angabe des expliziten Pfades (als Umkehr des Hinweg's)
moeglich sein??
Wenn das bei der (Rechnungshof: weglesen: kostenguenstigen)
Nutzung des INTERnet's nicht mehr gehen sollte, ist das doch
wohl ein Fehler der Gate-Software SUB <-> INTER - Net ??
--
Holger Petersen Pf 3501 2300 Kiel
Tel. 0431/336038
Matthias Urlichs
schreibt sy...@kbbs.zer.sub.org:
<
< Es ist nicht nur sinnvoll, DUPE's zu erkennen, sondern im Interesse
< der Systembetreiber (und deren Geldbeutel) selbst _erkennbare_ Dupe's
< gar nicht erst entstehen zu lassen.
<
< Da beste (einzige) Rezept dafuer ist ein abgestimmtes Routing.
<
Routing zu geben, und auf der Subnetz-Seite sowieso nicht...
<
< PS: zum Problem "nichtregistrierte" == "unzulaessige" Domain:
<
< Das ANTworten sollte doch innerhalb des uucp-Netzes duch
< moeglich sein??
Eigentlich nicht. Die Doku sagt explizit, dass der Newspfad von A nach B im
allgemeinen Fall kein Mailpfad von B nach A ist / sein kann.
Reroutende Mailsysteme werfen einen solchen Pfad sowieso um, und:
die XXX->Sub-Gatesoftware hat bereits die Aufgabe, Adressen zu generieren,
auf die Mensch auch antworten kann.
Angesichts der Tatsache, dass ich absolut keinen Vorteil einer Adresse
"fasel.zer" gegenueber "fasel.zer.sub.org" sehe, und im Gegenteil erstere
eine ungueltige Adresse und damit im allgemeinen Fall ein unbeantwortbares
Posting darstellt, sehe ich ehrlich gesagt keinen vernuenftigen Grund fuer
den Aufwand, der offenbar getrieben wird, um solche Adressierungen trotzdem
zum Funktionieren zu bringen.
< Wenn das bei der (Rechnungshof: weglesen: kostenguenstigen)
< Nutzung des INTERnet's nicht mehr gehen sollte, ist das doch
< wohl ein Fehler der Gate-Software SUB <-> INTER - Net ??
<
Es gibt keine "Gatesoftware" Subnetz<->Internetz. Beide verwenden
dieselben Adress/Nachrichten/etc.-Formate, und im Subnetz haben nur
Adressen aufzutreten, die im Internet gueltig sind.
Folgerung: Gates sind unnoetig.
--
Matthias Urlichs -- url...@smurf.sub.org -- url...@smurf.ira.uka.de /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany -- +49-721-9612521 \o)/
Bruno Blissenbach
sagt sy...@kbbs.zer.sub.org :
>
> TERRA%SOL.C...@UZERCP.ZER wrote on Sun, 12-29-1991 at 20:19 h
> under the subject 'Re: Dupes durch Crossposting':
>
> >
> > Hallo,
> >
> > url...@smurf.sub.org (urlichs) writes:
> > >in sub.gateways, artikel <25...@sol.ccc.de>,
> > > schreibt te...@sol.ccc.de (Frank Simon):
> > >festzulegen,
>
> > >Das einzige, das das Problem loest, ist eine vernuenftige
> > >Gate-Implementierung, die dafuer sorgt, dass
> > >- Message-IDs eineindeutig vergeben werden
> > >- Nachrichten zer->sub->zer und sub->zer->sub im wesentlichen unveraendert
> > > bleiben.
unveraendert muessen From/Reply-To etc bleiben in dem Sinne,
dass sie in allen Netzen die gleiche mailbox beschreiben.
> > Gehen meine Artikel zwar ins Zerberus, aber in einen Teil des Zerberus
> > steht da terra%sol.$uu...@uucp.zer und in einen anderen Teil dann mit
> > te...@sol.zer (oder demnaechst dann auch frank...@sol.zer) ?
>
> Es gibt im Z-Netz Software, die nicht nur die ID und den Absender,
> sondern _auch_ die Message-LAENGE auswertet.
Wenn die message die gleiche ist, sollte auch die Laenge gleich sein
- es sei denn man zaehlt potentiell unterschiedliche Header/Footer mit.
> > Aber unabhaengig davon, ob ich glaube ob ein Zustaendigskeitsbereich
> > moeglich ist oder nicht (jede andere Loesung ist mir auch lieber), sind
> > wir wohl einer Meinung. :-)
Zustaendigkeitsbereich ?
> Es ist nicht nur sinnvoll, DUPE's zu erkennen, sondern im Interesse
> der Systembetreiber (und deren Geldbeutel) selbst _erkennbare_ Dupe's
> gar nicht erst entstehen zu lassen.
Richtig!
> Da beste (einzige) Rezept dafuer ist ein abgestimmtes Routing.
Voellig unnoetig (s.o.) und im Subnetz nicht machbar.
Holger Petersen :
> Das ANTworten sollte doch innerhalb des uucp-Netzes duch
> Angabe des expliziten Pfades (als Umkehr des Hinweg's)
> moeglich sein??
Nein. Das kann klappen, muss aber nicht. Der Grund ist, dass mail
und news z.T. auf verschieden Wegen transportiert werden, und nicht
alle System, die bestimmte anderen news weitergeben, das auch in
umgedrehter Richtung mit mail machen (koennen/wollen)
> Wenn das bei der
> Nutzung des INTERnet's nicht mehr gehen sollte, ist das doch
> wohl ein Fehler der Gate-Software SUB <-> INTER - Net ??
Sowas gibt es nicht direkt, das waere allenfalls uucp <--> internet,
und darauf hat kaum ein Subnetz'ler Einfluss :-(
Abgesehen davon, veraendern diese Gateways (theoretisch) die newsheader
nicht (ausser durch Verlaengern von "Path: " versteht sich) weil auf
beiden Seiten RFC-733, RFC-822, RFC-1036 (und Nachfolger) zugrunde liegen.
B.Blissenbach
- Domain: bru...@purodha.GUN.de GeoNet: MBK1:B.Blissenbach OshoNet: 49/52.
-- X.400: G=Bruno; S=Blissenbach; O=B.Blissenbach; PRM=GeoNet; ADM=DBP; CO=DE.