home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Boink! 1995 May/June
/
Image.bin
/
df_
/
mailbox
/
point
/
xp300u.exe
/
UUCP.DOC
< prev
next >
Wrap
Text File
|
1994-03-22
|
107KB
|
2,161 lines
-------------------------------
Cross \\// Version 3.0
//\\ Point MS-DOS
» universelle Pointsoftware «
-------------------------------
UUCP-Modul
Versuch einer Dokumentation
(c) 1993,94 Peter Mandrella
Inhalt
════════════════════════════════════════════════════════════════════
I Grundlagen
1.1 Usenet, Internet und Sub-Netze
1.2 News, Mails und Mailinglisten
1.3 UUCP - das Übertragungsprotokoll
1.4 Wie werde ich Usenet-Teilnehmer?
II Installation und Bedienung
2.1 Installation und Konfiguration
2.2 Netzanruf
2.3 Bestellen und Verwalten von Newsgroups (changesys)
2.4 "Sysop-Mode" (Disk-Poll)
III Arbeiten mit UUCP
3.1 Envelope-Adressierung
3.2 Cancel-Nachrichten
3.3 Teilnahme an Mailinglisten
3.4 Dateitransfer mit UUCP
3.5 Dateitransfer per Mail
IV Technische Dokumentation
4.1 RFC-Daten, Packer und der Nachrichten-Konvertierer UUZ
4.2 Der XP-UUCICO
4.3 Dateilisten-Konvertierprogramme
Anhang
A. Dateien im CrossPoint/UUCP-Paket
B. Glosssar
C. Weiterführende Literatur
D. CrossPoint/UUCP - Versionsgeschichte
I Grundlagen
════════════════════════════════════════════════════════════════════
Vorwort
Im Oktober '92, genau ein Jahr nach Beginn der CrossPoint-
Entwicklung, habe ich mit der Arbeit an etwas begonnen, dessen
Umfang damals kaum abzuschätzen war: Dem Ausbau einer Z-Netz/Fido
/MausNet-Pointsoftware zu einem vollständigen UUCP-Paket. Das Ziel
war, ein anwenderfreundliches UUCP-Komplettsystem herzustellen, das
sich genauso leicht installieren, bedienen und warten läßt wie z.B.
ein Fido-Pointprogramm.
Das erste Ergebnis dieser Arbeit befindet sich nun auf Ihrer
Festplatte. Wie jedes erste Ergebnis, so stellt auch dieses sicher
noch nicht der Weisheit letzten Schluß dar. So beinhaltet das
Programm z.B. noch keine Verwaltung von Threads, wie man sie von
verschiedenen Newsreadern gewohnt ist. Insgesamt bietet CrossPoint
aber schon jetzt einen Komfort und Leistungsumfang, der herkömmliche
UUCP-Systeme bei weitem übertrifft.
Haben Sie bereits mit einer anderen UUCP-Software gearbeitet und
möchten nun auf CrossPoint umsteigen?
Dann sollten Sie zunächst einmal XPOINT.DOC lesen, oder zumindest
die ersten Kapitel kurz überfliegen, um sich mit dem Grundkonzept
von CrossPoint vertraut zu machen; es weicht deutlich von dem
anderer Newsreader/Mailer ab. Die Terminologie in den einzelnen
Netzen ist sehr unterschiedlich, und um eine größtmögliche
Konsistenz zu erreichen, verwendet CrossPoint innerhalb des
Programms weitgehend einheitliche Begriffe, z.B. "Point" statt
"leaf-site", "Brett" statt "Newsgroup" und "PM" statt "Mail". Bei
allen Verfechtern einer klaren Usenet-Terminologie möchte ich mich
schonmal im voraus dafür entschuldigen. Innerhalb von UUCP.DOC habe
ich mich bemüht, die "korrekten" Bezeichnungen zu verwenden.
Im Übrigen können Sie gleich bei Abschnitt II dieses Textes
fortfahren; Teil I wendet sich ausschließlich an Usenet-Einsteiger.
Sind Sie Neueinsteiger im Usenet?
Dann sollten Sie nichts überstürzen. Das Usenet erhebt den Anspruch,
professioneller zu sein als Hobby-Mailboxnetze wie Fido oder Z-Netz,
und oft ist es das sogar. Lesen Sie den folgenden Text genau, und
machen Sie sich vor allem mit den technischen Details vertraut. Wenn
Sie in einer Usenet-Gruppe eine technische Frage stellen, müssen Sie
damit rechnen, mit einem Schwall technischer Begriffe und
Sachverhalte überschüttet zu werden. Dem sollten Sie gewachsen sein.
Bevor wir zum Schluß dieses Vorwortes kommen, möchte ich mich noch
bei Martin Jahner <marty@ruessel.sub.org> bedanken, dessen Rechner
unzählige, hinterhältige Angriffe durch meinen uucico absturzfrei
überstanden hat, bei Hajo Zierke <hajo@quijote.in-berlin.de>, der
sich trotz aller Bugs nicht davon abhalten ließ, das Programm ein
halbes Jahr lang betazutesten, und bei Lutz Petersen
<lp@shlink.hanse.de>, der mir eine Menge Nachhilfe in Sachen RFC-
Netze erteilt und an Teil I dieses Textes mitgewirkt hat. Mein ganz
besonderer Dank geht an Ian Lance Taylor <ian@airs.com>, ohne dessen
hervorragende Dokumentation des UUCP-Protokolls dieses Programm
nicht möglich gewesen wäre.
Peter Mandrella
Juli 1993
1.1 Usenet, Internet und Sub-Netze
────────────────────────────────────────────────────────────────────
Die verblüffendste Eigenschaft der meisten UUCP-anwendenden Personen
und derer, die es werden möchten, ist, daß sie gar nicht wissen, an
welchem Netz sie da eigentlich teilnehmen (wollen). Grund der
Verwirrungen ist, daß wir es hier nicht mit einem homogenen Netz wie
z.B. dem FidoNet oder MausNet zu tun haben, dessen Systeme alle in
einer zentralen Liste erfaßt sind. Niemand weiß genau, wieviele
Teilnehmer das Netz hat - die Schätzungen bewegen sich zwischen
hunderttausend und einigen Millionen - und niemand kann sagen, wer
nun mit welcher Technik daran teilnimmt.
Glücklicherweise gibt es bestimmte technische Standards, die in
diesem Netzbereich weit verbreitet sind, und anhand dieser Standards
läßt sich eine grobe Einordnung treffen.
■ RFCs: Die technische Grundlage
Allen Netzen, mit denen wir uns im folgenden beschäftigen werden,
ist eines gemeinsam: Sie begründen sich auf einer Reihe von
technischen Standards, die witzigerweise die Bezeichnung "Request
for Comments" (Aufforderung zu Kommentaren) haben; man spricht daher
von "RFC-basierten Netzen". Die verschiedenen RFC-Texte sind bzw.
werden fortlaufend durchnumeriert und in den Netzen veröffentlicht.
Falls Sie sich näher für diese Dokumente interessieren, so finden
Sie in Abschnitt IV dieses Textes eine Übersicht derjenigen, die für
CrossPoint relevant sind.
Eine Ausnahme bildet das UUCP-Protokoll, auf das wir noch näher zu
sprechen kommen werden. Es ist nicht in den RFCs beschrieben.
■ Was ist Usenet?
"Ein loser Zusammenschluß von allen, die meinen, daß sie
dazugehören". Dies ist eine sehr treffende Definition, aber sie ist
wenig hilfreich. Besser läßt sich das Usenet als die Menge aller
Rechner - genannt "sites" - beschreiben, die untereinander
öffentliche Nachrichten - genannt "news" - austauschen. Nach dieser
allgemeinen Definition sind z.B. auch Mailboxen im Z-Netz Teilnehmer
im Usenet; in etwas spezielleren Definitionen wird das Usenet
dagegen auf den RFC-Bereich eingeschränkt. Der entsprechende RFC-
Standard trägt die Nummr 1036; somit ist das Usenet also die Menge
aller Rechner, die öffentliche Nachrichten im RFC-1036-Format
austauschen.
Um es noch einmal zu verdeutlichen: Das Usenet ist *kein*
geschlossenes, physikalisches Netz, genausowenig wie "die
Autofahrer" eine geschlossene Bevölkerungsgruppe sind.
Da Sie mit CrossPoint öffentliche Nachrichten austauschen werden,
dazu noch im RFC-Format, nehmen Sie mit CrossPoint am Usenet teil.
■ Was ist Internet?
Das Internet ist ein weltweiter Zusammenschluß von ziemlich vielen
Rechnern - meist unixartiger Natur -, die über das in den RFCs
definierte Internet Protocol (IP) Daten untereinander austauschen.
Zwischen den einzelnen Systemen bestehen permanente Verbindungen
über Standleitungen, oft auch über besondere
Hochgeschwindigkeitsleitungen, sodaß dieses Netz ausgesprochen
schnell ist; Nachrichtenlaufzeiten von wenigen Sekunden sind keine
Seltenheit. Mittels IP läßt sich von jedem zu jedem beliebiebigen
anderen Internet-Rechner eine direkte Verbindung herstellen. Jeder
der Rechner hat eine weltweit eindeutige Internet-Adresse.
Die Aufgabe des Internet besteht darin, die Infrastruktur für
bestimmte Dienste zur Verfügung zu stellen. Wichtige Dienste sind
z.B. der Austausch von öffentlichen Nachrichten (News) und privaten
Nachrichten (Mail), die Übertragung von Dateien (FTP = File Transfer
Protocol) und das Herstellen von Online-Terminal-Verbindungen zu
einem Internet-Rechner (Remote Login). Technische Grundlage für
diese Dienste bilden wiederum entsprechende RFC-Standards.
Betreiber des Internet sind hauptsächlich Firmen, Universitäten und
öffentliche Einrichtungen. Als privater Anwender werden sie wegen
der hohen Kosten normalerweise nicht direkt am Internet teilnehmen;
CrossPoint ist auch gar nicht dafür ausgelegt.
■ Sub-Netze
Das Internet ist nicht nach außen abgeschlossen, sondern es stellt
Verbindungen zwischen einer Vielzahl von Sub-Netzen (logischen
Teilnetzen) her. Das Kennzeichen der Sub-Netze ist, daß sie
ebenfalls bestimmte Dienste bereitstellen - insbesondere Mail und
News -, und daß sie einen oder mehrere Übergangspunkte zum Internet
besitzen, d.h. Systeme, die sowohl am Sub-Netz als auch am Internet
teilnehmen. Schickt nun ein Teilnehmer von Sub-Netz A in Deutschland
eine Mail an jemanden im Sub-Netz B in den USA, dann tritt sie in
Deutschland in das Internet ein, wird darin schnell in die USA
transportiert und tritt dort wieder aus dem Internet aus. Das in den
Sub-Netzen am weitesten verbreitete Übertragungsprotokoll - das
Gegenstück zum IP im Internet - ist UUCP; wir werden später noch
näher darauf eingehen.
Ein Beispiel für ein solches Sub-Netz ist das gleichnamige SubNet in
Deutschland - ein Zusammenschluss von Privatpersonen, die ihre
Rechner über Modem- und ISDN-Verbindungen zu einem logischen Netz
verknüpft haben. Der zentrale Rechner des SubNet verfügt über einen
InterNet-Zugang und wickelt den Verkehr mit der Außenwelt ab.
Daneben gibt es auch viele regionale Sub-Netze wie z.B. Hanse-
Networking (das HanseNet) in Hamburg oder das Hannover-Net (HanNet)
in Hannover. Diese Netze besitzen öffentliche Modem- und ISDN-
Zugänge, die Sie für unterschiedliche Gebühren nutzen können.
Halten wir also fest: Als CrossPoint-Anwender - oder allgemein: als
Benutzer einer UUCP-Software - nehmen Sie an einem RFC-basierten
Sub-Netz teil und nutzen dessen Mail- und News-Dienste. Da dieses
Netz mit dem Internet verbunden ist, können Sie auch Nachrichten mit
Internet-Teilnehmern (z.B. in Firmen oder Universitäten)
austauschen.
1.2 News, Mails und Mailinglisten
────────────────────────────────────────────────────────────────────
Während innerhalb von CrossPoint der Unterschied zwischen einer
öffentlichen und einer privaten Nachricht nur im Drücken einer
anderen Taste besteht, wird in RFC-Netzen streng zwischen Mail (=
privaten Nachrichten) und News (= öffentlichen Nachrichten)
unterschieden. Traditionell werden sogar zum Versenden von Mail und
News unterschiedliche Programme verwendet. Als CrossPoint-User
merken Sie diesen Unterschied z.B. daran, daß für Mail und News oft
unterschiedliche Kostenregelungen gelten, oder daß bestimmte
Features nur bei News oder nur bei Mails (z.B. Envelope-Adressen;
mehr dazu später) unterstützt werden.
■ Mails (PMs)
Das Wichtigste an einer Mail ist die Adresse des Empfängers. Im
Usenet gibt es ungefähr ein halbes Dutzend verschiedene Arten, Mails
zu adressieren. Innerhalb von CrossPoint wird nur *eine* Form der
Adressierung verwendet; andere Formen werden, soweit möglich, in
diese Form umgewandelt.
- Domainadressierung (Internet-Adressierung)
Dies ist DIE Standardform der Adressierung. Sie ist einerseits
leistungsfähig genug, um die ungeheure Anzahl von Teilnehmern in
RFC-basierten Netzen in den Griff zu bekommen, andererseits aber
sehr einfach zu handhaben.
Eine "domainisierte" Adresse hat immer folgende Form (die
Leerzeichen gehören nicht dazu und dienen nur der übersichtlicheren
Darstellung) ...
User @ Rechner . Domain . Topleveldomain
und wird immer von rechts nach links interpretiert. Schicken Sie
z.B. eine Mail an "ghostwriter@hot.zer.de", dann läuft sie folgenden
Weg:
Topleveldomain ist ".de"
-> Die Mail geht an den zentralen Rechner in Deutschland, der für
"de" zuständig ist. Dieser Rechner kennt alle Domains unterhalb
von "de" und stellt die Nachricht an den zuständigen Rechner für
die betreffende Domain zu:
Domain ist ".zer.de"
-> Die Mail geht an den zentralen deutschen Rechner für die Domain
"zer" innerhalb von "de". Dieser wiederum kennt alle Rechner,
die an "zer" teilnehmen und schickt die Mail weiter an den
Zielrechner:
Rechner ist "hot.zer.de"
-> Nun wird der linke Teil der Adresse als Username interpretiert,
d.h. die Mail landet im Postfach von "ghostwriter".
Etwas anders verläuft der Weg der Nachricht natürlich, wenn Sie sie
z.B. innerhalb der Domain "zer.de" absenden. In diesem Fall wird sie
nicht erst bis zum Zentralrechner für "de" weitergeleitet, sondern
direkt innerhalb der Domain "zer" zugestellt.
An diesem Beispiel ist übrigens auch sehr schön zu erkennen, daß die
Domain-Adressoerung nicht auf bestimmte Netze beschränkt ist;
"zer.de" befindet sich nämlich im Z-Netz, einem nicht-RFC-basierten
Netz, die Nachricht läuft also über einen Gateway (Schnittstelle
zwischen zwei Netzen).
Weitere Beispiele für Topleveldomains sind:
.fr Frankreich \
.dk Dänemark | Länderkennungen
.fi Finnland /
.com kommerzielles Teilnetz \
.edu Bildungseinrichtungen | vor allem in Nord-
.gov Regierungs-Teilnetz | Amerika verbreite
.mil militärisches Teilnetz | TopLevel-Domains
.nato Teilnetz der NATO |
.org Organisation /
Es gibt noch zwei abgewandelte Formen der Domainadressierung, bei
denen die Adresse um den Realname (also Ihren Namen) erweitert wird:
ghostwriter@hot.zer.de (Ulrich Stamm)
"Ulrich Stamm" <ghostwriter@hot.zer.de>
Innerhalb von CrossPoint werden Sie diese Form der Adressierung aber
nie verwenden, da XP immer Adresse und Realname trennt (einzige
Ausnahme: Die Eingabe einer Vertreteradresse mit Realname bei /Edit
/Boxen/Edit/RFC|UUCP). Es könnte aber passieren, daß jemand seine
Adresse in dieser Form angibt. Um ihn oder sie mit XP anzuschreiben,
müssen Sie den Realname und die Klammern weglassen. Die Groß
/Kleinschreibung der Adressen ist übrigens beliebig;
Ghostwriter@HOT.Zer.de wäre also ebenfalls möglich.
- UUCP-("Bang")-Adressierung
Bei der UUCP-Adressierung wird der genaue Pfad angegeben, den eine
Nachricht bis zum Zielsystem laufen soll, z.B. system1!system2
!system3!endsystem!username. Diese Form der Adressierung ist
überholt und nicht RFC-konform und wird daher von CrossPoint nicht
unterstützt. Wenn es denn unbedingt sein muß, können Sie versuchen,
die Interpretation der Adresse Ihrem UUCP-Server zu überlassen;
hängen Sie dazu einfach dessen Adresse in der Form "@server.domain"
an. Mit ein wenig Glück funktioniert es.
■ MIME
Ursprünglich konnten RFC-Nachrichten nur aus reinen ASCII-Zeichen
bestehen, d.h. es konnten keine nationalen Sonderzeichen und keine
Binärdaten übertragen werden. Seit 1992 gibt es einen neuen Standard
namens MIME, der dieses Manko behebt, und der von CrossPoint bereits
weitgehend unterstützt wird. Es wird aber noch eine Weile dauern,
bis MIME netzweit verwendet wird - wenn Sie innerhalb einer
Nachricht z.B. deutsche Umlaute verwenden, kann es durchaus
passieren, daß sie beim Empfänger in Form von unlesbaren
Hieroglyphen ankommen. Sie sollten also vorerst noch sparsam damit
umgehen, zumindest bei Nachrichten ins Ausland.
Der MIME-Standard gilt bisher übrigens nur für Mails; mit einer
Adaption für News ist aber in absehbarer Zeit zu rechnen.
■ News
Öffentliche Nachrichten im Usenet, genannt Artikel, werden - wie in
allen anderen Netzen auch - in verschiedenen Brettern verteilt,
genannt Newsgroups oder Gruppen. Die Anzahl der Newsgroups ist
schwer abzuschätzen, da sie täglich schwankt, und nirgendwo wirklich
alle Newsgroups verfügbar sind; sie dürfte z.Zt. in der
Größenordnung von ca. 5000 Stück liegen.
Die Gruppennamen sind hierarchisch angeordnet, und die einzelnen
Ebenen werden durch Punkte getrennt. So steht z.B.
comp.dcom.modems
für die Gruppe MODEMS im Bereich DFÜ (Data COMmunications) in der
Hierarchie COMPuter. Beachten Sie, daß innerhalb von CrossPoint
keine Punkte, sondern grundsätzlich Slashes (/) zum Trennen der
einzelnen Brettebenen verwendet werden! Innerhalb von XP sieht diese
Gruppe also so aus:
/comp/dcom/modems
(Ausnahmen bestätigen die Regel: Bei /Config/Anzeige/Bretter können
Sie die Anzeige für die Brettliste - und *nur* dafür - auf
"Punktschreibweise" umstellen).
Eine Besonderheit von Usenet-News, die inzwischen auch im Z-Netz
übernommen wurde, sind die sogenannten Crosspostings. Dies sind
Nachrichten, die physikalisch nur einmal vorhanden sind, sich aber
in mehreren Gruppen befinden, d.h. die mehrere Empfänger haben. Auf
diese Weise können Artikel, die thematisch in mehrere Gruppen
gehören, in jede passende Gruppe geschickt werden, ohne daß sie
mehrfach gesendet werden müßten. Näheres dazu finden Sie in Kap.
4.6. von XPOINT.DOC.
■ moderierte Newsgroups
Beim Stichwort "Moderator" fällt Ihnen vielleicht das FidoNet ein,
wo in jedem Brett ein Moderator lauert, der Sie auf alle etwaigen
Regelverstöße hinweisen wird. Mit dem Moderatorsystem im Usenet hat
es jedoch eine völlig andere Bewandtnis: In moderierte Newsgroups
dürfen Sie nicht direkt schreiben. Stattdessen müssen Sie jede
Nachricht an einen Moderator senden, der entscheided, ob sie zum
Thema der Gruppe paßt - wenn ja, dann wird er/sie die Nachricht
dorthin weiterleiten.
Das automatische Umleiten Ihrer Nachrichten an einen Moderator kann
CrossPoint für Sie übernehmen; Sie müssen dazu nur die Adresse des
Moderators als Brettvertreter eintragen. Näheres dazu finden Sie in
Kap. 4.5. von XPOINT.DOC.
■ Mailinglisten
Das Einrichten von Newsgroups ist mit einem gewissen Aufwand und
Kosten für die an der Übertragung beteiligten Systeme verbunden.
Mailinglisten sind eine einfache Alternative zu Newsgroups, die es
jedem ermöglicht, eine Konferenz zu einem bestimmten Thema zu
eröffnen, ohne eine neue Newsgroup einrichten zu müssen.
Technisch gesehen ist eine Mailingliste nichts anderes als ein
irgendwo installierter, automatisch arbeitender
Nachrichtenverteiler; in der Praxis ist sie eine über den Mailweg
arbeitende Newsgroup. Schicken Sie eine Nachricht an die
Mailingliste, so wird sie automatisch an alle Listenteilnehmer
weitergeleitet. Um an einer Mailingliste teilzunehmen, müssen Sie
eine Anmeldenachricht an den Listenverwalter (das ist meist kein
Mensch, sondern ein automatisch arbeitendes Programm (ein "Daemon"))
senden. Gleiches gilt für das Abmelden von der Liste. Eine Liste
aller bekannten Mailinglisten wird regelmäßig in der Gruppe
mail.mailing-lists veröffentlicht.
1.3 UUCP - das Übertragungsprotokoll
────────────────────────────────────────────────────────────────────
■ UUCP? Kann man das essen?
Nein, ganz sicher nicht. UUCP steht für Unix to Unix CoPy - ein
ursprünglich für UNIX entwickeltes Programmpaket, das nichts weiter
macht, als Dateien zwischen zwei Rechnern auszutauschen und ggf.
eine Weiterverarbeitung dieser Dateien zu veranlassen. Die
Beschränkung auf UNIX ist längst aufgehoben, aber der Zweck ist der
gleiche geblieben: UUCP ist ein Standardverfahren zum Austauschen
von Nachrichtenpaketen zwischen RFC-Netz-Systemen (für Fido-User: es
entspricht in seiner Funktion in etwa einem Fido-Mailer).
Der Nachrichtenaustausch zwischen zwei UUCP-Systemen läuft in drei
Schritten ab:
Zunächst meldet sich das anrufende System beim angerufenen an, indem
es seinen Systemnamen und ggf sein Paßwort sendet (Login). Diese
Anmeldung ist *nicht* Teil der UUCP-Spezifikation und kann bei jedem
System wieder ein wenig anders aussehen. Bei den meisten Systemen
wird CrossPoint sich automatisch anmelden können, aber bei einigen
Systemen wird es nötig sein, ein speziell angepaßtes Anmeldescript
zu schreiben; mehr dazu später.
Nach der Anmeldung wird das sogenannte uucico-Programm gestartet
(bei XP: UUCICO.EXE), das die weitere Übertragung vornimmt. Das
anrufende und das angerufende System einigen sich nun auf eines der
folgenden UUCP-Übertragungsprotokolle, das anschließend gestartet
wird und für den eigentlichen Dateiaustausch sorgt:
UUCP-g: Dies ist das meistverwendete Protokoll; es wird praktisch
von jedem UUCP-System unterstützt. Die Qualität der
einzelnen Implementationen ist sehr unterschiedlich.
Schlechte uucicos übertragen die Daten in sehr kleinen
Blöcken von z.B. 64 Bytes; dies ist in etwa mit dem XModem-
Protokoll vergleichbar. Gute Implementationen verarbeiten
auch große Blöcke von z.B. 1024 Bytes und erreichen damit
Geschwindigkeiten, die ungefähr denen von ZModem
entsprechen.
CrossPoint unterstützt alle möglichen UUCP-g-Blockgrößen von
32 bis zum einem Maximum von 4096 Bytes. Es kommt
darüberhinaus mit beliebig wechselnden Blockgrößen während
einer Verbindung zurecht, sodaß es mit jeder nur denkbaren
Gegenstelle zusammenarbeiten sollte.
UUCP-f: Dies ist ein sehr simples Protokoll, das beim Übertragen
ungepackter ASCII-Daten etwas effizienter arbeitet als UUCP-
g. Ansonsten ist es nicht empfehlenswert.
UUCP-z: Es gibt zwei verschiedene Protokolle mit dieser Bezeichnung.
Bei dem von XP unterstützen UUCP-z handelt es sich um eine
in Deutschland übliche Variante von UUCP-f, die i.d.R. ein
wenig effizienter arbeiten dürfte als UUCP-g. Auf
ungesicherten Modemverbindungen (also ohne V42) ist es aber
nicht empfehlenswert.
UUCP-e: Ein extrem simples Protokoll mit optimalem Datendurchsatz,
aber ohne jede Fehlerkorrektur. Es darf nur dann verwendet
werden, wenn Datenverluste bei der Übertragung oder an der
seriellen Schnittstelle absolut ausgeschlossen sind.
UUCP-i: Ein bidirektionales Protokoll, das die Daten in beide
Richtungen gleichzeitig überträgt; nicht verwendbar bei HST-
oder PEP-Modems. Wird von CrossPoint nicht unterstützt.
Vielleicht sind Sie jetzt aufgrund der vielen technischen Details
ein wenig verwirrt und wissen nicht, welches Protokoll Sie verwenden
sollen. Empfehlung: Nehmen Sie zuerst einmal UUCP-g. Das ist recht
fehlersicher und sollte überall funktionieren. Später, wenn Sie mit
der Materie besser vertraut sind, können Sie jederzeit auf ein
anderes Protokoll umsteigen.
Nähere technische Details zu UUCP finden Sie in Kapitel 4.2.
1.4 Wie werde ich Usenet-Teilnehmer?
────────────────────────────────────────────────────────────────────
Sie müssen ein UUCP-System finden, bei dem Sie "pollen" können, d.h.
über das Sie Ihre Nachrichten verschicken und empfangen. Dies kann
sich deutlich schwieriger gestalten als die Suche nach einer Z-Netz-
oder Fido-Mailbox - öffentlich zugängliche UUCP-Sites sind selten.
Wenn Sie nicht gerade in einem Ballungsgebiet wohnen, werden Sie
meist in die Regional- oder Fernzone ausweichen müssen.
Die beiliegende Datei UUCP_PUB.DOC beinhaltet eine Liste von
öffentlichen UUCP-Systemen in Deutschland und deren
Ansprechpartnern. Beachten Sie, daß ständig neue Systeme dazukommen
und alte wegfallen; auch Telefonnummern haben in der DFÜ-Szene die
Eigenschaft, sich gelegentlich zu ändern. Es ist also durchaus
möglich, daß viele Einträge in der Liste bereits veraltet sind. Eine
aktuelle Version der Liste wird gelegentlich in der Gruppe
de.etc.lists veröffentlicht.
Wer keine andere Möglichkeit zur Kontaktaufnahme hat, kann sich per
E-Mail an 'lp@shlink.hanse.de' wenden (Telefon, E-Mail-Adresse und
Ort angeben) und sich einen Ansprechpartner vermitteln lassen.
■ Postmeister und Wurzeln
Von anderen Netzen kennen Sie möglicherweise den Username SYSOP als
Synonym für den Systembetreiber. In RFC-basierten Netzen ist dieser
Name äußerst unüblich; stattdessen erreichen Sie Ihren
Ansprechpartner dort immer unter dem Namen "postmaster" (d.h.
postmaster@system.do.main). Gelegentlich wird auch die Bezeichnung
"root" verwendet, was dem Namen des Systemverwalters auf einem Unix-
Rechner entspricht.
■ Wie sollte ich mich im Usenet verhalten?
Als Neuuser sollten Sie erst einmal Erfahrungen sammeln. Studieren
Sie das Verhalten anderer Usenet-Teilnehmer und lernen Sie daraus.
Lesen Sie die Artikel in de.newusers; dort finden Sie wertvolle
Hinweise für Einsteiger.
Wenn Ihnen das Verhalten eines Users nicht gefällt, dann rufen Sie
nicht nach der Koordination - es gibt nämlich keine. Das Usenet ist
ein streng chaotisch organisiertes, selbsttragendes Gebilde. Wenn
Sie meinen, daß jemand aus dem Netz ausgeschlossen werden sollte,
dann können Sie dies umgehend veranlassen: Nehmen Sie ihn/sie
einfach in Ihren Nachrichtenfilter (Fachjargon: Killfile) auf, und
schon sind Sie ihn/sie für immer los :-)
Denken Sie aber auch immer daran, daß Ihnen das gleiche passieren
kann, falls Sie mit Ihren Artikeln jemandem Grund dazu geben.
II Installation und Bedienung
════════════════════════════════════════════════════════════════════
Dieser Abschnitt enthält Informationen, die speziell die
Installation und Nutzung von CrossPoint im Usenet betreffen.
Ausführlichere Informationen zur Installation und Benutzung finden
Sie in XPOINT.DOC.
2.1 Installation und Konfiguration
────────────────────────────────────────────────────────────────────
Zunächst die gute Nachricht: Sie benötigen keinerlei
Zusatzprogramme. Das CrossPoint/UUCP-Paket ist tatsächlich rundum
komplett; es enthält nicht nur einen vollständigen uucico, sondern
auch alle benötigten Packer/Entpacker. Sie können also sofort
loslegen.
Nun die schlechte Nachricht: Sie müssen trotzdem damit rechnen, daß
die Einrichtung Ihrer UUCP-site (site = Point) etwas mehr Arbeit und
Nerven in Anspruch nimmt, als die eines Fido- oder gar MausNet-
Points; zu groß ist die Anzahl der möglichen Fehlerquellen.
Versuchen Sie, auftretende Probleme zunächst in Zusammenarbeit mit
dem Systembetreiber zu lösen. Er ist ab besten dazu in der Lage, die
Fehlerursache zu entdecken.
Als Erstes müssen Sie einige Daten über Ihren UUCP-Server in
Erfahrung bringen:
- Telefonnummer
- Systemname und Domain
- mögliche Packer (compress, freeze, gzip)
- bevorzugtes UUCP-Protokoll; bei UUCP-g: maximale Paketgröße
- Wird "batched SMTP" (bsmtp) unterstützt?
Außerdem müssen Sie noch drei Dinge mit dem Systembetreiber
ausmachen:
- Ihren Systemnamen (= Sitename, "Pointname")
- Ihren Loginnamen
- Ihr Paßwort
Den Sitenamen können Sie sich selbst aussuchen; er wird Bestandteil
Ihrer Usenet-Adresse. Beispiel: bei peter@xpoint.ruessel.sub.org ist
xpoint der Sitename. Der Loginname kann gleich dem Sitenamen sein,
muß es aber nicht. Oft besteht er aus dem Sitenamen mit einem
vorangestellten "u".
Beim ersten Start fragt CrossPoint folgende Eingaben ab:
■ den Netztyp Ihres Servers: Geben Sie "RFC/UUCP" ein.
■ Boxname: Geben Sie hier den Systemnamen des Servers ein (das ist
nur das 3-7buchstabige, oft etwas kryptische Kürzel, *ohne* die
angehängte Domain)
■ den Usernamen: Das ist der Name, unter dem Sie schreiben werden
(der Teil vor dem "@" in Ihrer Adresse). Der Name kann später
jederzeit beliebig geändert werden.
Wenn Sie CrossPoint bereits für ein anderes Netz installiert hatten,
muß der UUCP-Server wie gewohnt per /Edit/Boxen angelegt werden.
Als nächstes müssen Sie die einzelnen Felder unter /Edit/Boxen/Edit
/Point ausfüllen. Ausführlichere Erläuterungen dazu finden Sie in
der Online-Hilfe. Die diversen Schalter im unteren Teil des Fensters
können Sie zunächst unverändert lassen; nur die SMTP-Einstellung
sollten Sie überprüfen. Unter Edit/Modem sollten Sie Baudrate und
Schnittstelle korrekt einstellen; alle übrigen Felder sind bereits
mit sinnvollen Werten vorbelegt.
Wichtig sind die Einstellungen unter Edit/Namen: Unter "Realname"
sollten Sie Ihren richtigen Namen eintragen. Dies ist zwar keine
unbedingte Pflicht, gehört im Usenet aber zum guten Ton. Im Feld
"Domain" muß Ihre eigene Domain und im Feld "Serverdom." diejenige
des Serversystems eingetragen werden. Die beiden Domains sind
*meistens* gleich, müssen es aber nicht. Hier noch ein Beispiel:
Ihre Adresse: ich@arrgh.xyz.sub.org
-> Ihr Username: ich
Ihr Systemname (Pointname): arrgh
Ihre Domain: .xyz.sub.org
Serveradresse: abc.sub.org
-> Systemname des Servers: abc
Serverdomain: .sub.org
Einige weitere UUCP/RFC-Einstellungen finden Sie bei /Config
/Optionen/Netze/Verschiedenes; Näheres dazu ist in der Online-Hilfe
erläutert. Wenn Sie noch keine Usenet-Erfahrung haben, sollten Sie
die Einstellungen zunächst unverändert lassen.
2.2 Netzanruf
────────────────────────────────────────────────────────────────────
Sind alle Daten korrekt eingetragen, so können Sie den ersten Anruf
starten. Verwenden Sie dazu den Menüpunkt /Netcall/Einzeln. Nach
beendetem Anruf finden Sie im Brett /»Netzanruf eine Nachricht mit
dem Ergebnis des Anrufs.
■ Wenn der Netcall nicht funktioniert ...
dann kann das sehr viele Ursachen haben. Ich will versuchen, alle
aufzuzählen, die mir einfallen.
Erscheint beim Einloggen mehrmals hintereinander Login / Paßwort /
Login / Paßwort, so haben Sie vermutlich bei /Edit/Boxen/Edit/Point
einen falschen Loginname oder ein falsches Paßwort eingetragen. Im
Zweifelsfall fragen Sie bitte beim Systembetreiber nach.
Erscheint eine Login-Meldung des angerufenen Systems, und
anschließend passiert nichts mehr - CrossPoint legt dann nach ca.
einer Minute von alleine wieder auf -, so lesen Sie bitte unten im
Abschnitt "Login-Scripts" weiter.
Wenn CrossPoint sich überhaupt nicht mit Ihrem Modem versteht, dann
haben Sie vermutlich eine falsche Schnittstelle eingestellt oder
etwas falsches unter /Config/Modem/... eingetragen. Evtl. liegt es
auch daran, daß Sie ein Spar-Modemkabel besitzen, bei dem das CD-
oder das CTS-Signal nicht weitergeleitet wird. In diesem Fall
sollten Sie "CD ignorieren" bzw. "CTS ignorieren" einschalten. Falls
das Modem eine &C-Option besitzt, muß sie eingeschaltet sein (AT
&C1). Eine genauere Beschreibung der wichtigsten Modem-Kommandos
finden Sie in Anhang F von XPOINT.DOC.
Erscheint in der Netcall-Wartepause immer die Meldung "Anruf
eingegangen", dann unterstützt Ihre serielle Schnittstelle oder Ihr
Modemkabel kein RING-(Klingel-)Signal. In dem Fall müssen Sie
/Config/Modem/../RING-Erkennung abschalten.
Erhalten Sie eine Nachricht mit einer Fehlermeldung wie "remote
execution - rfsmtp - permission denied" oder Ähnliches, dann sollten
Sie sich mit dem Systembetreiber noch einmal wegen des verwendeten
Packers und der Benutzung von Batched SMTP absprechen - es hat
entweder ein Mißverständnis gegeben, oder der Sysop hat vergessen,
für Sie den korrekten Entpacker freizugeben.
Gibt es während der UUCP-g-Übertragung regelmäßig gehäufte Fehler,
dann sollten Sie einmal einen Netcall im Debug-Mode durchführen;
Starten Sie XP dazu mit Parameter /d. Sie erhalten dann einen
wesentlich ausführlicheren Netzanruf-Bericht, aus dem Sie oder ich
evtl. die Ursache des Problems erkennen können. Während eines Debug-
Mode-Netcalls werden viele zusätzliche Informationen auf dem
Bildschirm angezeigt - lassen Sie sich davon nicht irritieren.
Kommen von Ihnen verschickte Nachrichten trotz fehlerfreier
Übertragung nicht an, so wird's knifflig. Es kann an einem falsch
eingestellten Packer (s.o.) oder - bei PMs - an einer falschen SMTP-
Einstellung liegen. Es kann daran liegen, daß Sie Ihren Systemnamen
oder die Domain falsch eingetragen haben, sodaß Ihre Nachrichten
nicht durchgelassen werden. Es kann auch daran liegen, daß
CrossPoint und das angerufene System sich aus irgendeinem Grunde
nicht verstehen. Weiterhelfen kann Ihnen in diesem Fall nur der
Systembetreiber - er muß nachsehen, wo die von Ihnen verschickten
Nachrichten landen.
■ Login-Scripts
Wie bereits erwähnt, ist der Anmeldevorgang bei UUCP-Systemen nicht
standardisiert. Verstehen CrossPoint und der angerufene Server sich
nicht, so bleibt Ihnen nichts anderes übrig, als XP über ein Login-
Script entsprechend anzupassen. Sind Sie absoluter nicht-
Programmierer, so wenden Sie sich nach Möglichkeit an einen
erfahrenen User (zur Not auch an mich :-) - geben Sie in dem Fall
unbedingt Name und Telefonnummer des Servers an!.
Zur Aktivierung eines Login-Scripts sind drei Dinge nötig:
o Lesen Sie Teil VIII von XPOINT.DOC; dort ist die Scriptprogram-
mierung beschrieben.
o Passen Sie das mitgelieferte Standard-Script UUCP.SCR
entsprechend an. Beachten Sie, daß das Login genau dann beendet
ist, wenn vom Server der Text "^Pshere" gesendet wurde.
o Tragen Sie das Script bei /Edit/Boxen/Edit/Diverses als
Netzanruf-Script ein.
■ Nachrichtentest
Wenn Sie testen möchten, ob Ihre öffentlichen Nachrichten ankommen,
können Sie eine Nachricht in eine der Testgruppen schreiben, z.B. in
de.test. Sie erhalten dann automatisch Antwort von verschiedenen
Programmen, deren einzige Aufgabe darin besteht, Antworten auf
Testnachrichten zu verschicken. Seien Sie aber vorsichtig beim
Schreiben in internationalen Testgruppen - dies ist der beste Weg,
um Ihr Postfach mit hunderten von Kilobytes unnützer Mails zu
füllen.
Das Versenden von PMs testen Sie am besten, indem Sie
Empfangsbestätigungen anfordern (s. XPOINT.DOC, Kap. 5.9).
2.3 Bestellen und Verwalten von Newsgroups (changesys)
────────────────────────────────────────────────────────────────────
Es gibt zwei Möglichkeiten. Entweder, Ihr UUCP-Server verfügt über
changesys, d.h. er hat ein sog. changesys-Script installiert. Dann
haben Sie Glück: CrossPoint biete eine optimale changesys-
Unterstützung - das Bestellen / Abbestellen von Newsgroups
(Brettern) ist damit genauso komfortabel wie im Z-Netz, MausNet etc.
Wenn der Server *kein* Changesys anbietet, wird für die
Brettbestellungen ein gewisses Maß an Handarbeit nötig sein. Wie es
im Einzelnen funktioniert, erfahren Sie vom Systembetreiber; ein
standardisiertes Verfahren gibt es nicht.
■ Changesys einrichten
Das Prinzip von Changesys besteht darin, daß beim Server eine Datei
existiert, in der sich für jede pollende Site ein Eintrag mit den
bestellten Newsgroups befindet, das sogenannte "sysfile". Mit den
Befehlen "getsys" und "setsys" kann dieser Eintrag abgefragt oder
komplett ersetzt werden.
Bevor Sie Newsgroups bestellen können, müssen Sie dem
Systembetreiber mitteilen, daß Sie changesys verwenden möchten. Sie
erhalten dann ein Changesys-Paßwort, das nicht gleich Ihrem
Loginpaßwort sein muß, und das bei /Edit/Boxen/Edit/RFC|UUCP
einzutragen ist. Außerdem müssen Sie CrossPoint dort mitteilen,
unter welchem Betreff changesys Ihnen Sysfile-Einträge zuschickt. Um
dies festzustellen, sollten Sie mit /Nachricht/Brettmanager
/Sonstiges/../getsys Ihr aktuelles Sysfile anfordern (dazu sind
*zwei* Anrufe notwendig - einer zum Absetzen des Befehls und einer
zum Abholen des Ergebnisses). Stimmte der eingetragene Betreff nicht
mit dem vom Server gesendeten überein, so sollten Sie nach der
Korrektur noch einmal ein getsys senden; CrossPoint erhält dadurch
eine Liste der z.Zt. bestellten Newsgroups, die es für spätere
(Ab)Bestellungen benötigt.
Als Nächstes können Sie mit /Nachricht/Brettmanager/Liste_anfordern
die aktuelle Newsgroup-Liste bestellen und sie mit /Nachricht
/Brettmanager/Liste_einlesen aktivieren. Neben den Newsgroup-Namen
enthält die Liste noch diverse Steuerinformationen, die nicht weiter
von Interesse sind. Nur auf das letzte Zeichen jeder Zeile sollten
Sie achten: Steht dort "y", so haben Sie freien Zugriff auf die
Gruppe; "m" dagegen bedeutet, daß sie moderiert ist.
■ Newsgroups (ab)bestellen
Siehe XPOINT.DOC, Kap. 3.2.
■ Die .BBL-Datei
CrossPoint legt für jeden Usenet-Server eine Datei mit Name
<Server>.BBL an, in der sich eine Liste der gerade bestellten
Newsgroups befindet. Nach jeder Bestellung oder Abbestellung wird
der Inhalt dieser Datei aktualisiert und mit einem 'setsys'-Befehl
an Changesys geschickt. Wenn Sie möchten, können Sie diese Datei
auch von Hand bearbeiten. Auf diese Weise läßt sich ggf. der
Sysfile-Eintrag drastisch verkleinern: Wenn Sie *alle* Newsgroups
einer bestimmten Hierarchie bestellen möchten, so genügt es, den
Hierarchienamen anzugeben - z.B. "de" für alle DeNet-Newsgroups,
oder "comp.sys.next" für alle NeXT-Newsgroups. Verwenden Sie
/Nachricht/Brettmanager/Sonstiges/setsys, um die manuell geänderte
.BBL-Datei absenden zu lassen.
Mit /Nachricht/Brettmanager/Sontiges/../help erhalten Sie eine
Anleitung zur manuellen Bedienung von Changesys. Ich rate aber
grundsätzlich von deren Gebrauch ab - das Changesys-Frontend von XP
ist nicht nur sehr komfortabel, sondern es verhindert auch
Fehleingaben.
2.4 "Sysop-Mode" (Disk-Poll)
────────────────────────────────────────────────────────────────────
Statt dem Verschicken von Nachrichtenpaketen per UUCP bietet Ihnen
CrossPoint auch die Möglichkeit, ausgehende Pakete auf der
Festplatte abzulegen und eingehende Pakete von dort einzulesen.
Dieses Verfahren ist z.B. dann nützlich, wenn Sie selbst Betreiber
eines anrufbaren UUCP-Systems sind und CrossPoint nur als "Frontend"
einsetzen möchten. Zur Verwendung des UUCP-Sysop-Modes von XP
sollten Sie Kenntnisse über die Benennung und den Aufbau von UUCP-
Nachrichtenpaketen haben. Nähere Informationen dazu finden Sie in
Kapitel 4.1.
Zur Aktivierung des Sysop-Modes müssen Sie unter /Edit/Boxen/Edit
/Point das gewünschte Ein- und Ausgangsverzeichnis eintragen. Im
Eingangsverzeichnis erwartet XP beliebige gepackte oder ungepackte
News- und Mailpakete. Für jedes Paket müssen eine D- und eine X-
Datei vorhanden sein. Die Dateinamen müssen den in Kapitel 4.1
beschriebenen Dateinamenkonventionen von XP entsprechen.
Im Ausgangsverzeichnis legt XP alle ausgehenden Nachrichten in Form
von X-, D- und (je Netcall) einer C-Datei ab. Die C-Datei kann neben
den UUCP-Steuerinformationen zur Übertragung der D- und X-Dateien
auch Datei-Anforderungen enthalten, die mit /Nachricht/Fileserver
erzeugt wurden. Die C- oder X-Dateien können ignoriert werden, falls
Sie sie nicht zur Weiterverabeitung der Nachrichten benötigen. Falls
bei /Edit/Boxen/Edit/Point ein Upload-Packer eingetragen ist, werden
die ausgehenden D-Dateien gepackt (sowohl für News als auch für
SMTP-Batches).
III Arbeiten mit UUCP
════════════════════════════════════════════════════════════════════
Dieser Abschnitt beschreibt spezielle Features und Dienste von UUCP,
Usenet und Internet, die XP in irgendeiner Weise unterstützt. Er
wird in zukünftigen Versionen mit Sicherheit noch um einige Kapitel
wachsen.
3.1 Envelope-Adressierung
────────────────────────────────────────────────────────────────────
Jede Mail, die durch das Usenet geschickt wird, besitzt nicht nur
einen Absender und Empfänger, sondern zwei von Jedem: die
ursprünglichen Adressen und die sogenannten Envelope-Adressen. Bei
einer neuen Mail, die ganz normal verschickt wird, merken Sie davon
nichts - ursprüngliche Adressen und Envelope sind identisch. Zum
Tragen kommt die Envelope-Adressierung erst, wenn eine Nachricht
weitergeleitet wird: Dann enthält der Envelope die neue Absender-
und Empfängeradresse, während die Originaladressen unverändert
bleiben.
Nehmen wir z.B. an, peter@xpoint.ruessel.sub.org schickt eine
Nachricht an posthamster@dumpfbacke.sub.org, und der wiederum leitet
die Nachricht an sysop@mybox.zer.de weiter. Dann kommt Sie beim
letzten Empfänger mit folgenden Adressen an:
Originalempfänger: posthamster@dumpfbacke.sub.org
Originalabsender: peter@xpoint.ruessel.sub.org
Envelope-Absender: posthamster@dumpfbacke.sub.org
Envelope-Empfänger: sysop@mybox.zer.de
- Und was bedeutet das für mich als CrossPoint-Anwender?
Nun, es bedeutet, daß Sie bei solchermaßen weitergeleiteten
Nachrichten (bei XP gibt es dazu übrigens den Menüpunkt /Nachricht
/Weiterleiten/Original) folgendes angezeigt bekommen:
Empfänger: hier steht der Envelope-Empfänger
Absender: hier steht der Originalabsender
Originalempfänger: hier steht der Originalempfänger
Weiterleit-Absender: hier steht der Envelope-Absender
Und es bedeutet, daß Sie beim Antworten auf diese Nachricht die Wahl
zwischen drei Adressen haben: Absender, Weiterleit-Absender oder
Originalempfänger.
Leider wird in Envelope-Absendern oft noch die alte UUCP-
Adressierung ohne Domainangabe verwendet; dadurch entstehen
teilweise recht seltsame Konstrukte. Gelegentlich enthält eine
Nachricht auch ".uucp" als Domain im Envelope-Absender, was meist
ein Zeichen für eine falsch konfigurierte Software ist. Lassen Sie
sich durch solch ungültigen "Weiterleit-Absender" nicht verwirren
und antworten Sie einfach an den Originalabsender!
3.2 Cancel-Nachrichten
────────────────────────────────────────────────────────────────────
Ein nettes, wenn auch umstrittenes RFC-Feature sind die sogenannten
Cancel-Nachrichten (to cancel = streichen, aufheben). Mit solchen
Nachrichten können Sie einmal abgeschickte, öffentliche Nachrichten
wieder löschen. Dazu wird der betreffenden Nachricht eine
Löschnachricht hinterhergeschickt, und überall, wo beide Nachrichten
aufeinandertreffen, wird die Originalnachricht entfernt. Böse
Zeitgenossen verwenden dieses Feature dazu, die Nachrichten anderer
User zu löschen. Mit CrossPoint ist dies natürlich nicht möglich.
Zum Versenden einer Cancel-Nachricht wählen Sie die zu löschende
Nachricht und dann den Menüpunkt /Nachricht/Weiterleiten/Löschen.
Generell sollten Sie sparsam mit dieser Funktion umgehen. Lesen Sie
Ihre Nachrichten besser vor dem Absenden noch zweimal durch, statt
nachher einen Löschversuch zu starten; dadurch belasten Sie das Netz
nicht mit unnötigen Daten, und Sie sind *ganz* sicher, daß die
Nachricht nirgendwo gelesen wird - wesentlich sicherer als bei
"gecancelten" Nachrichten.
Mit /Edit/Schablonen/Löschnachricht können Sie den Text editieren,
den XP in Cancel-Nachrichten schreibt. Was dort steht, ist völlig
egal; entscheidend für das Funktionieren ist nur eine spezielle
Steuerinformation, die von /Nachricht/Weiterleiten/Löschen
automatisch erzeugt wird. Dies bedeutet auch, daß Cancel-Nachrichten
*nur* mit diesem Menüpunkt erzeugt werden können.
| Eingehende Cancel-Nachrichten werden von XP automatisch ausgewertet
| und bewirken, daß sowohl die Bezugsnachricht als auch die Cancel-
| Nachricht selbst auf "gelesen" und "löschen" gesetzt und bei der
| nächsten Reorganisation entfernt werden. Außerdem kann auf die
| Bezugsnachricht nicht mehr geantwortet werden.
Das einzige andere Netz, bei dem sich Nachrichten nachträglich
löschen lassen, ist übrigens das MausNet. Allerdings funktioniert es
dort nur, wenn die Nachricht sich noch innerhalb der Serverbox
befindet; dadurch sind Manipulationen ausgeschlossen.
3.3 Teilnahme an Mailinglisten
────────────────────────────────────────────────────────────────────
Das Konzept von Mailinglisten wurde ja bereits erklärt (falls Sie
sich nicht mehr genau erinnern können: blättern Sie einfach nochmal
zurück zu Kap. 1.2).
Nehmen wir einmal an, Sie würden sich für Tandem-Fahrräder
interessieren. Beim Durchlesen der Mailinglisten-Übersicht stellen
Sie erfreut fest, daß es eine Tandem-Mailingliste gibt, und senden
umgehend eine Nachricht an tandem-request@hobbes.ucsd.edu mit Bitte
um Aufnahme. Einen Tag später bricht in Ihrem PM-Fach das Chaos aus:
Wegen der großen Anzahl von Tandem-Mails sind die wirklich an Sie
gerichteten Mails kaum noch auszumachen.
Was tun? Ganz einfach: Sie müssen sich nur unter einem anderen
Usernamen bei der Mailingliste anmelden. XP kann beliebig viele PM-
Bretter verwalten, und alle Nachrichten aus der Mailingliste wandern
in ein eigenes Brett. Ändern Sie also bei /Edit/Boxen/Edit/Namen
Ihren Usernamen, z.B. in "tandem", senden Sie die Anforderung an die
Mailingliste und tragen Sie anschließend wieder Ihren richtigen
Namen ein.
Es wird übrigens empfohlen, beim Bestellen ("subscriben") einer
Mailingliste noch einmal die vollständige Adresse in den
Nachrichtentext aufzunehmen, am besten in einer Signatur am Ende der
Nachricht. Man weiß nie, wie die Absenderadresse aussieht, wenn die
Nachricht auf dem Weg über ein dutzend Stationen den Empfänger
erreicht hat...
3.4 Dateitransfer mit UUCP
────────────────────────────────────────────────────────────────────
Daß UUCP-Systeme Nachrichten austauschen, ist allgemein bekannt. Daß
viele [die meisten?] davon aber auch umfangreiche Dateiarchive
besitzen und einen allgemeinen Dateiup- und download (Senden und
Bestellen von Dateien) ermöglichen, weiß außerhalb des Usenet wohl
kaum jemand. Oft ist das Dateiarchiv offen zugänglich, d.h. Sie
können und dürfen es - im Gegensatz zum FidoNet - auch dann nutzen,
wenn Sie ansonsten gar kein Usenet-Teilnehmer sind.
Größtes Problem beim UUCP-Filerequest (also beim Bestellen von
Dateien) sind die äußerst bescheidenen Dateilisten der UUCP-Systeme.
Normalerweise handelt es sich dabei um simple Listen eines
bestimmten Verzeichnisbaumes, wie sie unter DOS von DIR /s oder
unter UNIX von ls -lr erzeugt werden. Dadurch gibt es zum einen fast
soviele verschiedene Listenformate wie UUCP-Systeme, und zum anderen
enthalten die Listen keine Kommentare zu den einzelnen Dateien; Sie
müssen also jeweils anhand der Dateinamen erraten, um was es sich
handelt. Dies ist zum Glück meist einfacher, als es sich anhört,
weil wesentlich längere Dateinamen als unter DOS verwendet werden
können:
■ Exkurs: *NIX- und ähnliche Dateisysteme
Die meisten UUCP-Rechner laufen wohl unter Unix-ähnlichen
Betriebssystemen, die bei der Benennung von Dateien wesentlich
flexibler sind als DOS - sowohl, was die Länge angeht, als auch bei
den erlaubten Zeichen. So ist z.B. "linux-pbmplus.bin.tar.z" ein
einwandfreier Unix-Dateiname. CrossPoint versucht, beim Download
solcher Dateien einen möglichst sinnvollen DOS-Dateinamen zu
erzeugen; bei diesem Beispiel wäre es z.B. LINUX-PB.TAZ (TAZ ist
eine unter DOS übliche Erweiterung für Dateien, die mit den Unix-
Programmen tar und Z gepackt wurden; mehr dazu später). XP stellt
ggf. durch eine fortlaufende Nummer in der Dateierweiterung sicher,
daß dabei keine zwei gleichen DOS-Dateinamen entstehen.
Eine unangenehme Eigenschaft von Unix-Dateisystemen ist, daß sie auf
einer korrekten Groß/Kleinschreibung der Dateinamen bestehen. Hieße
eine Datei also z.B. Linux-PBMplus.Bin.tar.Z, dann müßten Sie den
Namen exakt in dieser Form angeben. Etwas großzügiger ist das Amiga-
Filesystem, auf das Sie im Usenet auch gelegentlich treffen werden.
Es erlaubt zwar alle Freiheiten beim Benennen von Dateien,
verschluckt sich aber nicht, wenn anschließend eine abweichende
Schreibweise verwendet wird.
Eine letzte Unix-Eigenschaft, die Sie kennen sollten, ist die Angabe
eines relativen Pfadnamens mit vorangestellter Tilde (~). Falls Sie
dieses Zeichen auf Ihrer Tastatur nicht finden sollten, so verwenden
Sie Alt-126 zur Eingabe. ~ steht, grob gesagt, für ein bestimmtes
Startverzeichnis, unterhalb dessen Sie alle weiteren Dateien finden.
Suchen Sie z.B. die Datei xp300-1.exe im Unterverzeichnis msdos, so
wäre der komplette Pfadname ~/msdos/xp300-1.exe (ach ja, eine
weitere Unix-Eigenschaft: Verzeichnisse werden mit / und nicht mit \
getrennt). Auf der Seite des angerufenen Systems wird ~ dann zu
einem bestimmten, vollständigen Pfadnamen expandiert, um den Sie
sich nicht weiter zu kümmern brauchen. Durch diesen Trick können
alle Dateien jederzeit in ein anderes Unterverzeichnis verlagert
werden, ohne daß Sie etwas davon merken.
Was Sie außerdem noch wissen sollten ist, daß Amiga-Filesysteme
ähnlich wie DOS-Festplatten partitioniert werden können, daß die
einzelnen Bereiche aber normalerweise nicht über einzelne
Buchstaben, sondern über aussagekräftigere Namen wie z.B. "uupub:"
oder "uucp:" angesprochen werden. Ansonsten entsprechen diese Namen
in etwa den Laufwerksbuchstaben von DOS.
■ Fileserver anlegen
Bevor Sie bei einem UUCP-Server Dateien bestellen können, muß er
zusätzlich zum Eintrag bei /Edit/Boxen noch bei /Edit/Systeme als
Fileserver erfaßt werden (vgl. auch XPOINT.DOC, Kap. 4.3). Dazu sind
folgende Eingaben erforderlich:
- Systemname: Der Sitename des Systems, so wie er auch bei /Edit
/Boxen eingetragen ist.
- Kommentar: egal
- Fileserver: Wählen Sie "UUCP-Fileserver" aus der F2-Auswahlliste.
- Indexdatei: Dies ist der Name der Dateiliste, die mit /Nachricht
/Fileserver/Liste/Anfordern bestellt wird. Meistens
~/index, evtl. aber auch etwas ganz anderes. Fragen
Sie im Zweifelsfall den Systembetreiber (postmaster).
Ich weiß, daß das Eingabefeld etwas kurz bemessen
ist.. sollte es *nicht* ausreichen, werden Sie die
Dateiliste stattdessen wie jede andere Datei auch
anfordern müssen (s.u.).
- Konvertierer: Dazu kommen wir gleich noch.
■ Dateiliste bestellen und konvertieren
Ist der UUCP-Fileserver korrekt eingetragen, so sollten Sie als
nächstes eine Dateiliste anfordern. Wenn Sie den Namen der Liste wie
oben erklärt eingetragen haben, genügt dazu /Nachricht/Fileserver
/Liste/Anfordern. Ansonsten müssen Sie den Namen der Datei bei
/Nachricht/Fileserver/Bestellen von Hand eingeben. Nach
erfolgreichem Anruf sollte sich die bestellte Dateiliste im bei
/Config/Pfade eingetragenen Filerequest-Verzeichnis befinden. Den
endgültigen Namen der Datei können Sie aus dem UUCP-Filerequest-
Report ersehen, den XP nach dem Anruf in Ihrem PM-Brett ablegt.
Nun kommt der interessante Teil. Sie müssen herausfinden, welches
Format die Liste hat, und sie ggf. in ein XP-kompatibles Format
konvertieren lassen.
(1) Amiga-Listenformat
Directory "uupub:pic" on Freitag 09-Jul-93
power.gif 130915 ----rwed 11-Jun-93 22:33:54
edbot12.gif 192118 ----rwed 07-Mai-93 15:35:16
Amiga_logo.iff 7478 ----rwed 26-Feb-93 16:45:18
Brauner_Riese2.iff 52320 ----rwed 01-Jun-93 19:50:14
Directory "uupub:text" on Freitag 09-Jul-93
xpoint.txt 318681 ----rwed 23-Mai-93 15:19:28
umfragebogen.txt 50574 ----rw-d 31-Mai-93 18:23:03
umfrageerg1.txt 108122 ----rw-d 31-Mai-93 18:24:04
umfrageerg2.txt 31326 ----rw-d 31-Mai-93 18:24:24
4 files - 1011 blocks used
Sieht die Liste so aus, dann kann XP sie direkt verarbeiten. Lesen
Sie sie einfach mit /N/Fileserver/Liste/Datei_einlesen ein.
(2) UNIX-ls-Format
/public/TeX/unix-tex/DVIware/lpr-viewers/crudetype/CYBER:
total 65
-r--r--r-- 1 uucp uucp 3521 Apr 24 21:10 noscheme.add
-r--r--r-- 1 uucp uucp 5803 Apr 24 21:10 nosve.ch
-r--r--r-- 1 uucp uucp 1224 Apr 24 21:10 nosve.com
-r--r--r-- 1 uucp uucp 2953 Apr 24 21:10 nosve.doc
-r--r--r-- 1 uucp uucp 49368 Apr 24 21:11 nosvebind.cyb
/public/TeX/unix-tex/DVIware/lpr-viewers/crudetype/PRIME:
total 11
-r--r--r-- 1 uucp uucp 9594 Apr 24 21:11 primos.ch
-r--r--r-- 1 uucp uucp 767 Apr 24 21:11 primos.cpl
/public/TeX/unix-tex/DVIware/lpr-viewers/crudetype/VMS:
total 22
-r--r--r-- 1 uucp uucp 3543 Apr 24 21:11 tiny.dmp
-r--r--r-- 1 uucp uucp 44 Apr 24 21:11 tiny.tex
-r--r--r-- 1 uucp uucp 4214 Apr 24 21:11 vms.ch
Sieht die Liste genau so aus, dann müssen Sie bei /Edit/Systeme im
Feld "Konvertierer" das Programm UUCP-FL1.EXE aus der F2-Liste
wählen. Wenn Sie die Liste anschließend einlesen lassen, konvertiert
XP sie in sein eigenes Format.
(3) ein weiteres, gelegentlich verwendetes Format
#CREATED 04-Aug-1993 13:00
#
DR-X 0 24-Jan-1993 19:15 /
DRWX 0 04-Aug-1993 11:32 /incoming
FRW- 431297 21-Jul-1993 05:56 /incoming/ack3d.zip
FRW- 104631 30-Jun-1993 16:03 /incoming/APEDEMO.LZH
FRW- 1625 30-Jun-1993 16:03 /incoming/APEDEMO.TXT
Sieht die Liste so aus, dann müssen Sie als Konvertierer das
Programm UUCP-FL2.EXE wählen.
(4) Die Liste sieht irgendwie ganz anders aus.
Dann haben Sie zwei Möglichkeiten. Falls Sie programmieren können
oder einen Programmierer verfügbar haben, dann schreiben Sie ein
kleines Programm (oder lassen Sie es schreiben :-), das die Liste in
ein XP-kompatibles Format konvertiert. Näheres dazu finden Sie in
Kapitel 4.3.
Im anderen Fall schicken Sie mir die einen Auszug aus der Liste - am
besten die ersten 5-10 KByte - zu. Ich werden dann versuchen, einen
passenden Konvertierer zu schreiben.
■ Dateien bestellen
Ist erst einmal eine brauchbare Liste vorhanden, so ist alles
Weitere ganz einfach. Wählen Sie /Nachricht/Fileserver/Bestellen,
wählen Sie den gewünschten Fileserver, markieren Sie die gewünschten
Dateien mit <Space> und drücken Sie <Enter>. Beim nächsten Anruf
werden die Dateien bestellt und ein UUCP-Filerequest/Filetransfer-
Report in Ihrem PM-Brett abgelegt.
Sollte sich bereits eine Datei unter gleichem Namen im Filerequest-
Verzeichnis befinden, oder mehrere der bestellten Dateien durch
Kürzen des Namens gleich heißen, so ersetzt XP die letzten ein oder
zwei Zeichen der Dateierweiterung durch eine fortlaufende Nummer.
Achtung! In vielen Dateilisten sind nicht nur Dateien, sondern auch
Unterverzeichnisse aufgeführt; in Unix-Listen sind sie normalerweise
mit einem "d" markiert. Daß solche "Dateien" nicht bestellt werden
können, dürfte sich von selbst verstehen.
Falls am Ende der Dateiliste "zu wenig Speicher, um komplette Liste
anzuzeigen" erscheint, sollten Sie zusätzlichen EMS-Speicher zur
Verfügung stellen. Ohne EMS können nur Listen mit einer Größe von
ca. 100-200k angezeigt werden.
■ Und wie funktioniert das Ganze?
Zum Bestellen einer Datei schickt XP eine Nachricht mit Betreff
"Request" an den Pseudouser "UUCP-Fileserver". Innerhalb der
Nachricht befindet sich eine Liste aller bestellten Dateien. Möchten
Sie z.B. kontrollieren, ob XP das Dateilistenformat richtig erkannt
hat, so wählen Sie in der Userliste den User "UUCP-Fileserver" und
sehen Sie sich den Inhalt der Nachricht an. Wenn alles funktioniert
hat, dann befindet sich darin eine Liste aller bestellten
Nachrichten inclusive des vollständigen Dateipfades. Beachten Sie,
daß dieser Pseudouser NUR innerhalb von XP existiert! Vor dem
tatsächlichen Bestellen der Datei wird die Bestellnachricht in etwas
wesentlich Komplizierteres umgewandelt, auf das ich hier nicht näher
eingehen möchte.
Statt /N/Fileserver/Bestellen zu verwenden, können Sie auch direkt
eine Request-Nachricht an den UUCP-Fileserver schreiben. Innerhalb
dieser Nachricht können Sie übrigens optional auch den Namen
angeben, den die bestellte Datei unter DOS erhalten soll - setzen
Sie ihn einfach, mit einem Leerzeichen getrennt, hinter den
Quelldateinamen z.B.
Challisti-19.lzh CHAL-19.LZH
Challisti-20.lzh CHAL-20.LZH
Dies ist vor allem dann praktisch, wenn die Unix-Dateinamen nach der
Kürzung gleich lauten würden.
■ Dateien senden
Bevor Sie Dateien an ein UUCP-System senden, müssen Sie sich
erkundigen, in welchem Verzeichnis neue Dateien abgelegt werden
sollen. Intelligente Systeme leiten alle eingehenden Dateien
automatisch in das korrekte Verzeichnis um (so, wie CrossPoint :-),
aber bei vielen müssen Sie den gesamten Pfad mit angeben, z.B.
~/incoming/neue-Datei.
Zum Senden haben Sie wieder zwei Möglichkeiten. Am einfachsten geht
es mit /Nachricht/Fileserver/Senden: Geben Sie den Namen der
Quelldatei und Pfad+Name der Zieldatei an, starten Sie den Netcall -
fertig.
Die andere Möglichkeit besteht darin, Dateien von Hand an den UUCP-
Fileserver zu senden. Wählen Sie dazu den betreffenden Pseudouser
und drücken Sie "I" für "Binärnachricht". Wählen Sie nun die
Quelldatei aus und geben Sie anschließend im Editor Pfad+Name der
Zieldatei an. Das Ganze wird dann als sog. "File Attach"
gespeichert, also als Textnachricht mit einer angehängten Datei. Am
besten sehen Sie sich vorher einmal an, wie eine mit /N/Fileserver
/Senden erzeugte File-Attach-Nachricht aussieht.
Beachten Sie, daß Uhrzeit und Datum einer Datei bei UUCP nicht mit
übertragen werden. Diese Einschränkung läßt sich umgehen, indem Sie
die Datei einfach nochmal zusätzlich einpacken, z.B. mit LHArc
(LHArc ist deswegen empfehlenswert, weil es als einziger Packer auf
allen Rechnersystemen verfügbar ist). Beim Auspacken erhält die
Datei dann wieder den korrekten Datumseintrag.
■ Dateien von XP versenden lassen
U.U. möchten Sie Dateien nicht manuell, sondern durch ein externes
Programm versenden lassen. Mit Hilfe des AUTOEXEC-Verzeichnisses (s.
XPOINT.DOC, Kap. 7.6) ist dies denkbar einfach:
Nehmen wir an, Sie möchten die Datei D:\SCAN\SCANV106.ZIP so
uploaden lassen, daß sie beim Server shlink.hanse.de im Verzeichnis
~/incoming abgelegt wird. Dazu müssen Sie eine Datei mit beliebigem
Namen und der Erweiterung ".MSG" im AUTOEXEC-Unterverzeichnis
erzeugen lassen, die folgenden Inhalt hat (die Pfeile dienen nur zur
Abgrenzung):
-->
Empfaenger: UUCP-Fileserver@shlink.hanse.de
Betreff: egal; wird durch den Dateinamen ersetzt
Server: shlink
Datei: D:\SCAN\SCANV106.ZIP
~/incoming/scanv106.zip
<--
Achten Sie auf korrekte Schreibweise von "UUCP-Fileserver"!
Wenn Sie die .MSG-Datei über ein Programm erzeugen lassen, das über
/Config/Tasten eingebunden ist, sollten Sie für dieses Programm den
Autoexec-Schalter setzen, damit unmittelbar nach der Rückkehr zu XP
das AUTOEXEC-Verzeichnis abgearbeitet wird.
■ vom Server veranlaßte Dateiübertragung
Rein technisch gesehen sind die beiden Partner bei einer UUCP-
Verbindung immer gleichberechtigt. Daher kann der Betreiber des
Servers auch Dateien bei Ihnen anfordern oder zu Ihnen senden. Die
erstere Möglichkeit wird von XP z.Zt. nicht unterstützt, da dies bei
einem nicht anrufbaren Programm wenig Sinn macht. Das Senden von
Dateien durch den Server ist dagegen uneingeschränkt möglich. Solche
Dateien werden genau wie angeforderte Dateien im File-Request-
Verzeichnis abgelegt, und Sie werden auch hier durch einen UUCP-
Filerequest/Filetransfer-Report über den Empfang der Dateien
benachrichtigt.
■ Unix-Packer
Nachdem wir uns bereits mit Unix-Dateisystemen beschäftigt haben,
müssen wir noch ein letztes Mal auf dieses Betriebssystem
zurückkommen. Unter Unix werden Dateien meist nicht mit LHArc, PKZIP
oder gar ARJ gepackt, sondern mit tar+compress oder tar+gzip. Das
Programm tar faßt zunächst mehrere Dateien in einer zusammen, und
compress oder gzip (GNU ZIP, nicht zu verwechseln mit und nicht
kompatibel zu PKZIP) packen sie anschließend. Folgende
Dateierweiterungen sind dabei üblich:
.tar = tar
.tar.Z = tar + compress
.tar.gz = tar + gzip
Eine .tar.Z-Datei muß erst mit compress und dann mit tar entpackt
werden, eine .tar.gz-Datei entsprechend mit gzip und tar. Unter DOS
wird statt ".tar.z" üblicherweise die Erweiterung ".TAZ" verwendet.
Entpacken von .Z: compress -d Archivdatei
oder gzip -d Archivdatei
Entpacken von .gz: gzip -d Archivdatei
Auspacken von .tar: tar -xf Archivdatei [Datei(en)]
Auflisten von .tar: tar -tvf Archivdatei
Da die Programme compress, gzip und tar nicht unbedingt zur
Standardausstattung eines DOS-Rechners gehören und auch nicht in
jeder Mailbox zu finden sind, sind sie im CrossPoint/UUCP-Paket mit
enthalten.
Wenn Sie selbst eine Datei mit tar+compress packen möchten, so
verwenden Sie folgende Befehlsfolge:
tar -cf Archivdatei Quelldateien
compress Archivdatei
Entsprechendes gilt für tar+gzip. Beachten Sie, daß tar immer alle
Unterverzeichnisse mit einpackt!
■ Anonymous UUCP (nuucp)
Dies ist nicht etwa eine anonyme Gruppe von UUCP-Geschädigten,
sondern vielmehr die Möglichkeit, bei einem UUCP-System Dateien zu
bestellen oder abzuliefern, ohne dort als "Point" eingetragen zu
sein. Eine Liste mit deutschen Anonymous-UUCP-Sites finden Sie am
Ende von UUCP_PUB.DOC; eine aktuelle Version der Liste wird
regelmäßig in de.admin.archiv veröffentlicht.
Ein Anonymous-UUCP-System muß genau wie jeder andere Fileserver
zunächst bei /Edit/Boxen erfaßt werden. Loginname und Paßwort sind
üblicherweise "nuucp". Als Pointname und eigene Domain sollten Sie
die gleichen wie bei Ihrem UUCP-Stammserver angeben; auf diese Weise
weiß der Mensch auf der anderen Seite zumindest, wer anruft. Im
übrigen gelten die gleichen Hinweise wie in Kap. 2.1 und 2.2.
Rein theoretisch ließen sich per nuucp auch Mails direkt abliefern -
ähnlich Crash-Mails im FidoNet - aber in der Praxis wird dieses
Features aus Sicherheitsgründen meist gesperrt sein.
3.5 Dateitransfer per Mail
────────────────────────────────────────────────────────────────────
Neben den oben beschriebenen UUCP-Systemen, bei denen Sie direkt
anrufen und Dateien anfordern können, gibt es auch eine Reihe von
Systemen, die einen Dateitransfer per Mail anbieten - sogenannte
"Mail Server". Dazu ist auf dem betreffenden Rechner ein Pseudouser
eingerichtet, der auf bestimmte Befehle reagiert. Der wichtigste
Befehl ist HELP - damit bekommen Sie eine Anleitung zur Bedienung
des Mail Servers.
Möchten Sie z.B. die Hilfe von ftp-mailer@ftp.informatik.tu-muenchen
.de anfordern, dann senden Sie an diese Adresse eine Nachricht mit
beliebigem Betreff (wird ignoriert) und nur einer Zeile Inhalt,
nämlich HELP. In diesem Hilfstext sind dann alle weiteren Befehle
erläutert. Mit dem Befehl INDEX erhalten Sie eine Liste der
vorhandenen Dateien. Achtung: Diese Liste kann mehrere hundert KByte
groß sein! Nachrichten an Mail-Server können auch mehrere Befehle
enthalten, jeweils ein Befehl pro Zeile.
Eine Liste einiger deutscher Mail Server und deren Befehlssyntax
finden Sie in der beiliegenden Datei UUCP_PUB.DOC.
IV Technische Dokumentation
════════════════════════════════════════════════════════════════════
In diesem Abschnitt finden Sie Dinge, die für Normalanwender weniger
von Interesse sind. Ich will versuchen, ein paar Informationen zu
RFC, UUCP und deren Implementation in XP zu geben. Falls Sie sich
genauer informieren möchten, empfehle ich die folgenden Dokumente:
RFC-822, 976 und 1521: Nachrichtenformat von Mails
RFC-1036 Nachrichtenformat von News
UUCP-FAQ von Ian Taylor: exakte Beschreibung des UUCP-Protokolls;
wird gelegentlich in comp.mail.uucp veröf-
fentlicht
Die genannten und die meisten anderen RFC-Texte sollten bei jedem
besseren nuucp-Server verfügbar sein, der UUCP-Text von Ian Lance
Taylor eigentlich auch.
4.1 RFC-Daten, Packer und der Nachrichten-Konvertierer UUZ
────────────────────────────────────────────────────────────────────
■ Aufbau von RFC-Nachrichten
RFC-Nachrichten bestehen aus einem Nachrichtenkopf (Header), einer
Leerzeile und dem Nachrichteninhalt (Body), haben also den gleichen
prinzipiellen Aufbau wie ZCONNECT-Nachrichten (s. XPOINT.DOC, Kap.
7.1). Die einzelnen Zeilen sind normalerweise nur mit LFs (ASCII
#10) getrennt, aber gelegentlich kann es auch CR/LF (#13/#10) sein.
Offiziell dürfen in Header und Body nur 7bit-ASCII-Zeichen verwendet
werden (#32 bis #126, Tab (#9), CR, LF und FF (#12)). In der Praxis
sind die meisten Teile des Usenet inzwischen aber 8bit-durchlässig,
zumindest in Europa, sodaß innerhalb des Textes auch nationale
Sonderzeichen möglich sind. Der in Deutschland verwendete
Zeichensatz ist ISO-8859-1. Stattdessen können 8bit-Zeichen mit MIME
auch als 7bit-Zeichen codiert werden; näheres dazu finden Sie in RFC
1341.
Der Header besteht aus einer Liste von Bezeichner-Doppelpunkt-
Whitespace-Inhalt-Kombinationen. Lange Headerzeilen können auf
mehrere Zeilen aufgeteilt werden (sog. "folding"); in diesem Fall
müssen alle Zeilen außer der ersten mit einem Whitespace
(Leerzeichen oder Tab) beginnen. Der Empfänger muß sie wieder zu
einer Zeile zusammensetzen. Eine Beschreibung der einzelnen Zeilen
entnehmen Sie bitte den genannten RFCs.
■ Newspakete
Öffentliche Nachrichten werden zu sogenannten Newsbatches
zusammengepackt. Dazu wird jeder Nachricht die Zeile "#! rnews
nnnn", gefolgt von einem LF, vorangestellt, wobei statt nnnn die
exakte Größe der Nachricht in Bytes einzusetzen ist. Bitte beachten
Sie, daß dabei auch CR-Zeichen im Gegensatz zu der Angabe in RFC
1036 *mitgezählt* werden. Ein Newsbatch besteht also aus einer Folge
von rnews, Header, Body, rnews, Header, Body, ...
Newsbatches werden i.d.R. mit compress, freeze oder gzip gepackt.
Nach dem Packen wird dem Ganzen die Zeile "#! cunbatch", "#!
funbatch" oder "#! gunbatch" (möglicherweise auch zunbatch statt
gunbatch - hier streiten sich noch die Gelehrten) vorangestellt,
gefolgt von einem LF. Daran erkennt der Empfänger, welcher Entpacker
verwendet werden muß.
Genaugenommen handelt es sich bei "#! rnews" etc. übrigens um UNIX-
Befehle, die von einer Shell abgearbeitet werden - daher der Name
"Newsbatches": Es handelt sich dabei tatsächlich um eine Art
Batchdateien.
■ Mailpakete
Beim Mailtransport gibt es zwei Möglichkeiten: UUCP-Mail oder SMTP-
Mail. Beide Methoden dienen dazu, zusätzlich zu den Adressen im
Header (To: = Empfänger und From: = Absender) die Envelope-Adressen
zu übertragen (s. Kap. 3.1).
Die Envelope-Adressierung bei UUCP-Mails ist geradezu grotesk. Der
Envelope-Absender wird in eine zusätzliche "From"-Zeile vor Beginn
der Mail gesetzt. Dabei werden Username und Domain getrennt; der
Envelope-Absender peter@xpoint.ruessel.sub.org sieht dann z.B. so
aus:
From peter [Datum] remote from xpoint.ruessel.sub.org
Der Envelope-Empfänger wird dagegen als Parameter eines rmail-
Befehls in eine UUCP-X-Steuerdatei geschrieben (s.u.).
Bei SMTP-Mails werden mehrere Mails zu einem Mailbatch
zusammengefaßt. Dabei wird jeder Mail der Envelope in Form der zwei
Zeilen MAIl FROM und RCPT TO vorangestellt. Eine gute Beschreibung
dieses Verfahrens finden Sie in RFC 976.
■ UUCP: X- und D-Files
Zu versendende Newsbatches, UUCP-Mails und SMTP-Mailbatches werden
in Dateien abgelegt, die mit einem "D" beginnen. Zu jeder D-Datei
wird eine X-Datei generiert, in der steht, was mit der D-Datei
gemacht werden soll. Jede Zeile in der X-Datei besteht aus einem
Buchstaben, einem Leerzeichen und einem Inhalt (genaugenommen gibt
es auch Zeilen ohne Inhalt, aber die benötigen wir nicht). Der
Buchstabe gibt an, wie der Inhalt zu interpretieren ist; die
einzelnen Zeilen sind mit LF (ASCII #10) getrennt. Im folgenden will
ich nur die Zeilentypen beschreiben, die für XP relevant sind; eine
genaue Beschreibung aller übrigen Zeilen finden Sie im UUCP-FAQ.
# - beliebige Kommentarzeile
U - In dieser Zeile steht User- und ein Systemname des Users, der
die Datei angeliefert hat.
F - Name der D-Datei
I - nochmal der Name der D-Datei
C - auszuführender Befehl
Die C-Zeile in der X-Datei gibt an, was mit der D-Datei passieren
soll. Es handelt sich dabei ursprünglich um den Namen eines Unix-
Programms, das mit der D-Datei als Eingabe gestartet werden soll -
XP verwendet dazu allerdings keine getrennten Programme. Das
Kommando "rnews" bedeutet, daß sich in der D-Datei ein Newspaket
befindet. "rmail" steht für eine einzelne Mail, "rsmtp" für einen
SMTP-Batch aus mehreren Mails. Bei gepackten SMTP-Batches wird je
nach Packer "rcsmtp", "rfsmtp" oder "rzsmtp" verwendet. Hinter dem
Kommando "rmail" wird zusätzlich der Name bzw. die Adresse des
Empfängers der Mail angegeben (der Envelope-Empfänger - s Kap. 3.1).
Der in der F-Zeile angegebene Dateiname wird nach Konventionen des
ursprünglichen Unix-Filesystems (max. 14 beliebige Zeichen) gebildet
und muß von DOS-UUCP-Systemen in einen DOS-konformen Namen
umgewandelt werden. Der Unix-Dateiname besteht aus dem Datei-
Kennbuchstaben (D oder X), gefolgt von einem Punkt, dem auf 7
Zeichen gekürzten UUCP-Namen des Absendesystems, einem Buchstaben
(dem "UUCP-Grade") und vier weiteren alphanumerischen Zeichen, bei
denen zwischen Groß- und Kleinschreibung unterschieden wird. XP
entfernt den Sitenamen, ersetzt den Punkt durch einen Bindestrich
und fügt hinter dem "Grade" eine einstellige Hexadezimalziffer ein,
in der die Schreibweise der letzten vier Zeichen codiert ist: Für
jedes großgeschriebene Zeichen wird ein Bit gesetzt. Das
niederwertige Bit entspricht dabei dem ersten Zeichen. Sind alle
vier Zeichen kleingeschrieben - was meistens der Fall ist - steht
hier eine "0".
■ Der Nachrichtenkonvertierer UUZ
Alle eingehenden X- und D-Dateien werden vom uucico im SPOOL-
Unterverzeichnis abgelegt. Als nächstes entpackt XP alle gepackten
News- und SMTP-Batches, und konvertiert das Ganze anschließend mit
UUZ in einen ZCONNECT-Puffer:
UUZ.EXE -uz SPOOL\X*. PUFFER ownsite.domain
(für ownsite wird Ihr Systemname eingesetzt). Wie Sie sehen, gibt XP
als Quelldateien nur die X-Dateien an. UUZ liest dann aus den X-
Dateien die Namen der passenden D-Dateien aus. UUZ *kann* die D-
Dateien auch direkt verarbeiten, allerdings würden dabei eventuell
vorhandene UUCP-Envelope-Empfänger verlorengehen.
Sollte also irgendwann bei einem Anruf mal etwas schiefgegangen
sein, können Sie RFC-Daten auf diese Weise manuell konvertieren. UUZ
erkennt auch, wenn ein Paket noch gepackt ist und ruft automatisch
den passenden Entpacker auf. Sie sollten nur darauf achten, daß die
Entpacker im aktuellen Verzeichnis vorhanden sind - ansonsten könnte
es passieren, daß Sie sich plötzlich im Compress von PC-Tools o.ä.
wiederfinden.
4.2 Der XP-UUCICO
────────────────────────────────────────────────────────────────────
Der wichtigste Teil des XP/UUCP-Paketes neben dem Nachrichtenkonver-
tierer UUZ ist UUCICO.EXE. Es handelt sich dabei um einen von Grund
auf neuentwickelten uucico mit folgenden Leistungsmerkmalen:
o Protokolle g/G, f, z und e
o UUCP-g: - Packet-Sizes 32 bis 4096
- Window-Sizes 3 bis 7
- variable Packet-Sizes während einer Verbindung
o Taylor-UUCP-kompatible "size negotiation"
o wahlweise FOSSIL- oder direkter Schnittstellenzugriff
o Unterstützung von IRQ 1-15
Die Aufrufsyntax ist
UUCICO <Config-Datei> <UUCP-Command-Datei>
Der UUCICO muß *nach* dem Login und nach dem Erkennen des Strings
^PShere gestartet werden; nach dem Programmende muß die Verbindung
getrennt werden. Bei der UUCP-Command-Datei handelt es sich um eine
Datei im üblichen UUCP-Format, allerdings mit CR/LF-Zeilentrennungen
- so, wie sie von UUZ erzeugt wird.
Die Config-Datei wird von XP unter dem Namen UUCICO.CFG im XP-
Verzeichnis abgelegt, aber es darf auch eine beliebige andere Datei
in einem anderen Verzeichnis sein. Wie alle XP-Config-Dateien,
besteht sie aus einer Liste von Bezeichner/Wert-Paaren, die jeweils
mit einem Gleichheitszeichen getrennt sind.
Die folgenden Angaben sind obligatorisch:
Server Sitename des angerufenen Systems
Node eigener Sitename
PortNr Schnittstellen-Nr
PortAdr hex. Schnittstellen-Adresse (entfällt bei FOSSIL)
IRQ IRQ-Nummer (entfällt bei FOSSIL)
Baud Baudrate
Folgende Angaben sind optional:
Language Sprachkennung, Default D: es muß eine passende
Sprachdatei vorhanden sein, z.B. Sprachkennung D
-> XPUU-D.RES
Debug Y/N, Default N: Debug-Mode aktivieren (wie XP/d)
DebugWindow Koordinatinaten des Fensters, in dem im Debug-Mode
die Ausgabe erfolgen soll (X1 X2 Y1 Y2, Default 0)
Colors Default $70 $7F $7E (Farbe) /$07 $0F $0F (mono):
Hintergrundfarbe, Textfarbe und Statuszeilenfarbe
des Übertragungsfensters
MaxWinSize Default 7: max. Windowsize bei UUCP-g
MaxPacketSize Default 64: max. Paketgröße bei UUCP-g
VarPacketSize Y/N, Default N: Ausgangspaketgröße darf variieren
ForcePacketSize Y/N, Default N: Ausgangspaketgröße auf MaxPacket-
size festnageln
Protocols Default gfe: mögliche Protokolle, bestes zuerst
SizeNegotiation Y/N, Default N: Taylor UUCP size negotiation.
Setzt voraus, daß auch in der UUCP-C-Datei ent-
sprechende Informationen enthalten sind.
FilereqPath Default FILES\: Pfad für eingehende nicht-Nach-
richten-Pakete
C-File Name der UUCP-C-Datei; wenn angegeben, kann der
zweite Parameter beim UUCICO-Aufruf entfallen
UUlogfile Logfile-Name
FOSSIL Y/N, Default N: FOSSIL-Treiber verwenden, falls
vorhanden
IgnoreCD Y/N, Default N: CD-Signal ignorieren
IgnoreCTS Y/N, Default N: CTS-Signal ignorieren
Die Namen der zu sendenden Nachrichtenpakete und sonstigen Dateien
müssen sich in der C-Datei befinden; die Nachrichtenpakete müssen
alle im SPOOL-Unterverzeichnis abgelegt sein. IgnoreCD und IgnoreCTS
sollten nur in Ausnahmefällen verwendet werden; von der Verwendung
bei Modemverbindungen ist grundsätzlich abzuraten.
Abgebrochene, empfangene Nachrichtenpakete erhalten als Extension
.001 oder eine entsprechend höhere Nummer, falls Palete mit .001
oder den folgenden Zahlen bereits vorhanden sind.
UUCICO.EXE ist hiermit als Freeware freigeben. Ich kann aber nicht
garantieren, daß er mit irgendeinem anderen Programm in irgendeiner
Weise so zusammenarbeiten wird, wie Sie sich es wünschen.
4.3 Dateilisten-Konvertierprogramme
────────────────────────────────────────────────────────────────────
Dieses Kapitel knüpft an Kap. 3.4 an. Es soll dabei helfen, eigene
Dateilisten-Konvertierprogramme zu schreiben.
CrossPoint unterstützt grundsätzlich zwei Typen von UUCP-
Dateilisten. Beim ersten Typ befindet sich zu Beginn jeder Zeile der
komplette Pfad+Dateiname der einzelnen Dateien, optional gefolgt von
einem oder mehreren Leerzeichen oder Tabs und beliebigen weiteren
Daten. Beispiel:
/pub/TeX/unix-tex/DVIware/lpr-viewers/crudetype/CYBER/noscheme.add
/pub/TeX/unix-tex/DVIware/lpr-viewers/crudetype/CYBER/nosve.ch
/pub/TeX/unix-tex/DVIware/lpr-viewers/crudetype/CYBER/nosve.com
/pub/TeX/unix-tex/DVIware/lpr-viewers/crudetype/CYBER/nosve.doc
/pub/TeX/unix-tex/DVIware/lpr-viewers/crudetype/CYBER/nosvebind.cyb
/pub/TeX/unix-tex/DVIware/lpr-viewers/crudetype/PRIME/primos.ch
/pub/TeX/unix-tex/DVIware/lpr-viewers/crudetype/PRIME/primos.cpl
/pub/TeX/unix-tex/DVIware/lpr-viewers/crudetype/VMS/tiny.dmp
/pub/TeX/unix-tex/DVIware/lpr-viewers/crudetype/VMS/tiny.tex
/pub/TeX/unix-tex/DVIware/lpr-viewers/crudetype/VMS/vms.ch
Statt der absoluten Pfade mit beginnendem / dürfen es auch relative
Pfade mit beginnendem ~/ oder beliebige andere, gültige Pfadangaben
sein. Leerzeilen, Kommentarzeilen oder sonstige Zeilen stören
prinzipiell nicht; das Program wird Sie aber auch nicht daran
hindern, solche Zeilen als Datei zu bestellen (außer bei
Leerzeilen).
Das zweite - meist übersichtlichere - Dateilistenformat besteht aus
Blöcken für die einzelnen Verzeichnisse. Jedem Block muß eine Zeile
vorangestellt sein, die aus dem Schlüsselwort "Directory " (das
Leerzeichen gehört dazu!) und dem Verzeichnisnamen besteht. Der
Verzeichnisname kann alleine dort stehen oder in Anführungszeichen
eingeschlossen sein. Am Ende kann ein Slash (/) oder ein Doppelpunkt
angehängt sein, der von XP ignoriert wird. Beispiel:
Directory /public/TeX/unix-tex/DVIware/lpr-viewers/crudetype/CYBER:
noscheme.add -r--r--r-- 1 uucp 3521 Apr 24 21:10
nosve.ch -r--r--r-- 1 uucp 5803 Apr 24 21:10
nosve.com -r--r--r-- 1 uucp 1224 Apr 24 21:10
nosve.doc -r--r--r-- 1 uucp 2953 Apr 24 21:10
nosvebind.cyb -r--r--r-- 1 uucp 49368 Apr 24 21:11
Directory /public/TeX/unix-tex/DVIware/lpr-viewers/crudetype/PRIME:
primos.ch -r--r--r-- 1 uucp 9594 Apr 24 21:11
primos.cpl -r--r--r-- 1 uucp 767 Apr 24 21:11
Directory /public/TeX/unix-tex/DVIware/lpr-viewers/crudetype/VMS:
tiny.dmp -r--r--r-- 1 uucp 3543 Apr 24 21:11
tiny.tex -r--r--r-- 1 uucp 44 Apr 24 21:11
vms.ch -r--r--r-- 1 uucp 4214 Apr 24 21:11
Auch hier gilt, daß beliebige andere Zeilen ignoriert werden. Die
Länge der Zeilen ist übrigens beliebig; bei mehr als 80 Zeichen kann
innerhalb des XP-Listers nach rechts und links geblättert werden.
Als Ausgangsbasis für eigene Listenkonvertierer können Sie die
Turbo-Pascal-Quelltexte von UUCP-FL*.PAS verwenden, die im XP/UUCP-
Paket enthalten sind.
Anhang
════════════════════════════════════════════════════════════════════
A. Dateien im CrossPoint/UUCP-Paket
────────────────────────────────────────────────────────────────────
uucp.doc das lesen Sie gerade
uucico.exe uucico-Programm (s. Kap. 4.2)
xpuu-d.res deutsche Sprachdatei für uucico
uuz.exe Nachrichtenkonvertierer (s. Kap. 4.1)
compress.exe Unix-kompatibler Packer/Entpacker
freeze.exe Packer/Entpacker
gzip.exe GNU ZIP - Packer/Entpacker
copying Copyright-Informationen zu gzip
tar.exe Unix-kompatibles Archivprogramm
uucp_pub.doc Liste von öffentlichen, deutschen UUCP-Systemen
uvalid.doc McAfee-Validation-Codes für die diversen EXE-Dateien
uucp.scr Standard-UUCP-Loginscript
uucp-fl*.exe UUCP-Dateilisten-Konvertierer
uucp-fl*.pas Quelltexte der Dateilisten-Konvertierer
B. Glossar
────────────────────────────────────────────────────────────────────
Account Benutzerkennung; Postfach bei einer Mailbox, auf
einem Unix-Rechner o.ä.
Artikel öffentliche Nachricht
Bang(-Pfad) Nachrichtenroute in der Form "System1!System2!..."
BCC Blind Carbon Copy - Kopie einer Nachricht an
weitere Empfänger, die für den Originalempfänger nicht
erkennbar ist
BITNET auf IBM-Protokollen basierendes Netzwerk mit eigener
Adressierungsform; kennt keine ^Newsgroups, sondern
verwendet stattdessen ^Mailing-Listen
Body "Benutzerteil" einer Nachricht, im Gegensatz zum
^Header
Bounce Zurücksenden einer unzustellbaren Nachricht
Cancel- Löschnachricht zum nachträglichen Löschen einer ver-
Message schickten Nachricht
CC Carbon Copy - Kopie einer Nachricht an weitere
Empfänger
CfV Call for Vote - Aufruf zur Abstimmung, insbesondere
zur Einrichtung einer neuen ^Newsgroup im ^Usenet
Crossposting öffentliche Nachricht in mehreren ^Newsgroups, die
physikalisch nur einmal übertragen wird
Domain rechter Teil einer Internet-Adresse (s. Kap. 1.2);
auch: organisatorischer Zusammenschluß einer Menge von
Usenet-Sites, die eine bestimmte Adreßdomain verwenden
Expire Haltezeitüberschreitung von Nachrichten / Programm
zum Löschen von Nachrichten, die die Haltezeit
überschritten haben
FAQ Frequently Asked Questions - eine Sammlung von
häufig gestellten Fragen und Antworten darauf zu einem
bestimmten Thema. Im Usenet finden Sie FAQs zu allen
Themen in der Gruppe news.answers.
Followup öffentliche Antwort auf eine öffentliche Nachricht
FTP File Transfer Protocol = Dateiübertragungsprotokoll,
das zum Dateitransfer im ^Internet eingesetzt wird
Gateway Übergang zwischen zwei Netzen
Gopher Internet-Programm/Verfahren/Standard zur Abfrage von
Online-Datenbanken
Header der Teil einer Nachricht, der Steuerinformationen
enthält
Host Rechner, insbesondere im ^Internet, der irgendwelche
Dienste zur Verfügung stellt
IN Individual Network e.V. - Zusammenschluß von
Privatpersonen in Deutschland, der Mail-, News- und
Internetanbindung ermöglicht.
Internet schnelles, weltweites Online-Standleitungsnetz,
das hauptsächlich von Firmen, Bildungseinrichtung und
sonstigen Organisationen getragen wird
IRC Internet Relay Chat - weltweites Chatsystem (System
zur Online-Textkommunikation per DFÜ) im Internet
ISO International Standardisation Organisation -
internationales Normungsgremium. Speziell: ISO-8859-1
= im europäischen Internet üblicher Zeichensatz.
Mail (Gesamtheit der) private(n) Nachricht(en)
Mailer Programm zum Lesen und Schreiben von Mails (im
FidoNet: Programm zur Übertragung von Mails)
Mailing-Liste Nachrichtenverteiler für ein bestimmtes Thema; quasi
eine Newsgroup, die per Mail abgewickelt wird
MIME Multipurpose Internet Mail Extensions = Internet-
Standard zur Übertragung von binären Daten,
internationalen Sonderzeichen, großen Dateien und
Multimedia-Daten
News (Gesamtheit der) öffentliche(n) Nachrichten
Newsreader Programm zum Lesen/Schreiben von ^News
Newsgroup Brett/Forum, in dem öffentliche Nachrichten
ausgetauscht werden
NNTP Programm/Verfahren zur Übertragung von ^News im
^Internet
PGP Pretty Good Privacy - Programm zur Nachrichten-
verschlüsselung mit dem "RSA-Verfahren"
Posting (Versenden einer) öffentliche(n) Nachricht
Postmaster Ansprechpartner einer Usenet-Site bzw. einer Domain
Realname der Name im wirklichen Leben - im Gegensatz zum
"Username"
Rekursion ^Rekursion
RFC Request for Comments - Internet-Standard-Spezifikation
(es gibt bis jetzt ca. 1500 davon)
RfD Request for Discussion - Aufruf zur Diskussion,
insbesondere zur Einrichtung einer neuen ^Newsgroup im
^Usenet
Routing Nachrichtentransport über bestimmte Wege
Sendmail kompliziertes Unix-Programm zum ^Routing von ^Mail
Site System/Knoten/"Point" im ^Usenet
SLIP Serial Line Internet Protocol - Verfahren zur
Teilnahme am Internet per Modem oder ISDN
SMTP Simple Mail Transfer Protocol - Programm/Verfahren zur
Übertragung von ^Mail im ^Internet
Smurf Schlumpf
Spooling Bereitstellen versandfertiger Nachrichten/Dateien in
einem bestimmten Festplattenverzeichnis
Subject Betreff einer Nachricht
Sub-Netz s. Kap. 1.1
Summary Zusammenfassung einer Nachricht
Traffic Nachrichtenaufkommen
Usenet Menge aller Systeme, die ^News austauschen
uucico Programm zur UUCP-Nachrichtenübertragung
UUCP Nachrichten-Transportverfahren und -programm im
^Usenet und in Sub-Netzen (s. Kap. 1.1)
UUencode Verfahren und Unix-Programm, mit dem binäre Dateien
im ASCII-Format codiert werden können, um sie per Mail
zu übertragen.
C. Weiterführende Literatur
────────────────────────────────────────────────────────────────────
Auf black.toppoint.de befindet sich ein Archiv der haeufig
gestellten Fragen ("frequently asked questions" oder FAQs) im USENET
und ein Archiv der RFCs. Man kann sich unter der Nummer 0431-673121
mit dem Login sauger, kein Passwort einloggen. Im Verzeichnis /pub
/faq befinden sich zum Beispiel die Texte
* Ein Verzeichnis der verfuegbaren FAQ Texte
-r--r--r-- 1 ftp 203350 Jul 31 21:54 /pub/faq/INDEX
* Verzeichnis der neu hinzu gekommenen FAQ-Texte
-r--r--r-- 1 ftp 661 Jul 31 21:50 /pub/faq/NEW
Wichtige FAQs sind zum Beispiel:
(Archive-Name: Dir/File bedeutet: Die Datei steht
unter dem Namen /pub/faq/Dir/File zur Verfuegung)
> Subject: A Primer on How to Work With the Usenet Community
> Newsgroups: news.announce.newusers,news.answers
> Date: 26 Apr 1993 00:01:31 -0500
> Archive-name: usenet-primer/part1
Der Text enthaelt gewissermassen die Netiquette des
USENET. Er ist das Vorbild fuer viele Netiquette-Texte
in anderen Netzen.
19311 Apr 30 21:50 /pub/faq/usenet-primer/part1
> Subject: Answers to Frequently Asked Questions about Usenet
> Newsgroups: news.announce.newusers,news.answers
> Date: 26 Apr 1993 00:01:34 -0500
> Archive-name: usenet-faq/part1
Der Text gibt Antworten auf haeufig gestellte Fragen im
USENET und viele nuetzliche Hinweise, wie man vermeiden
kann, als Idiot oder Neuling negativ aufzufallen.
39797 Apr 30 21:50 /pub/faq/usenet-faq/part1
> Subject: Hints on writing style for Usenet
> Newsgroups: news.announce.newusers,news.answers
> Date: 26 Apr 1993 00:01:49 -0500
> Archive-name: usenet-writing-style/part1
Der Text enthaelt einen Ueberblick darueber, wie man
saubere und gut lesbare Texte schreibt. Es enthaelt
viele nuetzliche Hinweise, wie man als Neuling positiv
auffallen kann.
5057 Apr 30 21:50 /pub/faq/usenet-writing-style/part1
> Subject: USENET Software: History and Sources
> Newsgroups: news.admin.misc,news.announce.newusers,...
> Date: 26 Apr 1993 00:01:40 -0500
> Archive-name: usenet-software/part1
Ein Ueberblick ueber die im USENET verwendete Software
auf den verschiedenen Betriebssystemen. Ausserdem eine
kurze Genesis des Netzes.
23445 Apr 30 21:50 /pub/faq/usenet-software/part1
> Subject: UUCP Internals Frequently Asked Questions
> Newsgroups: comp.mail.uucp,comp.answers,news.answers
> Date: 14 Jun 93 08:30:03 GMT
> Archive-name: uucp-internals
Dieser Text von Ian Lance Taylor, dem Autor von
Taylor-UUCP, geht auf die Eigenschaften, Vor- und
Nachteile der verschiedenen uucico-Protokolle ein.
Ausserdem wird die interne Funktionsweise von UUCP kurz
beleuchtet.
63636 Jun 16 21:50 /pub/faq/uucp-internals
> Subject: What is Usenet?
> Newsgroups: news.announce.newusers,news.admin.misc,news.answers
> Date: 26 Apr 1993 00:01:19 -0500
> Archive-name: what-is-usenet/part1
Eigentlich muesste dieser Text heissen "What USENET is
not". Anders als Fido, Z-Netz oder andere Netze kennt
USENET keine zentrale Koordination, Aufpasser oder
andere Stellen, an die man sich wenden kann. Trotzdem
kann nicht jeder machen, was er moechte. Warum das so
ist, warum das gut so ist und wieso das funktioniert,
wird einem vielleicht klar, wenn man diesen Text
verstanden hat.
16479 Apr 30 21:50 /pub/faq/what-is-usenet/part1
black.toppoint.de ist auch ein Archiv fuer RFCs. Im Verzeichnis
/pub/specs befinden sich die Spezifikationen verschiedener
Formate und Protokolle:
2048 Mar 12 19:33 fido
1024 Mar 13 13:58 gif87a
1024 Mar 13 13:57 midi
1024 Mar 12 19:33 nachrichtenformate
1024 Mar 12 20:27 rfc
1024 Feb 2 15:28 rich_text_format
1024 Mar 12 19:34 zconnect
Es gibt sehr viele RFC-Texte und Spezifikationen. Nur sehr wenige
sind auch fuer UUCP-Benutzer interessant (s. Abschnitt IV):
31702 Mar 2 07:31 /pub/specs/rfc/rfc-0800-0899/rfc822.z
14374 Mar 2 07:35 /pub/specs/rfc/rfc-1000-1099/rfc1036.z
347082 Mar 2 07:40 /pub/specs/rfc/rfc-1300-1399/rfc1341.ps
57141 Mar 2 07:40 /pub/specs/rfc/rfc-1300-1399/rfc1341.z
5658 Mar 2 07:40 /pub/specs/rfc/rfc-1300-1399/rfc1342.z
22126 Mar 2 07:40 /pub/specs/rfc/rfc-1300-1399/rfc1343.ps.z
8968 Mar 2 07:40 /pub/specs/rfc/rfc-1300-1399/rfc1343.z
19335 Mar 2 07:40 /pub/specs/rfc/rfc-1300-1399/rfc1344.ps.z
8089 Mar 2 07:40 /pub/specs/rfc/rfc-1300-1399/rfc1344.z
Die Endung ".z" zeigt an, dass die Dateien mit dem Packer "gzip"
gepackt sind. Sie koennen zu Hause oder auf black.toppoint.de mit
"gunzip" ausgepackt werden und neu gepackt werden (auf
black.toppoint.de stehen lha, zoo und andere Packer zur Verfuegung).
RFCs liegen immer in plain ASCII und optional in Postscript vor.
Postscript-RFCs haben die Endung ".ps". Postscript kann zum Beispiel
mit dem Programm ghostscript sichtbar gemacht werden oder auf nicht
postscriptfaehigen Drucker ausgegeben werden.
D. CrossPoint/UUCP - Versionsgeschichte
────────────────────────────────────────────────────────────────────
2.15 beta (03.08.93)
o erste freigegebene Betaversion
2.92 beta (06.11.93)
o Sysop-Mode
o diverse Bugfixes
2.93 beta (13.12.93)
o Relogin-Netcalls (Änderung in UUCP.SCR beachten!)
o optional Absender User@Server.domain (Edit/Boxen/Edit/RFC|UUCP)
o UUCP-Transfer kann mit <Esc> abgebrochen werden
o Schalter für 7/e/1 bei Edit/Boxen/Edit/Point
o UUZ fängt zusätzliche MIME-Fehler ab
Bugfixes
o Absturz bei RING o.ä. während des Einsortierens von Nachrichten
beseitigt
| 3.0 (22.03.94)
| o Auswertung von Cancel-Nachrichten ist nicht mehr optional
| Bugfixes
| o UUCP-g stabilisiert
| o Doppelte Übertragung bei Verbindungsabbrüchen beseitigt
| o Fehler im FOSSIL-Handling beseitigt; ISDN über cFos funktioniert
| jetzt
| o changesys-Problem beseitigt