Programmierprotokoll UZERCP V3.0/3.2 01.Maerz/26.August 1991 __________________________________________________________________________ 1. Vorwort 2 2. UUCP -> ZER 3 2.1 Absender 3 2.1.1 Makros 3 2.2 Absender (Fortsetzung) 4 2.3 Empfaenger 6 2.3.1 Sonderzeichen-Konvertierung 6 2.3.2 Brett-Empfaenger 6 2.3.3 Prioritaeten nach RFC 6 2.4 Message-Id 7 3. ZER -> UUCP 13 3.1 Empfaenger 13 3.1.1 Makros 13 3.2 Empfaenger (Fortsetzung) 13 3.3 Absender 15 3.4 Message-Id 16 4. Probleme/Vorschlaege 17 4.1 Doppel-Adressen 17 4.2 Langadressen 17 4.3 Fehlsteuerungen 17 4.4 Vorstellungsformular 18 - Seite 2 - 1. Vorwort __________ Der folgende Text ist aus meinen Notizen entstanden, die ich als Vorarbei- ten zur vollstaendigen Umgestaltung des "UZERCP"-Gateways (Mitte bis Ende April 1991) erstellt habe. Der Text wurde dann im Juli/August 1991 nochmal ueberarbeitet, nachdem ein neues Gateway-Release (3.2) fertiggestellt war, in dem weitere Vorschlaege aus dem Netz beruecksichtigt waren und einige nach wie vor bestehende Probleme beseitigt worden sind. Viele Probleme wurden mir erst waehrend der Codierzeit bewusst. Ich habe daher versucht, alle er- denklichen Schwierigkeiten vorwegzunehmen und eine Loesung dafuer zu finden. Dabei haben zahlreiche Anregungen von Benutzern sowohl aus dem UUCP-, als auch aus dem Zerberus-Bereich und aus anderen Netzwerken dazu beigetragen, Probleme zu erkennen und Loesungen zu suchen. Fuer alle weiteren Anregungen, Kritiken und Vorschlaege bin ich - wie immer - dankbar, sofern sie sachlich vorgetragen werden. Ich habe den gesamten Text grundsaetzlich als "Programmieranleitung" ge- schrieben, da nur konkrete Anweisungen eine Arbeitsgrundlage bieten. Inso- fern stellt er nur indirekt eine Erweiterung des Protokolls der "GateBau '90" dar. Er ist vielmehr als praktische Ergaenzung dazu gedacht. Die einzige "echte" Neuerung ist die ausfuehrliche Beschreibung einer Loesung des Makro-Problems. Deshalb wurde dieser Teil auch in ein eigenes Unterka- pitel gefasst. *** Achtung - wichtig fuer alle Programmierer: In dieser Ueberarbeitung (Au- gust '91) wurde die Form der Gateway-Service-Adressen voellig neu gestal- tet, um bestehende Probleme zu beseitigen und zukuenftige Probleme zu umge- hen! Die Service-Adressen sind daher nun NICHT mehr in Uebereinstimmung mit den auf der GateBau '90 beschlossenen Service-Adressen! Ich bitte dies un- bedingt zu beachten und daher Punkt 2.1.1-h, 2.2-10 und Punkt 3.1.1-b unbe- dingt zu lesen! Dank geht an Martin Husemann aus Bielefeld, der eine optimale Loesung des Message-Id-Problems durch seine praktischen Beispiele ermoeglicht hat. Ausserdem geht ein herzlicher Dank an Kai Henningsen aus Muenster fuer die kritische Ueberpruefung des letzten Entwurfs und einige wertvolle Anregungen bezueglich der Domain-Verwaltung beim Uebergang vom UUCP ins Zerberus. Zu guter Letzt ebenfalls ein Dank an Lutz Petersen aus Elmshorn fuer viele an- dere praktische Vorschlaege. Obwohl ich diesen Text ausschliesslich auf einen Gateway zwischen Zerberus und UUCP beziehe, hoffe ich, dass sich moeglichst viele Programmierer damit anfreunden koennen. Ausserdem basiert die Anleitung auf dem bisherigen Zerbe- rus Netcallformat. Zu gegebener Zeit wird das neue Netcallformat natuerlich zahlreiche Aenderungen noetig machen. Dies wird aber mit Sicherheit erst in nicht absehbarer Zeit geschehen. Wichtig erschien mir auch, endgueltige Standards fuer die Bezeichnung von Kontrollzeilen festzulegen. Dabei habe ich mich zu 100% an die RFC-Standards gehalten. Es ist im momentanen Zu- stand eine Katastrophe, dass z.B. die so wichtigen Message-Id's beim einen Gateway mit "Message-Id: " gekennzeichnet werden und beim anderen mit "Ms- gId: " oder "MessageId:", obwohl schon in der "GateBau '90" EINDEUTIG eine RFC-konforme Form "Message-Id: " vorgeschrieben wurde. Im momentanen Zu- stand koennen daher nicht einmal Dupes ausgeschlossen werden. Ich hoffe, dass in Zukunft wenigstens die FORM einheitlich wird! Viel Spass beim Lesen! Volker Ulle - Seite 3 - 2. UUCP -> ZER ______________ Im Folgenden wird die Konvertierung einer Nachricht aus dem UUCP-Bereich in das Zerberus-Netz beschrieben. 2.1 Absender 1 - Teil in runden Klammern als Realname heraustrennen (Rest ist dann ohne Realname). 2 - Teil VOR einer spitzen Klammer als Realname heraustrennen (Rest ist dann ohne Realname). Spitze Klammer entfernen. 3 - Ueberpruefen, ob der Absender die Zerberus-Domain (.zer.sub.org) enthaelt. Wenn ja: Linken Teil VOR der Domain als neuen Absender heraustrennen, in Grossschrift wandeln und ".ZER" nachstellen. 4 - Anhand einer Liste ueberpruefen, ob der Absender die Domain eines ande- ren, registrierten Netzes enthaelt. Wenn ja: Linken Teil VOR der Domain als neuen Absender heraustrennen. Dann eine "Ersatz-Domain" bilden aus einem Klammeraffen, sowie dem Namen des fuer das entsprechende Netz guel- tigen Gateways. Wenn der Absender keine registrierte Domain enthaelt: Absender so lassen und als "Ersatz-Domain" die Zerberus Gateway-Domain fuer UUCP-Gateways (@UUCP.ZER) benutzen. Gateways, die (noch) nicht als UUCP eingetragen sind, benutzen ihre eigene Zerberus-Domain (z.B. @UZERCP.ZER). Nach einer Uebergangsfrist werden solche Domains al- lerdings untersagt. 5 - Kam der Absender NICHT aus dem Zerberus (Ueberpruefung bei Schritt 3 er- folglos), wird der Absender durch "Escapen" (\) in Grossbuchstaben gewandelt, sowie Klammeraffen in Prozentzeichen gewandelt. Ausserdem wird ihm die bei Schritt 4 erzeugte "Ersatz-Domain" nachgestellt. 6 - Kann der Absender nicht durch bestimmte Massnahmen (Loeschen der Pseudo- Domain '.UUCP') auf eine Laenge unter 41 Zeichen gebracht werden, wird ein gatewayspezifisches Makro eingesetzt. 2.1.1 Makros Die folgende Makro-Regelung ist nur noetig, wenn die Adressen im Fremdnetz (z.B. UUCP) laenger als 40 Zeichen sein koennen. a - Ist der Absender laenger als 40 Zeichen, wird zuerst, fuer den Fall, dass kein bekanntes Makro gefunden werden kann, die Zahl und die Laenge des naechsten eigenen Makros ermittelt. b - Nun wird der Teil zwischen dem ersten Punkt (.) und dem Klammeraffen (@) herausgetrennt (Domain). c - Nun wird zuerst in der eigenen Makrotabelle und dann in den Ma- krotabellen ALLER uebrigen, registrierten Gateways nach diesem Makro ge- sucht. Wurde in einer Tabelle das Makro gefunden, und wird der Absender nach Ersetzen dieses Makros kuerzer als 41 Zeichen, wird das Makro in dem Absender ersetzt und die Makroersetzung beendet. d - Konnte das Makro nicht gefunden werden und wird der Absender durch Ein- setzen des in (a) erzeugten Makros kleiner als 41 Zeichen, wird dieses eigene, neue Makro eingesetzt und mit (g) fortgefahren. e - Konnte das Makro nicht gefunden werden oder konnte der Absender nicht auf die erforderliche Laenge reduziert werden, wird der Teil des Absen- der zwischen dem Prozentzeichen (%) (falls vorhanden) und dem Klammeraffen als Makro herausgetrennt und bei (c) und (d) fortgefahren. f - Fuehrten alle Versuche zu keinem Ergebnis, wird der gesamte Teil des Ab- senders vor dem Klammeraffen in ein Makro gewandelt und mit (c) und (d) fortgefahren. g - Dieses Makro wird nun in der gateway-eigenen Makrotabelle eingetragen. Dabei werden die Makros fortlaufend mit ganzen natuerlichen Zahlen, beginnend bei 1, numeriert. Ein Makro beginnt immer mit einem Dollarzeichen ($), gefolgt von zwei Grossbuchstaben oder einem Grossbuchstaben und einer Zahl, der sogenannten "Gateway-Id", die jeden Gateway eindeutig identifiziert, und einer natuerlichen Ganzzahl, die keine fuehrenden Nullen oder Fuellzeichen enthaelt. Die Gateway-Id's und die zugehoerigen Namen/Netzadressen sollten von einer Stelle zentral vergeben und verwaltet werden. Als Empfehlung gilt weiterhin, dass der erste Buchstabe der Gateway-Id moeglichst identisch sein sollte mit dem Anfangsbuchstaben des Namens des Netzes, in das der Gateway leitet bzw. - Seite 4 - mit dem im Zerberus ueblichen Namen des Gateways zu diesem Netz. Der zweite Buchstabe (bzw. Zahl) kann beliebig gewaehlt werden. h - Um auch anderen Gateways mitzuteilen, dass ein neues Makro generiert wurde und ihnen die Moeglichkeit zu geben, dieses Makro in ihrer Tabelle einzutragen, wird noch eine Kontrollnachricht in ein dafuer vorgesehenes Brett gesandt. Dieses Brett heisst /T-NETZ/MACROS. Die Kontrollnachricht traegt als Absender den Namen '@.ZER'. wird dabei durch das Gateway-Service-System ersetzt und durch die Id des Gateways. Fuer UZERCP lautet dieser Absender also "UU@A-LINK-H.ZER" (siehe auch Punkt 3.1.1-b). Im Betreff der Nachricht steht 'ADD $XXn'. XX steht fuer die Gateway-Id und n fuer die Makro-Nummer. Die erste Zeile der Nachricht enthaelt das Makro selbst. Alle weiteren Zeilen werden ignoriert. Ist die Nummer des so beschriebene Makros in der Tabelle des entsprechenden Gateways schon belegt, wird das "alte" Makro von diesem neuen ueberschrieben. Enthaelt die Betreffzeile das Kontrollwort 'DEL' (statt 'ADD'), so wird das benannte Makro aus der Tabelle ersatzlos gestrichen. Enthaelt die Betreffzeile das Kontrollwort 'DIR $XX', wobei XX fuer die Gateway-Id steht, so enthaelt die Nachricht die komplette Makro-Liste des Gateways mit der Kennung XX. Die alte Makro-Liste des entsprechenden Gateways wird dann vollstaendig durch diese neue ersetzt. Als Empfehlung gilt, dass jeder Gateway einmal im Monat ein solches Makro-Directory in das Kontrollbrett /T-NETZ/MACROS sendet. Dies verbessert die Aktualitaet der Makrolisten und damit die Zustellbarkeit von Nachrichten. Vor jeder Veraenderung der Makroliste eines Gateway durch Steuernach- richten sollte jedoch eine Ueberpruefung des Absenders der Steuernach- richt erfolgen, um Missbrauch zu vermeiden. Sinnvoll ist eine Ueberprue- fung, ob die in dem Betreff der Steuernachricht genannte Gateway-Id mit der in der Liste der Gateway-Serviceadressen genannten Service-Adresse uebereinstimmt. Ist dies der Fall, kann davon ausgegangen werden, dass der Absender der Steuernachricht zur Veraenderung der entsprechenden Ma- kroliste autorisiert ist. Der Aufbau der Liste ist wie folgt: Jede Zeile der Liste enthaelt ein Makro in der Form '$XXn,'. XX steht fuer die Gateway-Id wie sie auch in der Betreffzeile steht, n fuer die Makro-Nummer und fuer das entsprechende Makro in der ZERBERUS- Schreibweise (also Grossbuchstaben mit entsprechenden 'Escapes' (\)). Die Makro-Id und das Makro selbst muessen durch ein Komma voneinander getrennt sein. 2.2 Absender (Fortsetzung) 7 - Ergab die Ueberpruefung in Schritt (3) oder die Pruefung der Message-Id, dass der Absender NICHT aus dem Zerberus ist, so wird in die Nachricht eine Zeile "Message-Id: " eingefuegt, die die Original-Id enthaelt (also mit spitzen Klammern), wie sie aus dem UUCP kam. Das vereinfacht beim "Wiederaustritt" aus dem Zerberus die Erkennung von "Fremdnachrichten", da dann GRUNDSAETZLICH bei Vorhandensein einer 'Message-Id: '-Zeile einfach die Id aus dieser Zeile genommen werden kann und die Id im Zerberus-Header garnicht mehr beachtet werden muss. 8 - Wurde beim Absender ein Makro eingesetzt und liegt der Absender somit nicht mehr in seiner urspruenglichen Form vor, so wird in die Nachricht ausserdem noch eine Zeile "From: " eingefuegt, die den Originalabsender der Nachricht enthaelt, wie er nach Bearbeitungsschritt (2) existiert. 9 - Falls vorhanden, werden ausserdem "Realname: ", "Organization: ", "References: " und eine "Reply-To: " Zeile eingefuegt. 10- Nun wird zum Abschluss IMMER eine 'X-Gateway: '-Zeile mit derGateway-Id eingefuegt. Diese Id ist fuer jeden Gateway eindeutig und besteht aus zwei Grossbuchstaben oder einem Grossbuchstaben und einer Zahl. Fuer UZERCP z.B. ist dies "UU". Danach folgt - durch ein Leerzeichen getrennt - der Name des Gateway-Service-Systems. Dieser Name ist NICHT der Name des Gateways im Netz (also z.B. UUCP), sondern der Name des Systems, an das eventuelle Anfragen fuer den Gateway (z.B. Info-Re- quests) geschickt werden muessen. Fuer den Leser einer Nachricht ermoeg- licht dies die Identifikation der einzelnen Gateways. Normalerweise ist das Gateway-Service-System der Name der Zerberus-Mailbox, an die der Gateway angeschlossen ist (Server). Der Name kann also z.B. 'A-LINK-H' oder 'SHLINK' lauten. Der User mit dem Namen der Gateway-Id auf diesem Service-System (bei der A-LINK-H z.B. "UU@A-LINK-H.ZER") ist dann Emp- faenger von Service-Nachrichten fuer den entsprechenden Gateway. Danach - Seite 5 - koennen (durch ein weiteres Leerzeichen getrennt) optional noch weitere Informationen stehen (z.B. eine Software-Information oder Versionsnummer). Die Zeile sieht dann z.B. folgendermassen aus: 'X-Gateway: UU A-LINK-H [UZERCP V3.2]'. - Seite 6 - 2.3 Empfaenger Die Umwandlung der Empfaengerangabe geschieht in vollem Einklang mit den RFC-Regeln. Dies sollte bei ALLEN Gateways grundsaetzlich geschehen, da nur so eine Funktionsfaehigkeit bei Adressierung ueber alle Netze hinweg erreicht werden kann. 2.3.1 Sonderzeichen-Konvertierung Ein Problem stellen dabei die Ausrufezeichen und Prozentzeichen dar, die in Zerberus-Adressen als normale Zeichen zwar verwendet werden duerfen, aber im UUCP eine Funktion als Sonderzeichen bei der Adress-Aufloesung haben. Daher werden die Ausrufezeichen (falls noetig) im UUCP durch eine Hilfskonstruktion nach RFC transportiert. Diese Konstruktion sieht eine Umwandlung der Ausrufezeichen in die Zeichen- folge '#033#' vor. Folglich muss diese Zeichenfolge im Empfaenger vor dem Eintritt in das Zerberus wieder in das Ausrufezeichen zurueckgewandelt wer- den. Eine Rueckwandlung des Prozentzeichens ist nicht notwendig, da die Be- deutung des Prozentzeichens in den Zerberus-Adressen zum einen die gleiche ist, wie im UUCP und zum anderen keine Probleme verursacht, da das Prozent- zeichen bei der Adress-Aufloesung die niedrigste Prioritaet hat (siehe unten: Prioritaeten nach RFC). Folglich koennen die Prozentzeichen aus Zerberus- Adressen im UUCP ruhig auch als Prozentzeichen transportiert werden. Bei Ausrufezeichen ist dies NICHT moeglich, da sie eine hoehere Prioritaet haben. Wichtig ist auch, dass die Rueckwandlung des Codes #033# in ein Ausrufezei- chen erst GANZ am Schluss der Konvertierung stattfindet, kurz bevor die Nachricht ins Zerberus verschickt wird und wenn die Interpretation der Emp- faengeradresse vollstaendig abgeschlossen ist, da andernfalls das Ausrufezei- chen in der Adresse zu boesartigen Fehlinterpretationen fuehrt, die mit Si- cherheit den Verlust der Nachricht bewirken! 2.3.2 Brett-Empfaenger Ist der Empfaenger kein Benutzer, sondern eine UUCP-Gruppe, so muss die Emp- faengerangabe nicht weiter konvertiert werden, sondern es kann gleich der zugehoerige Name des Zerberus-Brettes gesucht werden. 2.3.3 Prioritaeten nach RFC Da einige Verwirrung bezueglich der Prioritaeten der Sonderzeichen herrschte, will ich hier nochmal kurz die Prioritaetsregeln nennen. Absolut hoechste Prioritaet in einer Adresse hat der sogenannte Klammeraffe (@). Hinter dem Klammeraffen steht das naechste System, das hinter dem Gateway erreicht werden soll. Ist in einer Adresse kein Klammeraffe vorhanden, jedoch ein Ausrufezeichen, ist der Teil der Adresse VOR dem Ausrufezeichen das naechste System, das erreicht werden soll. Hat eine Adresse weder einen Klammeraffen, noch ein Ausrufezeichen, so wird ein Prozentzeichen gesucht. Konnte eines gefunden werden, wird es in einen Klammeraffen gewandelt und wie ein solcher behandelt. Die Prioritaeten lauten also: @ > ! > % Ein Beispiel soll dies verdeutlichen: a!b%c@d wird zu d!a!b%c und daher zuerst an d weitergeleitet. Dort wird a!b%c an a weitergeleitet. Dort wird b%c zu c!b und daher an c weitergeleitet. Dort geht die Mail an b. Nur diese und KEINE ANDERE Konvertierung von Adressen ist nach RFC zu- laessig! - Seite 7 - 2.4 Message-Id Nun wird die Message-Id bearbeitet und entsprechend konvertiert: Sofern die Domain '.zer.sub.org' in der Message-Id vorhanden ist, die Nachricht also urspruenglich auch aus dem Zerberus stammt, werden die spitzen Klammern entfernt und die ID auf den Teil vor dem '.zer.sub.org' gekappt. Eine Umwandlung der Gross/Kleinschreibung findet nicht statt, da Zerberus die Message-Id's mit korrekter Gross/Kleinschreibung transportiert und ID's auch 'case-sensitive' behandelt. War die Nachricht urspruenglich nicht aus dem Zerberus, so muessen wir aus der Original-Id eine eindeutige Zerberus-Id erzeugen, die die maximal zulaessige Laenge von 19 Zeichen nicht ueberschrei- tet. Daher nun einiges theoretisches zur eindeutigen Konvertierung einer belie- bigen Message-Id in das Zerberus-Format: Im Zerberus stehen uns 19 Zeichen fuer die Message-Id zur Verfuegung. Davon werden 8 Zeichen fuer eine System-Kennung und ein Zeichen fuer den Klammeraf- fen belegt. Folglich stehen nur noch 10 Zeichen fuer die eigentliche Id zur Verfuegung. In diesen 10 Zeichen muss nun eine Id beliebiger Laenge eindeutig codiert werden. Wir koennen bei diesen 10 Zeichen nicht beliebige Zeichen nehmen. Es duerfen nur 7-bit Zeichen sein und ausserdem sind zahlreiche Sonderzeichen ausge- schlossen. Daher benutzen wir nur die Zahlen von 0 bis 9, die Grossbuchsta- ben A-Z, den Unterstrich (_), die Kleinbuchstaben a-z und die Tilde (~). Damit kommen wir auf 64 Zeichen und koennen somit pro Zeichen in der Zerbe- rus-Id 6 Bit darstellen. Da wir zehn Zeichen zur Verfuegung haben, koennen wir 10 * 6, also insgesamt 60 Bit darstellen. Wir muessen uns nun ueberlegen, wie wir diese 60 Bit sinnvoll ausfuellen. Nach Vorschlag von Martin Husemann sollte in diesen 60 Bit auf jeden Fall eine 32-Bit CRC-Pruefsumme nach ANSI X3.66 (Z-Modem-Polynom) ueber die ge- samte Id enthalten sein. Folglich bleiben noch 28 Zeichen fuer andere Pru- efverfahren uebrig. Sinnvoll erscheint es, in diesen 28 Bit das Absendeda- tum der Nachricht zu codieren. Nach Vorschlag von Holger Lubitz nehmen wir eine Codierung der zwischen einem bestimmten, festgelegten Datum und dem Absendedatum verstrichenen Sekunden vor. Als Anfangsdatum nehmen wir den 1. Januar 1970 00:00:00 Uhr. Da wir mit 28 Bit nur einen Zeitraum von etwas mehr als 8 Jahren codieren koennen, muessen wir einen Ringzaehler schaffen. Der Zeitraum von 8 Jahren reicht allerdings zur Vermeidung von Dupes voll- staendig aus. Wir fuellen also die linken 28 Bit (hoeherwertige Bits) mit dem codierten Datum aus und die niederwertigen 32 Bits mit der CRC-Pruefsumme. Das Absendedatum sollte in der Form yyyymmddhhmm vorliegen. Da im Zerberus die Sekundenangabe verloren geht, muss die Sekundenangabe grundsaetzlich auf Null gesetzt werden! Wir koennen also nur auf eine Minute genau codie- ren. Eine zweistellige Jahresangabe wird sinnvoll auf 4 Zeichen ergaenzt (86 == 1986 und 03 == 2003). Die CRC-Pruefsumme wird ueber die GESAMTE Original-Id (also mit spitzen Klammern u.ae.) gebildet und - falls noetig - links mit Nullen auf 32 Bit aufgefuellt. Nun teilen wir diese 60-Bit-Binaerzahl in Bloecke zu jeweils 6 Bit auf, die nach der oben genannten Regel den 10 Zeichen der Id zugeordnet werden. Den erzeugten Werten ordnen wir nach folgender Zuordnungstabelle entspre- chende Zeichen zu: 0 == 0 1 == 1 2 == 2 3 == 3 4 == 4 5 == 5 6 == 6 7 == 7 8 == 8 9 == 9 10 == A 11 == B 12 == C 13 == D 14 == E 15 == F 16 == G 17 == H 18 == I 19 == J 20 == K 21 == L 22 == M 23 == N 24 == O 25 == P 26 == Q 27 == R 28 == S 29 == T 30 == U 31 == V 32 == W 33 == X 34 == Y - Seite 8 - 35 == Z 36 == _ 37 == a 38 == b 39 == c 40 == d 41 == e 42 == f 43 == g 44 == h 45 == i 46 == j 47 == k 48 == l 49 == m 50 == n 51 == o 52 == p 53 == q 54 == r 55 == s 56 == t 57 == u 58 == v 59 == w 60 == x 61 == y 62 == z 63 == ~ Wir erhalten somit eine Folge von 10 ASCII-Zeichen, die Absendedatum und Pruefsumme der Nachricht codiert enthalten. Ein Beispiel (MIT Codierung der Sekundenangabe): Das Absendedatum lautet: Dienstag, 7. Mai 1991 02:08:48 Uhr Das Ausgangsdatum ist daher: 19910507020848 Zwischen dem 1.1.1970 und dem 7.5.1991 liegen 7796 Tage. Dies entspricht 673.574.400 Sekunden. Bis 02:08:48 sind weitere 7728 Sekunden vergangen. Insgesamt also 673.582.128 Sekunden oder in Binaerer Form: 101000001001100000110000110000 Sekunden. Da wir einen Ringzaehler von 28 Bit haben, kuerzen wir diesen Binaerwert auf die niederwertigen (rechten) 28 Bit und erhalten somit den Wert 1000001001100000110000110000 als Datumscodierung. Die CRC-Pruefsumme ueber die Id ergibt den Hex-Wert: 2BF6DA7 oder in binae- rer Form: 10101111110110110110100111. Wir fuellen diese 26 bit auf 32 auf: 00000010101111110110110110100111 und fuegen das codierte Datum und die Pru- efsumme zur 60 Bit Id zusammen: 100000100110000011000011000000000010101111110110110110100111. Schliesslich teilen wir die Folge in 10 Gruppen zu 6 Bit auf, wandeln die Gruppen in Dezimalwerte zurueck und weisen den Werten nach der obigen Ta- belle entsprechende Zeichen zu: Gruppe 1. 2. 3. 4. 5. 6. 7. 8. 9.10. Folge 100000 100110 000011 000011 000000 000010 101111 110110 110110 1 00111 Dezimal 32 38 3 3 0 2 47 54 5439 Zeichen W b 3 3 0 2 k r r c Somit ergibt sich fuer die 10 Zeichen der Zerberus-Id die Zeichenfolge 'Wb3302krrc'. Schliesslich fuegen wir noch einen Klammeraffen und einen Systemnamen an. Der Systemname entspricht dem im Zerberus registrierten Systemnamen fuer Ga- teways zu dem jeweiligen Netz, also z.B. MAUS, FIDO, UUCP, ARTNET u.ae.. Ga- teways zu Netzen ohne registrierte Domain und einen Systemnamen im Zerberus sollen nach einer Frist nicht mehr zugelassen werden. Die vollstaendige Zer- berus-Id waere dann Wb3302krrc@UUCP und koennte nun auf das Netz geschickt werden. Natuerlich muss beim Uebergang einer Nachricht vom Zerberus ins UUCP, die eine 'Message-Id: '-Zeile mit der expliziten Angabe einer Id enthaelt, diese Id aus der Zeile entsprechend konvertiert werden und mit der zerberus-internen Id verglichen werden, um festzustellen, ob die Id's zueinander gehoeren. Der einfache String-Vergleich, wie er vorher noch moeglich war, muss daher jetzt entfallen. Darueber aber spaeter mehr. Da es manchem vielleicht einige Schwierigkeiten bereitet, den oben be- schriebenen Konvertierungs-Vorgang in einer Sprache zu codieren, gebe ich im Folgenden noch ein Beispielprogramm in Basic, das den eben beschriebenen - Seite 9 - Konvertierungsvorgang der Beispielnachricht durchfuehrt. Wer einen Quick-Ba- sic-Compiler der Version 4.0 oder hoeher besitzt, kann das Programm direkt ausfuehren. Die CRC-Berechnungsroutine ist in Basic allerdings sehr langsam, da durch Fehler beim Quick-Basic-Compiler, bei Arithmetik mit Integer-Vari- ablen doppelter Laenge, auf eine Binaerwandlung beim Shiften der Pruefsum- men zurueckgegriffen werden musste. In C gestaltet sich das Ganze wesent- lich einfacher (eine entsprechende Routine wurde von Martin Husemann schon in /Z-NETZ/TELECOM/GATEWAY gepostet). DECLARE SUB DAYDIFF (YYYY1%, MM1%, DD1%, YYYY2%, MM2%, DD2%, DAYS!) DECLARE SUB CRC (MSGID$, CRC32$, CRC32TAB#()) DECLARE SUB MKID (DATUM$, MSGID$, ZERID$, CRC32TAB#()) DECLARE SUB GETZ (DEZ#, Z$) DECLARE SUB BIN2DEZ (BIN$, DZ#) DECLARE SUB DEZ2BIN (DZ#, BIN$, FILL%) DEFINT A-Z DIM CRC32TAB#(32 * 8 - 1) DEF FNHEX2BIN$ (HX$) DEZ# = 0 FOR N = 1 TO LEN(HX$) Z$ = MID$(HX$, N, 1) IF Z$ > "9" THEN Z = ASC(Z$) - 55 ELSE Z = VAL(Z$) END IF DEZ# = DEZ# + Z * (16 ^ (LEN(HX$) - N)) NEXT BIN$ = "" WHILE DEZ# > 0 IF DEZ# - INT(DEZ# / 2) * 2 > 0 THEN BIN$ = "1" + BIN$ ELSE BIN$ = "0" + BIN$ DEZ# = INT(DEZ# / 2) WEND FNHEX2BIN$ = BIN$ END DEF DEF FNBIN2DEZ# (BIN$) A# = 0 FOR N = LEN(BIN$) TO 1 STEP -1 IF MID$(BIN$, N, 1) = "1" THEN A# = A# + 2 ^ (LEN(BIN$) - N) ELSE IF MID$(BIN$, N, 1) <> "0" THEN PRINT "Keine Binaerzahl !": END END IF NEXT FNBIN2DEZ# = A# END DEF DEF FNSHR# (CRC32#, N) C$ = FNHEX2BIN$(HEX$(CRC32#)) IF LEN(C$) >= N THEN FNSHR# = FNBIN2DEZ#(LEFT$(C$, LEN(C$) - N)) ELSE FNSHR# = 0 END IF END DEF DEF FNUPDC32# (OCTET, CRC32#) = CRC32TAB#((CRC32# XOR OCTET) AND &HFF) XOR (FNSHR#(CRC32#, 8)) REM CRC Polynom &hedb88320# DATA &h00000000#, &h77073096#, &hee0e612c#, &h990951ba#, &h076dc419#, &h706af48f#, &he963a535#, &h9e6495a3# DATA &h0edb8832#, &h79dcb8a4#, &he0d5e91e#, &h97d2d988#, &h09b64c2b#, &h7eb17cbd#, &he7b82d07#, &h90bf1d91# DATA &h1db71064#, &h6ab020f2#, &hf3b97148#, &h84be41de#, &h1adad47d#, &h6ddde4eb#, &hf4d4b551#, &h83d385c7# - Seite 10 - DATA &h136c9856#, &h646ba8c0#, &hfd62f97a#, &h8a65c9ec#, &h14015c4f#, &h63066cd9#, &hfa0f3d63#, &h8d080df5# DATA &h3b6e20c8#, &h4c69105e#, &hd56041e4#, &ha2677172#, &h3c03e4d1#, &h4b04d447#, &hd20d85fd#, &ha50ab56b# DATA &h35b5a8fa#, &h42b2986c#, &hdbbbc9d6#, &hacbcf940#, &h32d86ce3#, &h45df5c75#, &hdcd60dcf#, &habd13d59# DATA &h26d930ac#, &h51de003a#, &hc8d75180#, &hbfd06116#, &h21b4f4b5#, &h56b3c423#, &hcfba9599#, &hb8bda50f# DATA &h2802b89e#, &h5f058808#, &hc60cd9b2#, &hb10be924#, &h2f6f7c87#, &h58684c11#, &hc1611dab#, &hb6662d3d# DATA &h76dc4190#, &h01db7106#, &h98d220bc#, &hefd5102a#, &h71b18589#, &h06b6b51f#, &h9fbfe4a5#, &he8b8d433# DATA &h7807c9a2#, &h0f00f934#, &h9609a88e#, &he10e9818#, &h7f6a0dbb#, &h086d3d2d#, &h91646c97#, &he6635c01# DATA &h6b6b51f4#, &h1c6c6162#, &h856530d8#, &hf262004e#, &h6c0695ed#, &h1b01a57b#, &h8208f4c1#, &hf50fc457# DATA &h65b0d9c6#, &h12b7e950#, &h8bbeb8ea#, &hfcb9887c#, &h62dd1ddf#, &h15da2d49#, &h8cd37cf3#, &hfbd44c65# DATA &h4db26158#, &h3ab551ce#, &ha3bc0074#, &hd4bb30e2#, &h4adfa541#, &h3dd895d7#, &ha4d1c46d#, &hd3d6f4fb# DATA &h4369e96a#, &h346ed9fc#, &had678846#, &hda60b8d0#, &h44042d73#, &h33031de5#, &haa0a4c5f#, &hdd0d7cc9# DATA &h5005713c#, &h270241aa#, &hbe0b1010#, &hc90c2086#, &h5768b525#, &h206f85b3#, &hb966d409#, &hce61e49f# DATA &h5edef90e#, &h29d9c998#, &hb0d09822#, &hc7d7a8b4#, &h59b33d17#, &h2eb40d81#, &hb7bd5c3b#, &hc0ba6cad# DATA &hedb88320#, &h9abfb3b6#, &h03b6e20c#, &h74b1d29a#, &head54739#, &h9dd277af#, &h04db2615#, &h73dc1683# DATA &he3630b12#, &h94643b84#, &h0d6d6a3e#, &h7a6a5aa8#, &he40ecf0b#, &h9309ff9d#, &h0a00ae27#, &h7d079eb1# DATA &hf00f9344#, &h8708a3d2#, &h1e01f268#, &h6906c2fe#, &hf762575d#, &h806567cb#, &h196c3671#, &h6e6b06e7# DATA &hfed41b76#, &h89d32be0#, &h10da7a5a#, &h67dd4acc#, &hf9b9df6f#, &h8ebeeff9#, &h17b7be43#, &h60b08ed5# DATA &hd6d6a3e8#, &ha1d1937e#, &h38d8c2c4#, &h4fdff252#, &hd1bb67f1#, &ha6bc5767#, &h3fb506dd#, &h48b2364b# DATA &hd80d2bda#, &haf0a1b4c#, &h36034af6#, &h41047a60#, &hdf60efc3#, &ha867df55#, &h316e8eef#, &h4669be79# DATA &hcb61b38c#, &hbc66831a#, &h256fd2a0#, &h5268e236#, &hcc0c7795#, &hbb0b4703#, &h220216b9#, &h5505262f# DATA &hc5ba3bbe#, &hb2bd0b28#, &h2bb45a92#, &h5cb36a04#, &hc2d7ffa7#, &hb5d0cf31#, &h2cd99e8b#, &h5bdeae1d# DATA &h9b64c2b0#, &hec63f226#, &h756aa39c#, &h026d930a#, &h9c0906a9#, &heb0e363f#, &h72076785#, &h05005713# DATA &h95bf4a82#, &he2b87a14#, &h7bb12bae#, &h0cb61b38#, &h92d28e9b#, &he5d5be0d#, &h7cdcefb7#, &h0bdbdf21# DATA &h86d3d2d4#, &hf1d4e242#, &h68ddb3f8#, &h1fda836e#, &h81be16cd#, &hf6b9265b#, &h6fb077e1#, &h18b74777# DATA &h88085ae6#, &hff0f6a70#, &h66063bca#, &h11010b5c#, &h8f659eff#, &hf862ae69#, &h616bffd3#, &h166ccf45# DATA &ha00ae278#, &hd70dd2ee#, &h4e048354#, &h3903b3c2#, &ha7672661#, &hd06016f7#, &h4969474d#, &h3e6e77db# DATA &haed16a4a#, &hd9d65adc#, &h40df0b66#, &h37d83bf0#, &ha9bcae53#, &hdebb9ec5#, &h47b2cf7f#, &h30b5ffe9# DATA &hbdbdf21c#, &hcabac28a#, &h53b39330#, &h24b4a3a6#, &hbad03605#, &hcdd70693#, &h54de5729#, &h23d967bf# DATA &hb3667a2e#, &hc4614ab8#, &h5d681b02#, &h2a6f2b94#, &hb40bbe37#, &hc30c8ea1#, &h5a05df1b#, &h2d02ef8d# FOR N = 0 TO 32 * 8 - 1 READ CRC32TAB#(N) NEXT MSGID$ = "<07.05.1991/02:08:48XYZabcDEFG@testsystem.han.de>" DTM$ = "19910507020848" CALL MKID(DTM$, MSGID$, ZERID$, CRC32TAB#()) - Seite 11 - PRINT ZERID$ END SUB BIN2DEZ (BIN$, DZ#) STATIC DZ# = 0 I = LEN(BIN$) FOR N = I TO 1 STEP -1 IF MID$(BIN$, N, 1) = "1" THEN DZ# = DZ# + 2 ^ (I - N) END IF NEXT END SUB SUB CRC (MSGID$, CRC32$, CRC32TAB#()) STATIC OLDCRC32# = &HFFFFFFFF FOR I = 1 TO LEN(MSGID$) C$ = MID$(MSGID$, I, 1) OLDCRC32# = FNUPDC32#(ASC(C$), OLDCRC32#) NEXT CRC32$ = HEX$(NOT OLDCRC32#) END SUB SUB DAYDIFF (YYYY1, MM1, DD1, YYYY2, MM2, DD2, DAYS!) STATIC K1! = 365! * YYYY1 + DD1 + 31! * MM1 - 31! IF MM1 >= 3 THEN K1! = K1! - INT(.4 * MM1 + 2.3) ELSE YYYY1 = YYYY1 - 1 B1! = K1! + INT(YYYY1 / 4!) - INT(.75 + INT(YYYY1 / 100!) * .75) K2! = 365! * YYYY2 + DD2 + 31! * MM2 - 31! IF MM2 >= 3 THEN K2! = K2! - INT(.4 * MM2 + 2.3) ELSE YYYY2 = YYYY2 - 1 B2! = K2! + INT(YYYY2 / 4!) - INT(.75 + INT(YYYY2 / 100!) * .75) DAYS! = B2! - B1! END SUB SUB DEZ2BIN (DZ#, BIN$, FILL) STATIC DEZ# = DZ# BIN$ = "" WHILE DEZ# > 0 IF DEZ# - INT(DEZ# / 2) * 2 > 0 THEN BIN$ = "1" + BIN$ ELSE BIN$ = "0" + BIN$ DEZ# = INT(DEZ# / 2) WEND IF FILL > LEN(BIN$) THEN BIN$ = STRING$(FILL - LEN(BIN$), "0") + BIN$ END SUB SUB GETZ (DEZ#, Z$) STATIC IF DEZ# < 10 THEN Z$ = CHR$(48 + DEZ#) ELSE IF DEZ# < 36 THEN Z$ = CHR$(55 + DEZ#) ELSE IF DEZ# = 36 THEN Z$ = "_" ELSE IF DEZ# < 63 THEN Z$ = CHR$(60 + DEZ#) ELSE IF DEZ# = 63 THEN Z$ = "~" ELSE Z$ = "" END IF END IF END IF END IF END IF END SUB - Seite 12 - SUB MKID (DATUM$, MSGID$, ZERID$, CRC32TAB#()) STATIC YYYY = VAL(LEFT$(DATUM$, 4)) MT = VAL(MID$(DATUM$, 5, 2)) DD = VAL(MID$(DATUM$, 7, 2)) HH = VAL(MID$(DATUM$, 9, 2)) MM = VAL(MID$(DATUM$, 11, 2)) SS = VAL(MID$(DATUM$, 13, 2)) CALL DAYDIFF(1970, 1, 1, YYYY, MT, DD, DAYS!) SECS# = DAYS! * 86400! + HH * 3600 + MM * 60 + SS CALL DEZ2BIN(SECS#, BIN$, 28) BIN$ = RIGHT$(BIN$, 28) CALL CRC(MSGID$, CRC32$, CRC32TAB#()) BN$ = FNHEX2BIN$(CRC32$) IF LEN(BN$) < 32 THEN BN$ = STRING$(32 - LEN(BN$), "0") + BN$ BIN$ = BIN$ + BN$ ZERID$ = "" FOR I = 1 TO 55 STEP 6 BN$ = MID$(BIN$, I, 6) CALL BIN2DEZ(BN$, DEZ#) CALL GETZ(DEZ#, Z$) ZERID$ = ZERID$ + Z$ NEXT END SUB - Seite 13 - 3. ZER -> UUCP ______________ Im Folgenden wird die Konvertierung einer Nachricht aus dem Zerberus-Netz in den UUCP-Bereich beschrieben. 3.1 Empfaenger 1 - Befindet sich in der Mail eine "To: "-Zeile, so wird der Empfaenger durch die Empfaengerangabe in dieser Zeile ersetzt. 3.1.1 Makros a - Enthaelt die Empfaengerangabe ein Dollarzeichen ($), werden die ersten beiden Zeichen nach dem Dollarzeichen als "Gateway-Id" betrachtet. Ab dem dritten Zeichen hinter dem Dollarzeichen beginnt die Makronummer. Es wird solange gesucht, bis das erste Zeichen auftritt, das keine Zahl von 0 bis 9 repraesentiert. Ist die so erzeugte Makronummer groesser als 0 und gehoert die Gateway-Id zu einem bekannten (registrierten) Gateway, wird in der Makrotabelle des entsprechenden Gateways nach dem Makro ge- sucht. b - Wurde das Makro gefunden, wird es im Empfaenger ersetzt und die Nach- richt weiterverarbeitet. Wurde es nicht gefunden und stammt es nicht vom eigenen Gateway, wird die gesamte Nachricht an einen User "@.ZER" im Zerberus weitergeleitet. wird dabei durch den Namen des sogenannten "Gateway-Service-Systems" ersetzt. wird durch die Id des Gateways ersetzt, der ueber das "Gateway-Service- System" erreichbar ist. Die gesamte Adresse ist die sogenannte "Ser- vice-Adresse" des entsprechenden Gateways, an die auch Info-Requests und andere Anfragen geschickt werden koennen. Der Gatewaybetreiber bzw. Server-Sysop muss selbst dafuer sorgen, dass die bei der Service-Adresse ankommenden Nachrichten korrekt weitergeleitet bzw. verarbeitet werden. Das Gateway-Service-System muss ein im Zerberus offiziell registriertes Zerberus-System sein. Sinnvollerweise fuehrt man dazu im Gateway eine Tabelle, in der die Gateway-Id's und die zugehoerigen Service-Adressen der Gateways gespeichert sind. Frueher wurde fuer diese Zwecke von uns die Adresse "GATEWAY@.ZER" benutzt. Da aber unter einer Ser- vice-Adresse (Gateway-Server) eventuell mehrere Gateways zu verschie- denen Netzen bedient werden, ist der Username "GATEWAY" nicht eindeutig genug. Daher benutzen wir nun die Id des jeweiligen Gateways als Iden- tifikation. Dies ist auch deswegen die sinnvollste Loesung, weil die Id und das Serversystem die einzigen Informationen sind, die als Identifi- kation fuer den entsprechenden Gateway in der X-Gateway-Zeile zur Verfue- gung stehen. Fuer eine Uebergangszeit koennen auf Servern, die nur EINEN Gateway bedienen, sicherheitshalber beide Service-Adressen gefuehrt wer- den. c - Wurde eine Nachricht wegen eines unbekannten Makros an die Service- Adresse des erzeugenden Gateways weitergeleitet (ge'forward'ed), ist es wichtig, dass in der Kopfzeile der weitergeleiteten Nachricht eine Zeile "To: " vorhanden ist, die die originale Empfaengerangabe enthaelt (mit dem unbekannten Makro). Wichtig ist ebenfalls, dass in einer weiteren Kopfzeile eine Zeile "X-Forward: " vorhanden ist, die aufgebaut ist, wie die "X-Gateway: "-Zeile, also die eigene Gateway-Kennung enthaelt. An der "X-Forward: "-Zeile erkennt der naechste Gateway, dass die Nach- richt schon weitergeleitet wurde und die "To: "-Zeile daher wie eine Zerberus-Empfaengerangabe (aus dem Header) zu behandeln ist. Wichtig ist natuerlich auch, dass eventuell vorhandene Zusatzinformationen ebenfalls in den Kopfzeilen weiter mitgefuehrt werden. Es ist z.B. denkbar, dass ein Gateway aus einem Fremdnetz die Nachricht ins Zerberus weitergelei- tet hat, die ein unbekanntes Makro enthielt. In diesem Fall muss auch die Message-Id aus dem Fremdnetz mitgefuehrt werden und folglich eine "Message-Id: "-Zeile eingefuegt werden. Beispiel: Aus dem Mausnetz kommt eine Nachricht ueber ZERMAUS ins Z-Netz, die an SHGATE weitergeleitet wird und ein Makro des UZERCP-Gates enthaelt, das bei SHGATE unbekannt ist. Folglich wird die Nachricht von SHGATE an UZERCP weitergeleitet. Der Routeweg koennte dann z.B. so aussehen: MAUS- BOX->ZERMAUS->SHGATE->UZERCP->UUCP-SYSTEM. Die Message-Id muesste dann vom SHGATE in einer "Message-Id: "-Zeile zum UZERCP mitgefuehrt werden. 3.2 Empfaenger (Fortsetzung) - Seite 14 - 2 - Befand sich KEINE "To: "-Zeile in der Mail ODER befand sich in der Mail eine "X-Forward: "-Zeile, wird der Empfaenger nach RFC-Prioritaeten (siehe oben) konvertiert und danach werden alle Zeichen nach "klein" gewandelt, ausser den Zeichen, vor denen ein Rueckstrich (\) steht. - Seite 15 - 3.3 Absender 1 - Ausrufezeichen im Absender werden in die Zeichenfolge '#033#' konver- tiert, da dieses Zeichen im UUCP eine Sonderfunktion besitzt (siehe oben). 2 - Dann wird der Absender fuer UUCP zusammengestellt, indem eine Form @.zer.sub.org erzeugt wird, was einfach durch An- haengen der Domain '.zer.sub.org' an den Zerberus-Absender geschieht. Weiterhin wird der gesamte Absender in Kleinbuchstaben gewandelt. 3 - Befand sich KEINE "Message-Id: "-Zeile in einer der ersten Textzeilen der Nachricht, wird der unter (2) erzeugte Absender eingesetzt. Befand sich jedoch eine "Message-Id: "-Zeile in der Nachricht, ist davon aus- zugehen, dass diese Nachricht von einem anderen Gateway stammt, der aus einem Fremdnetz ins Z-Netz gatet und wir muessen eine UUCP-Absenderan- gabe nach folgenden Kriterien erzeugen: Ist in der Nachricht eine "From: "-Zeile vorhanden, muessen wir als Absender EXAKT diese Zeile einsetzen. Ist keine "From: "-Zeile vorhanden (weil die Absenderangabe in das Zerberus-Absenderfeld passte), muessen wir die UUCP-Absenderangabe aus der Zerberus-Absenderangabe erzeugen. Dazu trennen wir aus der Zer- berus-Absenderangabe den Teil vor dem Klammeraffen heraus. Diesen Teil wandeln wir nach den bekannten "Escape-Regeln" in Kleinbuchstaben um und ersetzen das rechts stehende Prozentzeichen (falls mehrere vorhan- den sind) durch einen Klammeraffen. Hier wird auch noch einmal deut- lich, warum jedes Netz, dass nach Zerberus "gatet", eine gueltige, regi- strierte Domain besitzen muss und diese auch bei allen Nachrichten ins Zerberus in der Absenderangabe einfuegen muss: Nur dann entsteht naemlich bei der eben beschriebenen Absender-Wandlung eine gueltige UUCP-Absen- der-Adresse! Andernfalls ist die Absenderangabe nicht nur unbrauchbar, sondern auch unzulaessig und wuerde massive Proteste im UUCP hervorrufen. Andere (denkbare) Absenderwandlungen, die sich am Zerberus-Gatewaynamen orientieren und mit Hilfe des Gatewaynamens eine zugehoerige Domain er- zeugen, sind unzulaessig, da zu EINEM Gatewaynamen NICHT zwingend auch immer nur EINE Domain gehoeren muss (wie z.B. im UUCP). In jedem Fall muessen wir verhindern, dass beliebige Benutzer im Zerberus durch Eingabe einer "Message-Id: "-Zeile und/oder einer "From: "-Zeile in ihrer Nachricht den Gateway "irre" fuehren und ihren Absender auf diese Weise faelschen. Daher muessen wir eine Ueberpruefung durchfuehren. Dies geschieht, indem wir die Message-Id aus der "Message-Id: "-Zeile nach den in 2.4 genannten Regeln in eine gueltige Zerberus-Id umwandeln. Dann vergleichen wir die Id aus dem Header der Nachricht mit der von uns selbst erzeugten Id. Sind die beiden Id's gleich, so koennen wir da- von ausgehen, dass die From-Zeile nicht kuenstlich erzeugt wurde, da eine "From: "-Zeile grundsaetzlich nur zusammen mit einer "Message-Id: "- Zeile vorkommen kann. Daher ist die Korrektheit der "Message-Id: "- Zeile auch ein eindeutiges Indiz fuer die Korrektheit der "From: "- Zeile. Ein "Faelschen" des Absenders ist somit ausgeschlossen. 4 - Befand sich eine "Realname: "-Zeile in der Nachricht, wird dem Absender noch der Realname in runden Klammern nachgestellt. Da wir die Netzadresse (From-Zeile) und den Realnamen (Realname-Zeile) im Zerberus grundsaetzlich getrennt transportieren, koennen wir den Realnamen (sofern vorhanden) IMMER hinter die Adresse stellen. 5 - Nun wird der UUCP-Header nach Bedarf aufgebaut. Hierbei sollte noch ueberlegt werden, wie man die "From:"- und "Reply-To:"-Zeile im UUCP aufbaut. Folgende Entscheidung scheint hier sinnvoll: Fuer den Fall, dass KEINE "Reply-To: "-Zeile in der Zerberus-Nachricht vorhanden ist, setzt man in beide Zeilen den unter (4) erzeugten Absender in UUCP-Domainform ein. Ist jedoch eine "Reply-To: "-Zeile in der Zerberus-Nachricht vor- handen, setzt man beim UUCP-"From:" den unter (4) erzeugten Absender und beim UUCP-"Reply-To: " den in der "Reply-To: "-Zeile der Zerberus- Nachricht stehenden Absender, ein. - Seite 16 - 3.4 Message-Id Nun wird die Message-Id bearbeitet. Es wird, sofern im Nachrichtentext keine 'Message-Id: '-Zeile ist, die die zerberus-interne Id ueberschreibt, an die Id grundsaetzlich .zer.sub.org angefuegt und sie wird in spitze Klammern gepackt (Standard-ID). Eine Umwandlung in Kleinbuchstaben findet NICHT statt, da Zerberus ID's case-sensitive behandelt und die Gross/Kleinschreibung beim Wiedereintritt ins Zerberus sonst nicht mehr re- konstruierbar waere. Befand sich im Text jedoch eine 'Message-Id: '-Zeile, so wird die Id NICHT konvertiert und exakt in der Form weiterverwendet, wie sie in der 'Message-Id: '-Zeile stand. Um auch hierbei (wie bei der From- Zeile) Manipulationen durch Zerberus-Benutzer zu verhindern, die Dupes er- zeugen, muessen wir ebenfalls eine Ueberpruefung durchfuehren, falls dies nicht schon bei 3.3 unter Punkt (3) geschehen ist. Hierzu bilden wir die Zerbe- rus-Id wie im Kapitel UUCP->ZER unter 2.4 beschrieben und vergleichen diese Zeichenfolge mit der Zerberus-Id aus dem Header der Nachricht. Sind beide Id's identisch, ist sichergestellt, dass die Id aus der 'Message-Id: '-Zeile wirklich die originale Id der Nachricht ist und wir koennen sie bedenkenlos in die UUCP-Nachricht einsetzen. - Seite 17 - 4. Probleme/Vorschlaege ______________________ 4.1 Doppel-Adressen Aufgrund der, unter anderem durch die Makros geforderten, Gateway-Eigen- schaften, muss jeder Gateway eindeutig ueber eine Netzadresse im Zerberus zu erreichen sein. Auch fuer Info-Request-Abfragen ist dies notwendig. Gleichzeitig sollen aber - der Vereinheitlichung wegen - alle Gateways die gleiche Netzadresse (UUCP) besitzen. Folglich muss in der Zerberus-Mailbox, die einen Gateway bedient (Server), dieser Gateway ueber zwei Adressen erreicht werden. Zum einen muessen Nachrichten an ein System "@UUCP.ZER" an den Gateway wei- tergereicht werden, zum anderen muss der spezifische Gateway ueber die soge- nannte "Service-Adresse" als User "" (bzw. frueher "GATEWAY") ueber die Mailbox erreichbar sein. Beispiel: Der Gateway "UZERCP" an der A-LINK-H muss ueber die Service-Adresse "UU@A-LINK-H.ZER" (frueher "GATEWAY@A-LINK-H.ZER") erreichbar sein, aber es muessen auch alle Nachrichten an die Adresse "@UUCP.ZER" zum "UZERCP" weitergeleitet werden. Daher wird ein Netzsystem "UUCP" in der A-LINK-H eingetragen, das den Gateway repraesentiert. Gleich- zeitig wird ein User "UU" (frueher "GATEWAY") eingetragen, bei dem ein Stellvertreter "UU@UUCP.ZER" oder "GATEWAY@UUCP.ZER" (je nach Software-Ei- genschaften des Gateways) definiert wird. Alle Nachrichten an die Service- Adresse "UU@A-LINK-H.ZER" werden also an den User "UU" bzw. "GATEWAY" auf dem "UUCP"-Gateway weitergeleitet. Nun ist der Gateway sowohl als UU@A-LINK-H, als auch als UUCP adressierbar. Bei dem oben genannten Beispiel pollt der Gateway die A-LINK-H dann unter dem Namen 'UUCP'. 4.2 Langadressen Als "Langadressen" werden Adressen bezeichnet, die zu lang sind, um im Zer- berus innerhalb der Adresszeile (max. 40 Zeichen) transportiert zu werden. Dieser Umstand machte z.B. die Makro-Generierung noetig. Andererseits sind kurze Adressen auch uebersichtlicher und verstaendlicher fuer den "Laien-Be- nutzer". Makros werden momentan beim Eintritt von Nachrichten aus dem UUCP ins Zer- berus erzeugt. Und dabei wird auch NUR der (zu lange) UUCP-Absender behan- delt. Es ist jedoch auch ohne weiteres denkbar, dass Empfaenger-Adressen, die aus dem UUCP kommen, laenger als 40 Zeichen sind. Dies koennte der Fall sein, wenn der Empfaenger nicht im Zerberus beheimatet ist, sondern in einem ande- ren Netz und Zerberus nur als "Transportmittel" verwendet wird. Da es einen erheblichen Aufwand bedeuten wuerde, auch hier eine Loesung zu implementieren, bleibt dieses Problem vorerst ungeloest. Folglich wird mo- mentan eine zu lange Adresse auf 40 Zeichen gekuerzt und daher als unzu- stellbar behandelt. Der Gateway-Operator muss manuell eingreifen. Die Erfahrung bei UZERCP ueber fast 2 Jahre hat jedoch gezeigt, dass solche Adressierungen nicht vorkommen (bisher jedenfalls). Weiterhin soll Zerberus nicht als Transportmittel in andere Netze "missbraucht" werden. Der Wahlspruch koennte lauten: "Das Netz, das nur auf Umwegen ueber Zerberus erreichbar ist, hat Pech gehabt, wenn es von der Welt abgeschlossen ist!" Auch hier bekommt die Forderung der "GateBau '90" erneut Bedeutung: "Jedes Netz soll sich eine international bekannte Domain zulegen und dadurch regi- strieren lassen". Geschieht dies, sind Probleme mit Ueberlaengen bei Adressen ohnehin ausgeschlossen. 4.3 Fehlsteuerungen Die Steuerung der Konvertierung ueber die ersten Zeilen einer Nachricht mit entsprechenden Kontrollzeilen ("From: ", "To: ", u.s.w.) birgt natuerlich - Seite 18 - die Moeglichkeit in sich, durch gezieltes, manuelles Einfuegen von Fehlinfor- mationen die Gateways "irre" zu fuehren. Da dies jedoch im Wesentlichen nur mit der "From: "-Zeile und der "Message-Id: "-Zeile moeglich ist (falsche Absender und Dupes), wurde weiter oben auf die Kontrollmoeglichkeiten hinge- wiesen, um solche Manipulationen weitgehend auszuschliessen. Andere Manipu- lationen, z.B. an der "To: "-Zeile (in Verbindung mit der "X-Forward: "-Op- tion) fuehren hingegen nur dazu, dass die Nachricht ihren Empfaenger nicht er- reicht. Man kann durch Fehleintraege also den Gateway nur dazu bringen, Dinge zu tun, die mehr oder weniger unsinnig sind. "Kaputt" machen kann man damit nichts. Und wer Wert darauf legt, dass seine Nachrichten ueberall ankommen, der wird ohnehin keine unsinnigen Zeilen in eine Nachricht einfuegen. 4.4 Vorstellungsformular Sollten die in der GateBau '90 und ihren Erweiterungen (zu denen auch diese praktischen "Programmier-Anleitungen" gehoeren) geforderten Gateway-Eigen- schaften als bindend fuer das Z-Netz erklaert werden, hat dies weitreichende Folgen fuer den zukuenftigen Gatewaybetrieb. Die zahlreichen, von Gateways ins Zerberus-Netz geforderten Eigenschaften, machen dann eine zentrale Ueberpruefung, Registrierung und Erfassung noetig, um einen einwandfreien Netzverkehr auch in Zukunft zu gewaehrleisten. Zu der schon immer notwendi- gen technischen Ueberpruefung kompatibler Systeme auf die Einhaltung des Zer- berus Netcall-Formats durch die technische Koordination, muss sich nun fuer Gateways auch eine Ueberpruefung und staendige Kontrolle der Einhaltung der GateBau-Eigenschaften gesellen. Folglich muss von Gateway-Betreibern zur An- schliessung eines Gateways an das Z-Netz in Zukunft auch ein erweitertes Vorstellungsformular fuer Gateways ausgefuellt werden, in dem gewisse Gate- way-Parameter erfasst werden. Schliesslich muss eine der Z-Netz-Systemliste aehnliche Gatewayliste regelmaessig veroeffentlicht werden, damit die Gateway- betreiber ihre Service-Adressliste aktuell halten koennen. Ich schlage daher folgendes Gateway-Vorstellungsformular vor (als Beispiel schon ausgefuellt fuer den UZERCP-Gateway): ------------------------------------------------------------------ Gatewayname: UZERCP Standort: Langenhagen bei Hannover Fremdnetzname: UUCP Zerberus Gatewayname: UUCP.ZER Intern. Fremdnetz-Domain: .zer.sub.org Zerberus-Server: A-LINK-H.ZER (Aquila-Link Hannover) Fremdnetz-Server: veeble.han.de (Public access Unix Hannover) Gateway-Id: UU Gateway-Service-Adresse: UU@A-LINK-H.ZER X-Gateway-Zeile: UU A-LINK-H [UZERCP V3.2] -- -------- ------------------------------ 1 2 3 Pollzeiten Zerberus: 18-21 und 1-4 Uhr Pollzeiten Fremdnetz: 20-23 und 3-6 Uhr Betreiber: Langenhagener Verein f. Sozialarbeit e.V. Adresse: Postfach 1831, 3012 Langenhagen Telefon: 0511-732021/22 Bei Veraenderungen dieser Daten muss die Gateway-Koordination sofort benach- richtigt werden! Ausgenommen von der sofortigen Benachrichtigung ist das Feld 3 der X-Gateway-Zeile (Softwarename und Versionsnummer) ------------------------------------------------------------------