@database "CLFido.guide" @author "Jörg Deckert" @remark "$VER: CLFido Guide 5.1ß1 (05. März 1999)" @remark "Created with GoldED 4.7.0 (13.5.97)" @index INDEX @node MAIN "Inhalt" @{b}@{u}CLFido@{uu}@{ub} Connectline Fido Mailer/Tosser © 1986-96 by Oliver Wagner und Mathias Mischler © 1998-99 by Jörg Deckert -------------------------------------------------------------------------- @{"Einführung " link EINFUEHRUNG} - Erste Worte zu CLFido @{"Rechtliches " link RECHTLICHES} - Auch das unbedingt lesen! @{"Features " link FEATURES} - Was kann CLFido? @{"Einschränkungen" link EINSCHRAENKUNGEN} - Was geht noch nicht? @{"Installation " link INSTALLATION} - Was gehört dazu? @{"Konfiguration " link KONFIGURATION} - Was kann man alles einstellen? @{"Benutzung " link BENUTZUNG} - Wie funktioniert das? @{"ToDo " link TODO} - Was gibt es noch zu tun? @{"History " link HISTORY} - Was wurde bereits getan? @{"Author " link AUTHOR} - Von wem stammt das alles? @endnode @node RECHTLICHES "Rechtliches" @{b}@{u}Rechtliches@{uu}@{ub} CLFido ist Teil des Connectline-Paketes und darf nur mit Connectline zusam- men zu den in der Connectline-Dokumentation angegebenen Bedingungen einge- setzt werden. Für Connectline-Benutzer im dortigen Sinne ist das vorliegende CLFido also ohne zusätzliche Kosten einsetzbar. Im übrigen wird von mir keinerlei Garantie weder für die ordnungsgemäße Funktion des Programmes noch für sonst irgendetwas übernommen. @endnode @node FEATURES "Features" @{b}@{u}Features@{uu}@{ub} Mit CLFido ist Connectline nun als vollwertiges Fido-System einsetzbar, wo- bei es sogar als Hub verwendbar ist (jedenfalls läuft es bei mir als sol- cher). CLFido verarbeitet die üblichen Packet-Formate und beherrscht Connects zu den meisten anderen eingesetzten Fido-Mailern. Weiterhin gatet CLFido nun gatebau-konform nach ZConnect. Allerdings werden nicht alle Header beibehalten, sondern nur die zur Funktion wichtigen umge- setzt. Deswegen und da das ganze noch völlig ungetestet ist, warne ich davor, Connectline als öffentliches Gateway einzusetzen. Als Gateway für direkt angeschlossene Systeme, bei denen gewährleistet ist, daß nicht über andere Gateways wieder zurückgegatet wird, sollte Connectline aber keine Probleme bereiten. @endnode @node EINSCHRAENKUNGEN "Einschränkungen" @{b}@{u}Einschränkungen@{uu}@{ub} - Das Hydra-Protokoll arbeitet noch nicht korrekt Sollten manche Systeme beim Pollen per Hydra Probleme haben, sollten diese Hydra disablen. Sobald ich Zeit dazu habe, überarbeite ich das Hydra-Protokoll. - Der Mailer beherrscht @{u}nur@{uu} das EMSI-Handshake. Fido-Nodes müssen zwar auch FTS-1 beherrschen, in meiner langen Zeit als Fido-Node hat allerdings noch nie jemand mit FTS-1 Handshake gepollt. Ich denke also nicht, daß irgendwelche Beschwerden deswegen kommen. - Zwischen den verschiedenen Flowfile-Typen (Hold, Normal, Crash...) wird nicht unterschieden, bei jedem Poll wird alles verschickt. @endnode @node KONFIGURATION "Konfiguration" @{b}@{u}Konfiguration@{uu}@{ub} @{"Sortin " link SORTIN} - Wichtige Änderung! @{"Fido " link FIDOKONFIG} - Fido-Netzkonfiguration @{"Systeme " link SYSTEME} - Hinterlegen der Fido-Systeme @{"Routing " link ROUTING} - Wo gehen die Mails hin? @{"Areafix " link AFIXCONFIG} - Auto-Forward u.a. @endnode @node SORTIN "Sortin-Konfiguration" @{b}@{u}Sortin-Konfiguration@{uu}@{ub} In den Sortin-Prefs muß auf der letzten Seite (Sonstiges) das Erzeugen der Gateway-Zeile unbedingt ausgeschaltet werden, da diese fehlerhaft ist. Grund ist, daß in den aktuellen Sortin-Prefs (Version 1.12 vom 13.1.98) nach den Änderungen von Ralf Ramge Müll in das Feld der nun eigentlich nicht mehr vorhandenen GateID geschrieben wird. Dieses Feld wird vom Sortin (besser: von den cl_mail_xxx-libraries) aber beim Erzeugen der Gateway- Zeile immer noch gelesen, wenn der Meta-Header "__SOURCEFMT:" genutzt wird. Die UUCP-Teile erzeugen diesen nun auch nicht mehr, ich halte ihn aber zur korrekten Funktion für erforderlich. Das erfordert Änderungen in mehreren CL-Programmteilen. Nachtrag: Obwohl ich nun alle Sourcen habe, sind die erforderlichen Änderungen noch nicht durchgeführt. Das passiert erst in der nächsten Version. @endnode @node FIDOKONFIG "Fido-Netzkonfiguration" @{b}@{u}Fido-Netzkonfiguration@{uu}@{ub} Am Fido-Konfigurationsprogramm (FidoPrefs) wurden keine Änderungen vor- genommen. Teilweise haben die einzelnen Punkte aber eine neue Bedeutung. Es gibt die folgenden 3 Seiten: @{"Pfade " link PFADE} - Pfade für ein- und ausgehende Daten @{"Nodenummern" link NODENUMMERN} - die eigenen Adressen in verschiedenen Netzen @{"Filerequest" link FILEREQUEST} - Konfiguration der Magics @{"Sonstiges " link SONSTIGES} - Standard-Origin @endnode @node PFADE "Fido-Konfiguration: Pfade" @{b}@{u}Pfade@{uu}@{ub} Pfad für ausgehende Daten: Hier legt der Tosser Packets, Bundles und Flow- Files zur Abholung durch die angeschlossenen Fido-Systeme bereit. Beispiel: Connectline:Data/Fido/Outbound Pfad für eingehende Daten: Der Mailer speichert eingehende Fido-Mails und -Files hier ab. Diese werden dann von CLToss weiterbearbeitet. Beispiel: Connectline:Data/Fido/Inbound @endnode @node NODENUMMERN "Fido-Konfiguration: Nodenummern" @{b}@{u}Nodenummern@{uu}@{ub} Hier wird die Zugehörigkeit des eigenen Systems zu den verschiedenen Fido- kompatiblen Netzen definiert. Durch Klicken auf das Gadget "Neu" wird ein neuer Eintrag hinzugefügt. Die einzelnen Stringgadgets haben folgende Bedeutung: NetzID: Dient zur einfachen Unterscheidung der verschiedenen Netze. Hier ist aber eine wichtige Funktion dazugekommen: Werden neue Bretter/Areas automatisch eingetragen, so wird dem ZConnect- Brettnamen die NetzID vorangestellt. Lautet die NetzID für das Fidonet z.B "FIDONET", so wird aus der Area "AMIGA.GER" das Brett "FIDONET/AMIGA.GER". Somit wird automatisch eine gewisse Übersichtlichkeit erreicht. Zone: Hier gibt man an, welche Zonen zum betreffenden Netz gehören. Also fürs Fidonet z.B. "1-6" und fürs Amiganet "39-41". Nodenummer: Die eigene Fido-Adresse für diese Netz. Hat man in einem Netz mehrere Adressen (AKAs), sind weitere, bis auf die Nodenummer identische Einträge anzulegen. Dabei ist die Reihenfolge wich- tig: Der oberste Eintrag bestimmt die Adresse, die in Mails und Packets als Absender eingetragen wird. Pointnet: Die Pointnet-Adresse. Im Normalfall immer 0:0/0.0 Brettmaske: Hier wird die Zuordnung der einzelnen Bretter zu den verschie- denen Fido-AKAs des eigenen Systems vorgenommen. Alle Bretter, auf welche diese Maske paßt, gehören zu diesem Netz mit der soeben angegebenen NetId und Nodenummer. Mails, die aus Connectline oder von Nicht-Fido-Systemen in diese Bretter geschrieben werden, haben als Absender die unter "Nodenummer" eingetragene Adresse. Wenn alle Bretter, wie unter "NetzID" beschrieben, automatisch angelegt werden, kann man hier in der Regel "/*" eintragen, also z.B. "FIDONET/*". Will man alle UUCP/ZConnect-Bretter gegatet unter dem Fido- Netz mit anbieten, muß die Maske auf alle Bretter außer auf Bretter von anderen Fido-kompatiblen Netzen passen. Also z.B. "~((AMIGANET|CHESSNET)/#?)". Domain: Die hier angegebene Domain erhalten alle Mails aus diesem Netz, die nicht von einem direkt angeschlossenen Fido-System (oder dessen Points) stammen. Damit können anhand der Domain auch Mails verschiedener Fido-kompatibler Netze, die von ein und demselben Uplink stammen, unterschieden werden. Origin: Dieses Origin wird unter alle Echomails aus diesem Netz ge- schrieben, die noch kein Origin enthalten, also unter direkt in Connectline geschriebene Mails oder unter gegatete Mails. Mit dem untersten Gadget kann unterschieden werden, wie Binärmails versen- det werden: Als File-Attach oder UU-codiert. Für die meisten Fido-kompatib- len Netze werden File-Attaches verwendet. Diese dürfen jedoch meist nicht geroutet werden, funktioniert also nur für direkt angeschlossene Systeme. Alternative wäre dann die UU-Codierung, das ist in Fido aber teilweise nicht gern gesehen. Z.Z. wird von CLFido aber weder File-Attach noch UU- Codierung unterstützt. @endnode @node FILEREQUEST "Filerequest" @{b}@{u}Fido-Filerequests@{uu}@{ub} Connectline unterstützt sogenannte WaZOO-Filerequests nach FTS0006. Update- Requests sind auch möglich (Nodelisten-Flag XX). Wie das funktioniert, steht unter @{"Benutzung" link USEFREQ}. Dabei sind auch sogenannte "Magics" möglich, diese werden auf der Seite "Filerequest" konfiguriert. Durch Betätigen von "Neu" wird ein neuer Eintrag angelegt. Dabei werden folgende Punkte abgefragt: Name: Der Name des Magics, wie der vom anfordernden System im Request- File aufgeführt werden muß. Typ: Zwei Typen sind derzeit möglich: "Sende File" schickt die unten unter "File" angegebene Datei. "Kommando" führt die unter "File" angegebene Datei aus. Deren Standardausgabe wird in eine Datei umgeleitet, welche dann gesendet wird. Priorität: Das anfordernde System muß mindestens diese Priorität besitzen. Paßwort: Nur bei Angabe dieses Paßwortes wird das Magic gesendet. File: Die entsprechende Datei (s. "Typ"). Beim Typ "Sende File" ist auch die Angabe eines Standard-AmigaDOS-Patterns möglich. In diesem Fall wird die neueste aller auf das Pattern passenden Dateien gesendet. @endnode @node SONSTIGES "Fido-Konfiguration: Sonstiges" @{b}@{u}Sonstiges@{uu}@{ub} Bei allen Netzen, für die auf der vorangegangenen Seite (Nodenummern) kein Origin eingetragen wurde, wird das hier eingetragene verwendet. @endnode @node SYSTEME "Systeme" @{b}@{u}Systeme@{uu}@{ub} Die Konfiguration von Fido-Systemen in den System-Prefs unterscheidet sich nicht wesentlich von der für andere Netze. Deswegen wird hier nur auf die Unterschiede eingegangen. Wie bei anderen Netzen solle auch jedes Fido-System nur einmal eingetragen werden, auch wenn es verschiedenen Fido-Netzen angehört. Auf der 1. Seite (Allgemein) wird ganz normal ein Name und die Domain einge- tragen. Die verwendete Domain ist prinzipiell bei reinen Fido-Systemen egal, gatet das System jedoch in andere Netze, ist dies (natürlich) die Absender- Domain. Genauere Erläuterungen dazu gibts unter @{"Routing" link Routing}. Handelt es sich um einen Fido-Point, wird dieser Punkt angehakt und der zugehörige User einge- tragen. Im Unterschied zu allen anderen Fido-Systemen muß also jeder Fido- Point auch als Online-User eingetragen sein. Das hat für ihn den Vorteil, daß er seine (Net-)Mails notfalls auch online lesen kann. Auf der Routing-Seite wird Patalias-/Domainrouting nicht angehakt, bei "Routing an:" wird üblicherweise das gerade zu konfigurierende System selbst eingetragen. "Routemails" und "Eilmails" sollte angehakt werden, alle Kosten bleiben bei 0. Unter "Batch/Packen" wird der verwendete Packer eingetragen. Achtung: Der Entpacker für eingehende Daten wird also nicht (wie bei anderen Fido-Programmen) automatisch erkannt! Prearc wird im Fido immer genutzt, als Batchgröße kann 0 eingetragen werden. Die Seite "Datenaustausch": Das Protokoll ist egal, da der Mailer je nach Gegenstelle automatisch das beste Protokoll wählt. Genutzt werden nur die internen Protokolle Hydra und ZModem (8k und 1k). Bei "Paßwort" können 2 Paßwörter eingetragen werden (durch 1 Leerzeichen getrennt). Das erste ist das Session-Paßwort für den Mailer, das 2. das Packet-Paßwort. Fehlt letzteres, wird einfach keins verwendet. Unter "Telefon" wird die Fido- Adresse des Systems eingetragen, daraus wird mittels Nodelist die Telefon- Nummer ermittelt. Vorraussetzung ist die traplist.library aus den TrapDoor- Paket mit installierter Nodelist. Ansonsten kann man hier auch normal die Telefonnummer eintragen. In beiden Fällen sind mehrere, durch "|" getrennte Einträge möglich. Der Backup-Schalter wird (noch) nicht ausgewertet, alles andere wird wie üblich eingestellt. Auf den Seiten "Zugriffsrechte" und "Bretter" gibt es keinerlei Fido- spezifische Eintragungen. Auf der letzten Seite (Netzspezifische Parameter) genügt es vorerst, lediglich die Fido-Adressen (AKAs) des Systems (getrennt durch Leerzeichen) einzutragen, andere Parameter haben keine Bedeutung. Die Haupt-AKA sollte auch als erste aufgeführt sein, da diese als Empfängeradresse für Mails an dieses System aus nichtfido-Netzen genutzt wird (s. @{"Routing" link Routing}). @endnode @node ROUTING "Routing" @{b}@{u}Routing@{uu}@{ub} Wohl am kompliziertesten ist die Konfiguration des korrekten Routings. Deswegen soll dies hier ausführlich am Beispiel beschrieben werden. Die Konfiguration wird mit dem normalen Routeeditor von Connectline vorgenommen. Das erleichtert die Sache für eingefleischte ZC-Freaks und ist für angestammte Fidoianer (wie mich) gewöhnungsbefürftig. Am wichtigsten ist es, zu verstehen, wie die @{"Umwandlung" link ADRESSWANDLUNG} zwischen Fido- Adressen und rfc-Adressen erfolgt. Denn die gesamte Routin-Konfigu- ration bezieht sich auf ZConnect-Adressen. Allgemein gibt man bei der Routing-Konfiguration an, wohin private Mails (Netmails) an nicht direkt angeschlossene Systeme geschickt werden. Die Verteilung öffentlicher Mails (Echomail) wird davon nicht beeinflußt. Der Route-Editor von CL ist in 2 Hälften geteilt. Auf der linken Seite werden die Absender-Domains konfiguriert, für jede mögliche Absender- Adresse muß es dort einen Eintrag geben. Dadurch kann man abhängig von der Absenderadresse verschiedene empfängerabhängige Routings konfigu- rieren, was dann auf der rechten Seite geschieht. In den meisten Fällen wird ein Eintrag mit der Domain "*" genügen, damit geschieht das Routing unabhängig von der Absenderadresse. Zuerst sollten mit dem Gadget "Domainnamen editieren" auf der linken Seite sinnvolle Namen für die verschiedenen Absender-Domains eingegeben werden. Diese sind frei wählbar, sie dienen nur zur einfachen Unter- scheidung. Wird nur eine Absender-Domain verwendet, muß auch nur bei "Domain 1" etwas eingetragen werden (z.B. "alles"). Anschließend muß der Route-Editor beendet und neu aufgerufen werden. Als nächstes wird auf der rechten Seite die zu konfigurierende Absender- Domain ausgewählt. Als erstes wird der Smarthost eingetragen, das ist das System, an welches alle Mails mit nicht näher spezifizierten Empfänger- adressen geroutet werden. Als Beispiel gehen wir davon aus, das nur ein Uplink für "Internet"-email (also alle "richtigen" rfc/Zconnect-Adressen) existiert. Dieser ist dann der Smarthost und bekommt somit vorherst alle Mails an Nicht-Downlinks. Als Beispiel soll weiterhin angenommen werden, daß noch je ein Uplink für Fido-Netz und Amiganet (auch ein Fido-basierendes Netz) existiert. Die Adressen dafür sehen nach Wandlung so aus: p<@{FG shine}Point@{FG text}>.f<@{FG shine}Node@{FG text}>.n<@{FG shine}Net@{FG text}>.z<@{FG shine}Zone@{FG text}>.@{FG shine}do@{FG text}.@{FG shine}main@{FG text} do.main ist dabei immer gleich der Domain des Mailabsenders (also des Down- links). Können Downlinks mit verschiedenen Domains in diese Netze schreiben, treten diese verschiedenen Domains auch als Empfänger-Domains auf. Die Zone kann im Fidonet Werte von 1-6 besitzen, im Amiganet gibt es die Zonen 39, 40 und 41. Net, Node und Point können beliebige Zahlen sein. Für jede Kombina- tion aus Absender-Domain und Zone muß nun mit dem Gadget "Neu" ein Eintrag erzeugt werden. Im Beispiel sollen Downlinks mit der Domain "gera.thur.de" in beide Netze schreiben können, Downlinks mit "fido.net" nur ins Fidonet und Downlinks mit "amiga.net" ins Amiganet. Fido-Uplink ist das System "ha", für das Amiganet "amistep". Dann müssen im Listview auf der rechten Seite folgende Einträge stehen: z1.fido.net -> ha z1.gera.thur.de -> ha z2.fido.net -> ha z2.gera.thur.de -> ha z3.fido.net -> ha z3.gera.thur.de -> ha z39.amiga.net -> amistep z39.gera.thur.de -> amistep z4.fido.net -> ha z4.gera.thur.de -> ha z40.amiga.net -> amistep z40.gera.thur.de -> amistep z41.amiga.net -> amistep z41.gera.thur.de -> amistep z5.fido.net -> ha z5.gera.thur.de -> ha z6.fido.net -> ha z6.gera.thur.de -> ha Wesentlich einfacher ist es natürlich, wenn nur Downlinks mit einer bestimm- ten Domain in jeweils ein fidokompatibles Netz schreiben können. Dann genü- gen hier 2 Einträge. Es kann aber auch noch wesentlich komplizierter werden. Im obigen Beispiel mit nur einem Eintrag für alle Absender-Domains kann jeder Mails in jedes Netz schreiben. Um das zu verhindern, müssen mehrere Absender-Domains einge- tragen werden und für jede (meist ohne Smarthost) zulässigen die Empfänger- Domains angegeben werden. Weiterhin können Mails vom Uplink (oder sogar mehrerer Uplinks) verschiedene Domains haben haben. Von Uplink selbst stammende Mails haben immer dessen Domain (wie in den System-Prefs eingetragen). Mails anderer Systeme (die der Uplink nur durchroutet) haben die in den Fido-Prefs unter @{"Nodenummern" link NODENUMMERN} einge- stellte Domain. Der Einfachheit wegen sollten Uplinks, von denen nur eine Domain bezogen wird, nir gleiche Domain erhalten wie die in den Fido-Prefs für das netz eingestellte. Wie oben schon erwähnt, ist dies eine sehr komplexe Angelegenheit. Es sollte in jedem Fall ausgiebig Gebrauch vom Routetest gemacht werden. @endnode @node ADRESSWANDLUNG "Adreßwandlung" @{b}@{u}Adreßwandlung@{uu}@{ub} Da Connectline alle Mails im ZConnect-Format verarbeitet und speichert, muß die gesamte Fido-Mail nach ZConnect konvertiert werden. Auch Mails, die über Connectline von einem Fido-System an ein anderes geschickt werden, durchlaufen die Wandlung Fido -> ZConnect -> Fido. @{"Fido -> ZConnect" link FIDO2ZCONNECT} - ankommende Fido-Mail @{"ZConnect -> Fido " link ZCONNECT2FIDO} - abgehende Fido-Mail @endnode @node FIDO2ZCONNECT "Adreßwandlung Fido -> ZConnect" @{b}@{u}Fido -> ZConnect@{uu}@{ub} Die @{b}Adressen@{ub} ankommender Fido-Mails werden wie folgt nach ZConnect gewandelt (gilt gleichermaßen für Absender- und Empfängeradressen): 1. Handelt es sich um die Adresse eines direkt angeschlossenen Systems, wird dessen ZConnect-Adresse verwendet, wie im System-Editor konfigu- riert. 2. Ist es die Adresse eines Points von einer eingetragenen Fido-Box, ergibt sich folg. ZC-Adresse: p.boxname.do.main D.h., aus der Fido-Adresse 2:248/4002.15 wird p15.beg.fido.net, wenn die Fido-Box 2:248/4002 als "beg" mit der Domain "fido.net" im System- Editor hinterlegt ist. 3. Handelt es sich um die Adresse eines nicht direkt angeschlossenen Systems, erfolgt die Adreß-Bildung nach folg. Schema: p.f.n.z.do.main Dabei wird als "do.main" für Absenderadressen die die in den Fido-Prefs unter @{"Nodenummern" link NODENUMMERN} für das entsprechende Netz eingestellte Domain ver- wendet. Empfängeradressen erhalten die Domain des Systems, von welchem die Mail geliefert wurde. In späteren Versionen soll dies noch einfacher werden. Trifft also beispielsweise vom System ha.fido.net (2:248/2004) eine Mail von 2:2476/1001.12 ein, die an 2:248/4002.2 gerichtet ist, wird aus der Absenderadresse "p12.f1001.n2476.z2.fido.org". Die Empfänger-Adresse lautet "p2.beg.fido.net". ha und beg haben die Domain fido.net, in den Fido-Prefs wurde Für das Fidonet die Domain fido.org eingetragen (sinn- vollerweise sollte man dort aber auch z.B. fido.net verwenden). Schwieriger: Point2 (ein Fido-Point) des eigenen Systems schreibt eine Mail an 2:2476/1001.12. Da der Point auch eMail aus dem Internet be- kommt, ist er unter der offiziellen Internet-Domain des eigenen Systems (bitquell.gera.thur.de) eingetragen, also z.B. Point2.gera.thur.de. Die rfc-Adresse des Empfängers heißt demnach "p12.f1001.n2476.z2.gera.thur.de" Die Umwandlung der @{b}Namen@{ub} ankommender Fido-Mails funktioniert nach folgen- dem Schema: 1. Kommt die Mail von einem Point des eigenen Systems, wird dessen Fido- Name (Vorname Nachname) durch seinen Usernamen (Alias) ersetzt. 2. Bei Mails nach ZConnect/rfc wird der Fido-Empfängername zur Adressie- rung benutzt. Wie das genau geschieht, steht unter @{"Gateway" link GATEWAY}. 3. In allen anderen Fällen wird der Fido-Name (in der Regel also der Realname) verwendet, dabei werden alle Leerzeichen durch ein @{FG shine}_@{FG text} ersetzt. @endnode @node ZCONNECT2Fido "Adreßwandlung ZConnect -> Fido" @{b}@{u}ZConnect -> Fido@{uu}@{ub} Die @{b}Adressen@{ub} abgehender Fido-Mails werden wie folgt nach gewandelt (gilt gleichermaßen für Absender- und Empfängeradressen): 1. Mails an direkt angeschlossene Fido-Systeme erhalten die in den System- Prefs (Netzspezifische Parameter) eingestellte Fido-Adresse. Eine Mail an beg.fido.net bekommt also die Empfängeradresse 2:248/4002, wenn die beg als Box in den System-Prefs mit dieser Fido-Adresse hinterlegt ist. Das gilt auch für Points, diese erhalten ihre Mail im PM und an ihren Point mit der entsprechenden Fido-Adresse. 2. Mails an Points direkt angeschlossener Fido-Boxen haben auf ZConnect- Ebene die Form p.boxname.do.main ( s. @{"Fido -> ZConnect" link FIDO2ZCONNECT}). Als Fido-Adresse wird die der eingetragenen Box "boxname.do.main" ge- nommen, aber natürlich nit der . Entsprechend dem Beispiel aus 1. wird also aus p15.beg.fido.net 2:248/4002.15. 3. Entsprechend Punkt 3 bei @{"Fido -> ZConnect" link FIDO2ZCONNECT} gewandelte Fido-Adressen wer- den analog zurückgewandelt. Aus einer ZConnect-Adresse p12.f1001.n2476.z2.fido.net wird also die Fido-Adresse 2:2476/1001.12. Die Domain wird ignoriert. 4. Alle Mails mit ZConnect-Adressen, welche nicht nach den Punkten 1 bis 3 umzuwandeln sind, erhalten eine Fido-Adresse des eigenen Systems, da dieses dann als @{"Gateway" link GATEWAY} fungiert. Mails in Brettern/Echos erhalten die passende Adresse entsprechend der Brettmaske in den @{"Fido-Prefs" link FIDOKONFIG} unter @{"Nodenummern" link NODENUMMERN}. Die Umwandlung der @{b}Namen@{ub} abgehender Fido-Mails funktioniert nach folgen- dem Schema: 1. Enthält die Adresse den Realnamen, wird dieser, wie im Fidonet üblich, verwendet (maximale Länge auf 35 Zeichen beschnitten). 2. Ansonsten wird der Alias (also der Adreß-Teil vor dem @) als Fido-Name verwendet. Achtung: Solche Mails (also ohne Realname) werden in Brettern, die Realnamen-Pflicht haben (sollte bei Fido-Areas so sein) nicht weiter- geleitet! Erhält also beispielsweise ein Fido-Point eine Mail aus dem Internet ohne Angabe seines Realnamens, steht im Fido-Empfängername nur sein Alias, nicht der Realname. Damit kann der Fidopoint einfach zwischen Mails aus den Internet und Fido-NM unterscheiden. 3. Mails, bei denen die Adresse nach Punkt 4 gewandelt wurde, erhalten als Fido-Namen die ZConnect-Adresse. Dabei wird das @ durch ein % ersetzt. Ist die ZConnect-Adresse länger als 35 Zeichen, wird statt der Original- Domain eine kurze Dummy-Domain eingesetzt. Diese merkt sich Connectline, so daß bei Antworten an diese Dummy-Domain wieder die originale einge- setzt wird. Das Ganze dient dem einfachen Antworten auf ZConnect/rfc- Mails mit jedem Fido-Pointprogramm (s. @{"Gateway" link GATEWAY}). @endnode @node BENUTZUNG "Benutzung" @{b}@{u}Benutzung@{uu}@{ub} Die folgenden Punkte beschreiben, wie die User mit den einzelnen Programm- teilen umgehen müssen. @{"Gateway " link GATEWAY} - Netzübergreifende Mails @{"Areafix " link AREAFIX} - "Fido-MAPS" @{"Filerequest" link USEFREQ} - Files anfordern @endnode @node GATEWAY "Gateway" @{b}@{u}Gateway@{uu}@{ub} Das Gateway von und nach Fido wurde so aufgebaut, daß die User im Prinzip nichts beachten müssen. Die Bedienung des entsprechenden Mailprogrammes ist also immer die gleiche, egal aus welchem Typ von Netz eine Mail stammt. Zum besseren Verständnis soll hier aber trotzdem die Funktionsweise erläutert werden: @{"ZC, rfc" link ZCUSER} - ZConnect- und UUCP-Points sowie Online-User @{"Fido " link FIDOUSER} - Fido-Points @endnode @node ZCUSER "ZConnect- und UUCP-Point sowie Online-User" @{u}@{b}ZConnect- und UUCP-Points sowie Online-User@{uu}@{ub} In Netzen mit Fido-Standard haben diese die entsprechende Adresse des CL- Systems. Ist also in den Fido-Prefs z.B. das Fidonet mit der Adresse 2:248/4001 und das Amiganet mit 39:174/401 eingetragen, so haben alle Online-User, ZConnect- und UUCP-Points diese Adressen. Wird eine Mail ins Fidonet geschrieben, wird also automatisch als Absender die 2:248/4001 ein- getragen, bei Mails ins Amiganet die 39:174/401. ZConnect/UUCP-Points be- kommen also keine Pointnummer! Das Antworten auf Mails aus fidokompatiblen Netzen geschieht genauso wie bei allen anderen Mails. Das entsprechende Pointprogramm bzw. Online- Kommando setzt als Empfänger der neuen Mail wie gewohnt den Absender der Ursprungsmail ein. Das ist die entsprechend konvertierte Fido-Adresse, die bei der Antwort von Connectline wieder zurückgewandelt wird. Soll eine neue Mail (also keine Antwort) an einen Fido-User geschrieben werden, muß man natürlich wissen, wie man die (bekannte) Fido-Adresse in eine ZC/rfc-Adresse umsetzt. User direkt angeschlossener Fido-Systeme werden über ihre (stets vorhandene) ZC/rfc-Adresse angesprochen. Bei Points direkt angeschlossener Fido-Boxen wird die Adresse wie folgt gebildet: @p.box.do.main (Vorname Nachname) Soll also z.B. an einen Point der Box "beg" mit der Fido-Adresse 2:248/4002.15 geschrieben werden, adressiert man an erwin@p15.beg.fido.net (Erwin Testuser) Point 15 der beg hat also den Realnamen Erwin Testuser (der Alias ist be- liebig wählbar, er wird im Fido nicht übertragen), die beg hat die Domain fido.net. User anderer Fido-Systeme habe eine Adresse in folgender Form: @p.f.n.z.do.main (Vorname Nachname) do.main ist die Domain der Fido-Box, an welche alle Fido-Mails für nicht direkt angeschlossene Fido-Systeme geroutet werden, also der entsprechende Uplink. Dieser sollte also eine eine sinnvolle Domain bekommen, für das Fidonet z.B. fido.net. Hans Mustermann mit der Fido-Adresse 2:2476/1001.12 hat demnach die Adresse @p12.f1001.n2476.z2.fido.net (Hans Mustermann) Wird nicht an einen Point, sondern an einen Node geschrieben, entfällt das p. @endnode @node FIDOUSER "Fido-Points" @{u}@{b}Fido-Points@{uu}@{ub} Fido-Points müssen immer auch als User in Connectline eingetragen werden und haben auf ZConnect/rfc-Seite dann die entsprechende Adresse wie jeder andere Online-User oder Point. Heißt also das Connectline-System "bitquell" und gehört zur Domain "gera.thur.de", so hat der Pointuser "otto" mit dem Realnamen "Otto Punkt" die ZC/rfc-Adresse otto@bitquell.gera.thur.de (Otto Punkt) Auch Fido-Points müssen beim Antworten auf Mails aus Internet oder Z-Netz nichts beachten, die Adreß-Umsetzung übernimmt Connectline völlig transpa- rent. Bei neuen Mails (also keinen Antworten) muß man natürlich die Regeln zur Adreß-Umwandlung wieder kennen. Alle Mails, die in ein Nicht-Fido-Netz ge- schrieben werden, müssen als Fido-Adresse die des Connectline-Systems be- kommen. Statt des Fido-Namens wird die ZC/rfc-Adresse eingetragen, wobei das @{FG shine}@@{FG text} durch ein @{FG shine}%@{FG text} ersetzt wird. Als Beispiel hat das CL-System die Fido-Adresse 2:248/4001 und es soll eine Email an "dau@t-online.de" geschrieben werden. Diese Netmail muß dann also an "dau%t-online.de" bei 2:248/4001 adressiert werden. Leider sind Fido-Namen auf eine Länge von 35 Zeichen beschränkt, womit Fido- Points keine Email an eine längere Adresse schicken könnten. Weswegen wandelt CL solche langen Adressen in kürzere (mit eine Pseudo-Domain) um. Man kann also an diese Pseudo-Domain schreiben, Connectline setzt dann dafür die richtige Adresse ein. Da man bei der 1. Mail an einen ZC/rfc-User mit einer langen Adresse diese Pseudo-Domain noch nicht kennt (CL muß sie ja erst erzeugen), gibt es noch eine weitere Form der Adressierung: Als Fido-Adresse wird wieder die des CL- Systems eingesetzt, als Name aber "UUCP" oder "Gateway". Die eigentliche Email-Adresse kommt dann in die @{u}erste@{uu} Zeile des Message-Textes mit voran- gestelltem "An: " oder "To: ". Wichtig ist das Leerzeichen! Die erste Zeile der Mail sieht also so aus: An: Alias@do.main oder auch so: To: Alias@do.main (Vorname Nachname) @endnode @node AREAFIX "Areafix" @{b}@{u}Areafix@{uu}@{ub} Areafix ist die Standard-Methode zum Bestellen und Abbestellen von Areas im Fidonetz. Auch CLFido besitzt für die Downlinks ein Areafix, was z.Z. aber nur die allerwichtigsten Funktionen zur Verfügung stellt. Diese sind: @{b}[+]Areaname@{ub} Das angegebene Area wird bestellt, d.h. ab sofort werden Mails aus diesem Echo zum anfordernden System geschickt. Das @{FG shine}+@{FG text} vor dem Areanamen kann auch weggelassen werden. Bestellt werden können alle Areas, die im CL-System vorhanden sind und auf welche Zugriff besteht. Zusätzlich können Areas bestellt werden, die bei einem Uplink vorhanden sind (siehe dazu die @{"Areafix-Konfiguration" link AFIXCONFIG}). Diese werden automatisch in CL ein- getragen, das bestellende System gelinkt und das Area beim Up- link bestellt. @{b}-Areaname@{ub} Das angegebene Area wird abbestellt. @{b}%HELP@{ub} Ein Hilfetext wird per Netmail geschickt. Das passiert auch beim Verwenden unbekannter Kommandos. @{b}%LIST@{ub} Eine Liste aller im CL-System vorhandenen, bestellbaren Areas wird per Netmail zugeschickt. Nicht gelistet werden Areas, die bei einem Uplink vorhanden sind und automatisch dort bestellt werden können. Die Area-Listen der Uplinks sollte man deswegen seinen Downlinks zur Verfügung stellen (z.B. per FileRequest). @{b}%Query@{ub} Es wird eine Liste der bereits bestellten Areas geschickt. Obige Kommandos schreibt man als Fido-Downlink in den Text einer Mail (ein Kommando pro Zeile), welche an "Areafix" mit der Fido-Adresse des CL-Systems versendet wird. Als Subjekt wird das Areafix-Paßwort eingetragen, welches aber in dieser Version noch nicht ausgewertet wird. Auch ZConnect- und UUCP-Downlinks können Areafix nutzen, da Areafix als nor- males MAPS-Kommando implementiert ist. Dazu wird die Mail an "MAPS" ge- schrieben, Subjekt ist in diesem Fall "Areafix". Mit Areafix können, wie üblich, nur Mailechos bestellt werden. Ein Raid zum Bestellen von Fileechos existiert noch nicht. @endnode @node USEFREQ "Durchführen von Filerequests" @{b}@{u}Files requesten@{uu}@{ub} Filerequests können nach FTS0006 (WaZOO) ausgeführt werden. Dazu muß das an- fordernde System ein Requestfile schicken (????????.REQ), welches pro Zeile den Namen eines gewünschten Files enthält. Dabei gibt es auch einige erwei- terte Möglichkeiten, so daß eine Zeile allgemein folgenden Aufbau hat: [!][<+/->