fido-und-mailbox-netze

Was Mailbox-Netze überhaupt waren

Eine einzelne Mailbox war lokal. Ihre Bretter, privaten Nachrichten und Dateien lebten zunächst nur auf diesem einen Rechner. Ein Mailbox-Netz entstand dort, wo mehrere Systeme begannen, Nachrichten untereinander auszutauschen. Aus lokaler Kommunikation wurde verteilte Kommunikation. Die Nutzer bemerkten das oft nur daran, dass plötzlich Beiträge aus anderen Städten oder Ländern auftauchten. Technisch bedeutete es jedoch eine ganz andere Größenordnung.

Statt dass ein Benutzer ständig online sein musste, sammelte das System Nachrichten zunächst lokal. Zu festgelegten Zeiten wurden diese Datenpakete an andere Systeme übertragen – meist nachts, wenn Telefonkosten geringer waren oder die Leitungen der Box nicht für Benutzer blockiert werden sollten. Genau deshalb waren diese Netze asynchron. Eine Nachricht ging nicht sofort durch, sondern wanderte Schritt für Schritt von System zu System.

Das Netz bestand also nicht aus einer dauernden Online-Verbindung, sondern aus vielen kurzen, geplanten Transfers. Genau diese Logik machte Mailbox-Netze technisch interessant. Sie zwangen zu Struktur, zu Routing und zu Disziplin. Jede Verbindung kostete Zeit und Geld. Jede unnötige Übertragung war spürbar. Und jede Fehlerquelle – falsche Nummer, veralteter Knoten, schlechtes Timing – fiel unmittelbar auf.

„Eine Mailbox war ein Ort. Ein Mailbox-Netz war eine Transportlogik.“

FidoNet als prägender Standardfall

FidoNet wurde zum bekanntesten Mailbox-Netz, weil es aus der einzelnen BBS-Logik ein erstaunlich belastbares, verteiltes Nachrichtensystem machte. Der Grundgedanke war schlicht: Mail und Konferenzbeiträge werden zwischen Knoten weitergereicht. Aber aus dieser Schlichtheit entstand eine komplette Infrastruktur mit Adressierung, Knotenlisten, Standarddokumenten, Übertragungsprotokollen und Verwaltungsstruktur.

Technisch ist daran vor allem interessant, dass FidoNet nicht als luxuriöse Online-Welt gedacht war. Es war ein Netz für reale Wählleitungen. Damit stand von Anfang an nicht Komfort im Vordergrund, sondern Kostenbewusstsein, Routing und strukturierte Übertragung. Es war normal, dass Nachrichten spät nachts wanderten, dass einzelne Transfers gebündelt wurden und dass ein Ziel nicht direkt, sondern über Hubs oder Hosts erreicht wurde.

Gerade deshalb war FidoNet mehr als eine Sammlung von Mailboxen. Es war ein Netz mit eigenem Regelwerk, eigener Topologie und dem Anspruch, Interoperabilität zwischen sehr unterschiedlicher Software überhaupt erst herzustellen.

Adressierung: Zone, Net, Node, Point

Einer der prägnantesten Teile von FidoNet war die Adressform. Ein Knoten wurde typischerweise als Zone:Net/Node geschrieben, bei Power-Usern oder privaten Endsystemen erweitert zu Zone:Net/Node.Point. Das wirkte zunächst kryptisch, war aber hoch funktional: Die Adresse transportierte bereits einen guten Teil der Netzstruktur.

Ein Point war besonders interessant, weil er zeigte, dass das Netz nicht nur aus öffentlich erreichbaren Mailboxen bestand. Wer technisch versiert war, konnte sich als Point an einen Hostknoten hängen, Mail austauschen und Echomail lokal offline lesen oder schreiben. Das sparte Leitungszeit und reduzierte Kosten. Gleichzeitig war ein Point eben kein vollwertiger öffentlicher Knoten im Nodelist-Sinn.

„Die Adresse war nicht nur Kennung. Sie war bereits ein Stück Routingdenken.“

Nodes, Hubs, Hosts und Routing

FidoNet lebte nicht davon, dass jede Mailbox jede andere direkt anrief. Das wäre unter realen Telefonkosten und bei wachsender Knotenzahl schnell unerfreulich geworden. Deshalb bildete sich eine Hierarchie aus Nodes, lokalen Hubs, Hosts und größeren Routingpunkten. Genau dadurch wurde aus vielen Einzelverbindungen eine ökonomisch tragfähigere Struktur.

Innerhalb eines lokalen Netzes konnten Knoten häufig direkt miteinander tauschen, besonders wenn lokale Gespräche günstig oder kostenlos waren. Für überregionale Ziele war das anders. Dort wurden Nachrichten oft zunächst zu einem Hub oder Host gesammelt, der sie gebündelt weiterreichte. Das sparte Verbindungsaufbau, Leitungszeit und Gebühren.

Diese Topologie war keine Schönheitsfrage, sondern ein direktes Ergebnis der Kostenstruktur von Telefonnetzen. Das Netz war dort stark, wo es nicht jede Verbindung naiv einzeln behandelte, sondern Verkehr zusammenzog und erst dann weiterleitete.

Nodelist, Nodediff und Aktualität

Ohne aktuelle Knotendaten konnte ein Fido-Netz nicht vernünftig arbeiten. Genau deshalb war die Nodelist so zentral. Sie enthielt die bekannten aktiven öffentlichen Knoten, ihre Adressen, Rufnummern und weitere Betriebsinformationen. In FidoNet war diese Liste keine dekorative Übersicht, sondern operative Grundlage.

Besonders wichtig war dabei, dass die Nodelist regelmäßig aktualisiert und verteilt wurde. Statt jede Woche eine komplette Welt neu zu übertragen, arbeiteten viele Systeme mit Differenzdateien – also Nodediffs –, die die Änderungen zur Vorwoche beschrieben. Das war technisch nüchtern und bandbreitenschonend.

Wer mit veralteten Knotendaten arbeitete, bekam die Folgen unmittelbar zu spüren: Fehlanrufe, besetzte oder tote Nummern, nicht erreichbare Ziele, unnötige Gebühren und störendes Nachfassen. Genau deshalb war Aktualität hier nicht Komfort, sondern Voraussetzung für ein funktionierendes Netz.

Netmail, Echomail und Fileecho

In der Praxis war nicht jede Nachricht gleich. FidoNet unterschied verschiedene Verkehrsarten, und genau diese Trennung war wichtig, um das Netz verständlich zu halten.

Netmail war im Grunde die private Nachrichtenschicht des Netzes. Sie musste an ein konkretes Ziel gelangen. Routing, Priorität und Zustellbarkeit waren hier besonders wichtig. Echomail dagegen war die öffentliche Konferenzebene. Ein Beitrag in einem Echo wurde über definierte Verteilwege an alle teilnehmenden Knoten weitergegeben. So entstanden verteilte Diskussionsräume, die nicht an einer einzelnen Mailbox hingen.

Genau hier zeigte sich die Doppelrolle solcher Netze: einerseits persönliche Kommunikation, andererseits öffentliche Foren. Im einen Fall zählte zielgenaue Zustellung. Im anderen die verlässliche Replikation an viele Stellen.

„Netmail ging an jemanden. Echomail ging in einen Raum.“

BBS, Mailer, Tosser, Packer

Technisch bestand eine Fido-kompatible Umgebung selten aus nur einem einzigen großen Programm. Typisch war vielmehr eine Aufgabenteilung: Die Mailbox-Software bediente die Nutzer. Ein Frontend-Mailer führte die eigentlichen Verbindungen durch. Ein Tosser oder Mailprozessor entpackte eingehende Pakete, verteilte Inhalte in die richtigen Bereiche und bereitete ausgehende Daten für den nächsten Transfer vor. Häufig kamen noch Packer, Scanner, Editoren und Reader hinzu.

Diese Aufgabenteilung ist wichtig, weil sie zeigt, dass Mailbox-Netze nicht einfach „BBS plus Modem“ waren. Sie bestanden aus einer kleinen Werkzeugkette. Und genau diese Werkzeugkette machte das System beherrschbar: jedes Teil hatte eine klarere Aufgabe, statt alles in einem unübersichtlichen Monolithen zu verstecken.

NetCalls, Mail Hours und Telefonkosten

Die eigentliche physische Realität solcher Netze war das Telefon. Jede überregionale Verbindung musste gewählt werden. Jeder Verbindungsaufbau kostete. Jede Minute konnte relevant sein. Genau deshalb wurden Transfers oft in die Nacht gelegt. Dort waren Tarife günstiger, die Mailbox musste keine Benutzer bedienen, und der Verkehr ließ sich planbarer abarbeiten.

In FidoNet spielte dabei die Mail Hour beziehungsweise Zone Mail Hour eine wichtige Rolle. Bestimmte Zeitfenster mussten für Netzübergaben reserviert oder zumindest berücksichtigt werden. Auch außerhalb solcher Stunden liefen Transfers, aber der Grundgedanke blieb: Netzverkehr war zeitlich geplant, nicht dauernd beliebig.

Points und Offline-Arbeit

Ein besonders wichtiger Fortschritt für technisch versierte Nutzer war die Point-Logik. Statt sich lange interaktiv in eine öffentliche Mailbox einzuwählen, konnte ein Point-Nutzer Mail und Konferenzbeiträge gebündelt mit einem Host austauschen, lokal lesen, beantworten und erst später wieder gesammelt zurücksenden. Das sparte Leitungszeit und machte größere Diskussionsmengen überhaupt erst praktikabel.

Gerade bei wachsender Echomail war das entscheidend. Wer sich durch viele Konferenzen arbeitete, wollte nicht Minute um Minute am Online-Tarif vergeuden. Offline-Reader, Reply-Pakete und gebündelte Zustellung passten deshalb perfekt zur technischen und ökonomischen Realität der Zeit.

Ein Point war damit keine vollwertige öffentliche Box, sondern eher ein privater Endpunkt mit Netzanschluss über einen Hostknoten. Genau diese Zwischenstellung machte ihn so nützlich.

Andere Mailbox-Netze im deutschsprachigen Raum

FidoNet war wichtig, aber nicht allein. Gerade im deutschsprachigen Raum existierten weitere Mailbox-Netze mit eigener kultureller und technischer Handschrift. Dazu gehörten Netze, die stärker auf bestimmte Softwarefamilien, auf eigene Routingverfahren oder auf andere soziale Leitbilder setzten.

Neben Fido-typischen FTN-Strukturen waren besonders Netze interessant, die eigene Formate, eigene Verteilverfahren oder engere regionale Kultur mitbrachten. Manche verstanden sich stärker als Gegenöffentlichkeit, manche arbeiteten mit Realnamenpflicht, manche setzten auf alternative Routing- und Austauschlogiken. Technisch blieb jedoch die Grundidee ähnlich: Mailboxen tauschten Nachrichten gesammelt und asynchron aus, meist über nächtliche NetCalls oder fest geplante Verbindungsfenster.

• FidoNet-orientierte Netze: eher international, stark standardisiert, breit kompatibel.
• deutschsprachige Spezialnetze: stärker regional oder kulturell geprägt, teils mit eigener Software und eigenen Austauschverfahren.
• Gateways: wichtige Brücken zwischen Mailbox-Netzen, Usenet und später Internet-Mail.

Wer damals tiefer in die Materie einstieg, lernte deshalb schnell: „Mailbox-Netz“ ist kein einzelner Markenname, sondern ein ganzer Lösungsraum. Verschiedene Netze verfolgten denselben Grundgedanken mit unterschiedlicher Software, anderer Kultur und eigener technischer Disziplin.

Verhältnis zu Usenet, Shell-Accounts und Web

Mailbox-Netze standen nicht isoliert da. Sie lagen historisch zwischen mehreren Welten. Gegenüber der einzelnen BBS waren sie bereits verteilte Netze. Gegenüber Usenet blieben sie oft stärker mailbox- und sysop-geprägt. Gegenüber Shell-Accounts waren sie lokaler, telefonischer und direkter von Wählleitungen abhängig. Gegenüber dem Web wirkten sie später wie eine frühere, textnähere Stufe verteilter Kommunikation.

Viele technische Übergänge liefen über Gateways. Echomail-Konferenzen konnten mit Newsgroups gekoppelt werden. Netmail konnte in Internet-Mail übersetzt werden. Shell-Accounts öffneten später Räume, in denen Reader, News, Mail und schließlich Webserver näher zusammenrückten. Genau dort zeigt sich die Kontinuität: Die Werkzeuge wechselten, aber die Grundbegriffe – Adressierung, Transport, Routing, Zustellbarkeit, Textdisziplin – blieben.

Die Modem- und Telefonebene darunter beschreibt modems-und-dataphon.htm. Die lokale Mailbox-Praxis steht auf mailboxen-bbs.htm. Die News-Schicht darüber beschreibt usenet-und-newsgruppen.htm. Die spätere Host- und Shell-Ebene folgt auf shell-accounts-und-hosts.htm.

Was technisch daran stark war

Die eigentliche Stärke von Fido- und Mailbox-Netzen lag nicht in Geschwindigkeit oder Komfort. Beides war aus heutiger Sicht begrenzt. Stark war vielmehr, dass diese Netze mit sehr einfachen Mitteln eine belastbare Kommunikationsstruktur aufbauten: Adressierung, Routing, Knotenlisten, Paketlogik, Offline-Arbeit und klare Trennung zwischen Transport und Nutzung.

Gerade weil Telefonzeit knapp und Leitungsqualität unzuverlässig waren, mussten diese Netze diszipliniert sein. Nichts davon war überflüssiger Luxus. Die Struktur war direkt aus der Realität der Technik geboren. Und genau das macht sie bis heute interessant: Sie zeigen, wie weit man mit klarem Denken, gut getrennten Funktionen und nüchterner Netzlogik kommen kann.

„Die Mailbox war lokal. Das Denken dahinter war es längst nicht mehr.“