Per Anhalter durch das Zerberus-Netz oder Wie verdammt nochmal machen die das eigentlich ? Version 2, 15.2.1991 Vorwort zur zweiten Version: Die zweite Version versucht, in einigen unklaren Punkten Klarheit zu schaffen. Insbesondere sind die Laengenbeschraenkungen bei Headerfeldern nun hoffentlich definitiv. Ein neuer Abschnitt "EILMAIL" erlaeutert eine Methode, Eilmail (persoenliche Nachrichten > 4000 bytes) direkt abzuliefern. Ein neuer Abschnitt "Erfordernisse fuer einen Server" versucht, die Nicht-Point-Seite der Thematik anzuschneiden. Ein neuer Abschnitt "Glossar", der die am haeufigsten verwirrten Begriffe beschreibt. Immer noch kein Inhaltsverzeichnis. Alle geaenderten/eingefuegten Stellen sind mit einem "v2:" in der ersten Spalte gekennzeichnet. ZUKUNFT: Fuer dieses Jahr steht uns allen ein komplett geaendertes Netzprotokoll ins Haus. Fuer dieses gilt dann diese Abhandlung nicht mehr. Es wurde angekuendigt, dass dieses neue Protokoll von Anfang an sauber dokumentiert wird. Lasst uns hoffen. Das alte (dieses) Protokoll wird aber auf laengere Zeit noch von der Serversoftware unterstuetzt werden. Ernsthafte Pointprogrammierer sollten sich aber bereithalten, das neue Protokoll bei Fertigstellung moeglichst zuegig zu implementieren, da es viele der Einschraenkungen hier aufheben wird. Nun aber los: Sehr geehrte Programmierer: Vielleicht haben Sie irgendwann einmal das Beduerfnis gehabt zu wissen wie Zerberus-Systeme ihre Daten untereinander austauschen. Hier ist sie nun, die entgueltige Anleitung zum Netcall. Ich hoffe, dass sich keine Fehler eingeschlichen haben und alle wichtigen Punkte abgehandelt wurden. Wenn Sie ALLE Hinweise in dieser Dokumentation beachten, sollte es nicht sonderlich schwierig sein, ein Zerberus-kompatibles Netcallteil zu schreiben. Viel Spass dabei Patrick Schaaf (BRIAN_O'FISH@MULI.ZER) MIDGET (Muli Internal Development, Growing Entropy Telecommunications) Der Zerberus-Netcall: Zuerst wird die Verbindung zwischen den beiden Systemen auf irgendeine Art und Weise hergestellt (zum Beispiel ueber Modem). Nach erfolgtem Connect laeuft aus Sicht des Anrufers folgendes ab: a) Die andere Seite sendet den Mailbox-Begruessungsbildschirm. Dieser kann durch wiederholtes Senden von Ctrl-X abgebrochen werden. b) Die Mailbox sendet als Prompt den String "Username:". Nun sollte der Anrufer den String "ZERBERUS", gefolgt von CR/LF, senden. c) Wenn b) funktioniert hat und die Mailbox das "ZERBERUS" verstanden hat, sendet sie den String "Systemname:", andern- falls vermutet sie wahrscheinlich einen normalen Usernamen, sie sollten in dem Fall einige CR/LF - Paare senden, damit die Verbindung sich wieder synchronisiert, und bei b) weiter- machen. Wenn "Systemname:" empfangen wurde, sollte der Anrufer seinen System- (oder Terminal-/Point-) Namen senden, in Grossschrift und wiederum mit CR/LF beendet. d) War dies nicht erfolgreich, geht's wieder zu b), ansonsten sendet die Mailbox "Passwort:". Nun wird das vereinbarte Netzpasswort gesendet, ebenfalls in Grossschrift und durch CR/LF beendet. e) Wenn die Passworteingabe fehlgeschlagen ist, wird entweder wieder bei b) weitergemacht, oder die andere Seite sendet bei zuvielen Fehlversuchen den String "Netzzugriff verweigert" und legt auf. Wurde das Passwort korrekt erkannt, sendet die Mailbox erst einmal mehrere Zeilen, die den String "running ARC" enthalten. Sie ist nun die Daten fuer Sie am vorbereiten, was einige Zeit in Anspruch nehmen kann (Sie sollten an dieser Stelle ruhig sichergehen und mit einem Timeout von 10 Minuten arbeiten). f) Ist der Partner fertig mit Arcen, so sendet er ein einzelnes NAK-Zeichen (Ascii Hex 15, Dezimal 21) und erwartet nun Ihre Seriennummer. Diese Seriennummer besteht im Prinzip aus fuenf Zeichen, wobei das fuenfte die Summe der ersten vier ist (modulo 256), also (in C): char s[5]; s[4]=(char)(((int)s[0]+(int)s[1]+(int)s[2]+(int)s[3])&0xFF); Was Sie als Seriennummer nehmen, ist im Prinzip egal, Sie koennen zum Bleistift der Einfachkeit halber fuenf mal ein Nullbyte senden. v2: Einzige Einschraenkung: Wenn die verwendete Seriennummer in den v2: ersten 4 bytes die gleiche ist wie die der Serverbox, so wird v2: diese sehr wahrscheinlich (bei Original-Zerberus) sofort v2: abbrechen von wegen doppelte Seriennummer und Raubkopie. v2: Mit 5 Nullbytes sind Sie auf der sicheren Seite. Wenn die Seriennummer korrekt erkannt wurde, sendet die Gegenseite ein ACK (Ascii 6), wenn nicht, wieder ein NAK. Sollte die Seriennummer mehrmals nicht erkannt werden, legt die Gegenseite auf. g) Ist der Seriennummerncheck erfolgreich gelaufen (ACK empfangen), beginnt umgehend der eigentliche Netztransfer: Beim Netcall wird immer in je einer Richtung ein File gesendet. Bei Unidirektionalem Transfer (Xmodem, Zmodem) sendet zuerst der Anrufer, dann der Angerufene. Bei Bidirektionalem Transfer (Bimodem) werden beide Dateien gleichzeitig versandt. Der Anrufer sendet eine Datei namens CALLER, der Angerufene eine Namens CALLED. Es muss damit gerechnet werden, dass moeglicherweise der Dateiname der zu empfangenden Datei ein anderer als der erwartete ist. v2: Bei Bimodem-Transfer MUESSEN beide Dateinamen genauso generiert v2: werden wie hier beschrieben. Die Datei ist ein Archiv, gepackt mit ARC (bei manchen Systemen ist eventuell auch ZIP, ZOO oder LHARC als Archivformat moeglich). Die oben angesprochenen Dateien CALLER und CALLED sollten als Extension die jeweilige Arcer-Extension tragen. Im Archiv befindet sich eine Datei namens PUFFER und sonst nix. Diese Datei ist das eigentliche Netcallfile (Format s.u.). Wenn ein Partner nichts zu versenden hat, sollte er entweder eine Datei senden, die nur aus einem CR/LF-Paar besteht, oder aber ein Archiv, das ein PUFFER-File mit CR/LF enthaelt, beide Formen sollten erwartet werden. v2: g') Wenn eines der beiden Archive (togal welches) NICHT korrekt v2: uebertragen wurde, wird der gesammte Netcall als totaler v2: Fehlschlag gewertet und beim naechsten Anruf alles noch einmal v2: geschickt, IN BEIDE RICHTUNGEN. v2: NB: Es WAERE moeglich, dass, wenn eine der beiden Dateien korrekt v2: uebertragen wurde, diese NICHT nochmal uebertragen werden muss. v2: Das wird aber fast sicher zu Problemen mit alten Versionen fuehren v2: (man denke die Szenarien mal durch). Daher dieses REQUIREMENT! h) Direkt nach dem Versand der beiden Files wird die Verbindung getrennt. Format des Netcallfiles (PUFFER): Das PUFFER-File enthaelt nacheinander ohne Luecke alle Nachrichten, die versandt werden sollen. Eine Nachricht besteht dabei aus Kopf und Message. v2: Der Kopf enthaelt 8 Zeilen, die jeweils auf CR/LF enden. Ein Kopf sieht folgendermassen aus: ----------- Start o'Kopf ------------ ----------- End o'Kopf -------------- v2: (Die oberste und unterste Zeile gehoeren NICHT zum Kopf, sondern stehen v2: nur da, damit es schoener wird.) Die einzelnen Felder haben folgende Bedeutung: : Eine Zeichenkette ohne Leerzeichen und in Grossschrift. v2: Maximallaenge: 40 Zeichen Es gibt drei moegliche Erscheinungsformen: Empfaenger ist ein User, der in der Mailbox eingetragen ist, die das Netcallfile erhalten wird. Username darf keinen Klammeraffen (@) enthalten. Beispiel: BRIAN_O'FISH Empfaenger ist ein Brett in der Box, die das Netcallfile erhalten wird. Damit die Nachricht ankommen kann, muss das Brett dort natuerlich vorhanden sein. Beispiel: /T-NETZ/BESCHEUERT @.ZER Empfaenger ist der User im Netzsystem Beispiel: WOLFGANG@SOLARIS.ZER Es ist wichtig, dass fuer Nachrichten an User im Serversystem der Systemname NICHT im Empfaengerteil auftaucht, also die erste Erscheinungsform genommen wird ! Der Nachrichtentitel. Eine beliebige Zeichenkette mit einer v2: Maximallaenge von 40 Zeichen. Der Absender der Nachricht. Eine Zeichenkette ohne Leerzeichen und in Grossschrift. Maximallaenge sind wiederum 40 Zeichen. Der Absender sollte immer die Form @.ZER haben. Bei einem Terminal (Point) sollte der Pointname fuer den eigenen Systemnamen eingesetzt werden, das Serversystem wird das Feld entsprechend anpassen. Abweichungen siehe Abschnitt "Eilmail" Das Erstellungsdatum der Nachricht. Eine Zeichenkette nur aus Ziffern mit exakt 10 Zeichen Laenge ohne Leerzeichen dazwischen. Format: jjmmtthhmm jj = Jahr (00-99, gezaehlt seit 1900, ich weiss, 2000 ist nicht :-) mm = Monat (01-12) tt = Tag im Monat (01-31) hh = Stunde (00-23) mm = Minute (00-59) Es ist SEHR wichtig, dass das Format dieses Feldes stimmt, insbesondere die Laenge, da es sonst zu grossen Problemen auf dem Netz kommen kann. Der Nachrichtenpfad, den die Nachricht bereits gelaufen ist. Eine Zeichenkette ohne Leerzeichen, Maximallaenge 80 Zeichen, wenn es mehr werden, sollte abgeschnitten werden ! Format: !![...]! Die Systemnamen sind jeweils OHNE die Endung .ZER zu schreiben. Das eigene System wird immer am Ende angehaengt (umgekehrt wie bei UUCP!). Usernamen sollten im Pfad nicht auftauchen! Wird eine Nachricht neu generiert, sollte der Pfad leergelassen werden (Leerzeile, keine Blanks!), der Server wird sich dann als erstes System eintragen. v2: Manche Points erlauben es, dass sich der Point in den Pfad eintraegt, v2: damit fehlerhafte Serversoftware die eigenen Nachrichten nicht wieder v2: an den Point zurueckschickt. v2: Nachteil ist, dass auch ein Pointuser ganz woanders, der zufaellig v2: den gleichen Pointnamen hat, die Nachricht nie zu sehen bekommt. v2: DER POINTNAME SOLLTE NIE IM PFAD AUFTAUCHEN ! v2: Obig beschriebener Usus ruehrt ausschliesslich von fehlerhafter v2: Serversoftware her - es ist Aufgabe des Server-Programmierers, das v2: abzustellen, und nicht Aufgabe des Points, um den Fehler herumzu- v2: programmieren. Dies ist eine eindeutige Kennung der Nachricht. Der Theorie nach sollte sie NETZWEIT NIEMALS doppelt vorkommen. v2: Eine Zeichenkette ohne Leerzeichen mit maximal 19 Zeichen (sehr v2: wichtig!). v2: (NOTE: In Version 1 stand da '20 Zeichen'. Das war FALSCH. Sorry) Das "Standard"-Format ist folgendes: .@ wobei xx eine zweistellige Zufallszahl und yyyyy ein bei jeder Nachricht erhoehter Zaehler ist. Beispiel: 08.15@MIDGET v2: Dieses Standardformat ist NICHT vorgeschrieben, die MessageID ist v2: als Zeichenkette ohne Struktur zu behandeln, bei der nur die v2: Eindeutigkeit ueber einen laengeren Zeitraum gewaehrleistet sein v2: muss. Der Nachrichtentyp, gibt die Weiterverarbeitung der Nachricht an. Ein einzelnes Zeichen, und zwar: T fuer Textnachrichten B fuer Binaernachrichten Alle anderen Zeichen fuehren bei Zerberus- und Kompatiblen Systemen zu erheblichen Problemen, also bitte keine eigenen Formate definieren, sonst koennen Sie ihr Netcallfile gleich loeschen (Einlesen wird an der Stelle mit Fehler abgebrochen). Das Format von Binaerdateien ist frei, bei Textdateien sollten Sie darauf achten (mit Ihrer Software bei der Erstellung der Message sicherstellen), dass Zeilen mit CR/LF beendet werden und moeglichst IBM-Umlaute verwenden (wenn ueberhaupt). v2: ANSI- oder sonstige Steuerzeichen in Textnachrichten sind nicht v2: erlaubt. v2: Dies Konvention ist BINDEND. Nicht mit CR/LF beendete Zeilen oder v2: andere als IBM-Umlaute werden als Fehler in der Software angesehen. v2: (Wer das ueberprueft, ist eine andere Sache, ich wollte das nur v2: noch einmal klipp und klar betonen). Die Laenge der Message (der eigentlichen Nachricht) in Bytes. Wichtig bei empfangenen Netcallfiles: Vor der Zahl kann ein Leerzeichen stehen ! v2: [Der Abschnitt ueber PM-Laengen wird durch folgenden Abschnitt v2: ersetzt:] v2: Persoenliche Nachrichten (PMs) an User ausserhalb des Server- v2: systems duerfen eine Laenge von 4000 bytes NIE ueberschreiten. v2: NOTE: Es mag Implementierungen der Serversoftware geben, die in v2: Einzelfaellen laengere PMs korrekt als Eilmail weiterleiten, v2: aber dabei kann sehr viel schiefgehen: v2: - der Terminaluser kann die Nachricht nicht bezahlen v2: - es ist keine Eilmail zum entsprechenden Zielsystem v2: moeglich. v2: In all diesen Faellen wuerde die Nachricht fuer den User v2: unsichtbar unter den Tisch fallen und nicht ankommen. v2: Wie Eilmails trotzdem versandt werden koennen, beschreibt der v2: Abschnitt "Eilmail" weiter unten. Bei Brettnachrichten sollte auch die Laengenbeschraenkung beachtet werden, hier ist sie aber Sache des Serversysops, so dass, wenn ueberhaupt diese Einstellung parametrisiert werden sollte. Beispiel eines Kopfes: ----------- Start o'Kopf ------------ /T-NETZ/BESCHEUERT Info: Das Zerberus-Netcallformat BRIAN_O'FISH@MIDGET.ZER 9009071123 08.15@MIDGET T 4223 ----------- End o'Kopf -------------- Nach dem Kopf kommt dann im Netcallfile direkt die Message (beginnend mit dem ersten Byte nach dem CR/LF der -Zeile. Die Message ist genau bytes gross, danach folgt sofort im naechsten Byte der naechste Kopf. v2: EILMAIL v2: (der gesamte folgende Abschnitt ist neu in Version 2) Wie bereits oben bei der Erlaeuterung zu maximalen PM-Laengen beschrieben, duerfen selbige nicht laenger als 4000 bytes werden, wenn sie ueber das Netz geroutet werden sollen. Online-User in der Mailbox haben damit i.d.R. keine Probleme, da die Mailboxsoftware "Eilmails" anbietet, die beliebig lang sein koennen und DIREKT beim Zielsystem abgeliefert werden. Sie kosten meistens ziemlich viel Geld. Ein Point (Singleuser-System) kann nun im allgemeinen diese Eilmail- Funktion der Serversoftware NICHT nutzen. Wenn ein Point eine PM > 4000 bytes verschicken muss, sollte er sie direkt beim Zielsystem abliefern. Dazu muss er natuerlich die Tele- fonnummer des Zielsystems kennen (kann zum Beispiel ueber ein "LIST VERBOSE SYSTEME" von 'maps angefordert werden). Es muss dann folgendes anders als normal gemacht werden: - Absender im Mailheader ist nicht @.ZER, sondern @.ZER - wobei der echte Username in der Serverbox ist. (Die Zielbox weiss ja nix von diesem armen Point und koennte mit der Absenderadresse nix anfangen). - Die Empfaengeradresse darf den Klammeraffen und den Systemnamen nicht mehr enthalten, sondern nur noch den Usernamen (wie bei Empfaengern am Server). - Beim Einloggen in's Zielsystem sollte als eigener Systemname DIREKTPM gewaehlt werden. [Dies ist ein Vorschlag, ich werde den entsprechenden Systemnamen gleich reservieren...] - Als Passwort muss GAST verwendet werden - Transferprotokoll ist Xmodem - Packer ist Arc (PKARC), nicht Zip oder sonstwas ! v2: Erfordernisse fuer einen Server v2: (der gesamte folgende Abschnitt ist neu in Version 2) Ein Server im Sinne dieses Textes ist jedes System, das Nachrichten an andere Netzsysteme weiterleitet. Neben den oben beschriebenen Protokollen ist das folgende zu beachten: Bearbeitung eingehender Netcallfiles: - Steht im -Feld kein Klammeraffe, ist die Nachricht fuer das eigene System gedacht, sonst fuer ein Netzsystem. Der Server koennte checken, dass das Netzsystem er selbst ist, und die Nachricht dann auch als lokal betrachten. - Wenn der Netcall von einem Point kommt, muss das -Feld geaendert werden in @.ZER, damit auf dem Netz nicht der Pointname als Systemname auftaucht. - Der Server sollte sich als erstes selbst hinten in den eintragen (Format siehe oben) - Das -Feld darf in KEINEM Fall geaendert werden (ausser abschnippeln auf 19 Zeichen). Eine Interpretation (ausser einem genauen Stringcompare) ist verboten. - Fehlerhafte Nachrichtenkoepfe sollten nicht zu einem Abbruch des Einlesens fuehren - eine anstaendige Heuristik sollte ein Aufsetzen hinter der fehlerhaften Mail erlauben. Weiterschicken von PMs: - Eilnachrichten (PM > 4000 byte) sollten NIE geroutet werden. Wenn sie ueberhaupt versandt werden, dann nur als Eilmail. - Es waere wuenschenswert, wenn eine Eilmail, fuer die keine Versand- moeglichkeit besteht, nicht einfach verschwaende - eine kleine automatische Hinweismail an den Absender waere nicht schlecht. Weiterschicken von Brettnachrichten: - Es muss UNBEDINGT ein Rekursionscheck gemacht werden. Dieser sollte drei Sachen abdecken: - Ist die zu verschickende Nachricht im entsprechenden Brett bereits abgelegt (gleiche MessageID schon vorhanden), wird sie NIRGENDWOHIN weitergeschickt. - Ist eines der Systeme, an die weitergeschickt werden soll, bereits im eingetragen, sollte es die Nachricht nicht nochmal bekommen. - Wenn die Nachricht gerade durch einen Netcall von System A angenommen wurde, sollte sie nicht wieder zu A zurueckkommen. (siehe auch die Bemerkung oben ueber Pointnamen im ) Spezielle Logins: - Neben den eingetragenen Netzsystemen sollte jeder Netcall mit einem unbekannten Systemnamen und Passwort GAST angenommen werden. In diesem Fall sollten keine Daten versandt werden (leeres Netcallfile), aber die entgegengenommenen Daten (zumindest aber die lokal zu versendenden PMs) ausgewertet werden. Diese GAST-Calls sollten mit Xmodem und Arc als Packer durchgefuehrt werden. Dies ermoeglicht oben beschriebene Eilmail-Methode. Der Systemname DIREKTPM sollte reserviert bleiben, also nicht einge- tragen werden. v2: Glossar - Beschreibung der haeufigst verwendeten Begriffe v2: (der gesamte folgende Abschnitt ist neu in Version 2) ARCHIV Eine Datei, die andere Dateien enthaelt, die mit irgendeinem Packer komprimiert wurden. BRETTMAIL Eine beliebige Nachricht an ein beliebiges Brett - sie wird im allgemeinen auf das gesamte Netz verteilt. Die Unterscheidung in ->PM und BRETTMAIL wird anhand des Empfaenger- feldes im ->KOPF einer Nachricht getroffen. CONNECT Beginn der physikalischen Uebertragung CR Ascii-Zeichen fuer Carriage-Return (Dezimalcode: 13) -> LF, CR/LF CR/LF Ein CR, gefolgt von einem LF. Zeilentrenner bei Textnachrichten und sonstwo. DIREKTMAIL -> EILMAIL EILMAIL Neuerdings auch DIREKTMAIL, eine PM, die direkt beim Zielsystem abgeliefert wird, statt ->geROUTEt zu werden. ->PM groesser 4000 Bytes (->MESSAGE) MUSS als EILMAIL verschickt werden. GASTNETCALL Ein ->NETCALL mit einem nicht eingetragenen Systemnamen, bei dem als Passwort GAST verwendet wird. IBM-UMLAUTE Die Ascii-Codes der Umlaute, die im IBM-Zeichensatz verwendet werden: ae 132 AE 142 oe 148 OE 153 ue 129 UE 154 sz 225 KOPF Der Beginn einer ->NACHRICHT, in einem festen Format, der angibt, wohin die Nachricht gehen soll, woher sie kommt und wieviel Uhr es war. KLAMMERAFFE Das Ascii-Zeichen '@' (Dezimalcode 64). Trennt in Adressangaben den Usernamen vom Systemnamen. LF Ascii-Zeichen fuer Linefeed (Dezimalcode: 10) -> CR, CR/LF MAILBOX Hier als Synonym fuer ->SERVER verwendet MESSAGE Der eigentliche Inhalt einer ->NACHRICHT, kommt direkt nach dem ->KOPF MESSAGEID, MSGID Eindeutige Nachrichtenkennung, die zum Erkennen von ->REKURSIONen verwendet wird. MULI Eine Zerberus-Mailbox, die wilde Zeiten erlebt hat. NACHRICHT Das Atom beim Netcall. Eine Information fuer einen Empfaenger. Nachrichten werden immer zu ->PUFFERn zusammengefasst. Sie bestehen als anstaendiges Atom wiederum aus ->KOPF und ->MESSAGE NETCALL [-Protokoll] Der physikalische Transfer von Nachrichten zwischen zwei Rechnern beziehungsweise die dabei benutzten Verfahren. Das, was dieser Text fuer Zerberus beschreibt... PM Eine Persoenliche Mail - eine Nachricht an einen einzelnen User. Alternative ist eine ->BRETTMAIL, die an ein Brett und damit an mehrere Netzsysteme verteilt wird. -> EILMAIL POINT Ein Computer, der zwar ->NETCALLs entgegennimmt und durchfuehrt, aber KEINE Nachrichten an andere Systeme weiterleitet. Jeder Point hat einen (oder mehrere) ->SERVER, bei denen er regel- maessig anruft und seine Daten abholt. Ein Point hat einen Namen, der am gleichen Server nicht ein zweites Mal vergeben werden darf. -> SERVER, POINTUSER POINTUSER Der im Server eingetragene Username eines Menschen, der einen ->POINT betreibt. PUFFER Die Datei mit ->NACHRICHTen, die in einem ->ARCHIV verpackt versandt wird. Hat ebendiesen Namen (PUFFER) REKURSION Eine Rekursion tritt dann auf, wenn eine Nachricht ein zweites Mal bei einem bestimmten Rechner angelangt. -> MSGID ROUTEN Das versenden einer PM ueber mehrere Mailboxen, wenn Server und Zielsystem keine direkte Verbindung unterhalten. Nur fuer PM < 4000 Bytes erlaubt. -> EILMAIL SERVER Ein Computer, der ->NETCALLs entgegennimmt und weiterleitet. Jeder Server hat einen Namen, den Servernamen, der im gesamten Netz kein zweites mal vorkommen darf. -> POINT TERMINAL ->POINT TERMINALUSER ->POINTUSER Austesten von neuer Software: Zur Aufrechterhaltung des Netzbetriebes sollte bei neugeschriebener Netzsoftware unbedingt folgendes beachtet werden: - Testen Sie die Software ausfuehrlich mit ihrem Server, senden Sie in dieser Testphase KEINE Nachrichten an Netzbretter oder Netzuser. Halten Sie sich daran auch, wenn Sie von sich als gutem Programmierer ueberzeugt sind - Fehler passieren immer mal und koennen fatal sein. Dieser lokale Test sollte mindestens einen Monat laufen. - Arbeiten Sie mit ihrer Software und einem UEBERSCHAUBAREN Kreis von Beta-Testern. Eine zu schnelle Verbreitung von fehlerhafter Netzsoftware koennte zu erheblichen Rueckrufproblemen fuehren. - Wenn Sie eine Mailboxsoftware schreiben, die als Netzsystem (und nicht als Point/Terminal) an's Netz gehen soll, muessen sie die Software vor dem Netzanschluss von der technischen Netzkoordination (SYSOP@INFINET) testen lassen. Bei Pointsoftware ist dieser Test derzeit nicht obligatorisch, aber trotzdem sehr zu empfehlen. Genauere Informationen bitte bei Sysop@Infinet anfordern. Nachwort: Keines. Ich wollte die Mail nur nicht aprupt enden lassen. Viel Spass beim Programmieren.