mailboxen-bbs

CBBS und die frühe Mailbox-Idee – ein Rechner wird zum elektronischen Schwarzen Brett

Die Grundidee eines Bulletin Board Systems ist älter als die Mailboxphase, die ich selbst besonders erlebt habe. 1978 entstand im Raum Chicago mit dem CBBS von Ward Christensen und Randy Suess eines der ersten bekannten mikrocomputerbasierten Bulletin-Board-Systeme. Die Idee war erstaunlich direkt: Was vorher an einem echten Schwarzen Brett hing, sollte über einen Rechner und die Telefonleitung erreichbar werden.

Nutzer konnten sich einwählen, Nachrichten lesen und eigene Hinweise hinterlassen. Damit entstand etwas, das weder klassischer Großrechnerdienst noch Rundfunk noch bloß Telefonie war. Ein einzelner Mikrocomputer wurde zum öffentlichen digitalen Treffpunkt.

Aus dieser einfachen Grundidee entwickelte sich über die folgenden Jahre eine ganze Kultur. Mailboxen bekamen Benutzerkonten, Themenbereiche, Dateisammlungen, private Nachrichten, Netzanbindungen und zusätzliche Programme. Manche blieben kleine lokale Systeme, andere wurden groß, mehrleitungsfähig und über regionale oder internationale Mailboxnetze mit anderen BBS verbunden.

Meine eigene technische Linie beginnt später und aus der deutschen Praxis heraus. Trotzdem ist diese Vorgeschichte wichtig, weil sie zeigt, dass Mailboxen keine Nebenfunktion eines Modems waren. Das Modem war nur die Tür. Die eigentliche Innovation war der Rechner dahinter, der aus einzelnen Anrufen eine dauerhafte Gemeinschafts- und Informationsstruktur machte.

Von BTX zu Mailboxen

BTX war für mich ein früher Blick in eine vernetzte Welt, aber es blieb ein stark gelenktes System. Seiten kamen aus einem festen Dienst, Eingaben liefen in vorgegebenen Masken, und fast alles wirkte wie ein digitalisiertes Formularwesen. Technisch war das interessant, praktisch oft nützlich, aber geistig blieb es ein zentral verwalteter Raum.

Mailboxen und BBS fühlten sich anders an. Schon die Einwahl hatte einen anderen Charakter. Man verband sich nicht mit einer staatlich oder institutionell vorkonstruierten Oberfläche, sondern mit einem Rechner am anderen Ende, der von einem Sysop betrieben wurde und seine eigene Ordnung hatte. Das konnte chaotisch, ungeschliffen oder streng sein, aber genau darin lag die Qualität. Es war weniger Dienst und mehr Gegenüber.

Für mich war das wichtig, weil dort Technik spürbarer wurde. Man musste nicht nur Inhalte aufrufen, sondern verstehen, wie Verbindung, Login, Menüs, Dateibereiche und Transfer überhaupt zusammenspielen. Die Sache war weniger bequem, aber sehr viel lehrreicher.

„BTX war nützlich. Die Mailbox-Welt war freier, rauer und technisch ehrlicher.“

Einwahl, Modem und Terminalprogramm

Der Kern der Sache war simpel und zugleich empfindlich: Telefonleitung, Modem, Rechner, Terminalprogramm. In der Theorie klang das geradlinig. In der Praxis bedeutete es Parameter, Timing, Gegenstellenverhalten, Besetztzeichen und die ständige Frage, ob eine Verbindung sauber genug ist, um mehr zu tragen als nur einen kurzen Login-Versuch.

Das Terminalprogramm war keine hübsche Oberfläche, sondern Arbeitsgerät. Was zählte, waren Lesbarkeit, saubere Steuerzeichenverarbeitung, Upload- und Download-Funktionen, Logging und das Gefühl, die Gegenstelle nicht bloß anzusehen, sondern mit ihr wirklich zu arbeiten. Jede gelungene Einwahl war damit schon ein kleiner technischer Nachweis: Leitung steht, Modem spricht, Parameter passen, Gegenstelle antwortet.

Gerade weil alles langsamer und direkter war, wurde der Verbindungsaufbau bewusster erlebt. Man hörte förmlich, dass hier etwas geschieht. Die Verbindung war nicht „einfach da“, sondern musste aufgebaut, gehalten und im Zweifel wieder sauber hergestellt werden.

Was bei einem BBS-Anruf wirklich geschah

Aus Benutzersicht bestand ein Mailboxbesuch aus wenigen sichtbaren Schritten. Technisch liefen dabei mehrere Systeme hintereinander ab. Zuerst musste die Telefonverbindung zustande kommen. Dann handelten die Modems ihren Übertragungsmodus aus. Anschließend begann erst die Terminal- und BBS-Sitzung.

Das erklärt auch, warum Fehler so unterschiedlich aussehen konnten. Ein Besetztzeichen bedeutete etwas völlig anderes als ein fehlgeschlagener Modem-Handshake. Ein erfolgreicher CONNECT mit Zeichensalat deutete eher auf Terminalparameter hin. Ein sauberer Login mit späterem Transferabbruch führte wiederum in Richtung Protokoll oder Leitung.

Wer diese Ebenen auseinanderhalten konnte, war nicht nur erfolgreicher beim Einwählen. Er lernte nebenbei eine Denkweise, die später bei Netzwerken, Shells und Servern wieder auftauchte: erst die Schicht bestimmen, dann den Fehler suchen.

Eine Leitung oder mehrere Nodes – wie viele Benutzer gleichzeitig hinein konnten

Viele private Mailboxen begannen mit genau einer Telefonleitung. Dann galt eine harte physische Grenze: Ein Benutzer war online, alle anderen hörten beim Einwahlversuch nur Besetzt. Die maximale gleichzeitige Benutzerzahl betrug genau eins.

Größere Systeme konnten mehrere Telefonleitungen und mehrere Modems betreiben. Jede aktive Verbindung wurde häufig als eigener Node behandelt. Damit konnten mehrere Benutzer gleichzeitig eingeloggt sein, Nachrichten schreiben oder Dateien übertragen.

Das war technisch aufwendiger als nur ein weiteres Modem anzuschließen. Die BBS-Software musste parallele Sitzungen verwalten, Dateien gegen gleichzeitige Zugriffe absichern und gegebenenfalls Nachrichten oder Benutzerzustände synchron halten.

Wie eine Mailbox praktisch funktionierte

Sobald man eingeloggt war, zeigte sich schnell die innere Ordnung einer Mailbox. Es gab Bretter oder Themenbereiche, oft eine Benutzerführung in Menüs, Datei- und Nachrichtenbereiche, Regeln, manchmal kleine interne Kulturcodes und fast immer eine klare Handschrift des Betreibers. Nichts davon war neutral. Jede Mailbox wirkte ein wenig anders.

Für mich lag der Reiz gerade darin, dass diese Systeme textbasiert und unprätentiös blieben. Keine große Kulisse, keine unnötige Show. Stattdessen ein Rechner auf der anderen Seite, der einem in klaren Menüs sagte, was möglich ist: lesen, schreiben, laden, hochladen, verlassen. Das war nicht spektakulär, aber genau deshalb technisch glaubwürdig.

Wer aus einer solchen Welt kam, lernte nebenbei auch den Wert von Text als Arbeitsoberfläche. Nicht alles muss bunt sein, um präzise zu funktionieren. Dieser Gedanke blieb später bei Shells und im Web für mich sehr brauchbar.

Der SysOp – Betreiber, Administrator und oft auch Hausmeister des Systems

Hinter einer privaten Mailbox stand gewöhnlich kein anonymer Plattformkonzern, sondern ein konkreter Betreiber: der System Operator, kurz SysOp. Er stellte Rechner, Speichermedien, Modem, Telefonanschluss und häufig auch einen erheblichen Teil seiner Freizeit zur Verfügung.

Seine Aufgaben gingen weit über Technik hinaus. Benutzer freischalten, Nachrichtenbereiche pflegen, Dateiuploads prüfen, Backups erstellen, Zugriffsrechte vergeben, Störungen beheben und Regeln durchsetzen gehörten ebenso dazu wie das eigentliche Betreiben der Hardware.

Dadurch trug jede Mailbox eine erkennbare Handschrift. Der SysOp entschied, welche Themenbereiche existierten, welche Dateien erwünscht waren und welcher Umgangston akzeptiert wurde. Diese persönliche Verantwortung unterschied BBS-Kultur stark von späteren zentralisierten Plattformen.

• Technik: Rechner, Modems, Leitungen, Software, Datenträger und Backups betreiben.
• Administration: Benutzerkonten, Rechte, Zeitlimits und Zugänge verwalten.
• Inhalte: Bretter und Dateibereiche strukturieren und pflegen.
• Moderation: Regeln durchsetzen und Konflikte behandeln.
• Netzbetrieb: bei vernetzten BBS zusätzlich Mail- und Dateiaustausch mit anderen Systemen organisieren.

„Eine Mailbox war Software. Eine gute Mailbox war zusätzlich die tägliche Arbeit ihres SysOps.“

Benutzerkonten, Handles und Zugriffsrechte

Nicht jede Mailbox behandelte jeden Anrufer gleich. Ein neuer Benutzer konnte zunächst nur eingeschränkten Zugriff besitzen. Nach Registrierung oder persönlicher Freischaltung standen mehr Bretter, längere Online-Zeiten oder zusätzliche Dateibereiche zur Verfügung.

Häufig wurden Namen oder Handles verwendet. In manchen Szenen gehörte ein Handle zur eigenen Online-Identität, während andere Systeme stärker auf reale Namen setzten. Das hing von Kultur, Zweck und Regeln der jeweiligen Mailbox ab.

Zugriffslevel waren technisch praktisch. Sie erlaubten, Gästen nur einen kleinen Bereich zu zeigen, bekannten Nutzern mehr Funktionen zu geben und administrative Bereiche vollständig abzuschotten.

Bretter, Threads und lokale Gemeinschaft

Die Nachrichtenbereiche einer Mailbox wurden oft als Bretter bezeichnet. Das Bild passt gut: Man schaut nach, was neu angeheftet wurde, liest Antworten und hinterlässt selbst eine Nachricht.

Im Unterschied zu einem heutigen permanent aktualisierten Social-Media-Feed war die Nutzung stark zeitversetzt. Ein Benutzer schrieb etwas, legte auf, und andere antworteten Stunden oder Tage später. Diese Asynchronität war keine Einschränkung am Rand, sondern das Grundprinzip.

Lokale Bretter blieben auf genau dieser Mailbox. Vernetzte Echo-Bereiche konnten dagegen auf vielen Systemen gleichzeitig erscheinen. Damit entstand aus einzelnen Rechnern eine größere Diskussionslandschaft, ohne dass alle Teilnehmer gleichzeitig online sein mussten.

Gerade diese Verzögerung erzeugte oft eine andere Gesprächsform. Man musste nicht sofort reagieren. Eine Antwort war eher ein kleiner Text als ein flüchtiger Klick.

Dateibereiche, Uploads und die eigentliche Substanz

Ein wesentlicher Teil der Mailbox-Welt lag nicht in den Brettern, sondern in den Dateibereichen. Dort lagen Programme, Werkzeuge, Texte, Dokumentationen, Treiber, Utilities und manchmal auch Dinge, die mehr über die Szene sagten als jeder Nachrichtentext. Die Mailbox war damit nicht nur Kommunikationsraum, sondern auch Verteilstation.

Für mich war das technisch interessant, weil hier zum ersten Mal klar spürbar wurde, dass Rechner über Distanz nicht nur Worte, sondern echte Arbeitsmittel austauschen können. Eine Datei kam nicht aus der Hand eines Bekannten per Diskette, sondern über die Leitung. Langsam, störanfällig, aber real.

• Programme: Utilities, kleine Helfer, Terminal- und Systemwerkzeuge, manchmal auch Test- und Bastelsoftware.
• Texte: Dokumentationen, Readmes, Erklärungen, Listen und technische Hinweise, die oft mehr wert waren als die Dateien selbst.
• Uploads: Nicht bloß senden, sondern vorbereiten, benennen, prüfen und so ablegen, dass andere damit wirklich arbeiten konnten.
• Vertrauen: Je besser eine Mailbox gepflegt war, desto eher wusste man, dass ihre Dateien und Beschreibungen brauchbar waren.

Gerade diese Mischung aus Text und Datei war entscheidend. Man lernte nicht nur, etwas zu laden, sondern auch, warum eine Datei relevant ist, wie sie gedacht war und in welchem Systemzusammenhang sie steht. Auch das war ein Vorläufer späterer technischer Netzpraxis.

„Nicht nur Nachrichten waren wichtig. Wichtiger war oft, was im Dateibereich still auf einen wartete.“

Filebase, Beschreibungen und Upload-Regeln

Ein guter Dateibereich war mehr als ein Verzeichnis voller Archive. Dateien mussten benannt, beschrieben und einem Bereich zugeordnet werden. Ohne diese Pflege wurde selbst eine große Sammlung schnell wertlos.

Manche Mailboxen arbeiteten mit Upload-/Download-Verhältnissen oder Credits. Wer viel herunterladen wollte, sollte im Gegenzug selbst brauchbare Dateien beisteuern. Andere Systeme verzichteten bewusst darauf. Beides spiegelte die Kultur und Ressourcenlage des jeweiligen Systems wider.

Besonders wichtig war die Prüfung von Uploads. Eine unbekannte Datei konnte beschädigt, falsch beschrieben oder im schlimmsten Fall schädlich sein. SysOps und erfahrene Nutzer übernahmen deshalb eine frühe Form von Qualitätssicherung.

Dateiübertragung, Protokolle und Leitungsrealität

Sobald Dateien über die Leitung gehen sollten, wurde klar, warum Protokolle mehr sind als Theorie. Eine Übertragung musste gegen Fehler, Abbrüche und schlichte Langsamkeit bestehen. Schon dadurch wurden Namen wie XMODEM, YMODEM oder ZMODEM nicht bloß technische Etiketten, sondern praktische Unterschiede im Alltag.

Die Leitung war nie selbstverständlich sauber. Eine instabile Verbindung bedeutete nicht nur Wartezeit, sondern unter Umständen einen komplett neu anzufangenden Transfer. Genau deshalb war die Qualität des Übertragungsprotokolls nicht nebensächlich. Sie entschied darüber, ob man eine Datei wirklich bekommt oder nur viel Zeit verliert.

Für mich war das ein guter Lehrraum, weil sich hier mehrere Ebenen trafen: Rechner, Terminalsoftware, Gegenstelle, Protokoll und Leitung. Fehler konnten an jeder Stelle entstehen. Genau das schärfte den Blick dafür, Systeme nicht zu mystifizieren, sondern Schritt für Schritt zu zerlegen.

FidoNet – als einzelne Mailboxen begannen, untereinander Post auszutauschen

Eine einzelne Mailbox ist zunächst ein isolierter Rechner. FidoNet änderte genau diese Grenze. BBS-Systeme konnten Nachrichten und Dateien untereinander austauschen und dadurch ein verteiltes Netzwerk bilden, obwohl die einzelnen Systeme weiterhin eigenständig blieben.

Technisch war das kein permanentes Online-Netz wie das heutige Internet. Die Systeme riefen sich gegenseitig an beziehungsweise tauschten Daten über definierte Wege aus. Nachrichten wurden gesammelt, paketiert, weitertransportiert und am Ziel wieder einsortiert.

Die Stärke lag gerade in dieser Asynchronität. Ein Benutzer musste nicht gleichzeitig mit einem Empfänger oder einer entfernten Mailbox verbunden sein. Die Nachricht wanderte Schritt für Schritt durch das Netz.

Damit wurde aus Mailboxkultur echte Netzpraxis. Nicht im heutigen TCP/IP-Sinn, aber organisatorisch bereits mit Adressen, Routing, Regeln und verteilten Zuständigkeiten.

Netmail und Echomail – private Nachricht oder verteiltes Brett

Innerhalb vernetzter Mailboxwelten muss man zwischen unterschiedlichen Nachrichtenarten unterscheiden. Netmail richtet sich gezielt an eine bestimmte Adresse beziehungsweise einen bestimmten Teilnehmer im Netz.

Echomail funktioniert dagegen eher wie ein verteiltes Themenbrett. Nachrichten eines Echo-Bereichs werden zwischen beteiligten Systemen weitergereicht, sodass Benutzer auf unterschiedlichen Mailboxen dieselbe Diskussion lesen und beantworten können.

Das war ein entscheidender Schritt über die lokale Mailbox hinaus. Die eigene BBS blieb der Zugangspunkt, die Diskussion selbst konnte jedoch weit über die lokale Telefonnummer hinausreichen.

Nodelist, Adressen und Routing – ein Netz braucht Ordnung

Ein verteiltes Mailboxnetz kann nur funktionieren, wenn Systeme eindeutig adressiert und auffindbar sind. FidoNet arbeitete dafür mit einer hierarchischen Adressstruktur und einer Nodelist, in der teilnehmende Systeme und technische Informationen verzeichnet wurden.

Dadurch wussten Mailer und Betreiber, welche Systeme existierten und wie Nachrichten weitergeleitet werden konnten. Organisatorische Ebenen wie Zone, Net und Node halfen, ein großes Hobbyistennetz in handhabbare Bereiche zu gliedern.

Die Nodelist war dabei mehr als ein Telefonbuch. Sie war ein maschinenlesbarer Teil der Netzorganisation. Ohne gepflegte Adressen und Routingwissen würde Store-and-Forward schnell im Chaos enden.

„Ein dezentrales Netz wird nicht dadurch ordentlich, dass niemand zuständig ist. Es wird ordentlich, weil Zuständigkeiten verteilt sind.“

Nachtbetrieb, Zone Mail Hour und die Ökonomie der Telefonleitung

Vernetzte Mailboxen mussten ihre Nachrichten zu anderen Systemen transportieren. Da Telefonverbindungen Geld kosteten und Leitungen tagsüber für Benutzer gebraucht wurden, war nächtlicher Mailaustausch besonders sinnvoll.

In FidoNet gehörten definierte Mailer-Zeiten zur technischen Organisation. Während solcher Zeitfenster sollten Systeme für den Netmail-Austausch erreichbar sein. Das war kein romantisches Ritual, sondern praktische Netzdisziplin.

Nachrichten wurden gesammelt und gebündelt übertragen. Dadurch musste nicht für jede einzelne Nachricht sofort eine Fernverbindung aufgebaut werden. Store-and-Forward war damit auch eine Antwort auf reale Telefonkosten.

Offline-Reader – online kurz verbinden, zuhause in Ruhe lesen und schreiben

Weil jede Online-Minute Geld kosten konnte, entstand ein naheliegender Arbeitsstil: Nachrichten gesammelt herunterladen, Verbindung trennen, Inhalte offline lesen und Antworten vorbereiten.

Offline-Mail-Reader und Nachrichtenpakete machten genau das möglich. Statt lange in der Mailbox zu verweilen, wurde die teure Leitungszeit auf den eigentlichen Datentransfer reduziert.

Anschließend konnten Antworten gesammelt wieder hochgeladen werden. Das war effizient, besonders bei vielen Brettern oder vernetzten Echo-Bereichen.

Door-Programme – wenn die Mailbox externe Anwendungen öffnete

Viele BBS-Systeme konnten externe Programme starten, sogenannte Doors. Für den Benutzer wirkte es, als würde er innerhalb der Mailbox in einen zusätzlichen Dienst wechseln.

Das konnten Spiele, Datenbanken, Quizsysteme oder andere Anwendungen sein. Technisch musste die BBS dabei Benutzerinformationen und die bestehende Verbindung kontrolliert an das externe Programm übergeben und anschließend wieder zurücknehmen.

Door-Programme zeigen, dass Mailboxen weit mehr sein konnten als ein Menü aus Nachrichten und Dateien. Sie waren kleine Plattformen, die zusätzliche Funktionen integrieren konnten – lange bevor heutige Plattformbegriffe üblich wurden.

Telefonkosten, Besetztzeichen und Zeitdisziplin

Die technische Erfahrung einer Mailbox hing stark davon ab, ob sie im eigenen Ortsnetz lag oder nur über eine teurere Fernverbindung erreichbar war. Telefonkosten bestimmten mit, wie lange man online blieb und welche Mailboxen man regelmäßig anrief.

Dazu kam die Leitungszahl. Bei einer Single-Line-Mailbox konnte ein einziger langer Download die gesamte BBS für andere Benutzer blockieren. Zeitlimits waren deshalb nicht immer Schikane, sondern Ressourcenverwaltung.

Gute Vorbereitung sparte Geld und schonte die gemeinsame Infrastruktur: Nachrichten offline vorschreiben, gewünschte Dateien vorher notieren, Transferprotokoll korrekt einstellen und nach erledigter Arbeit wieder auflegen.

Vertrauen, Rechte und Sicherheitsgrenzen

Mailboxen waren offene Kommunikationsräume, aber keine sicherheitsfreien Räume. Benutzerkonten brauchten Passwörter, Dateiuploads mussten geprüft und administrative Funktionen geschützt werden.

Gleichzeitig war die Sicherheitskultur stark vom jeweiligen Betreiber abhängig. Ein engagierter SysOp konnte sein System sorgfältig pflegen. Ein schlecht administriertes System konnte dagegen veraltete Software, schwache Passwörter oder unkontrollierte Dateibereiche enthalten.

Auch hier entstand eine bis heute gültige Lehre: Vertrauen in eine Community ersetzt keine technische Zugriffskontrolle. Und technische Zugriffskontrolle ersetzt keine verantwortliche Administration.

Warum Mailboxen geistig schon in Richtung Shell gingen

Rückblickend war an Mailboxen nicht nur interessant, dass man sich einwählte, Nachrichten las oder Dateien lud. Wichtiger war, dass dort eine andere Haltung zu Rechnern entstand. Login, Prompt, Textoberfläche, Benutzerkennung, Gegenstelle, Dateiübertragung, Sitzungslogik, Verbindungsdisziplin – all das war geistig deutlich näher an späteren Shell-Accounts als an der damaligen Massencomputer-Oberfläche.

Wer einmal erlebt hatte, dass ein fremder Rechner am anderen Ende der Leitung auf Eingaben reagiert, Zugriff regelt, Dateien anbietet und eine eigene Ordnung besitzt, für den war der Schritt zu echten Mehrbenutzersystemen kein Sprung mehr. Er war nur noch die nächste Schicht.

Genau deshalb gehören Mailboxen in meine technische Linie nicht als Episode, sondern als Zwischenstufe. Vor BTX lag für mich die frühe Erfahrung, dass Vernetzung überhaupt faszinierend sein kann. Über Mailboxen wurde daraus ein konkreteres Rechnerdenken. Später kamen Shell-Accounts, HTML, CGI und Webarbeit dazu. Aber das Gefühl, dass Textoberflächen, Protokolle und saubere Zustände echte Werkzeuge sind, war da längst gelegt.

„Mailboxen waren nicht das Ende einer alten Technik. Sie waren der ruhige Vorraum dessen, was später selbstverständlich Web hieß.“

Die größere technische Linie dazu steht auf /sslxy/. Die frühere Funk- und Übergangsphase davor liegt auf 11-meter-band.htm.

Vom BBS zum Internet – warum die Mailboxwelt nicht einfach „verschwand“

Mit günstigerem Internetzugang, E-Mail, Usenet, FTP und dem World Wide Web verlagerte sich ein großer Teil der bisherigen Mailboxfunktionen in offene IP-Netze. Ein Benutzer musste nicht mehr für jeden einzelnen Dienst eine andere Telefonnummer wählen.

Das war technisch ein enormer Vorteil. Eine einzige Internetverbindung öffnete den Zugang zu vielen Servern gleichzeitig. Webseiten, Mailserver und FTP-Dienste waren nicht mehr an die Leitungszahl einer einzelnen lokalen Mailbox gebunden.

Trotzdem verschwanden die Ideen der BBS-Welt nicht. Benutzerkonten, Foren, Dateibereiche, private Nachrichten, Moderation und Community-Regeln tauchten im Internet in neuen Formen wieder auf.

Auch die soziale Nähe vieler kleiner Mailboxen blieb etwas Eigenes. Ein weltweites Web ist größer, aber ein lokales BBS konnte persönlicher und überschaubarer sein. Fortschritt ersetzte deshalb nicht jede Qualität eins zu eins.

„Das Web ersetzte viele Funktionen der Mailbox. Die Erfahrung einer kleinen selbst betriebenen digitalen Gemeinschaft ersetzte es nicht vollständig.“

Mailboxkultur heute erhalten – mehr als nur einen Telnet-Port öffnen

Historische BBS-Systeme lassen sich heute über Emulatoren, virtuelle Maschinen oder Telnet-Zugänge wieder betreiben. Das macht die Software erlebbar, ersetzt aber nicht vollständig die damalige Telefonrealität.

Ein sofort verfügbarer TCP/IP-Zugang kennt kein Besetztzeichen, keine Ortsnetzgebühr und keinen Modem-Handshake. Wer die historische Erfahrung dokumentieren will, sollte deshalb auch diese Rahmenbedingungen festhalten.

• ursprüngliche BBS-Software und Konfiguration archivieren
• Menüstrukturen und ANSI-/Textdarstellung dokumentieren
• Dateibereiche mit Beschreibungen erhalten, nicht nur nackte Archive
• Nodelists, FidoNet-Konfiguration und Mailer-Unterlagen sichern
• Terminalparameter und verwendete Modemgeschwindigkeiten dokumentieren
• historische Telefonkosten- und Leitungsbedingungen als Teil der Nutzungsgeschichte festhalten

Eine Mailbox ist als historische Technik nur dann vollständig verständlich, wenn man nicht nur die Software sieht, sondern auch die damaligen Begrenzungen. Gerade aus ihnen entstanden viele der klugen Lösungen: Offline-Reader, Nachtmail, Store-and-Forward, kurze Sitzungen und disziplinierte Dateitransfers.