Gatebau 97
Lutz Issler
Hallo,
wenn niemand etwas dagegen hat, wuerde ich die grobe Organisation einer Gatebau
97 in die Hand nehmen.
Dieses kleine Treffen haette nach dem, was mir so spontan einfaellt, die
grossen Aufgaben:
- die Gatebau-Dokumente zu aktualisieren
- die Gatebau-Dokumente zu Fido-Proposal und zu RFC zu machen
- die (Kreuz-)Vernetzung der Gateway-Koordinations-GABELN zu ueberdenken,
insbesondere im Hinblick auf das Usenet
- einen Standard fuer das Gaten von Dateien zu finden
- sich der MIME-im-Header-Problematik anzunehmen
Also... zeigt mal ein wenig Einsatz und teilt mir entweder hier in der GABELN,
per Mail an lutz_...@project.fido.de oder telefonisch unter 02154/7872 mit,
was ihr von diesem Vorschlag eines Treffens haltet und ob ihr an einer
Teilnahme interessiert seid.
Ich faende es jedenfalls genial, wenn man mal wieder was aktuelles als
Arbeitsgrundlage haette.
-.Lutz.-
Uwe Ohse @ DU3
In article <MSGID_2=3A2433=2F225.59...@fidonet.org>,
Lutz_...@project.fido.de (Lutz Issler) writes:
> wenn niemand etwas dagegen hat, wuerde ich die grobe Organisation einer Gatebau
> 97 in die Hand nehmen.
Schön. Aber warum wird das in gateways und nicht gatebau gepostet?
> - die Gatebau-Dokumente zu Fido-Proposal und zu RFC zu machen
Keine Chance. Dazu kann man bestenfalls einen Freiwilligen beauftragen,
aber die eigentliche Arbeit ist ein bischen zu lang für ein Wochenende.
> - die (Kreuz-)Vernetzung der Gateway-Koordinations-GABELN zu ueberdenken,
> insbesondere im Hinblick auf das Usenet
Sinnlos - die Leute mit der lautesten Meinung sind kaum diejenigen, die
zu einer Gatebau kommen.
> - einen Standard fuer das Gaten von Dateien zu finden
Ist das heute noch wichtig? Naja, macht mal.
> was ihr von diesem Vorschlag eines Treffens haltet und ob ihr an einer
> Teilnahme interessiert seid.
Interesse schon. Aber ohne Termin keine Zusage.
Gruß, Uwe
Albi Rebmann
Hello Lutz,
On Aug 18 21:36 97, Lutz Issler of 2:2433/225.59 wrote:
LI> Also... zeigt mal ein wenig Einsatz und teilt mir ...
LI> was ihr von diesem Vorschlag eines Treffens haltet und ob
LI> ihr an einer Teilnahme interessiert seid.
Vorschlaege sind ok, Intersse zu kommen habe ich auch.
Achja, was noch zum Tagespunkt dazu gehoert. Uebernahme aller References nach
FTN in mehrere Reply: Zeilen, Reihenfolge?
Albi...
Johann H. Addicks
UWE # OHSE.DE@2:2444/98 meinte am 21.08.97
UO> Schoen. Aber warum wird das in gateways und nicht gatebau gepostet?
Weil die Vernetzung in Gatebau wegen zer.z-netz.alt.gate-bau / zer.t-
netz.gate-bau / t-netz.gate-bau / z-netz.alt-gate-bau seit rund einem Jahr
extremst noped.
-jha-
--
j...@donut.de PGP-Key per RRQ oder FReq PhoneNet: 49:2319/6120.67
Lutz Issler
Hallo Uwe,
UO> Schoen. Aber warum wird das in gateways und nicht gatebau gepostet?
Weil in Gatebau schon seit Ewigkeiten keiner mehr was sinnvolles liest und
schreibt und hier die Idee entstanden ist. Passt Dir das nicht?
>> - die Gatebau-Dokumente zu Fido-Proposal und zu RFC zu machen
UO> Keine Chance. Dazu kann man bestenfalls einen Freiwilligen beauftragen,
UO> aber die eigentliche Arbeit ist ein bischen zu lang fuer ein Wochenende.
Richtig, aber man kann eine Form festlegen.
>> - die (Kreuz-)Vernetzung der Gateway-Koordinations-GABELN zu ueberdenken,
>> insbesondere im Hinblick auf das Usenet
UO> Sinnlos - die Leute mit der lautesten Meinung sind kaum diejenigen, die
UO> zu einer Gatebau kommen.
Richtig. Und?
>> - einen Standard fuer das Gaten von Dateien zu finden
UO> Ist das heute noch wichtig? Naja, macht mal.
Wichtig ist im Grunde genommen nichts, was wir besprechen - zumindest nicht,
wenn man die rasende Verbreitung von www und Co. im "Alltagsleben" betrachtet.
Weltbewegendes wollen wir auch gar nicht, auf das Hobby kommt es an. Und das
soll funktionieren.
UO> Interesse schon. Aber ohne Termin keine Zusage.
Wann kannst Du denn?
-.Lutz.-
Thomas Seeling
Hallo, Florian!
*** Am 21. August 1997 um 14:48 schrieb Florian Petri an Lutz Issler:
FP> Dabei sollten wir uns auch evtl. mal Gedanken machen, wie man Gruppen ala
FP> alt.binaries.* via FTN Fileecho und dann wieder als RFC-Newsgroup laufen
FP> lassen koennte, ohne einen MessageID Verlust hinzunehmen.
Da Fido-TIC-Dateien nicht genau definiert sind, hindert Dich nichts daran,
einen neuen Eintrag in TICs zu erzeugen, z.B. RFC-MSGID <string>.
Tschau...Thomas
Michael Holzt
Lutz Issler <Lutz_...@project.fido.de> schrieb im Beitrag
<MSGID_2=3A2433=2F225.59...@fidonet.org>...
> ich habe mal eine kleine Sammlung gemacht, wer kommen wuerde, wenn Ort
und
> Termin seinen Vorstellungen entspraechen. Bitte tragt euch bei Interesse
mit
> eurer Mailadresse in die Liste ein (ober bei Nichtinteresse wieder aus).
Ich schlage vor die Liste mit einer Nennung der Wunschorte in absteigender
Reihenfolge zu ergSnzen.
> Michael Holzt k...@flummi.de
Oldenburg, Dortmund
Matthias Andree
re...@flatta.in-berlin.de (=?ISO-8859-1?Q?Ren=E9_Kacza?=) schrieb am 24.08.1997:
> Formell würde ich mal folgendes für rfc -> ZC -> rfc einbinden:
>
> rfc -> ZC:
> Auswertung und Einbinden von
Was hier stand... fehlt.
> Mime-Multipart
> - Übernahme der Headerzeilen
> - 1:1 Weiterleitung des Body
Im Sonderfall: 2 * text/plain oder 1 * text/plain und 1 *
application/octet-stream umkodierung in Text respektive TYP:BIN mit
KOM:mentar.
> Mime-Application
> - Setzen des TYP: nach BIN
Ja.
> - 1:1 Weiterleitung des Body
Nein, bei UUEncode, Quoted-Printable und Base64 Body dekodieren.
> Mime-text/plain
> - Umkodieren des Body
Ja.
> - Setzen von X-DONT-GATE:
Nein.
> Festlegung der Verwertung von ZC Headerzeilen.
> (Man erinnert sich: X-ZC Zeilen werden zum grossen Teil an Gateways
> einfach gelöscht oder nach U-X-ZC gewandelt)
Wenn die Nachricht erkennbar aus ZConnect heraus gegatet wurde,
(X-Gatewaay:), dekodieren, wurde sie das nicht, ist U-X-ZC als Option
vielleicht sicherer.
> .
>
> ZC -> rfc
>
> PGP
> - Wandlung des Key-Headerinhalts in den Body mit gleichzeitiger
> Anpassung an den Mime-Standard
Ja, mit Möglichkeit zur Rückwandlung auf dem RFC->ZC-Gate.
> TYP: BIN
> - Verwertung der ZC-Information um rfc-gerechte MIME-Header zu
> bekommen.
Welche?
> X-DONT-GATE:
> - festschreiben
> das bei Nichtbeachtung des Headers keine weiteren Nachrichten von
> diesem Gateway angenommen - an dieses Gateway weitergegeben werden.
Der Header sollte nach Gatebau '97 absolut überflüssig sein.
> >- sich der MIME-im-Header-Problematik anzunehmen
> Das ist ja meine Spezi;)
Ach nee ;-)
> Da gibt es IMHO gar kein grosses Problem mehr.
> Zumindest bei rfc -> ZC -> rfc sollte innerhalb der letzten
> Disskussionen sich herauskristallisiert haben, was möglich ist.
>
> Faktum: Die Decodierung nicht auf die Useragenten abwälzen.
Um RFC-2047-escapte Header durch ZC zu tunneln, ist gar kein Eingriff
nötig. Wenn der Header in den ZConnect-Zeichensatz abgebildet werden
kann, könnte er dekodiert werden. Oder was meinst Du jetzt?
Gruß,
--
MATTHIAS ANDREE * Öffentlicher PGP-Schlüssel auf Anfrage verfügbar
René Kacza
[ Diese MSG wurde anscheinend auf irgendeinem Gateway abgeschnitte.
Daher das Repost ]
geschrieben von Lutz_...@project.fido.de am 18.08.97
zu "Gatebau 97":
>wenn niemand etwas dagegen hat, wuerde ich die grobe Organisation
>einer Gatebau 97 in die Hand nehmen.
Danke...
>die grossen Aufgaben:
>- die Gatebau-Dokumente zu Fido-Proposal und zu RFC zu machen
Letzteren in jedem Fall...
>- einen Standard fuer das Gaten von Dateien zu finden
Formell würde ich mal folgendes für rfc -> ZC -> rfc einbinden:
rfc -> ZC:
Auswertung und Einbinden von
Hier kommt jetzt eine zeile, die rot13-kodiert ist
Zvzr-Zhygvcneg
- Übernahme der Headerzeilen
- 1:1 Weiterleitung des Body
Hier kommt jetzt eine zeile, die rot13-kodiert ist
Zvzr-Nccyvpngvba
- Setzen des TYP: nach BIN
- 1:1 Weiterleitung des Body
Hier kommt jetzt eine zeile, die rot13-kodiert ist
Zvzr-grkg/cynva
- Umkodieren des Body
- Setzen von X-DONT-GATE:
Festlegung der Verwertung von ZC Headerzeilen.
(Man erinnert sich: X-ZC Zeilen werden zum grossen Teil an Gateways
einfach gelöscht oder nach U-X-ZC gewandelt)
.
ZC -> rfc
PGP
- Wandlung des Key-Headerinhalts in den Body mit gleichzeitiger
Anpassung an den Mime-Standard
TYP: BIN
- Verwertung der ZC-Information um rfc-gerechte MIME-Header zu
bekommen.
X-DONT-GATE:
- festschreiben
das bei Nichtbeachtung des Headers keine weiteren Nachrichten von
diesem Gateway angenommen - an dieses Gateway weitergegeben werden.
>- sich der MIME-im-Header-Problematik anzunehmen
Das ist ja meine Spezi;)
Da gibt es IMHO gar kein grosses Problem mehr.
Zumindest bei rfc -> ZC -> rfc sollte innerhalb der letzten
Disskussionen sich herauskristallisiert haben, was möglich ist.
Faktum: Die Decodierung nicht auf die Useragenten abwälzen.
Ok - wenn mir noch so einfällt meld ich mich;)
René
--
| Gehe zu C*nrad, begib dich direkt dorthin, gehe nicht über |
| V*bis, nehme ca. 30 DM mit, vergiß die Kabel nicht. |
+-- hi...@scorpio.in-berlin.de in de.comm.misc: Ein Monitor an zwei PCs? --+
Hinrich Donner
Hi Florian,
Du schriebst zum Thema 'Gatebau 97':
FP> Dabei sollten wir uns auch evtl. mal Gedanken machen, wie man Gruppen ala
FP> alt.binaries.* via FTN Fileecho und dann wieder als RFC-Newsgroup laufen
FP> lassen koennte, ohne einen MessageID Verlust hinzunehmen.
Das Problem sollte eigentlich kein wirkliches Problem sein, da ein
(unreifer) Entwurf seit GB94 vorliegt.
FP> * Eine weitere Frage, die wir ausdiskutieren und _festlegen_ muessen ist,
FP> wie man mit Nachrichten aus anderen Zonen umgehen muss; sprich Routing FTN
FP> Z99 -> RFC/FTN -> Z2
Uninteressant, da Domains unterschiedlich.
FP> * Zeilenumbrueche waren frueher mal ein Thema... imho duerfen keine
FP> Aenderungen am Messadge-Body erfolgen.
Imho richtig, aber praktisch vollkommen unmoeglich. CHARSET: ISO5 aus
ZConnect muss in irgendeiner Form an FTN angepasst werden.
Hinrich
René Kacza
geschrieben von m_an...@line.org am 26.08.97
zu "Re: Gatebau 97":
>> Auswertung und Einbinden von
>Was hier stand... fehlt.
Da stand nichts weiter - das was dazugehört, ist eine Aufzählung, die
hier folgt... ( hättest Du auch in der Mail schreiben können;-))
>> Mime-Multipart
>> - Übernahme der Headerzeilen
>> - 1:1 Weiterleitung des Body
>Im Sonderfall: 2 * text/plain oder 1 * text/plain und 1 *
>application/octet-stream umkodierung in Text respektive TYP:BIN mit
>KOM:mentar.
2* Text/plain ist aber auch wieder solch Sache.
Wer nimmt sich der Decodierung von 8bit und wer von QP an?
Und umkodiert ja - ZC->rfc Gateing nein
>> - 1:1 Weiterleitung des Body
>Nein, bei UUEncode, Quoted-Printable und Base64 Body dekodieren.
Ok.
>> Mime-text/plain
>> - Umkodieren des Body
>Ja.
>> - Setzen von X-DONT-GATE:
>Nein.
Hm... Wer garantiert mir, das der umkodierte nicht wieder
zurückgegatet wird?
>> Festlegung der Verwertung von ZC Headerzeilen.
>> (Man erinnert sich: X-ZC Zeilen werden zum grossen Teil an Gateways
>> einfach gelöscht oder nach U-X-ZC gewandelt)
>
>Wenn die Nachricht erkennbar aus ZConnect heraus gegatet wurde,
>(X-Gatewaay:), dekodieren, wurde sie das nicht, ist U-X-ZC als Option
>vielleicht sicherer.
Ich habe schon so ziemlich alles ausprobiert - ein Gate macht dies,
ein anderes das. Hier heisst es: Standard schaffen.
Es kann nicht sein, das ich unter rfc X-ZC-TELEFON: eintrage und das
Teil beim Gate nach ZC verloren oder gar U-kodiert wird.
Mache ich ein U- davor, dann kommt nur Quark raus;(
Mache ich ein X-Telefon - kommt gar nichts an.
>> PGP
>> - Wandlung des Key-Headerinhalts in den Body mit gleichzeitiger
>> Anpassung an den Mime-Standard
>Ja, mit Möglichkeit zur Rückwandlung auf dem RFC->ZC-Gate.
Ja bitte...
>> TYP: BIN
>> - Verwertung der ZC-Information um rfc-gerechte MIME-Header zu
>> bekommen.
>
>Welche?
>
>> X-DONT-GATE:
>> - festschreiben
>
>Der Header sollte nach Gatebau '97 absolut überflüssig sein.
Nein - siehe oben;
>> Das ist ja meine Spezi;)
>Ach nee ;-)
Och doch...
>> Faktum: Die Decodierung nicht auf die Useragenten abwälzen.
>
>Um RFC-2047-escapte Header durch ZC zu tunneln, ist gar kein Eingriff
>nötig. Wenn der Header in den ZConnect-Zeichensatz abgebildet werden
>kann, könnte er dekodiert werden. Oder was meinst Du jetzt?
Genau!
IMHO könnte das mitführen der originalen Zeile sogar entfallen, da am
Übergang ZC -> rfc ja jetzt schon richtig konvertiert wird...
René
--
| Die Comput ist weiblich und der Steckkart maennlich. |
| Der Steckkart dringt in die Comput ein; Penetration. |
| Das Kind heisst DAU. |
+---------Wau Holland in <6Yrub...@wau6458.other.thur.de>--+
Lutz Issler
Hallo Uwe,
UO> Soll heissen: Da kann man sich viel ausdenken, nur wirken wird es
nicht.
Schon klar - nur versuchen kann man's immer. Ich denke, ein (auch fuer das
Usenet offenes) Gatebau-Treffen hat ein Stueck weit "offiziellen"
Charakter,
und ebenso sind dessen Ent- und Beschluesse im Grunde verbindlich fuer die
Netze, deren Mitglieder bzw. Vertreter an dem Treffen teilgenommen haben.
Langer Rede kurzer Sinn: Waere einer vom Usenet dabei, koennte man
selbigem
zumindest eine formale Zusage - sofern diese erfolgte - durch einen
Vertreter
unter die Nase reiben. Und wenn keiner da war und das Usenet sich
beschwert
waere man in der Lage "aetsch" zu sagen, "ihr haettet doch kommen koennen"
:-)
UO> Fuer das Usenet sind die Mehrheitsverhaeltnisse nach der vergangenen
UO> Abstimmung ohnehin klar, und Kreuzvernetzungen sind sowieso boese ...
Da wuerde sich ja was dran machen lassen. Am technischen Aspekt zumindest,
vielleicht ziehen da mal mehr mit.
UO> naja, ich glaub' halt dass der Karren zu sehr festgefahren ist um da
UO> etwas bewegen zu koennen.
Das ist in jedem Netz die Gefahr. Die Frage ist halt nur, wie man damit
umgeht.
Entweder man akzeptiert die arrogante "mehrheitliche" Haltung oder
einzelne
versuchen dagegen anzugehene mit dem Ergebnis, das eine Gruppe doch nioch
irgendwie zum Dialog kreuzvernetz offensteht :-)
UO> Sind binaries in Mails wirklich ein Thema? Ich hab' ziemlich genau gar
UO> keine Probleme damit.
Ich auch nicht, glaub's mal nicht :-)
Allerdings gibt es da ein paar ZC-Binaerbretter, die ich gerne in FTN
haette.
Das funktioniert auch (schliesslich gibt's ja FileGate :-)), aber es ist
eben
kein Standard dafuer definiert.
Sobald es an MIME und aehnlichen Kram geht, den man in ZC und FTN auch mit
anderen technischen Mitteln erledigen kann, dann ist das auch hinter
meinem
Interessenshorizont.
UO> Na gut, wenn genug dafuer sind wird es das wohl sein :-)
>> Wann kannst Du denn?
UO> Siehe Mail.
Alles klar. Dann sehen wir uns :-)
-.Lutz.-
René Kacza
geschrieben von k...@flummi.de am 28.08.97
zu "Re: Gatebau 97":
>René Kacza <re...@flatta.in-berlin.de> schrieb im Beitrag
><6cT0j...@flatta.in-berlin.de>...
>> Festlegung der Verwertung von ZC Headerzeilen.
>> (Man erinnert sich: X-ZC Zeilen werden zum grossen Teil an Gateways
>> einfach gelöscht oder nach U-X-ZC gewandelt)
>
>Bitte? Das mußt Du jetzt aber belegen.
Och komm - den Thread wirklich nochmal aufwärmen?
Ok. Null Probleme.
Ich werde Dir genügend liefern; spätestens zur Gatebau...
Matthias Andree
Lutz_...@p59.f225.n2433.z2.fido.sub.org (Lutz Issler) schrieb am 28.08.1997:
> Langer Rede kurzer Sinn: Waere einer vom Usenet dabei, koennte man
> selbigem
> zumindest eine formale Zusage - sofern diese erfolgte - durch einen
> Vertreter
> unter die Nase reiben. Und wenn keiner da war und das Usenet sich
> beschwert
> waere man in der Lage "aetsch" zu sagen, "ihr haettet doch kommen koennen"
> :-)
Höhö - Du verkennst die Situation gewaltig. Das Usenet hat keine
Vertreter, die man dazu verdonnern könnte, wie Du Dir das vorstellst,
das mußt Du schon selbst machen, RFC ist Sache. Es gibt da keine
hierarchische Struktur.
Matthias Andree
re...@flatta.in-berlin.de (=?ISO-8859-1?Q?Ren=E9_Kacza?=) schrieb am 28.08.1997:
> 2* Text/plain ist aber auch wieder solch Sache.
> Wer nimmt sich der Decodierung von 8bit und wer von QP an?
Da fummeln RFC-Mail-Relays auch rein, wenn sie 8bit-Daten an 7-Bit
Syteme verschicken sollen. Dann vergewaltigen sie nämlich die 8Bit und
spucken QP aus. 8Bit wird gar nicht decodiert, und QP zu decodieren, ist
nun wirklich kein Problem.
> Und umkodiert ja - ZC->rfc Gateing nein
Warum das denn schon wieder nicht? Bei Mail mußt Du eh gaten, ob Du
willst oder nicht, und bei News wäre das einzig denkbare Problem
dasjenige, daß der erste der beiden text/plain-Teile Zeichen enthält,
die im ZConnect-Zeichensatz nicht abbildbar sind. Denn der Kommentar
einer ZC-Nachricht ist immer im ZC-Zeichensatz, während der Text (hier
der 2. Teil) in ISO-8859-x, x = 1, 2, ..., 9 oder Unicode (mir ist keine
Implementierung dafür bekannt) sein darf.
Wenn das nicht möglich ist, muß die Nachricht eben unverändert getunnelt
werden. Splitting wäre noch eine andere Möglichkeit, aber die würde ich
wohl eher als "dumme Idee" bezeichnen, weil sie - siehe Fido und das
Zurückgaten - viel zu instabil ist.
> >> - Setzen von X-DONT-GATE:
> >Nein.
>
> Hm... Wer garantiert mir, das der umkodierte nicht wieder
> zurückgegatet wird?
Niemand. Wo ist das Problem? Wenn die Gates intakt sind, gibt es doch
gar keines.
> Ich habe schon so ziemlich alles ausprobiert - ein Gate macht dies,
> ein anderes das. Hier heisst es: Standard schaffen.
Sicher.
> Es kann nicht sein, das ich unter rfc X-ZC-TELEFON: eintrage und das
> Teil beim Gate nach ZC verloren oder gar U-kodiert wird.
Verloren gehen darf es in der Tat nicht, daß es U-X-ZC- wird, ist nicht
gerade begrüßenswert, könnte ich aber akzeptieren, wenn für das RFC->ZC
Gate nicht sichtbar ist, daß die Nachricht originär ZConnect war, Du
also RFC-seitig X-ZC- erzeugt hast. Wenn da nicht der Umstand wäre, daß
ich es für albern halte, X-Header zu escapen, denn unter ZC und RFC sind
X-Header nicht auszuwerten und userdefiniert.
> Mache ich ein U- davor, dann kommt nur Quark raus;(
Wundert mich nicht. Willkommen in der Welt der U-U-Header %-)
> Mache ich ein X-Telefon - kommt gar nichts an.
Dann ist das Gate fehlerhaft.
[X-DONT-GATE-IT]
> >Der Header sollte nach Gatebau '97 absolut überflüssig sein.
>
> Nein - siehe oben;
Doch. Mein Gate wird den Header weder erzeugen noch beachten. Es wird
allein aufgrund der Tatsachen entscheiden, ob es gaten will oder nicht.
Wenn ich eine Nachricht nicht vernünftig abbilden kann, wo liegt dann
der Sinn im Gate? Dann kann ich sie auf dem ersten Gate schon wegwerfen
und muß sie nicht erst defekt bis zum zweiten schicken. Dann lieber
tunneln. Ist dann nur für ggf. dazwischenliegende ZC-Systeme dumm
gelaufen, weil die i. d. R. kein MIME dekodieren.
> >Um RFC-2047-escapte Header durch ZC zu tunneln, ist gar kein Eingriff
> >nötig. Wenn der Header in den ZConnect-Zeichensatz abgebildet werden
> >kann, könnte er dekodiert werden. Oder was meinst Du jetzt?
> Genau!
> IMHO könnte das mitführen der originalen Zeile sogar entfallen, da am
> Übergang ZC -> rfc ja jetzt schon richtig konvertiert wird...
Warum sollte die mitgeführt werden? Bei Date mag das sinnvoll sein, wenn
jemand noch zwei oder drei Bit per Stealth dort unterbringen will %-)
aber bei abbildbaren Zeilen sollte das nicht der Fall sein.
Florian Petri
Hallo Thomas,
am Sonntag, 24 August 1997 schrieb Thomas Seeling an Florian Petri:
TS> Da Fido-TIC-Dateien nicht genau definiert sind, hindert Dich nichts
TS> daran, einen neuen Eintrag in TICs zu erzeugen, z.B. RFC-MSGID
TS> <string>.
Wird nicht auch von irgendeinem Ticer gekillt, der diesen eintrag nicht
kennt?!?
cul Floh - DG3FEO - 0177-20 987 18 * e-mail: fl...@flop.swb.de *
Frank Ellermann
Moin moin Matthias,
MA> Das Usenet hat keine Vertreter [...] RFC ist Sache.
Ganz nebenbei, Fido natuerlich auch nicht, nur heisst es da
FTS / FSC / Policy statt RFC / Netiquette / "kanonisch" >:-)
Auf deutsch: gute Ideen setzen sich durch, weil sie publik
gemacht werden und gut sind, andere "Zwangsmittel" hat es
dazu auch im Fido nicht.
Greets, Frank
Lutz Issler
Hallo Matthias,
MA> Das Usenet hat keine Vertreter, die man dazu verdonnern koennte, wie Du
MA> Dir das vorstellst,
Ich hatte nen schlechten Tag. Kann ja mal vorkommen :-)
Fido praegt eben :-)
MA> das musst Du schon selbst machen, RFC ist Sache. Es gibt da keine
MA> hierarchische Struktur.
Usenet eben :-)
-.Lutz.-
Johnny Tevessen
Hi!
> Albi Rebmann 2:2471/77.0 (Internet?)
> Andreas Braukmann an...@abra.de
> Frank-Christian Kruegel fc...@i-online.ohz.north.de
> Johann H. Addicks j...@donut.de
> Lutz Issler lutz_...@project.fido.de
> Matthias Andree m_an...@line.org
> Michael Holzt k...@flummi.de
> Timm Ganske timm_...@of.maus.de
Johnny Teveßen j.tev...@line.org
Favourites: RFC->ZC, Dortmund.
ciao,
johnny
--
Trust nobody.
Michael Holzt
> >> (Man erinnert sich: X-ZC Zeilen werden zum grossen Teil an Gateways
> >> einfach gelöscht oder nach U-X-ZC gewandelt)
> >
> >Bitte? Das mußt Du jetzt aber belegen.
>
> Och komm - den Thread wirklich nochmal aufwärmen?
Du meinst Unwahrheiten aufwärmen?
> Ich werde Dir genügend liefern; spätestens zur Gatebau...
Da bin ich ja mal gespannt.
René Kacza
geschrieben von k...@flummi.de am 06.09.97
zu "Re: X-ZC-Header (was: Gatebau 97)":
>Du meinst Unwahrheiten aufwärmen?
Stop mal - werd' nicht ausfallend.
Begib Dich nach dejanews und such Dir das nochmal raus. Dann erzähle
mir, was daran 'Unwahrheiten' sind und dann kannst Du
weiterdiskutieren.
Ich habe bisher meine Erkenntnisse über diverse Gateways IMMER belegen
können und Headerauszüge mitgepostet. Des weiteren habe ich immer
versucht eine korrekte Diskussion zu führen - aber irgendwie geht das
da oben zu weit.
René
--
| Es geht aufwärts ... |
| ... sprach der Spatz, als die Katze ihn die Treppe hinauf trug |
+---Wolfgang Hohlbein / Johan Kerk - Spacelords St.Petersburg II----+
Matthias Andree
k...@flummi.de (Michael Holzt) schrieb am 06.09.1997:
> René Kacza <re...@flatta.in-berlin.de> schrieb im Beitrag
> <6cqZN...@flatta.in-berlin.de>...
> > >> (Man erinnert sich: X-ZC Zeilen werden zum grossen Teil an Gateways
> > >> einfach gelöscht oder nach U-X-ZC gewandelt)
> > >
> > >Bitte? Das mußt Du jetzt aber belegen.
> >
> > Och komm - den Thread wirklich nochmal aufwärmen?
>
> Du meinst Unwahrheiten aufwärmen?
Nein, meint er nicht.
René Kacza
geschrieben von M_An...@line.org am 31.08.97
zu "Re: Gatebau 97":
>> Wer nimmt sich der Decodierung von 8bit und wer von QP an?
>Da fummeln RFC-Mail-Relays auch rein, wenn sie 8bit-Daten an 7-Bit
>Syteme verschicken sollen. Dann vergewaltigen sie nämlich die 8Bit und
>spucken QP aus. 8Bit wird gar nicht decodiert, und QP zu decodieren,
>ist nun wirklich kein Problem.
Ist doch mein Reden;)
Nein im Ernst:
Wenn ich im RFC-Bereich eine MSG sende, die 8bit - ISO-8859-1 ist, die
dann auf ein SMTP trifft, wird daraus 8bit - quotet-printable
Das ist auch Ok.
Wenn ich aber multipart/alternative im Header habe, habe ich bereits
zwei 'eigentlich gleichlautende' Bodys. M(e)isst dann einmal text/html
und einmal text/plain - encoding 8bit
Das wird beim auftreffen auf ein SMTP zu:
text/html und der zweite Teil zu text/plain encoding qp
....
>Warum das denn schon wieder nicht? Bei Mail mußt Du eh gaten, ob Du
>willst oder nicht, und bei News wäre das einzig denkbare Problem
>dasjenige, daß der erste der beiden text/plain-Teile Zeichen enthält,
>die im ZConnect-Zeichensatz nicht abbildbar sind. Denn der Kommentar
Ich will eigentlich was anderes.
Aber das werd' ich wohl nicht durch bekommen...
Vergiss es...
>Wenn das nicht möglich ist, muß die Nachricht eben unverändert
>getunnelt werden. Splitting wäre noch eine andere Möglichkeit, aber
>die würde ich wohl eher als "dumme Idee" bezeichnen, weil sie - siehe
>Fido und das Zurückgaten - viel zu instabil ist.
Also tunneln mittels Splitting lehne ich - trotz meiner Gutartigkeit
für ZC rigeros ab...
Ich sehe eigentlich kein Problem beim 1:1 durchreichen.
Aber auch nur dann. Und darauf bezog sich:
>> >> - Setzen von X-DONT-GATE:
>> Hm... Wer garantiert mir, das der umkodierte nicht wieder
>> zurückgegatet wird?
>
>Niemand. Wo ist das Problem? Wenn die Gates intakt sind, gibt es doch
>gar keines.
Sag mir ein Gate, wo Du die Hand ins Feuer legst;)
>Verloren gehen darf es in der Tat nicht, daß es U-X-ZC- wird, ist
>nicht gerade begrüßenswert, könnte ich aber akzeptieren, wenn für das
>RFC->ZC Gate nicht sichtbar ist, daß die Nachricht originär ZConnect
Hm. Nun nehmen wir an:
Ein Gate verewigt sich und bei einem rfc-Relay fällt die Zeile unter
den Tisch....
>war, Du also RFC-seitig X-ZC- erzeugt hast. Wenn da nicht der Umstand
>wäre, daß ich es für albern halte, X-Header zu escapen, denn unter ZC
>und RFC sind X-Header nicht auszuwerten und userdefiniert.
Und gerade WEIL es Userdefiniert ist, muss das Gate entscheiden:
schädlich oder nicht.
Im Fall von X-ZC-Telefon und X-ZC-Post sollte das wohl eindeutig sein.
;-)
Ich erinner an den XP-Thread, der in d.c.s.c. lief, als X-XP_F:Header
auftauchten und XP's Anzeige-Verhalten beeinträchtigten.
Dort hiess es: X-Header sind Userdefiniert. Sprich: JEDER hat den
Header weiterzuleiten. Stört ein X-Header den Mailer ist dieser dafür
verantwortlich den Header zu löschen oder zu escapen.
Konsequenz: Der UUZ wurde bereinigt - X-XP_F wird gelöscht.
>> Mache ich ein X-Telefon - kommt gar nichts an.
>Dann ist das Gate fehlerhaft.
Au weia - soll ich das ausprobieren?
Ich habe gerade mal an 11 Leute eine Mail rausgeschickt.
Bei mindestens 3en kam das Teil fehlerhaft an.
Davon 2 ohne Telefon...
Auswertung, welches Gate da Mist baut kommt aber zur Gatebau - auf
Papier für Michael.
>Wenn ich eine Nachricht nicht vernünftig abbilden kann, wo liegt dann
>der Sinn im Gate? Dann kann ich sie auf dem ersten Gate schon
>wegwerfen und muß sie nicht erst defekt bis zum zweiten schicken. Dann
>lieber tunneln. Ist dann nur für ggf. dazwischenliegende ZC-Systeme
>dumm gelaufen, weil die i. d. R. kein MIME dekodieren.
Ok - damit könnte ich mich abfinden:-)
Das Mime.im.Header-Problem wird in der nächsten Woche (zumindest für
XP-ler) gelöst sein.
QP kann ich nun auch schon.
Mal sehen, was ich noch will...
>Warum sollte die mitgeführt werden? Bei Date mag das sinnvoll sein,
>wenn jemand noch zwei oder drei Bit per Stealth dort unterbringen will
>%-) aber bei abbildbaren Zeilen sollte das nicht der Fall sein.
Also von U-To: bis U-cc: habe ich jetzt schon alles gesehen...;(
Wie gesagt - die Auswertung kommt....
René
--
+---------- -----------+
| Fussnote: ein Posting "kommt" normalerweise sofort. Bei Moderation |
| ist es zuerstmal impotent :) |
+--- Henning Weede in <5ocac7$t4a$1...@unlisys.unlisys.net> ------------+
Matthias Andree
re...@flatta.in-berlin.de (René Kacza) schrieb am 09.09.1997:
[X-DONT-GATE-IT]
> >Niemand. Wo ist das Problem? Wenn die Gates intakt sind, gibt es doch
> >gar keines.
> Sag mir ein Gate, wo Du die Hand ins Feuer legst;)
Ich müßte bescheuert sein :-) Selbst meinem eigenen traue ich da nicht.
Weil nämlich der Korrektheitsbeweis nicht erbracht ist (und vermutlich
im gegenwärtigen Zustand nicht erbracht werden kann). Die Probleme mit
aktuellen Gateversionen von z. B. Unix/Connect oder AnUUCP sind aber
nicht so groß, daß ein pauschales Gateverbot für die Ausgabe
gerechtfertigt wäre.
> >Verloren gehen darf es in der Tat nicht, daß es U-X-ZC- wird, ist
> >nicht gerade begrüßenswert, könnte ich aber akzeptieren, wenn für das
> >RFC->ZC Gate nicht sichtbar ist, daß die Nachricht originär ZConnect
>
> Hm. Nun nehmen wir an:
> Ein Gate verewigt sich und bei einem rfc-Relay fällt die Zeile unter
> den Tisch....
Dann gehört das RFC-Relay abgeklemmt. Es hat keine X-Zeilen zu
entsorgen. Fertig.
> Ich erinner an den XP-Thread, der in d.c.s.c. lief, als X-XP_F:Header
X-XP_F ist in ZConnect nicht routbar, weil der _ im Header-Tag nicht
erlaubt ist. Die Nachricht muß gebounct (Mail) oder gelöscht (News)
werden.
> Konsequenz: Der UUZ wurde bereinigt - X-XP_F wird gelöscht.
Mit ein wenig Bauchgrimmen, ja.
> Au weia - soll ich das ausprobieren?
> Ich habe gerade mal an 11 Leute eine Mail rausgeschickt.
> Bei mindestens 3en kam das Teil fehlerhaft an.
> Davon 2 ohne Telefon...
>
> Auswertung, welches Gate da Mist baut kommt aber zur Gatebau - auf
> Papier für Michael.
Ok.
> Ok - damit könnte ich mich abfinden:-)
> Das Mime.im.Header-Problem wird in der nächsten Woche (zumindest für
> XP-ler) gelöst sein.
Das hilft dem Rest der Welt aber nicht.
> QP kann ich nun auch schon.
> Mal sehen, was ich noch will...
RFC-2047 ("MIME für Header") für mein Gate ist in Arbeit. Die
lowlevel-Funktionen leisten bereits und werden einige Newsreader-Autoren
zu Updates zwingen, weil das Gate gnadenlos auch base64 ausspuckt und
ich von mindestens einem Newsreader weiß, der base64 im Header in der
aktuellen Version nicht dekodieren kann, obwohl er sich mit dem Wörtchen
"MIME" schmückt. Aber das muß nicht weiter interessieren. Ist ja kein
Gatefehler...
> >Warum sollte die mitgeführt werden? Bei Date mag das sinnvoll sein,
> >wenn jemand noch zwei oder drei Bit per Stealth dort unterbringen will
> >%-) aber bei abbildbaren Zeilen sollte das nicht der Fall sein.
> Also von U-To: bis U-cc: habe ich jetzt schon alles gesehen...;(
>
> Wie gesagt - die Auswertung kommt....
Gerne. %-)
Michael Holzt
RenÚ Kacza <re...@flatta.in-berlin.de> schrieb im Beitrag
<6dQAp...@flatta.in-berlin.de>...
> >Du meinst Unwahrheiten aufwőrmen?
> Stop mal - werd' nicht ausfallend.
Kann es sein, da# Du łberempfindlich bist?
Michael Holzt
Matthias Andree <M_An...@line.org> schrieb im Beitrag
<0Ev7VMD...@trib0039.line.org>...
> > > >> (Man erinnert sich: X-ZC Zeilen werden zum grossen Teil an
Gateways
> > Du meinst Unwahrheiten aufwőrmen?
> Nein, meint er nicht.
Also obige Formulierung "zum grossen Teil" ist definitiv unrichtig. Der
gr÷#te Teil der Gateways ist UUCPfZ oder DUUCP, und die machen das beide
korrekt.
Die diversen Amiga-Gates haben zum gr÷#eren Teil das auch eingebaut.
Im łbrigen habe ich schon seit Ewigkeiten keinen Artikel mehr gesehen, wo
das falsch war. Und aus diesem grunde halte ich Rene|s Behauptungen
weiterhin fłr unrichtig.
Matthias Andree
k...@flummi.de ("Michael Holzt" ) schrieb am 13.09.1997:
> Also obige Formulierung "zum grossen Teil" ist definitiv unrichtig. Der
> gr÷˜te Teil der Gateways ist UUCPfZ oder DUUCP, und die machen das beide
> korrekt.
Du vergißt Unix/Connect, das erheblichen Anteil des Volumens stellt.
> Die diversen Amiga-Gates haben zum gr÷˜eren Teil das auch eingebaut.
Ja.
> Im brigen habe ich schon seit Ewigkeiten keinen Artikel mehr gesehen, wo
> das falsch war. Und aus diesem grunde halte ich Rene´s Behauptungen
> weiterhin f r unrichtig.
Bitte, tu was Du nicht lassen kannst.
René Kacza
geschrieben von k...@flummi.de am 13.09.97
zu "Re: X-ZC-Header (was: Gatebau 97)":
>Also obige Formulierung "zum grossen Teil" ist definitiv unrichtig.
>Der grö#te Teil der Gateways ist UUCPfZ oder DUUCP, und die machen das
>beide korrekt.
Und warum benutzt Du:
X-Gateway: ZCONNECT newserv.berlinet.de [UNIX/Connect v0.75b2 SunOS],
RFC1036/822 UE chessy.aworld.de [PolyNet RFC/ZC V4.911 15.5.1996
Serie 599198gr45FC-012]
>Die diversen Amiga-Gates haben zum grö#eren Teil das auch eingebaut.
Naja... man sieht es - ulkigerweise kommen 90% der berlinet.de über
newserv.berlinet.de
Willst Du noch mehr Header sehen?
>Im übrigen habe ich schon seit Ewigkeiten keinen Artikel mehr gesehen,
>wo das falsch war. Und aus diesem grunde halte ich Rene|s Behauptungen
>weiterhin für unrichtig.
Ja - ich verhandel' hier von Sachen, von denen ich keine Ahnung habe.
Und weils so schön ist, bringe ich gleich noch 'ne Hand voll Header.
Dann kannst DU Dich mit den Gatebetreibern auseinandersetzen und sie
umstimmen, andere (verschlimmbesserte;) ) Software zu benutzen.
(Richtig ist, das alle hier genannten Gateways X-ZC-Post und Telefon
übersetzen. Den Rest kann man hier ausmachen - leider liefen einige
MSG's über gleiche Gateways - deswegen nur solch kurzen Ausschnitt)
Ausgangspunkt war folgender RFC-Header
To: Zeile
10 Cc: Zeilen
From: Zeile
Diverse weitere Standard 'Pflicht-Zeilen'
Man beachte bitte die Länge:
# LEN: 448
brahcte der UUZ von XP vor & nach der Konvertierung ZC->RFC->ZC
| X-ZC-PGP-AVAIL:
| Mime-Header auf ISO-8859-1
| X-ZC-POST & TELEFON
Und raus kommt:
| U-To: =EMP:
| U-Cc: =1.KOP:
Weitere KOP:/EMP: und/oder U-Cc nicht enthalten
| GATE: RFC1036/822 newserv.berlinet.de [UNIX/Connect v0.75b2 SunOS]
| LEN: 852
Kein Charset-Header
| U-To: =EMP:
| U-Cc: =1.KOP:
Weitere KOP:/EMP: und/oder U-Cc nicht enthalten
| GATE: RFC1036/822 mailgate.mcnet.de [UNIX/Connect v0.75]
| LEN: 850
Kein Charset-Header
| EMP: =Umgeleiteter Account
| GATE: RFC1036/822 ius.gun.de [UNIX/Connect v0.74b4]
| EMP: =1.KOP:
| U-To: =Originaler Empfänger
Weitere KOP:/EMP: und/oder U-Cc nicht enthalten
| LEN: 850
Kein PGP-Header
Kein Charset-Header
| EMP: =Account
Weitere KOP:/EMP: und/oder U-Cc nicht enthalten
| GATE: RFC1036/822 UC cl-hh.comlink.de [DUUCP BETA vom 14.07.1997]
| LEN: 850
und zum ersten (und einzigsten) Mal:
| WAB: kwcom1.in-berlin.de!kwcom.in-berlin.de!flatta.in-berlin.de!re...@methan.chemie.fu-berlin.de
| U-Date: 07 Sep 1997 07:04:00 +0200
| U-To: =EMP
| U-Cc: =Irgendeiner aus der Liste
Weitere KOP:/EMP: und/oder U-Cc nicht enthalten
| GATE: RFC1036/822 apg.lahn.de [UNIX/Connect v0.75b4-t2]
| LEN: 850
Das zweite VIA: was ich gefunden habe
| EMP: =EMP
Weitere KOP:/EMP: und/oder U-Cc nicht enthalten
| U-MIME-VERSION: 1.0
| U-CONTENT-TYPE: text/plain; charset=ISO-8859-1
| U-CONTENT-TRANSFER-ENCODING: 8bit
| GATE: RFC1036/822 tribal.line.org [AnUUCP/UUSort 1.507 BETA (15.7.97)]
Kein PGP-Header
Kein Charset
Und nun Du.
René Kacza
>Kann es sein, da# Du überempfindlich bist?
Dein Zeichensatz ist defekt - und nicht nur das:
| Lines: 9
| Newsgroups: de.comm.gateways
| Message-ID: <01bcc06b$1ad48420$0228...@florian.kierspe.flummi.de>
| From: k...@flummi.de ("Michael Holzt" )
^ ^ Was das??
und in der folgenden Zeile breche ich mit \ um
|
References:<MSGID_2=3A2433=2F225.59...@fidonet.org6cT0jFsU2TB@\
flatta.in-berlin.de01bcb3e4$949c06e0$0228...@florian.kierspe.flummi\
.de6cqZN7qU2TB@flatta.in-berlin.de01bcba93$9cdcb4c0$0228a8c0@\
florian.kierspe.flummi.de>
| <6dQAp...@flatta.in-berlin.de>
Ein prima Beispiel, wie schön man seine Nachrichten versauen kann.
Und was das überempfindlich angeht:
Ich werde empfindlich, wenn man versucht mir was zu unterstellen,
obwohl man genau weiss (wissen sollte) was los ist.
René
René Kacza
geschrieben von M_An...@line.org am 12.09.97
zu "Re: Gatebau 97":
>> Sag mir ein Gate, wo Du die Hand ins Feuer legst;)
>Ich müßte bescheuert sein :-) Selbst meinem eigenen traue ich da
>nicht. Weil nämlich der Korrektheitsbeweis nicht erbracht ist (und
Ok. Damit bin ich schon wieder einen Schritt weiter.
Und weils so schön hell wird da draussen, bekommst Du auch noch einen
Header, mit der Auflage den Gatebetreiber auf die Finger zu hauen:
| References: <6cT0j...@flatta.in-berlin.de> <6dYMV...@flatta.in-berlin.de>
DA FEHLT EINE REFERENCES!
| X-Gateway: ZCONNECT ius.gun.de [UNIX/Connect v0.74b4]
| X-Comment-To: René Kacza
========== Der wird nicht kodiert!
>Probleme mit aktuellen Gateversionen von z. B. Unix/Connect oder
>AnUUCP sind aber nicht so groß, daß ein pauschales Gateverbot für die
>Ausgabe gerechtfertigt wäre.
Doch.. zumindest was der nicht vorhandene Standard und das damit
einhergehende schreddern angeht.
Wenn nicht mal ZC => RFC bzw. RFC => ZC klappt, wie soll da das
tunneln funktionieren????
>> Hm. Nun nehmen wir an:
>> Ein Gate verewigt sich und bei einem rfc-Relay fällt die Zeile unter
>> den Tisch....
>
>Dann gehört das RFC-Relay abgeklemmt. Es hat keine X-Zeilen zu
>entsorgen. Fertig.
Oder das ZC-System liefert die Zeilen schon gar nicht ein...
(Sieh mal in diesem Zusammenhang nach, ob bei Dir die fehlende
Referenz auch schon weg ist.)
>X-XP_F ist in ZConnect nicht routbar, weil der _ im Header-Tag nicht
>erlaubt ist. Die Nachricht muß gebounct (Mail) oder gelöscht (News)
Hm. das die Trotzdem rüber gegangen ist weisst Du?
Das es zu Problemen auf einigen Gates[TM] kam, hast Du noch in
Erinnerung?
>> Konsequenz: Der UUZ wurde bereinigt - X-XP_F wird gelöscht.
>Mit ein wenig Bauchgrimmen, ja.
Das gibt es bei mir auch; ein U- hätte es auch getan. Aber lieber so
als gar nicht, da es ja nicht mehr geroutet wird...
>> Auswertung, welches Gate da Mist baut kommt aber zur Gatebau - auf
>> Papier für Michael.
>Ok.
...in der Hoffnung das ich es schaffe - irgendwie bekomme ich jetzt
ein Zeitproblem...
>> Das Mime.im.Header-Problem wird in der nächsten Woche (zumindest für
>> XP-ler) gelöst sein.
>Das hilft dem Rest der Welt aber nicht.
Zumindest sind die Umsetzer beim EMPFÄNGER jeglicher ZC-basierenden
Systeme einsetzbar.
Das reicht aus.
Ich bastel nur immer Lösungen, die woanders besser eingebaut werden
sollten. Leider programmiere ich noch in TP6.0 und das ganze auch rein
realmode + Textorientiert.
>RFC-2047 ("MIME für Header") für mein Gate ist in Arbeit. Die
>lowlevel-Funktionen leisten bereits und werden einige
>Newsreader-Autoren zu Updates zwingen, weil das Gate gnadenlos auch
>base64 ausspuckt und ich von mindestens einem Newsreader weiß, der
;) - Ich kanns nicht fassen. Da kommt doch tatsächliche einer auf die
Idee, rfc's mal richtig zu lesen. (freu)
>> Also von U-To: bis U-cc: habe ich jetzt schon alles gesehen...;(
>> Wie gesagt - die Auswertung kommt....
>
>Gerne. %-)
Siehst Du weiter unten im Thread schon einen Teil. Prost Mahlzeit.
René
--
Nun wird wohl in der naechsten c't stehen "Brechts Radiotheorie:
Jeder Mensch ein Sender". Ich glaube, Brecht wuerde angesichts
dieser Kurzfassung eher wiederauferstehen als sich im Grabe
rumdrehen, aber soooo hat er es nicht gesagt. Trotzdem ok, IMO. (wau)
Johann H. Addicks
re...@flatta.in-berlin.de meinte am 15.09.97
RK> Dein Zeichensatz ist defekt - und nicht nur das:
RK>
RK> | Lines: 9
RK> | Newsgroups: de.comm.gateways
RK> | Message-ID: <01bcc06b$1ad48420$0228...@florian.kierspe.flummi.de>
RK> | From: k...@flummi.de ("Michael Holzt" )
RK> ^ ^ Was das??
RK>
Wo ist das Problem:
EMP: /Z-NETZ/TELECOM/GATEWAY
EDA: 19970913173723W+0
MID: 01bcc06b$1ad48420$0228...@florian.kierspe.flummi.de
GATE: RFC1036/822 UH link-gl.de [UUCPfZ V5.81 U031]
ROT: bluebocs.donut.de!doo.donut.de!link-gl.de!horst.is-koeln.de!um1.pce.de!news.gtn.com!news.technet.net!not-for-mail
LEN: 267
ORG: Technet GmbH
U-NNTP-Posting-Host: 194.231.46.115
U-X-Newsreader: Microsoft Internet News 4.70.1155
ABS: k...@flummi.de (Michael Holzt)
BET: Re: X-ZC-Header
BEZ: 6dQAp...@flatta.in-berlin.de
René Kacza <re...@flatta.in-berlin.de> schrieb im Beitrag
<6dQAp...@flatta.in-berlin.de>...
> >Du meinst Unwahrheiten aufwärmen?
> Stop mal - werd' nicht ausfallend.
>- aber irgendwie geht das da oben zu weit.
Kann es sein, daß Du überempfindlich bist?
-jha-
--
j...@donut.de PGP-Key via FREQ 2:2444/1007 PhoneNet: 49:2319/6120.67
Johann H. Addicks
re...@flatta.in-berlin.de meinte am 15.09.97
> X-Gateway: ZCONNECT newserv.berlinet.de [UNIX/Connect v0.75b2 SunOS],
> RFC1036/822 UE chessy.aworld.de [PolyNet RFC/ZC V4.911 15.5.1996
> Serie 599198gr45FC-012]
Hier ist Michaels Posting heil (mit korrekten Umlauten und keinen " im
Realnamen) angekommen.
Eventuell solltest Du ueberlegen, mal in eine halbwegs brauchbar betreute
Domain zu wechseln.
Michael Holzt
> > Also obige Formulierung "zum grossen Teil" ist definitiv unrichtig. Der
beide
> > korrekt.
Unix/Connect ist für mich kein Maßstab mehr. Wir wissen doch alle, was es
ständig für einen Ärger mit dieser Möchtegern-Gateway-Software gibt. Ich
ordne mittlerweile Unix/Connect in eine Schublade mit Gigo und ifmail (nur
nicht -tx Versionen).
Gruss
Michael
Michael Holzt
René Kacza <re...@flatta.in-berlin.de> schrieb im Beitrag
<6duNv...@flatta.in-berlin.de>...
> geschrieben von k...@flummi.de am 13.09.97
> zu "Re: X-ZC-Header":
>
> >Kann es sein, da# Du überempfindlich bist?
> Dein Zeichensatz ist defekt - und nicht nur das:
Die von Dir gezeigten Fehler sind nicht im Original enthalten. Du solltest
vielleicht mal einen vernünftigen Newsfeed wählen. Nur schließ bitte nicht
von dem Müll den Du in Eurer Domain so erhälst (weil Ihr einen miesen
Gateway davor habt ... nämlich Unix/Connect) darauf, daß das überall so
mies ist.
Gruss
Michael
Michael Holzt
> Und warum benutzt Du:
> X-Gateway: ZCONNECT newserv.berlinet.de [UNIX/Connect v0.75b2 SunOS],
> RFC1036/822 UE chessy.aworld.de [PolyNet RFC/ZC V4.911 15.5.1996
> Serie 599198gr45FC-012]
Ich *benutze* überhaupt nichts. PolyNet ist in Sachen X-ZC afaik fehlerfrei
(mein Gate war auch über den Umweg eines anderen Systemes an
chessy.aworld.de angebunden, und trotzdem sind die Headerzeilen überall
korrekt angekommen). Was kann ich dafür, das man in Berlin immer noch
meint, solche miese Software wie Unix/Connect verwenden zu müssen.
> >Die diversen Amiga-Gates haben zum grö#eren Teil das auch eingebaut.
> Naja... man sieht es - ulkigerweise kommen 90% der berlinet.de über
> newserv.berlinet.de
Das ist ja wohl kein Amiga-Gate.
> Und weils so schön ist, bringe ich gleich noch 'ne Hand voll Header.
Toll. Davon war der Großteil das bekannt schlechte Unix/Connect. Bei DUUCP
bin ich über den letzten Stand nicht auf dem laufenden, und AnUUCP war mir
nicht bekannt. Ist auch imho wenig im Einsatz (offensichtlich zum Glück).
> Und nun Du.
Demnächst. Probiers einfach mal mit UUCPfZ (leider momentan nur für DOS
erhältlich).
Gruss
Michael
Frank-Christian Kruegel
On 19 Sep 1997 05:46:18 GMT, "Michael Holzt" <k...@flummi.de> wrote:
>Demn=E4chst. Probiers einfach mal mit UUCPfZ (leider momentan nur f=FCr =
DOS
>erh=E4ltlich).
"momentan" ist gut. Ich habe mich mit dem Autor in Verbindung gesetzt =
wegen Unix
oder Win32 Portierung. Fehlanzeige. Ich h=E4tte die Portierung auch =
selbst
gemacht. Fehlanzeige. Sourcen gibts nicht. Auch nicht gegen Geld und/oder=
NDA.
Seufz.
=46rank-Christian Kr=FCgel
----------------------------------------------------------------------
fc...@i-online.ohz.north.de - 2:2426/3060.1 http://www.ohz.north.de/
René Kacza
geschrieben von J...@DONUT.de am 17.09.97
zu "Re: X-ZC-Header":
>re...@flatta.in-berlin.de meinte am 15.09.97
>> | From: k...@flummi.de ("Michael Holzt" )
>Wo ist das Problem:
Das schrieb ich bereits.
Das Teil kam:
flummi.de -> ZC Gateway -> ZC -> ZC-Gateway -> rfc
Warum werde ich das Gefühl nicht los, das Du nur nörgelst?
> Kann es sein, daß Du überempfindlich bist?
Kann es sein, das Du nichts verstanden hast?
René Kacza
geschrieben von j...@CWW.de am 17.09.97
zu "Re: X-ZC-Header":
>Hier ist Michaels Posting heil (mit korrekten Umlauten und keinen " im
>Realnamen) angekommen.
>Eventuell solltest Du ueberlegen, mal in eine halbwegs brauchbar
>betreute Domain zu wechseln.
Du solltest nocheinmal darüber nachdenken, von wo ich lese und
schreibe.
Du solltest nocheinmal mein Posting lesen.
Martin Schaack
Am _17.09.97_ schrieb _j...@CWW.de_ :
>Hier ist Michaels Posting heil (mit korrekten Umlauten und keinen " im
>Realnamen) angekommen.
Hier halb.(Mit nur einem " und mit kaputten Sonderzeichen)
>
>Eventuell solltest Du ueberlegen, mal in eine halbwegs brauchbar betreute
>Domain zu wechseln.
>Absender : j...@CWW.de (Johann H. Addicks)
Nun, IMHO hat cww.de auch schon das eine oder andere Problem gebracht
:-)
Daniel Kroening
Hallo!
User Frank-Christian Kruegel "fc...@i-online.ohz.north.de" schrieb
zum Thema "Re: X-ZC-Header":
FCK> "momentan" ist gut. Ich habe mich mit dem Autor in Verbindung gesetzt
FCK> wegen Unix oder Win32 Portierung. Fehlanzeige.
DUUCP für Linux/Intel gibt es hier in der HIT:
Modem 19k2..: 0681/38972-50
Modem 28k8..: 0681/38972-60
ISDN........: 0681/38972-20 (X75)
Login.......: SAUGER
Brettname...: /BINAER/DOS/ZERBERUS
Bei Bedarf gibts das auch für Solaris/Sun oder SunOS.
KROENING
Daniel Kröning - Telefon 0681/38972-0 - Fax 0681/38972-70
Michael Holzt
> >Wo ist das Problem:
> Das schrieb ich bereits.
>
> Das Teil kam:
> flummi.de -> ZC Gateway -> ZC -> ZC-Gateway -> rfc
Fehlerhaft ist hier der zweite Gateway, und das ist der Gateway hinter dem
Du hängst. Da kann hier keiner was für, und bei 90% der Empfänger dürfte
der Artikel fehlerlos angekommen sein. Dies wollte jha auch nur aufzeigen.
Aber offensichtlich hast Du bei manchen Absendern direkt Vorbehalte
gegenüber Ihren Artikeln.
> > Kann es sein, daß Du überempfindlich bist?
> Kann es sein, das Du nichts verstanden hast?
Der Satz gehörte noch zum Body des geforwardeten Artikels. Offensichtlich
hast DU nichts verstanden.
Mark-Oliver Wolter
Michael Holzt <k...@flummi.de> wrote:
: Die von Dir gezeigten Fehler sind nicht im Original enthalten. Du solltest
: vielleicht mal einen vernünftigen Newsfeed wählen. Nur schließ bitte nicht
: von dem Müll den Du in Eurer Domain so erhälst (weil Ihr einen miesen
: Gateway davor habt ... nämlich Unix/Connect) darauf, daß das überall so
: mies ist.
-----------------
Lines: 9
Newsgroups: de.comm.gateways
Message-ID: <01bcc06b$1ad48420$0228...@florian.kierspe.flummi.de>
From: k...@flummi.de ("Michael Holzt" )
Path: mow.physik.uni-bremen.de!news.IAEhv.nl!Cabal.CESspool!bofh.vszbr.cz!news.maxwell.syr.ed
u!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!newsfeed.nacamar.de!fu-berlin.de!newserv.ber
linet.de!tbx.berlinet.de!ttb.aworld.de!chessy.aworld.de!news.technet.net!not-for-mail
Organization: Technet GmbH
Subject: Re: X-ZC-Header
Date: Sat, 13 Sep 1997 17:37:23 +0000
X-Mailer: Microsoft Internet News 4.70.1155
References: <MSGID_2=3A2433=2F225.59...@fidonet.org6cT0jFsU2TB@flatta.in-berlin.de01bcb
3e4$949c06e0$0228...@florian.kierspe.flummi.de6cqZN7qU2TB@flatta.in-berlin.de01bcba93$9cdcb4
c0$0228...@florian.kierspe.flummi.de>
<6dQAp...@flatta.in-berlin.de>
X-Gateway: ZCONNECT newserv.berlinet.de [UNIX/Connect v0.75b2 SunOS],
RFC1036/822 UE chessy.aworld.de [PolyNet RFC/ZC V4.911 15.5.1996 Serie 599198gr45FC-0
12]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
RenÚ Kacza <re...@flatta.in-berlin.de> schrieb im Beitrag
<6dQAp...@flatta.in-berlin.de>...
> >Du meinst Unwahrheiten aufwõrmen?
> Stop mal - werd' nicht ausfallend.
>- aber irgendwie geht das da oben zu weit.
Kann es sein, da# Du ³berempfindlich bist?
-------------
So ist der Artikel hier angekommen.
Man beachte den Path: ... _dies_ ist die Version, die auf den
größten Newsservern rumliegt.
Also wer hat hier einen schlechten Newsfeed?
--
| | | MfG MOW []-)
| | | Leobener Str.4, App.6-15, 28359 Bremen, Tel. ++49-421-210492
M O W http://www.zfn.uni-bremen.de/~g02o/ or ++49-177-2503055
/' | `\ Always logon - the bright side of life !
Michael Holzt
Mark-Oliver Wolter <ro...@mow.physik.uni-bremen.de> schrieb im Beitrag =
<602u7c$q...@mow.physik.uni-bremen.de>...
> Path: =
mow.physik.uni-bremen.de!news.IAEhv.nl!Cabal.CESspool!bofh.vszbr.cz!news.=
maxwell.syr.ed
> =
u!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!newsfeed.nacamar.de!fu-b=
erlin.de!newserv.ber
> =
linet.de!tbx.berlinet.de!ttb.aworld.de!chessy.aworld.de!news.technet.net!=
not-for-mail
> So ist der Artikel hier angekommen.
> Man beachte den Path: ... _dies_ ist die Version, die auf den
> gr=F6=DFten Newsservern rumliegt.
> Also wer hat hier einen schlechten Newsfeed?
Zufall, da=DF der Artikel schneller =FCber diesen normal viel =
langsameren ZConnect/RFC-Weg angekommen ist. Gegenbeispiel (auch gro=DFe =
Newsserver, bbnplanet und fu-berlin ist auch dabei):
Path: =
news.telemedia.de!bignews.telemedia.de!bignews.guetersloh.mediaways.net!n=
ews-fra.maz.net!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!newsfeed.i=
nternetmci.com!193.174.75.126!news-was.dfn.de!news-fra1.dfn.de!news-ber1.=
dfn.de!fu-berlin.de!news-out2.du.gtn.com!news-in2.du.gtn.com!news.gtn.com=
!news.technet.net!not-for-mail
Trotzdem ist der Feed =FCber Unix/Connect schlecht, weil die Artikel =
dort h=E4ufiger kaputt gehen. Ich pers=F6nlich w=FCrde solche Artikel =
nicht weitergaten.
Gruss
Michael
René Kacza
geschrieben von k...@flummi.de am 19.09.97
zu "Re: X-ZC-Header":
>solltest vielleicht mal einen vernünftigen Newsfeed wählen. Nur
>schließ bitte nicht von dem Müll den Du in Eurer Domain so erhälst
Du hast es immer noch nicht begriffen.
Vielleicht sollte Euer System aber mal vernünftig per SMTP/UUCP
abliefern und nicht ZC-Gateways benutzen um seine Spools loszuwerden.
Hinweis: Mach mal ein whois auf IN-Berlin.de
René
--
| Gehe zu C*nrad, begib dich direkt dorthin, gehe nicht über |
| V*bis, nehme ca. 30 DM mit, vergiß die Kabel nicht. |
+-- hi...@scorpio.in-berlin.de in de.comm.misc: Ein Monitor an zwei PCs? --+
René Kacza
>> > unrichtig. Der gröÿte Teil der Gateways ist UUCPfZ oder DUUCP, und
>Unix/Connect ist für mich kein Maßstab mehr. Wir wissen doch alle, was
Da widerspricht etwas.
Es ging nicht um Maßstab von Software sondern um die Häufigkeit der
Anwendungen.
Äpfel mit Birnen verglichen?
R.
--
+ >Also, wie war das? Es gibt offene und abgeschlossene Server. Gibt es +
| >auch Server, die weder offen noch abgeschlossen sind? [...] |
| Aufgeschlossene Server? Sind die dann besonders kontaktfreudig? |
+ - - - gefunden in: <bjoer...@baer.mayn.de> - - - - - - - - - - - - -+
René Kacza
>überall korrekt angekommen). Was kann ich dafür, das man in Berlin
>immer noch meint, solche miese Software wie Unix/Connect verwenden zu
Was kann ich dafür, das newserv.berlinet.de an die Uni einliefert?
>> Naja... man sieht es - ulkigerweise kommen 90% der berlinet.de über
>> newserv.berlinet.de
>Das ist ja wohl kein Amiga-Gate.
Darum ging es nicht. Es geht um das, was zum Schluss rauskommt.
Es kann doch nicht Dein Ernst sein, zu verlangen es sollen alle auf
AMiga umsteigen:-)
[Header]
>Toll. Davon war der Großteil das bekannt schlechte Unix/Connect. Bei
>DUUCP bin ich über den letzten Stand nicht auf dem laufenden, und
>AnUUCP war mir nicht bekannt. Ist auch imho wenig im Einsatz
Ja und?
Es ist doch wohl vollkommen Schnuppe, über welches Gate geroutet wird.
Es ist doch wohl vollkommen Schnuppe, über welche Software gegatet
wird....
Solange die Gateway-Betreiber nicht auf Ihre defekte Software
reagieren und die Programmierer sich nicht mal hinsetzen und ihr Teil
debuggen, wird sich an der Situation nichts ändern.
Aber wozu haben wir diese(!) Gruppe???
>Demnächst. Probiers einfach mal mit UUCPfZ (leider momentan nur für
>DOS erhältlich).
Ich nicht. Ich bin rfc - via uucp - System.
- angeschlossen per Free-BSD-Unix-Derivat an die Uni.
Michael Holzt
Ren=E9 Kacza <re...@flatta.in-berlin.de> schrieb im Beitrag =
<6eLxX...@flatta.in-berlin.de>...> zu "Re: X-ZC-Header (was: Gatebau 97)":
>=20
> >> > unrichtig. Der gr=F6=FFte Teil der Gateways ist UUCPfZ oder =
DUUCP, und
> >Unix/Connect ist f=FCr mich kein Ma=DFstab mehr. Wir wissen doch =
alle, was
>=20
> Da widerspricht etwas.
> Es ging nicht um Ma=DFstab von Software sondern um die H=E4ufigkeit =
der =20
> Anwendungen.
Alle Gateways sind Scheisse, weil Gigo scheisse ist, und zu oft =
verwendet wird?
--=20
Gruss Michael
Backup-Mailaddress: k...@mark.sub.de, Phone: +49-2359-903362
Michael Holzt
> Solange die Gateway-Betreiber nicht auf Ihre defekte Software =20
> reagieren und die Programmierer sich nicht mal hinsetzen und ihr Teil =
> debuggen, wird sich an der Situation nichts =E4ndern.
Ja richtig. Nur sind weder jha noch ich, oder andere Leute die Du =
momentan anfeindest Betreiber oder Programmierer vom defekten =
Unix/Connect. Aber uns schreibst Du b=F6se Artikel wegen kaputter =
Artikel. Beschwerd Dich gef=E4lligst beim berlinet-Gateway, aber der ist =
imho nach unseren letzten Erfahrungen eh unbelehrbar. Oder setz Dich =
daf=FCr ein, da=DF Artikel von diesem Gateway nicht mehr weitergeleitet =
werden. Da Du dort oben sitzt, ist es wohl naheliegend, da=DF Du Dich =
darum k=FCmmerst, und nicht andere. Oder Du regst Dich einfach nicht =
mehr auf.=20
Was sollen jha und ich machen? Uns in den Zug setzen und solange auf den =
Berlinet-Gate-Betreiber einpr=FCgeln, bis er was vern=FCnftiges benutzt?
Du hast und hattest nun wirklich keinen Grund auf jha oder mich sauer zu =
sein. Trotzdem hast Du uns angemacht, und dann beschwerst Du Dich =FCber =
die passenden Reaktionen.
René Kacza
geschrieben von Martin....@t-online.de am 19.09.97
zu "Re: X-ZC-Header":
>Hier halb.(Mit nur einem " und mit kaputten Sonderzeichen)
Das ist das, was Crosspoint daraus verzapft hat.
>Nun, IMHO hat cww.de auch schon das eine oder andere Problem gebracht
Ohne spitzfindig zu sein...: Wer war gestern mit Mailinglisten-
Substcribes beschäftigt?
René
--
| Es geht aufwärts ... |
| ... sprach der Spatz, als die Katze ihn die Treppe hinauf trug |
+---Wolfgang Hohlbein / Johan Kerk - Spacelords St.Petersburg II----+
René Kacza
geschrieben von k...@flummi.de am 22.09.97
zu "Re: X-ZC-Header":
>Trotzdem ist der Feed über Unix/Connect schlecht, weil die Artikel
>dort häufiger kaputt gehen. Ich persönlich würde solche Artikel nicht
>weitergaten.
Wieso 'weitergaten'? Es gatet nach newserv.berlinet.de niemand!
Als Feed würde ich solche Artikel nicht annehmen.
Darum auch meine Forderung newserv.berlinet.de endlich abzuklemmen;
offensichtlich werden von dort defekt-gegatete Nachrichten auf alle
möglichen Newsserver verteilt.
Das unterstützt meine obige Aussage, das ganz bestimmt NICHT 90%
Deinen Artikel in der Rein-Form bekommen haben.
Ich habe nur keine Lust, immer und immer wieder das gleiche zu
schreiben, wenn es niemand verstehen will.
Oder kannst Du mir erklären, warum ich in de.comm.gateways bereits 31
Artikel geschrieben habe, die darauf verwiesen das ich rfc-System bin
und (mehr oder weniger) von der / über die FU versorgt werde?
rené
René Kacza
geschrieben von ro...@mow.physik.uni-bremen.de am 21.09.97
zu "Re: X-ZC-Header":
>Man beachte den Path: ... _dies_ ist die Version, die auf den
>größten Newsservern rumliegt.
Zu bemerken sei noch, das selbst nacamar und diverse anderen Uni-s
(hier Bremen) diesen Artikel so bekommen haben, was daruf schliessen
lässt, das technet.net gar nicht erst versucht hat den ordentlich zu
verteilen sondern sofort über ein Gateway abkippte.
Eigentlich schade, das die Diskussion zur Gatebau so entgleisen
musste...
rené
--
+---------- -----------+
| Fussnote: ein Posting "kommt" normalerweise sofort. Bei Moderation |
| ist es zuerstmal impotent :) |
+--- Henning Weede in <5ocac7$t4a$1...@unlisys.unlisys.net> ------------+
René Kacza
geschrieben von k...@flummi.de am 21.09.97
zu "Re: X-ZC-Header":
>Fehlerhaft ist hier der zweite Gateway, und das ist der Gateway hinter
>dem Du hängst. Da kann hier keiner was für, und bei 90% der Empfänger
Ich hänge hinter keinem Gateway! Das sollte auch dem letzten klar
geworden sein. Ich hänge hinter FU - und nur das zählt für mich.
Wenn Du auf einem Newsserver schreibst, der seine News erst über einen
Gateway absetzt, dann liegt das Problem bei mir?
Doch ganz bestimmt nicht. Aber darum geht es hier auch gar nicht.
Es heisst hier: de.comm.gateways Richtig? Richtig.
Ergo werden Fehler eines Gateways / einer defekten Software hier
behandelt. Richtig?
Ich versuche seit meinem ersten Posting sowohl die Programmierer als
auch die Betreiber dahin zu bringen, dieser Software endgültig adé zu
sagen, bzw. die Bug's zu entfernen.
Warum schreien hier eigentlich alle so laut, wie gut Ihre Anbindung
und IHRE Software ist, liefern aber dennoch an defekte Gateways aus?
>dürfte der Artikel fehlerlos angekommen sein. Dies wollte jha auch nur
>aufzeigen. Aber offensichtlich hast Du bei manchen Absendern direkt
>Vorbehalte gegenüber Ihren Artikeln.
In wie fern der Artikel wirklich zu 90% sauber rausgegangen und
verteilt wurde, lässt sich wohl schlecht nachvollziehen; ich denke
aber mal, das es einige hundert rfc-Systeme gibt bei denen das nicht
der Fall ist.
Was die Vorbehalte angeht:
Nein das stimmt nicht und das sollte Dir auch mittlerweile klar sein.
Ich bin weder ein notorischer noch ein paranoider. Wenn Du das
Gegenteil beweisen willst, steht Dir nichts im Wege. Bedenke aber, das
ich bestimmt sehr oft (zumindest für meine Verhältnisse) zum Hörer
greife und lieber ein klärendes Telefongespräch vorziehe, als blind
los zu wüten.
Es gibbet allerdings auch Dinge, die mich einfach anstinken. So unter
anderem auch das entsprechende Subject in dieser Group. Den Beweis
habe ich mit meinem F'up darauf bereits erbracht.
Ich werde einer konstruktiven Diskussion nicht im Wege stehen. Jedoch
denke ich mal, das man hier aneinander vorbei redet und/oder sich
nicht verstehen will/kann.
Aus diesem Grunde hatte ich auch vor meinen Horizont beim Gatebau '97
zu erweitern - aber was soll's.
>Der Satz gehörte noch zum Body des geforwardeten Artikels.
Ja und? Trotzdem darf ich wohl meinen Senf darunter setzen.
Michael Holzt
> Wenn Du auf einem Newsserver schreibst, der seine News erst =FCber =
einen =20
> Gateway absetzt, dann liegt das Problem bei mir?
Der Newsserver setzt seine News nicht =FCber einen Gateway ab. =
Zuf=E4llig wird aber die chessy auch davon gespeist, und die hat eine =
ziemlich gute Anbindung, feedet diverse ZC-Systeme und pollt UUCP =FCber =
eine Standleitung. Raus gehts wohl alle paar Stunden.
> Es heisst hier: de.comm.gateways Richtig? Richtig.
> Ergo werden Fehler eines Gateways / einer defekten Software hier =20
> behandelt. Richtig?
Unsicher.Ich glaube nach Charta ist eher de.comm.gatebau die Gruppe. Ich =
habe sie leider gerade nicht vorliegen. Ist aber eigentlich auch =
unerheblich, und darum gings auch nicht.
> Warum schreien hier eigentlich alle so laut, wie gut Ihre Anbindung =20
> und IHRE Software ist, liefern aber dennoch an defekte Gateways aus?
"Geschrien" haben vor allem jha und ich (nach entsprechenden =
Anfeindungen). Wir haben beide vern=FCnftige Software am laufen (bzw. =
habe ich momentan gar keinen Gateway am laufen), und wir liefern auch =
beide nicht an defekte Gateways aus. Ich habe leider noch kein =
=FCbernat=FCrlichen Kr=E4fte entwickelt, um berlinet am Gaten zu =
hindern. Au=DFer vielleicht der Holzhammer-Methode - Pfadf=E4lschung. =
Aber sowas l=E4=DFt sich nicht mal mit Gateway-Fehlern begr=FCnden.
> Was die Vorbehalte angeht:
> Nein das stimmt nicht und das sollte Dir auch mittlerweile klar sein.
Mittlerweile haben sich die Wogen gegl=E4ttet, mittlerweile hast Du ein =
paar Informationen und Standpunkte gepostet, die bisher nicht so klar =
waren, und mittlerweile denke ich sowieso etwas ander dr=FCber. Du =
beziehst Dich aber h=E4ufig auf Artikel die noch vor dem "mittlerweile" =
lagen.
> Es gibbet allerdings auch Dinge, die mich einfach anstinken. So unter =
> anderem auch das entsprechende Subject in dieser Group. Den Beweis =20
> habe ich mit meinem F'up darauf bereits erbracht.
Gut, aber ich war es nicht.
> Aus diesem Grunde hatte ich auch vor meinen Horizont beim Gatebau '97 =
> zu erweitern - aber was soll's.
Von mir aus kannst Du trotzdem kommen. Ich entschuldige mich hiermit =
f=FCr Entgleisungen meinerseits, erwarte allerdings von Dir auch =
zumindest ein gewisses Eingest=E4ndnis einer Mitschuld. Denn Deine =
Postings waren auch nicht immer das gelbe das Ei. Von mir aus k=F6nnen =
wir uns darauf einigen, da=DF wir uns beide scheisse verhalten haben, =
und die Sache begraben. Ich habe mich bisher im Netz nur mit einigen =
Leuten restlos verkracht, und ich steh da auch nicht so drauf.
> >Der Satz geh=F6rte noch zum Body des geforwardeten Artikels.
> Ja und? Trotzdem darf ich wohl meinen Senf darunter setzen.
Dein Senf sah aber noch so aus, als wenn Du den Satz jha zuschieben =
w=FCrdest.
Michael Holzt
31 =20
> Artikel geschrieben habe, die darauf verwiesen das ich rfc-System bin =
> und (mehr oder weniger) von der / =FCber die FU versorgt werde?
Einen solchen Artikel habe ich erst gelesen, *nachdem* ich den =
Bezugsartikel gepostet hatte. Leider sind die Laufzeiten nicht immer =
ganz so da=DF was sie sein sollten, was sich ja auch dadurch =
best=E4tigt, das offensichtlich manchmal der ZC-Weg schneller ist.
Dirk Meyer
In der Nachricht vom 22.09.97 12:38 Uhr schrieb re...@flatta.in-berlin.de
> [Header]
> >Toll. Davon war der Großteil das bekannt schlechte Unix/Connect
> [...]
> Solange die Gateway-Betreiber nicht auf Ihre defekte Software
> reagieren und die Programmierer sich nicht mal hinsetzen und ihr Teil
> debuggen, wird sich an der Situation nichts ändern.
Unix/Connect ist besser als sein Ruf.
Die aktuelle Version ist 0.75b4.
Die X-ZC-Header werden schon seit langem korrekt gewandelt.
Dein X-ZC-PGP-KEY-AVAIL wurde hier auch richtig umgesetzt.
ROT: dinoex.sub.org!ud.dinoex.sub.org!phase23!news.hrz.uni-kassel.de!news-han1.dfn.de!news-ham1.dfn.de!news-ber1.dfn.de!fu-berlin.de!unlisys!bolzen.in-berlin.de!news.all.de!mind.de!scorpio.in-berlin.de!kwcom1.in-berlin.de!kwcom.in-berlin.de!flatta.in-berlin.de!rene
GATE: RFC1036/822 gate.dinoex.sub.org [UNIX/Connect v0.75b4-m2]
PGP-KEY-AVAIL:
Die meisten Betreiber reagieren darauf,
un stellen auf die aktuelle Version um.
Nur diese fallen normalerweise nicht auf.
> Ich nicht. Ich bin rfc - via uucp - System.
> - angeschlossen per Free-BSD-Unix-Derivat an die Uni.
Es gibt ein Port-Package für Free-BSD für unix-connect.
Gruß Dirk
-- Dirk Meyer, Im Grund 4, 34317 Habichtswald, Tel 05606/6512 Q (voice)
-- Origin: DINOEX Habichtswald -FRG- [dirk....@dinoex.sub.org]
Aenderungen an UnixConnect
seit 0.75b3
- uudecode bekommt einen festen Dateinamen vorgesetzt. Damit braucht das
Programm nicht mehr nach der dekodierten Datei zu suchen und uudecode
kommt nicht auf den Gedanke, eine falsche Datei zu überschreiben. Evtl.
kann auch noch das Erzeugen eines temp-Directories herausfliegen.
- Beim Dekodieren von UNIX/Connect-Multipart-Nachrichten wird die korrekte
Länge in den Header eingetragen.
- Nachrichten am Dateiende mit falschem LEN-Header werden jetzt wenigstens
soweit wie möglich konvertiert und nicht abgeschnitten.
- Beim uuencode wird nicht mehr der Text "SP_MULTIPART_BOUNDARY" angehängt,
sondern das Boundary
- Der ZC-Vertreter landet nicht im Envelope-Absender.
- Falsche Newsgroup-Namen werden tatsächlich nur ausgegeben, wenn ihr Header
auch geschrieben wird.
- Es wird nur noch ein Envelope-From ausgegeben.
- Header, die nur einmal auftreten dürfen, werden nur einmal ausgegeben.
- RFC-Header werden nach RFC822 umbrochen. Dafür gibt es neue Routinen in
zconv.c
- In call.c fehlte im Teil, der ge-fork()-t wurde, ein _exit(0).
seit 0.75b2
- neue Kompilier-Option: LOG_ERRORS_IN_HEADERS (default: ja). Hiermit werden
Parse-Fehler in X-Headern vermerkt.
- ZC-Brettnamen werden etwas intensiver geprüft.
- printbretter komplett neu (Dirk)
- einige Pointer-Bugs korrigiert, führten zum Absturz
[ ... oder zu nicht erkennen von X-Headern ... ]
- einige Speicherlöcher im Zusammenhang mit MIME beseitigt.
- EB mehrfach.
- zbatchsmtp: Datenloch gestopft, Dateien werden nur noch gelöscht, wenn
uursmtp nicht fehlgeschlagen ist.
Michael Holzt
> Zu bemerken sei noch, das selbst nacamar und diverse anderen Uni-s =20
> (hier Bremen) diesen Artikel so bekommen haben, was daruf schliessen =20
> l=E4sst, das technet.net gar nicht erst versucht hat den ordentlich zu =
=20
> verteilen sondern sofort =FCber ein Gateway abkippte.
Du hast mein Gegenbeispiel sicher auch gesehen. Zufall sag ich. Technet =
ist ein ziemlich guter Newsserver, auch wenn er nur zwei Feeds hat =
(momentan, demn=E4chst kommt ein Sat-Link hinzu).
Michael Holzt
Das hab ich ja auch gemeint. Lies "weitergaten", verstehe =
"weiterleiten". War ein kleiner Fehler.
> Darum auch meine Forderung newserv.berlinet.de endlich abzuklemmen; =20
Das forderst nicht nur Du. Aber wie?
René Kacza
geschrieben von k...@flummi.de am 24.09.97
zu "Re: X-ZC-Header":
>Von mir aus kannst Du trotzdem kommen. Ich entschuldige mich hiermit
>für Entgleisungen meinerseits, erwarte allerdings von Dir auch
Du bekommst Sie natürlich auch.
Mittlerweile sollte sich auch eine Mail bei Dir eingefunden haben,
sodas das Thema 'Anfeindungen' hiermit abgeschlossen sein sollte.
Wie ich bereits schrieb, gehe ich davon aus, das es hier zu einigen
Missverständnissen kam.
Wenn Johann seine Subjectwahl abklärt und hier ernsthaftes Interesse
an einem Treffen im RL besteht, bekomme ich meine Frau evtl. doch noch
überzeugt nach Dortmund zu fahren;)
René
Alle anderen Antworten müssen zurückstecken ich war zwei Tage Down
wegen Harrdwareupdate...
René
--
+------ -----+
| Das Androhen von Mailbomben ist nicht von allgemeinem Interesse.|
+------- Heiko Schlichting in: <5saj0o$5...@fu-berlin.de> -------+
Matthias Andree
k...@flummi.de (Michael Holzt) schrieb am 23.09.1997:
> Was sollen jha und ich machen? Uns in den Zug setzen und solange auf
> den Berlinet-Gate-Betreiber einprügeln, bis er was vernünftiges
> benutzt?
Nein, seine Rechner mit dem großen Magneten so lange heben und
fallenlassen, bis die Platten leer sind. Prügeln ist zu primitiv.
Gruß,
--
MATTHIAS ANDREE * Öffentlicher PGP-Schlüssel auf Anfrage verfügbar
René Kacza
Hallo Micha,
hier läuft irgendwas amok:
Path: kwcom.in-berlin.de!kwcom1.in-berlin.de!scorpio.in-
berlin.de!mind.de!news.bln.de!news.nacamar.de!newsfeed.nacamar.de!news-
out2.du.gtn.com!news-in2.du.gtn.com!news-
in1.ne.gtn.com!news.gtn.com!news.technet.net!not-for-mail
From: "Michael Holzt" <k...@flummi.de>
Newsgroups: de.comm.gateways
Subject: Re: X-ZC-Header
Date: 24 Sep 1997 17:13:36 GMT
Organization: Technet GmbH
Lines: 17
Message-ID: <01bcc90c$ac1e7900$0228...@florian.kierspe.flummi.de>
References: <MSGID_2=3A2433=2F225.59...@fidonet.org6cT0jFsU2TB@flatta.in-berlin.de01bcb3e4$949c06e0$0228...@florian.kierspe.fl><01bcc06b$1ad48420$0228...@florian.kierspe.flummi.de><6duNv...@flatta.in-berlin.de><01bcc4c5$b5247cc0$162ea8c0@holz
t.
NNTP-Posting-Host: 194.231.46.74
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Newsreader: Microsoft Internet News 4.70.1155
==========
Oki. Jetzt stimmt zwar der NNTP-Posting-Host (stimmt er wirklich;) )
jedoch ist die References.Id vollkommen daneben.
Wenn das Teil SO bei Dir angekommen ist, dann hab ich endlich einen
Grund news.fu-berlin.de was zu liefern.
*Frage an alle:*
Wer hat das Posting, auf welches ich mich hier beziehe noch so
bekommen???
Wer hat das Original von mir mit defektem Header bekommen?
René
PS: F'up auf poster gesetzt - weil zum zusammensuchen hier offtopic
Matthias Andree
k...@flummi.de (Michael Holzt) schrieb am 23.09.1997:
> Alle Gateways sind Scheisse, weil Gigo scheisse ist, und zu oft verwendet wird?
Bleibt locker. Ein beklopptes Gateway ist der Aufregung nicht wert.
Lutz Issler
Hallo Michael,
MH> Was sollen jha und ich machen? Uns in den Zug setzen und solange auf den
MH> Berlinet-Gate-Betreiber einpruegeln, bis er was vernuenftiges benutzt?
Als Termin fuer den Showdown wuerde ich den 23. Oktober vorschlagen. Dann
koenntet ihr Rene auf dem Rueckweg gleich mit zur Gatebau nehmen...
<gd&r>
-.Lutz.-
Matthias Andree
dirk....@dinoex.sub.org (Dirk Meyer) schrieb am 24.09.1997:
> Unix/Connect ist besser als sein Ruf.
> Die aktuelle Version ist 0.75b4.
...mit dem Patch, um Cancel-Nachrichten mit BEZ: zu versehen, der
getrennt durch die U/C-Mailingliste ging...
> Die X-ZC-Header werden schon seit langem korrekt gewandelt.
> Dein X-ZC-PGP-KEY-AVAIL wurde hier auch richtig umgesetzt.
>
> ROT: dinoex.sub.org!ud.dinoex.sub.org!phase23!news.hrz.uni-kassel.de!news-han1.dfn.de!news-ham1.dfn.de!news-ber1.dfn.de!fu-berlin.de!unlisys!bolzen.in-berlin.de!news.all.de!mind.de!scorpio.in-berlin.de!kwcom1.in-berlin.de!kwcom.in-berlin.de!flatta.in-berlin.de!rene
> GATE: RFC1036/822 gate.dinoex.sub.org [UNIX/Connect v0.75b4-m2]
> PGP-KEY-AVAIL:
>
> Die meisten Betreiber reagieren darauf,
> un stellen auf die aktuelle Version um.
> Nur diese fallen normalerweise nicht auf.
Das ist der Punkt. Andererseits hacken diese 0.74b4 patchlevel 12
gewaltig rein (immerhin hat das Gate, das diesen Müll lange Zeit
gefahren hat, die Bitten um Update erhört).
Matthias Andree
k...@flummi.de (Michael Holzt) schrieb am 24.09.1997:
> René Kacza <re...@flatta.in-berlin.de> schrieb im Beitrag <6eQAc...@flatta.in-berlin.de>...
> > Wieso 'weitergaten'? Es gatet nach newserv.berlinet.de niemand!
> > Als Feed würde ich solche Artikel nicht annehmen.
>
> Das hab ich ja auch gemeint. Lies "weitergaten", verstehe "weiterleiten". War ein kleiner Fehler.
>
> > Darum auch meine Forderung newserv.berlinet.de endlich abzuklemmen;
>
> Das forderst nicht nur Du. Aber wie?
Notfalls bei den Up- und Downstreams vorstellig werden, soweit die zu
ermitteln sind. Was nützt ein Gate, das keine Daten bekommt und/oder
loswird? Isolation ist genausogut.
Christopher Creutzig
On Mon, 15 Sep 1997, Matthias Andree wrote:
-> Du vergißt Unix/Connect, das erheblichen Anteil des Volumens stellt.
Ist hier egal, da UNIX/Connect diesen Fehler ebenfalls nicht macht.
--
Christopher Creutzig # Im Samtfelde 19 # D-33098 Paderborn # V+49-5251-71873
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
Für Wichtiges: Zur Zeit lese ich Mail an 'c...@mupad.de' deutlich öfter.
Christopher Creutzig
On Fri, 19 Sep 1997, Michael Holzt wrote:
-> von dem Müll den Du in Eurer Domain so erhälst (weil Ihr einen miesen
-> Gateway davor habt ... nämlich Unix/Connect) darauf, daß das überall so
Hast Du einen besseren Vorschlag? Wenn ich höre, daß DUUCP anscheinend
immer noch To:-Header verwirft etc., sehe ich nicht ein, Unix/Connect als
im Vergleich schlecht anzusehen.
Christopher Creutzig
On Tue, 9 Sep 1997, René Kacza wrote:
-> Also von U-To: bis U-cc: habe ich jetzt schon alles gesehen...;(
Gerade To: ist aber auch nicht abbildbar, da im EMP der Envelope-Empfänger
stehen muß. Also muß U-To: erzeugt werden, wenn keine relevante Information
verworfen werden soll.
Christopher Creutzig
On 23 Sep 1997, Michael Holzt wrote:
-> Ja richtig. Nur sind weder jha noch ich, oder andere Leute die Du
-> momentan anfeindest Betreiber oder Programmierer vom defekten
-> Unix/Connect. Aber uns schreibst Du böse Artikel wegen kaputter Artikel.
-> Beschwerd Dich gefälligst beim berlinet-Gateway, aber der ist imho nach
-> unseren letzten Erfahrungen eh unbelehrbar. Oder setz Dich dafür ein, daß
Wie wäre es stattdessen mir eine Fehlermeldung zu schicken? Momentan sieht
es so aus, daß einfach auf Unix/Connect eingehauen wird, die hier
beanstandeten Fehler seit mehreren Monaten behoben sind und daß es außerdem
niemand für nötig hielt, mich als Programmierer darauf aufmerksam zu machen
(z.B. durch sachliches Beschreiben hier).
Christopher Creutzig
On Sun, 21 Sep 1997, Michael Holzt wrote:
-> Fehlerhaft ist hier der zweite Gateway, und das ist der Gateway hinter dem
-> Du hängst. Da kann hier keiner was für, und bei 90% der Empfänger dürfte
In diesem Fall vermutlich eher das erste Gate, das aus
From: "Michael Holzt" <k...@flummi.de>
ein
ABS: k...@flummi.de ("Michael Holzt" )
gemacht hat.
Michael Holzt
Christopher Creutzig <chris...@nescio.foebud.org> schrieb im Beitrag =
<Pine.LNX.3.95.971017...@nescio.foebud.org>...
> On Fri, 19 Sep 1997, Michael Holzt wrote:
>=20
> -> von dem M=FCll den Du in Eurer Domain so erh=E4lst (weil Ihr einen =
miesen
> -> Gateway davor habt ... n=E4mlich Unix/Connect) darauf, da=DF das =
=FCberall so
>=20
> Hast Du einen besseren Vorschlag? Wenn ich h=F6re, da=DF DUUCP =
anscheinend
> immer noch To:-Header verwirft etc., sehe ich nicht ein, Unix/Connect =
als
> im Vergleich schlecht anzusehen.
"Mein Gateway macht scheisse. Ist aber egal, weil alle anderen das auch =
machen."
Eine interessante Einstellung. Im =FCbrigen: Ist es wirklich n=F6tig=20
Threads die 1 Monat alt sind, wieder aufzuw=E4rmen?
Johann H. Addicks
k...@flummi.de meinte am 18.10.97
MH> Eine interessante Einstellung. Im übrigen: Ist es wirklich nötig
MH> Threads die 1 Monat alt sind, wieder aufzuwärmen?
Das ist die beruechtigte Creutzig-Taktik!
Mit den Replies so lange warten bis die Bezugsnachrichten bei allen andern
expired sind und zusaetzlich dann gleich ein Dutzend Postings auf einmal
verschicken.
Das stellt dann fast immer sicher, zumindest in der Haelfte der Threads
das letzte Wort gehabt zu haben.
-jha-
--
j...@donut.de PGP-Key via FREQ 2:2444/1007 PhoneNet: 49:2319/6120.67
Matthias Andree
chris...@nescio.foebud.org (Christopher Creutzig) schrieb am 17.10.1997:
> On Tue, 9 Sep 1997, René Kacza wrote:
>
> -> Also von U-To: bis U-cc: habe ich jetzt schon alles gesehen...;(
>
> Gerade To: ist aber auch nicht abbildbar, da im EMP der Envelope-Empfänger
> stehen muß. Also muß U-To: erzeugt werden, wenn keine relevante Information
> verworfen werden soll.
Wenn der Envelope-Empfänger allein im To: auftaucht, kann man wohl guten
Gewissens auf U-To: verzichten.
Matthias Andree
chris...@nescio.foebud.org (Christopher Creutzig) schrieb am 17.10.1997:
> Wie wäre es stattdessen mir eine Fehlermeldung zu schicken? Momentan sieht
> es so aus, daß einfach auf Unix/Connect eingehauen wird, die hier
> beanstandeten Fehler seit mehreren Monaten behoben sind und daß es außerdem
> niemand für nötig hielt, mich als Programmierer darauf aufmerksam zu machen
> (z.B. durch sachliches Beschreiben hier).
Das nützt uns aber nix, wenn newserv.berlinet.de nicht updatet, und
zel...@zelator.berlinet.de (der Admin-Contact) sich nicht schert.
Nichtmal Empfangsbestätigungen gibt's von denen. Die sollte man echt
abklemmen.
Matthias Andree
j...@CWW.de (Johann H. Addicks) schrieb am 18.10.1997:
> chris...@nescio.foebud.org meinte am 17.10.97
>
> > -> Also von U-To: bis U-cc: habe ich jetzt schon alles gesehen...;(
>
> > Gerade To: ist aber auch nicht abbildbar, da im EMP der Envelope-EmpfSnger
> > stehen mu . Also mu U-To: erzeugt werden, wenn keine relevante Information
> > verworfen werden soll.
>
> So bloed es auch klingen macht, in ZC heisst das F-TO:
Ich fürchte, Du verwechselst etwas.
Alfons Berger schreibt eine Mail, beispielsweise in ein Echo oder Brett
Charlotte Dahmen antwortet darauf. Ihre Mail führt nun "F-TO: Alfons
Berger" - ohne Mailadresse oder dergleichen.
Wie man am F- unschwer erkennen kann, handelt es sich bei diesem
"ZC"-Header um einen, der aus der Fidowelt stammt oder eine Kludge für
ebendiese ist. Beim Gating RFC->ZC kann der Header nur entstehen, wenn
die Mail originär im FTS-Format vorgelegen hat (auch, wenn die meisten
Gates ein RFC-seitig manuell erzeugtes X-Comment-To: ebenfalls nach
F-TO: gaten werden).
Nachzulesen ist dies in den '93er oder '94er Gatebaudokumenten.
Christopher Creutzig
On 18 Oct 1997, Johann H. Addicks wrote:
-> > Gerade To: ist aber auch nicht abbildbar, da im EMP der Envelope-EmpfSnger
-> > stehen mu . Also mu U-To: erzeugt werden, wenn keine relevante Information
-> > verworfen werden soll.
->
-> So bloed es auch klingen macht, in ZC heisst das F-TO:
Der RFC822-Header To: wird definitiv nicht in F-To: gewandelt.
--
Christopher Creutzig # Im Samtfelde 19 # D-33098 Paderborn # V+49-5251-71873
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
"Das kann doch nicht so schwer sein, so ein paar Header zu erzeugen!"
(Eike Rathke auf der Gatebau'97)
Sara Avis
was ist gatebau, was heisst x-header ? was sollen x-z-x ? was bedeutet
x- wird nicht escaped ?
fragend
Michael Holzt
Sara Avis <lach...@sp.zrz.tu-berlin.de> schrieb im Beitrag =
<34732649...@sp.zrz.tu-berlin.de>...
> was ist gatebau, was heisst x-header ? was sollen x-z-x ? was bedeutet
> x- wird nicht escaped ?
> fragend
Gegenfrage. Was hast Du vor?
Matthias Andree
lach...@sp.zrz.tu-berlin.de (Sara Avis) schrieb am 19.11.1997:
> was ist gatebau, was heisst x-header ? was sollen x-z-x ? was bedeutet
> x- wird nicht escaped ?
a) Gatebau ist das Treffen einiger Gateprogrammierer
b) X-Header sind (unter RFC und ZConnect) Header, die mit X- beginnen.
c) X-Z-X- sind Programmfehler
d) X- wird nicht escapt hängt mit c) zusammen und bedeutet, daß Header,
die mit X- beginnen, 1:1 durchgereicht werden, ohne vorangestelltes U-
bzw. X-ZC-