---------------------------------------------------------------------------- So, hier ist der maschinell 'ent-TeX-te' Text der ZConnect 3.1 - Doku der Zerberus GmbH. Ich habe mich bemht, bei der Konvertierung nichts verlo- rengehen zu lassen, kann dafr aber nicht garantieren. Ich hatte auch we- der Lust noch Zeit, den Output von Hand nachzubearbeiten bzw. nachzuforma- tieren. Immerhin ist das Ergebnis von der Form her ja schon wesentlich brauchbarer als das Ausgangsprodukt. Das Dokument enth„lt zwei sich widersprechende Copyright-Hinweise. Ich be- ziehe mich auf den (weiter unten stehenden) Vermerk, wie er auch in der Ori- ginal-ZConnect-Doku auftaucht und nehme mal an, daá der obere Copyright- Hinweis sich auf das Buch in der gedruckten Form bezieht. Trotzdem habe ich beides inhaltlich unberhrt gelassen. (Dieser Absatz ist nur als legal dis- claimer gedacht...). Michael Grube, im Mai 1995 ---------------------------------------------------------------------------- (R) ZCONNECT Das Datenaustauschformat fuer MailBox-Netze Version 3.1 Wolfgang Mexner, Felix Heine, Matthias Jung, Hartmut Schroeder, Martin Husemann, Rena Tangens & padeluun Maerz 1995 ________________________________________________________________________ Copyright und Warenzeichen ________________________________________________________________________ ZERBERUS GmbH, Friedland: ZCONNECT Datenaustauschformat fuer MailBox-Netzwerke, Bielefeld: Verlag Art d'Ameublement, 1994, ISBN 3-9802182-3-6 (c) 1992 Martin Husemann fuer die Version 3.0 des Dokuments und spaeterer Erweiterungen. (c) 1993 Martin Husemann und Christoph Teuber fuer die Teile, die die Integration von PGP in ZCONNECT betreffen. (c) 1994 ZERBERUS Gesellschaft fuer Kommunika- tion mbH, Friedland, fuer diese Zusammen- stellung. Dieses Werk ist urheberrechtlich geschuetzt. Alle Rechte, auch die der Uebersetzung, des Nachdrucks und der Vervielfaeltigung vorbehalten. Ohne ausdrueckliche, schriftliche Genehmigung des Verlages ist es nicht gestattet, das Buch oder Teile daraus in irgendeiner Form durch Fotokopie, Mikroolm oder ein anderes Verfahren, auch nicht fuer Zwecke der Unterrichtsgestaltung, zu reproduzieren oder unter Verwendung elektronischer Systeme zu verarbeiten, vervielfaeltigen oder zu verbreiten. Dasselbe gilt fuer das Recht der oeffentlichen Wiedergabe. Verlag : Art d'Ameublement, Bielefeld Satz : TEX Belichtung : HP LaserJet III auf Folie Druck : OFF//SET Druckerei im Umweltzen- trum, Bielefeld Eingetragene Warenzeichen: Die in den Dokumentationen und im Programm genannten Programm- und Verfahrensnamen sind moeglicherweise urheber- ii_____________________________________________Copyright_und_Warenzeichen_ rechtlich und/oder warenzeichenrechtlich geschuetzt. Fehlende Hin- weise auf bestehende Urheberrechte oder Warenzeichen berechti- gen nicht zu der Annahme, dass ein solches nicht existiert. - ZERBERUS ist ein eingetragenes Warenzeichen der ZERBERUS GmbH, Deutschland - ZCONNECT ist ein eingetragenes Warenzeichen der ZERBERUS GmbH, Deutschland - Zmodem ist ein eingetragenes Warenzeichen der Omen Technology, Inc., USA - PKzip und PKunzip sind eingetragene Warenzeichen der PKWARE, Inc., USA - IBM, PS/2 und OS/2 sind eingetragene Warenzeichen der Internatio- nal Business Machines Corporation, USA - MS-DOS, GW-BASIC, MS-Windows und MS-Word sind eingetra- gene Warenzeichen der Microsoft Corporation, USA - Fido und FidoNet sind eingetragene Warenzeichen von Tom Jennings, Fido Software, USA - UNIX ist ein eingetragenes Warenzeichen der AT&T, Inc. und USL, Inc. - RSA ist ein eingetragenes Warenzeichen der RSA Data Security, Inc. - PGP ist ein eingetragenes Warenzeichen von Phil Zimmermann. ________________________________________________________________________ Inhaltsverzeichnis ________________________________________________________________________ I Einleitung 1 I.1 Danksagung : : : : : : : : : : : : : : : : : : : : 1 I.2 Copyright : : : : : : : : : : : : : : : : : : : : : 2 II Die Datenuebertragung 3 II.1 ZCONNECT implementieren : : : : : : : : : : : : : 3 II.2 Gesamtablauf : : : : : : : : : : : : : : : : : : : 3 II.3 Login : : : : : : : : : : : : : : : : : : : : : : : : 7 II.4 Grundlagen des ZCONNECT-Protokolls : : : : : : 8 II.4.1 Aufbau eines Blocks : : : : : : : : : : : 10 II.4.2 Protokollablauf : : : : : : : : : : : : : : 11 II.5 Header fuer Systeminformationen : : : : : : : : : 14 II.6 Header zur Verbindungssteuerung in der Datenaustausch-Phase : : : : : : : : : : : : : : 24 III Das Datenformat 35 III.1 Vor dem Transport : : : : : : : : : : : : : : : : 35 III.2 Nach dem Transport : : : : : : : : : : : : : : : 36 III.3 Inhalt : : : : : : : : : : : : : : : : : : : : : : : : 37 III.4 Header : : : : : : : : : : : : : : : : : : : : : : : 38 III.5 Adressen : : : : : : : : : : : : : : : : : : : : : : 39 III.6 Brettnamen : : : : : : : : : : : : : : : : : : : : 40 III.7 Weiterleiten : : : : : : : : : : : : : : : : : : : : 41 III.8 Automatisches Weiterleiten (Mailing-Listen, Netzwerk-Verteiler) : : : : : : : : : : : : : : : : 43 III.9 Weiterleitungen durch Netzwerk-Vertreter : : : 44 III.10 Beispiel : : : : : : : : : : : : : : : : : : : : : : : 44 III.11 Moegliche Header-Informationen : : : : : : : : : 45 III.12 Weitere Headerzeilen : : : : : : : : : : : : : : : 61 III.13 Verschluesselung von Nachrichten mit PGP : : : 62 iv_______________________________________________________Inhaltsverzeichnis_ III.13.1 Ziele der PGP Integration : : : : : : : : 63 III.13.2 Key Repraesentation : : : : : : : : : : : : 64 III.13.3 Unterschriften : : : : : : : : : : : : : : : 65 III.13.4 ZCONNECT Key Requests : : : : : : : 66 III.13.5 Durch PGP geaenderte Headerzeilen : : : 66 A Empfehlung fuer den 'MAPS-Roboter' 67 A.1 Allgemeines : : : : : : : : : : : : : : : : : : : : 67 A.2 Standardbefehle : : : : : : : : : : : : : : : : : : 67 A.2.1 HELP : : : : : : : : : : : : : : : : : : : : 68 A.2.2 LIST : : : : : : : : : : : : : : : : : : : : 68 A.2.3 ADD : : : : : : : : : : : : : : : : : : : : : 69 A.2.4 DEL : : : : : : : : : : : : : : : : : : : : : 69 A.3 Erweiterte Befehle : : : : : : : : : : : : : : : : : 69 A.3.1 HOLD : : : : : : : : : : : : : : : : : : : : 69 A.3.2 INDEX : : : : : : : : : : : : : : : : : : : 70 A.3.3 ORDER : : : : : : : : : : : : : : : : : : : 70 A.4 Anmerkungen : : : : : : : : : : : : : : : : : : : 71 ________________________________________________________________________ Kapitel I: Einleitung ________________________________________________________________________ Der ZCONNECT-Standard beschreibt den Datenaustausch zwischen verschiedenen Systemen in einem MailBox-Netzwerk. Die Ver- fahren wurden entworfen und ausgewaehlt mit Blick auf moegli- che Erweiterbarkeit ohne Aenderungen in der darauf basierenden Software und der moeglichst einfachen Konvertierbarkeit in andere Datenformate. Hierbei wurden speziell das alte Z-NETZ Format und das InterNet/UseNet Datenformat (s. RFC821/822/1036) beruecksichtigt. Ergebnis ist nun ein hinreichend einfaches, aber gleichzeitig sehr maechtiges Verfahren. Da ZCONNECT auf den Erfahrungen der genannten Protokolle aufsetzt, aber komplett neu entworfen wurde, konnte eine sehr viel kompaktere und schlichtere Struktur bei gleicher Leistungsfaehigkeit erreicht werden. Wir beschreiben die unterschiedlichen Protokollebenen in drei Kapiteln. Zunaechst wird die eigentliche Datenuebertragung (Online-Phase) erlaeutert. Im zweiten Kapitel stellen wir die ueber- tragenen Daten und damit das Nachrichtenformat vor. Schliess- lich onden Sie im Anhang eine Beschreibung eines Befehlsvorrats eines MAPS-Roboters, der automatisch Brettbestellungen fuer an MailBox-Systeme angeschlossene Points durchfuehrt. Hinweis: In der deutschen Sprache gibt es leider noch keinen neutralen Ausdruck fuer Personen, der beide Geschlechter umfasst. Da wir den Text nicht durch bestaendige Nennung beider Formen unnoetig kompliziert machen wollten, verwenden wir in dieser Dokumenta- tion ausschliesslich die weibliche Form. Selbstverstaendlich sind mit den Bezeichnungen Absenderin, Empfaengerin, Systembetreiberin etc. die entsprechenden maennlichen Personen mitgemeint. I.1 Danksagung Wir danken dem FoeBuD e.V. fuer ein Dauertestsystem, Peter Mandrella, Marc Zimmermann und allen anderen Point-Programmiererinnen sowie Frank Scheizel fuer viele Tips und Anregungen, Christian Mock fuer die Zusendung der Zeitzonentabelle (zusammengestellt von Gary Dixon), Hans-Christian Fricke, Garry Glendown, Michael Grube, Toni 2_____________________________________________________Kapitel_I:_Einleitung_ Guenzel-Peltner, Joachim Haas, Daniel Kroening, Holger Lembke, Dirk Meyer, Helmut Neumann, Sandro Paolino, Goetz Schuchard, Ralph Seichter, Christoph Teuber, Oliver Wagner, Matthias Watermann und Andreas Wittkemper fuer die Mitarbeit im ZCONNECT-Wahlgremium, Hinrich Donner fuer die Moderation der ZCONNECT-Wahlen, Andrea Hildebrand und allen anderen, die uns bei diesem harten Stueck Arbeit unterstuetzt haben. Insbesondere gilt unser Dank Hartmut Schroeder und Martin Husemann, ohne die es ZCONNECT nie gegeben haette. I.2 Copyright Alle Rechte liegen bei den Autorinnen. Dieses Dokument darf beliebig vervielfaeltigt und unveraendert weitergegeben werden. ZCONNECT darf unveraendert in allen (auch kommerziellen) Applika- tionen lizenzfrei implementiert werden. In diesem Fall muss in der jeweiligen Dokumentation und im jeweiligen Programm an glei- cher Stelle wie die Nennung der Programmautorinnen der Hin- weis: '(c) fuer ZCONNECT: ZERBERUS GmbH, Fried- land (FRG). ZCONNECT ist ein eingetragenes Warenzeichen der ZERBERUS GmbH, Friedland (FRG)' beziehungsweise eine Ueber- setzung in der Landessprache des jeweiligen Programms erschei- nen. Werden in einem Programm keine Autorinnen oder Rechte genannt, muss der Hinweis an angemessener Stelle erfolgen. Die Dokumentation kann im Buchhandel unter der interna- tionalen Bestellnummer ISBN 3-9802182-3-6 oder direkt bei der ZERBERUS GmbH bestellt werden (Vorkasse, Scheck oder bar). Die Doku ist im Format DIN A5, gebunden, mit einer Diskette verse- hen und kostet 30 DM. ________________________________________________________________________ Kapitel II: Die Datenuebertragung ________________________________________________________________________ II.1 ZCONNECT implementieren Sie koennen seit etwa Mitte 1993 einen Auszug aus einem C-Source kostenlos erhalten, der das hier beschriebene Protokoll implemen- tiert. Auf der Basis dieses Quelltextes werden Sie sicher schnell zu einer eigenen Version gelangen und insbesondere die kosteninten- sive und muehselige Online-Testphase verkuerzen. Aber auch wenn Sie nicht in 'C' arbeiten, werden Sie mit wenig Aufwand die Uebertragungsphase realisieren koennen. Sie benoetigen dazu: o Eine 16-bit CRC Routine nach dem kX-Modem Polynom o Eine Verwaltung fuer 'Header' (siehe unten) o Dateitransportprotokolle (z.B. Z-Modem), die Sie aber auch als externe Programme aufrufen koennen. In der folgenden Beschreibung werden Texte gelegentlich in C- Notation angegeben. Hier ein kurze Erlaeuterung: \r Return, Dezimal 13, Hex. 0D \n Newline, , Dezimal 10, Hex. 0A Die Anfuehrungsstriche (") gehoeren nicht zu den Texten, son- dern dienen nur deren Begrenzung. II.2 Gesamtablauf Grobskizze eines kompletten Verbindungsaufbaus: 1. Login (einmalig) 2. Austausch der Systeminformationen (einmalig) 3. Austausch von Daten (mehrmals hintereinander) 4. Logoff (einmalig) Eine etwas feinere Skizze des Verbindungsaufbaus fuer die Anrufe- rin (ohne Fehlerkorrektur): 1. Vorbereitungsphase (noch oOine) o Auswahl der anzuwaehlenden MailBox 4_________________________________________Kapitel_II:_Die_Datenuebertragung_ o Falls Daten fuer die MailBox vorhanden sind, diese packen o Verbindung zur anderen MailBox herstellen 2. Loginphase (Online) Warten auf Username ! Usernamen 'zconnect' eingeben Warten auf Passwort ! Passwort '0zconnec' eingeben Warten auf 'BEGIN' 3. Austausch der Systeminformationen ! Senden der eigenen Systeminformationen Empfangen der Systeminformationen des anderen o Ermitteln der Gemeinsamkeiten ! Senden der endgueltigen Verbindungsdaten, die fuer diese Verbindung gelten Empfangen der Bestaetigung der endgueltigen Daten 4. Datenaustausch ! Senden der Anforderung (z.B. 'Mails holen', 'Mails senden' oder 'Mails holen und senden') Empfangen der Rueckmeldung (z.B. Meldung, wieviel kByte an Mails bereitliegen) ! Aufforderung zum Ausfuehren des Kommandos oder Senden einer Abbruch-Aufforderung Empfangen der Bestaetigung des Kommandos Gegebenenfalls warten, bis Mails bereitgestellt sind Umschalten auf Filetransferprotokoll, Daten holen, zurueckschalten auf ZCONNECT 5. Weiterer Datenaustausch ! Senden der naechsten Anforderung (z.B. Mails senden) Empfangen der Bestaetigung ! Senden, ob Anforderung auch ausgefuehrt werden soll Empfangen der Bestaetigung der Kommandos ! Umschalten auf Filetransferprotokoll, Daten senden, zurueckschalten auf ZCONNECT 6. Logoff ! Senden der Logoffanforderung Empfangen der Bestaetigung der Logoffanforderung II.2:_Gesamtablauf______________________________________________________5 ! Senden der endgueltigen Logoffanforderung Empfangen Bestaetigung Logoff 7. Nacharbeiten (OOine) o Merken der neuesten Parameter der Box, die angerufen wurde o Files und Mails loeschen, die nicht mehr gebraucht wer- den o Verarbeiten (Einsortieren der empfangenen Mails) Eine etwas feinere Skizze des Anrufes fuer die angerufene MailBox (ohne Fehlerkorrektur): 1. Loginphase Verbindung wird hergestellt (Online) ! Loginmeldung senden (kurz, da sie nicht abgebrochen wird!) ! Senden 'Username:' Empfangen des Usernamens 'zconnect' ! Senden 'Passwort:' Empfangen des Passwortes '0zconnec' o ZCONNECT Uebertragungsmodul aktivieren Das ZCONNECT-Uebertragungsmodul macht nun folgendes: ! Senden drei mal 'BEGIN\r\n' mit je 0,5 Sekunden Pause. Nach dem letzten 'BEGIN' erfolgt eine Pause von 1 Sekunde. Die Zeitspanne von 'Username:' bis zum letzten 'BEGIN' darf maximal 2 Minuten betra- gen. 2. Austausch Systeminformationen Empfangen der Systeminformationen des anderen ! Senden der eigenen Systeminformationen Empfangen der endgueltigen Verbindungsdaten ! Senden der Empfangsbestaetigung 3. Datenaustausch Empfangen der Anforderung (z.B. welche Mailtypen sollen gesendet oder empfangen werden) o Ueberpruefen und schaetzen, wie lange das Bereitstellen der Daten dauern wird - diese sollten normalerweise gepackt bereitliegen. Packzeiten treten nur bei einem 6_________________________________________Kapitel_II:_Die_Datenuebertragung_ Umpacken auf einen neuen Packer auf, sowie eventuelle Kopierzeiten. ! Senden der Bestaetigung, welche der gewuenschten Infor- mationen verfuegbar sind (PUT), wie lange es dauern wird diese bereitzustellen und welche Mailtypen von der Gegenstelle gewuenscht sind. Hier kann die angeru- fene auch bereits mitteilen, dass sie gar nichts hat. Empfangen der Bestaetigung des Kommandos und der Mitteilung ob die Gegenstelle die Daten nun endgueltig haben moechte (EXECUTE und WAIT), oder ob die Daten (dieses bezieht sich nur auf das aktuelle Mailpaket) z.B. erst nach dem Logoff vorbereitet werden sollen. ! Senden der Bestaetigung ! Senden 'Warten, bis Packen beendet' (optional), sofern eine Wartezeit > 0 Sekunden angegeben wurde. o Packen der Nachrichten ! Senden 'Packen beendet', sofern eine Wartezeit > 0 Sekunden angegeben wurde. ! Umschalten auf Filetransferprotokoll, Daten senden und/oder empfangen, zurueckschalten auf ZCONNECT 4. Weiterer Datenaustausch und Logoff Der weitere Datenaustausch erfolgt wieder analog dem ersten Zyklus. Die Kontrolle behaelt hierbei immer die Ange- rufene. Die Angerufene hat nun die Moeglichkeit, nur einen Teil der Daten bereitzustellen, oder den Transfer (z.B. die Festplatte ist voll oder das Kommando unbekannt) vollstaen- dig abzulehnen. Die Anruferin wird solange Mailpakete von der Gegenstelle anfordern, solange diese mitteilt, dass noch Archive zur Uebertragung bereitliegen. Vor jedem Aufruf des Transferprotokolls kann ueber 'Wait' eine Wartezeit verein- bart werden. Die Verbindung wird beendet, wenn eine Seite in einem Paket eine Logoff-Aufforderung sendet, was jeder- zeit erfolgen kann. Der Verbindungsabbruch erfolgt jeweils nach einem vollstaendigen Zyklus. Ein sofortiger Verbin- dungsabbruch erfolgt, wenn das aufgerufene Uebertragungs- protokoll einen Fehler gemeldet hat. Das zuletzt uebertragene Datenpaket wird in diesem Falle als nicht uebertragen gewer- tet. II.3:_Login_____________________________________________________________7 5. Nacharbeit (OOine) o Merken der neuesten Parameter der Box, die angerufen hat. o Vorbereiten der Datenarchive, die mit dem Kommando EXECUTE: L erst nach dem Logoff bereitgestellt werden sollten. o Files und Mails loeschen, die nicht mehr gebraucht wer- den o Verarbeiten (Einsortieren der empfangenen Mails) II.3 Login Wir haben das Login-Verfahren festgeschrieben1, damit alle ZCONNECT-MailBoxen weltweit Datenaustausch selbstaendig durch- fuehren koennen - auch wenn die Systeme noch nie vorher mitein- ander kommuniziert haben. Dabei geht das Login-Verfahren von drei Bedingungen aus: 1. Der Einlogname ist immer identisch, ebenso das Passwort. Dadurch ist es moeglich, ZCONNECT als Benutzerin in ein System einzutragen, das ansonsten keinen Eingriff in die Einlogprozedur erlaubt (z.B. VMS oder UNIX), dann aber, sobald der allgemeine ZCONNECT-Login gelungen ist, noch- mal Systemname und Passwort abzufragen. 2. Manche Systeme erlauben kein Login ohne Passwortab- frage oder erzwingen bestimmte (kryptische) Passworte. Wir haben daher Login und Passwort deoniert, nicht wie in alten Verfahren nur das Login. 3. Nicht immer kann die Formulierung der Login- oder Passwortabfrage konoguriert werden, auch ein Abbruch der Titelmeldung vor dem Login ist nicht systemunabhaengig deonierbar. Daher hat die Anruferin auf eine Vielzahl von Schluesselwoertern zu reagieren und anschliessend noch eine Pause abzuwarten (damit das Schluesselwort zur Not auch in die Titelmeldung geschrieben werden kann). Die Senderin wartet solange, bis die Empfaengerin in ihrer Loginmeldung einen der folgenden Strings sendet: 'ogin', 'OGIN', 'ame', 'AME' und eine Uebertragungspause von einer Sekunde gefolgt ist. Sendet die angerufene MailBox nichts, schickt die Anruferin nach 10 Sekunden '\r' (nur '\r', kein '\n', da dieses _________________________1 im Gegensatz z.B. zu UUCP 8_________________________________________Kapitel_II:_Die_Datenuebertragung_ auf einigen Betriebssystemen Probleme beim Einloggen verursa- chen kann2) und wartet wiederum auf die Einloganforderung. Bei erkannter Login-Anforderung sendet die Anruferin den Benutzernamen 'zconnect\r'. Erhaelt sie darauf innerhalb von 10 Sekunden keine Antwort, sendet sie '\r' und wartet wieder auf einen der o.g. Strings. Es sollten mindestens drei Versuche gestartet werden, bevor bei Misserfolg die Verbindung abgebro- chen wird. Die Empfaengerin antwortet bei Erhalt des Antwortstrings durch Senden der Passwortabfrage, in der einer der Strings 'word', 'WORD', 'wort' oder 'WORT' enthalten sein muss. Erhaelt die Empfaengerin keine Reaktion von der Senderin, so sendet diese von sich aus alle 2 Sekunden erneut den zuletzt gesendeten String. Die Senderin schickt darauf das Passwort '0zconnec\r'. Wird innerhalb von 10 Sekunden nicht geantwortet, sendet sie '\r' und wartet nun erneut auf die Passwortabfrage oder die Login-Frage. Nach dem Erhalt des '0zconnec\r' startet die Empfaen- gerin die ZCONNECT-Uebertragung. Dazu sendet sie dreimal den String 'BEGIN\r' mit jeweils 0,5 Sekunden Pause dazwischen und 1 Sekunde Pause danach. Dieses signalisiert der Anruferin, dass das Login gelungen ist und der Transfer beginnen kann. Die Ver- bindung wird abgebrochen, wenn das Login nicht innerhalb von 2 Minuten vollendet wird. Nach Erhalt des Strings 'BEGIN\r' geht auch die Anruferin in den Transfermodus. II.4 Grundlagen des ZCONNECT-Protokolls Eins der Hauptprobleme eines geregelten Filetansfers zwischen Systemen mit wechselnden Anforderungen ist eine moeglichst AEe- xible Deonition des Datenuebermittlungsprotokolls. Beim alten ZERBERUS-Netcallprotokoll (das im Hitchhikers Guide to Zerbe- rus Netcalls' von Patrick Schaaf dokumentiert wurde und vom ZERBERUSMailBox Programm bis Version 4.0 sowie von den diver- sen ZERBERUS-netcallkompatiblen Programmen verwendet wurde) war es nicht moeglich, mehr als ein Mailole auszutauschen, Files zu requesten oder ein Teil der Daten von der Gegenstelle auch mal einfach loeschen zu lassen, ohne sie zu uebertragen. Leider kann man sich ein AEexibleres Protokoll nur durch gestie- gene Komplexitaet erkaufen. Wir haben zwar versucht, es so ein- _________________________2 z.B. OS-9 II.4:_Grundlagen_des_ZCONNECT-Protokolls________________________________ 9 fach wie moeglich zu gestalten, jedoch wurde bei der Abwaegung Flexibilitaet Einfachheit, der Flexibilitaet der Vorzug gegeben. Anforderungen: o Flexibel, d.h. die Protokollinformationsdaten muessen erwei- tert werden koennen - ohne wiederum ein neues Protokoll deonieren zu muessen o Verschiedene Uebertragungsprotokolle. Die Daten muessen mit verschiedenen Protokollen (z.B. ZModem, BiModem, ftp) uebertragen werden koennen - ohne dass die Systembe- treuung dies jeweils einstellen muss. o Neue Anforderungen automatisch mit der Gegenseite absprechen. Sollte z.B. das Packerformat gewechselt werden, muessen beide automatisch auf das neu eingestellte Format gehen - oder sich auf dasselbe Format einigen (falls das Gewuenschte bei der Gegenseite nicht verfuegbar ist), ohne dass die Sysstembetreuung es einstellen muss und ohne dass deshalb ein Netcall missglueckt. o Die Anruferin waehlt aus, was sie haben will. Diejenige, die die Leitungskosten traegt, sagt auch, was sie wie haben will und was nicht, z.B. Eilmails abliefern, aber die oeffentlichen Nachrichten bis zum naechsten Anruf liegenlassen (und in der Zwischenzeit vorpacken). o Teilweise korrekt uebertragene Daten muessen soweit wie moeg- lich akzeptiert werden. Beim naechsten Anruf werden nur die fehlerhaften Daten wiederholt. o Das Protokoll selber muss so ausgelegt sein, dass es auch auf Verbindungwegen funktioniert, die nicht vollkommen daten- transparent sind. Bestes Beispiel ist das normale Datex-P Prool. Bedingung: es gelten nur CR und alle ASCII-Zeichen von hex 20 bis hex 7E. Nach dem Login werden Informationen nach einem relativ ein- fachen, aber AEexiblen Verfahren ausgetauscht. Das Protokoll hat ein gleichbleibendes Grundmuster: Es werden abwechselnd Bloecke untereinander ausgetauscht bis ein anderes Protokoll (zum Dateitransfer) aufgerufen wird. Danach geht der gegenseitige Austausch von Bloecken weiter. Ein Block wird von der anderen Station positiv bestaetigt (der Anwort- Block kann natuerlich wiederum neue Informationen enthalten) oder abgelehnt. Falls keine Bestaetigung empfangen wird, wird der- 10________________________________________Kapitel_II:_Die_Datenuebertragung_ selbe Block nach einer Timeoutzeit von 30 Sekunden noch einmal gesendet und wieder auf Bestaetigung gewartet. Die Bloecke sind durchlaufend numeriert, damit keine Verwechs- lungen auftreten koennen. II.4.1 Aufbau eines Blocks Das gesamte ZCONNECT-Online-Protokoll basiert auf dem Aus- tausch von Bloecken. Es handelt sich dabei um Datenpakete varia- bler Laenge - maximal ist ein Block (einschliesslich der Blockende- Zeichen) 32 kByte gross. Jeder Block ist in mehrere Zeilen unter- teilt, die durch ein '\r' (CR) getrennt werden. In jeder Zeile beondet sich ein Header (wie auch in den ZCONNECT-Daten, siehe unten), also eine alphanumerische Kennung gefolgt von einem Doppelpunkt ':' sowie der Nutzinformation bis zum Zeilenende. (Im Gegensatz zum Nachrichtenformat sind hier keine Leerzeichen oder Tabulatoren zwischen dem ':' und dem Inhalt erlaubt.) In einem Block sind nur folgende ASCII-Zeichen zugelassen: o Hex. 20 (dezimal 32) bis Hex. 7E (dez 127) einschliesslich o CR, Hex. 0d (dezimal 13) Alle anderen Zeichen werden als nicht uebertragen gewertet, also von der Empfaengerin ignoriert - so auch Linefeeds. Das Zeichen CR gilt als Zeilentrenner. Zwei direkt aufeinander folgende CR's markieren das Block-Ende. \r Zeilentrenner \r\r Blockende Es empoelt sich aus Sicherheitsgruenden, auch vor dem Block- Anfang zwei Zeilentrenner zu senden, da einzelne Zeilentrenner vor einem Block ignoriert werden. Header duerfen mehrfach in einem Block auftreten (also meh- rere Zeilen mit derselben Kennung), wenn das sinnvoll ist. Ueber jeden Block wird eine Pruefsumme auf Basis eines 16-Bit CRC nach X-MODEM Polynom errechnet. Diese Pruefsumme wird dann im Block selber mitgesendet. Dies geschieht auf einer Zeile mit der Kennung 'CRC'. Die Pruefsumme wird in grossgeschriebe- nen Hexadezimalzahlen (vierstellig mit fuehrenden Nullen) angege- ben. Diese Zeile sowie alle '\r' gehen nicht mit in die Pruefsumme ein. Der CRC muss daher nicht an einer bestimmten Position im Block stehen. Der CRC muss auch bei gesicherten Verbindungen uebertragen werden. II.4:_Grundlagen_des_ZCONNECT-Protokolls________________________________ 11 Weiterhin erhaelt jeder Block eine eindeutige Kennung, die seine Verwendung/Bedeutung im Protokollablauf deoniert. Diese Zeile hat die Kennung 'STATUS'. Als Daten in dieser Zeile gibt es derzeit: BLKn Datenblock (n von 1 bis 4, je nach Phase des Protokolls) ACKn Empfangsbestaetigungen auf den entsprechenden BLKn (daher auch n von 1 bis 4) NAK0 negative Empfangsbestaetigung: der Block wurde empfangen, ist aber ungueltig (z.B. falscher CRC durch Uebertragungsfehler) TMEn Umschaltungsblock fuer Erhaltung der Uebertra- gungsrichtung (n von 1 bis 4) EOTn Protokolluebergaenge und Abschlusszeichen (n von 1 bis 4) BEGn Bestaetigungen, dass das Datenpacken beendet wurde (n von 5 bis 6) EOTn Empfangsbestaetigung auf empfangene BEGs, Protokolluebergaenge und Abschlusszeichen (n von 5 bis 6) Hier ein Beispiel fuer einen gueltigen Block (Das '\r' am Zei- lenende steht fuer das als Zeilentrennung): SYS:BI-LINK\r SYSOP:Postmaster\r TEL:1 +49-521-19304\r PROTO:ZMODEM\r PASSWD:GUEST\r STATUS:BLK1\r CRC:F32C\r \r Hinweis: Der angegebene CRC-Wert ist falsch, der Block ist als BLK1 auch nicht komplett, er dient hier nur als Beispiel fuer den Block- Aufbau. II.4.2 Protokollablauf Die Senderin fordert Information durch einen BLK1 an. Die Emp- faengerin bestaetigt den korrekten Empfang durch Senden eines ACK1; eine falsche Pruefsumme wird durch Senden eines NAK0 ange- zeigt. In einem solchen Fall muss der BLK1 wiederholt gesendet wer- den. 12________________________________________Kapitel_II:_Die_Datenuebertragung_ Ein richtig empfangener ACK1 auf der Senderseite wird durch Senden eines TME1 bestaetigt, um die Gegenseitigkeit des Protokolls beizubehalten. Ein TME wird nicht durch ein ACK bestaetigt, sondern durch Senden eines BLK (BLK2 in diesem Fall). Ab jetzt laeuft alles wie vorher, nur mit vertauschten Rollen. Es passiert also abwechselnd ein Austausch von BLK, ACK, TME, BLK, ACK usw. bis zu ACK4, danach kann mit einem TME4 von der Empfaengerin die Fortsetzung des Protokolls mit einem BLK1 gefor- dert werden3. Durch Senden von drei EOT4 hintereinander (mit einer Sendepause von mindestens 1 Sekunde dazwischen) wird der Beginn eines anderen Uebertragungsprotokolls (z.B. ZMODEM um eine Datei zu uebertragen) oder des 'Warten auf Aktion' mar- kiert. Danach gehen beide wieder auf das ZCONNECT-Protokoll. Wenn die Uebertragung fehlerhaft gewesen sein sollte, erfolgt hier ein sofortiger Verbindungsabbruch und bei Bedarf eine erneute Anwahl des Systems. Ein Verbindungsabbruch erfolgt auch, wenn anhand des (optionalen) BYTE Headers festgestellt wird, dass das zu uebertragende Datenpaket nicht vollstaendig empfangen wurde. War die Uebertragung erfolgreich, so sendet die Angerufene solange NAK0, bis sich der Sender wieder mit einem BLK1 meldet. Die Daten gelten als erfolgreich uebertragen, wenn dieser BLK1 nun vom Empfaenger mit einem ACK1 bestaetigt wurde. Ohne diesen Hand- shake nach dem Protokolltransfer wird jeweils das zuletzt aus- getauschte Datenpaket (beim Vollduplex-Protokoll empfangenes und gesendetes Datenpaket) beim naechsten Anruf erneut uebertra- gen, auch wenn das Uebertragungsprotokoll keinen Fehler gemel- det hat, da die Uebertragungsprotokolle nicht unbedingt auf beiden Seiten einen Fehler melden muessen. Die in einem frueheren Zyklus uebertragenen Mailpakete werden nicht erneut uebertragen. Zu beachten ist, dass EOT4 bzw. EOT6 nur ein Endzeichen fuer die Synchronisation der Wartezeit ist. Die Information, ob und welches Uebertragungsprotokoll gestartet werden soll, wurde schon vorher in BLK4 und/oder BLK3 uebertragen. Das Warten auf Aktionen vor der Fileuebertragung ist optional und erfolgt nur, wenn entweder Senderin oder Empfaengerin mit dem Kommando WAIT eine Wartezeit gefordert haben. Ein War- _________________________3 Durch Senden eines TME4 kann daher auch der Transfer eines Mailpa- ketes abgelehnt werden - dieses wird bei ZERBERUS Version 5.2 derzeit ver- wendet, wenn keine Daten zur Uebertragung bereitliegen. Neuere ZCONNECT- Implementationen kuendigen dieses korrekter durch einen leeren PUT Header an. II.4:_Grundlagen_des_ZCONNECT-Protokolls________________________________ 13 tezeit wird meist nur dann gefordert, wenn die Bereitstellungs- zeit laenger als 10 Sekunden dauert. Haben sowohl Senderin als auch Empfaengerin WAIT: 0 vereinbart (oder gar kein WAIT Kom- mando geschickt), so beginnt der Protokolltransfer nach dem drit- ten EOT4. Wenn z.B. die Senderin warten soll, damit die Empfaengerin Zeit hat, ihr Mailarchiv zu packen (nur die seit dem letzten Packen hinzugekommenen Daten im ZCONNECT werden vorgepackt gespei- chert und neue adaptiv gepackt), stellt die Senderin nach dem Senden des letzten EOT4 die Uebertragung ein und komprimiert ihr Archiv. Wenn sie fertig ist, zeigt sie der Senderin dies durch Sen- den eines BEG5 (vorher Empfangspuffer loeschen) an. Diese zeigt durch dreimaliges Senden eines EOT5 an, dass sie verstanden hat. Hatte auch die Senderin etwas zu packen, so sendet diese nach dem Packen zunaechst ein BEG6, welches von der Empfaengerin mit drei EOT6 bestaetigt wird, sofern diese zum Empfang schon bereit war. Ist diese dagegen noch beim Bereitstellen, wird sie dagegen zunaechst mit einem BEG5 melden, welches von der Empfaengerin dann mit EOT5 bestaetigt wird, hiernach erfolgt dann nochmal der BEG5/EOT6-Austausch. Nach dem Uebertragen des EOT6 beginnt dann der eigentliche Datentransfer. Hatte die Senderin nichts zu packen, so entfaellt der BEG5/EOT5 Austausch. Nun koennen beide mit dem eigentlichen Uebertragen (externes Fileprotokoll) beginnen. Wenn ein beidseitiger Datenaustausch vereinbart wurde (PUT: und GET: im gleichen Block) und kein bidirektionales Protokoll verwendet wird, sendet hier zunaechst ________________________________________________________________________ ZCONNECT beim Austausch der Steuerinformationen: Send.: BLK1 TME1 ACK2 BLK3 TME3 ACK4 BLK1 u.s.w. Empf.: ACK1 BLK2 TME2 ACK3 BLK4 TME3 ACK1 ZCONNECT mit Packen und externem Uebertragungsprotokoll: Send.: ACK4 -Packen- EOT5-EOT5-EOT5 BEG6 ZMODEM Empf.: BLK4 EOT4-EOT4-EOT4 -Packen- BEG5 EOT6-EOT6-EOT6 ZMODEM ________________________________________________________________________ Abbildung II.1: Darstellung der Reihenfolge der uebertragenen ZCONNECT-Bloecke 14________________________________________Kapitel_II:_Die_Datenuebertragung_ die Anruferin, direkt danach sendet die angerufene MailBox.4 Die Anruferin hat darauf zu achten, dass generell immer nur ein Daten- paket angefordert wird - die gleichzeitige Anforderung eines Mail- paketes und eines Filerequests ist unzulaessig. Ein bidirektionaler Datentransfer kann von der Anruferin prinzipiell mit EXECUTE: N abgelehnt werden. In diesem Falle muss die Anruferin die Kom- mandos aufsplitten und der Angerufenen einzeln vorlegen. II.5 Header fuer Systeminformationen Nachfolgend werden die Kennungen erlaeutert, die in der ersten Phase (BLK1 bis ACK4) uebermittelt werden, um Daten ueber die beiden Systeme auszutauschen. Bei einigen Headern muss in der Datenzeile eine Portnummer angegeben werden. Dazu wird die Portnummer, gefolgt von einem Leerzeichen, am Anfang der Nutzinformation angegeben. Sind die Informationen auf alle Ports anwendbar, wird 0 als Portnummer angegeben. ARC +Portnummer, PAEicht Moegliche Datenkompressionen. Deoniert sind bisher: _Kuerzel_________Name________________Dateiendung____ ARC Arc/Pak .arc ARJ Arj .arj LHARC Lh1/2 .lzh LHA Lh1-5 .lha RAR Rar .rar ZOO Zoo .zoo ZIP Zip .zip ZIP2 Zip V2.0 .zi2 COMPRESS Compress .Z GZIP GNU-Zip .gz TAR-COMPRESS Tar und Compress .tar.Z, .tz TAR-GZIP Tar und GNU-Zip .tar.gz, .tgz RM Remove entfaellt NONE Keine Kompr. .non Auch hier werden Alternativen durch Leerzeichen getrennt hintereinandergestellt. Die Reihenfolge ist dabei relevant: _________________________4 Die Simulation eines Vollduplex-Protokolles ist nur aus Kompatibili- taetsgruenden zu den ersten Zconnect-Versionen deoniert. Neue Zconnect- Implementation sollten einen Vollduplex-Transfer nur dann anfordern, wenn auch ein Vollduplex-Protokoll in der Informationsphase vereinbart wurde II.5:_Header_fuer_Systeminformationen___________________________________ 15 die bevorzugten Packer stehen vorne. Ueblicherweise wer- den Packer auf allen Ports gleichartig verfuegbar sein, sodass nur ein ARC-Header mit Portnummer 0 gesendet wird.5 In Ausnahmefaellen (verschiedene Hard/Software auf verschie- denen Ports) kann dies aber auch anders sein. ARCEROUT optional Der Packer, mit dem die Daten zur Zeit gepackt vorlie- gen. Kodierung wie bei ARC. Die Angerufene sollte in BLK2 mit ihren Systemdaten der Anruferin unbedingt mittei- len, mit welchem Packer die Daten vorkomprimiert wur- den. Anhand der Systemdaten entscheidet die Anruferin dann, welche Packer endgueltig verwendet werden und ueber- traegt diese endgueltigen Parameter im BLK3. Unter ARCERIN steht hierbei dann der Packer, den die Angerufene verwen- den muss (bei Bedarf muss dann in der Vorbereitungsphase umgepackt werden) und bei ARCEROUT der Packer, den die Anruferin selber verwendet. ARCERIN Optional Der Packer, mit dem die Daten bei der Uebertragung gepackt sein sollen. Dieser wird nur dann von ARCEROUT abweichen, falls ARCEROUT auf dem empfangenden System nicht extrahiert werden kann. In diesem Fall fordert das betroffene System mit ARCERIN die Gegenstelle zum Umpacken auf. Der Wert fuer ARCERIN wird aus dem ARC- Header der Gegenstelle ermittelt, so dass dieser Packer auf jeden Fall fuer beide verfuegbar ist. Sowohl ARCEROUT als auch ARCERIN bezeichnen die Packer immer aus Sicht der Senderin des Headers - ARCERIN des Anrufers entspricht ARCEROUT der Angerufenen. CRYPT +Portnummer, optional Hiermit sind alle Verschluesselungsprogramme, die fuer die Mailkodierung verwendet werden koennen, gemeint. _Kuerzel__Name______________________________________ DES DES 56Bit DoD-Standard (lowtech) PGP RSA Public-Key-Verschluesselung (hightech) Sind mehrere Crypt-Moeglichkeiten vorhanden, gilt sinnge- maess das unter ARC Gesagte. Eine nicht existente CRYPT Zeile _________________________5 ZERBERUS Vers 5.2 sendet derzeit prinzipiell die Informationen fuer alle Ports separat und interpretiert Portnummer 0 nicht 16________________________________________Kapitel_II:_Die_Datenuebertragung_ besagt, dass die Daten nicht verschluesselt sind, die CRYPT Zeile gilt generell sowohl fuer die empfangenen als auch die gesendeten Daten. Die Passwort-Vereinbarung erfolgt off- line; Eine Public-Key-Passwortaustausch wird noch deo- niert. Ein evt. notwendiges Entcrypten/Umcrypten von Daten sollte generell oOine erfolgen. DOMAIN optional Internet-Domains des Systems. Falls mehrere gueltige Domains vorhanden sind, werden diese durch Leerzeichen oder Semikolon getrennt aufgefuehrt. Beispiel: DOMAIN:zer.de comlink.de zer.sub.org\r ISO2 +Portnummer, PAEicht Moegliche Verbindungsarten: _Kuerzel______Verbindungsart__________ V.21 300 Bps CCITT V.22 1200 Bps CCITT V.22bis 2400 Bps CCITT V.32 9600 Bps CCITT V.32bis 14400 Bps CCITT V.34 28800 Bps CCITT V.34T 28800 Bps Terbo V.FC 28800 Bps FastClass PEP 15000 Bps PEP-Modus HST 14400 Bps HST-Modus V110 ISDN-Protokoll BUNDLE ISDN-Protokoll X.75SLP ISDN-B-Kanal Protokoll HDLC ISDN-B-Kanal Protokoll BITTRANSP ISDN-B-Kanal Protokoll SNA-SDLC ISDN-B-Kanal Protokoll X.75BTX ISDN-B-Kanal Protokoll X.25 Datex-P Z.16 16800 Bps Zyxel Z.19 19200 Bps Zyxel Sind mehrere Verbindungsarten moeglich, werden diese durch je ein Leerzeichen getrennt hintereinandergestellt. Fuer jeden TEL-Header muss ein zugehoeriger ISO2-Header gesendet werden, es sei denn, alle Ports haben gleiche II.5:_Header_fuer_Systeminformationen___________________________________ 17 Faehigkeiten: dann wird ein ISO2-Header mit Portnummer 0 gesendet. ISO3 +Portnummer, optional, default: Transparent Angabe der Fehlerkorrekturmoeglichkeit und Moeglichkeit fuer Datenkorrektur auf dem Verbindungsweg. _Kuerzel________Verbindungsprotokoll____________ MNP bis Level 4 (nur Fehlerkorr.) MNP5 Level 5 bis 9 (Mit Datenkompr.) MNP10 V.42 Fehlerkorrektur V.42bis Datenkompression T70NL ISDN-B-Kanal Protokoll ISO8208 ISDN-B-Kanal Protokoll T90 ISDN-B-Kanal Protokoll TRANSPARENT Kein Ebene 3 Protokoll Falls mehrere Alternativen bestehen, werden diese durch je ein Leerzeichen getrennt hintereinandergestellt. Wur- den mehrere TEL-Header gesendet sind auch entsprechende ISO3-Header zu senden (vergleiche auch ISO2). KOORDINATEN optional Standort in geographischer Laenge und Breite. Format wie in folgendem Beispiel: KOORDINATEN:53 11 N / 10 44 E (city)\r Die Ergaenzung (city) in diesem Beispiel bezeichnet hier- bei, dass die Koordinaten die einheitlichen, fuer die jeweilige Stadt gueltigen Koordinaten sind, die sie zum Beispiel in jedem handelsueblichen Atlas (im Register den Stadt-Namen suchen) oder bei Ihrer Stadtverwaltung erfahren. MAILER +Portnummer, optional, Default: nur ZCONNECT Hier sind alle Formate zum Verbindungsaufbau deoniert, die das System versteht. Folgende Eintraege sind zur Zeit bekannt: 18________________________________________Kapitel_II:_Die_Datenuebertragung_ _Kuerzel________Verbindungsprotokoll__________________ ZCONNECT3.0 Das ZCONNECT-Datenformat vom 3. Aug. 92 ZCONNECT3.1 Das im folgenden Kapitel beschriebene Datenformat ZCONNECT steht fuer ZCONNECT3.0 und ZCONNECT3.1 ZNETZ das alte ZERBERUS-Protokoll FTS0001 FidoNet FSC0056 EMSI-Standard im Fido-Net MausTausch Die Schnittstelle zum MausNet Mehrere Moeglichkeiten werden wie unter ARC erlaeutert dar- gestellt. MAILFORMAT +Portnummer, optional, Default: nur ZCONNECT Hier sind alle Mailformate aufgefuehrt, die das System ver- steht. Folgende Eintraege sind zur Zeit bekannt: _Kuerzel________Datenformat___________________________ ZCONNECT3.0 Das ZCONNECT-Datenformat vom 3. Aug. 92 ZCONNECT3.1 Das im folgenden Kapitel beschriebene Datenformat ZCONNECT steht fuer ZCONNECT3.0 und ZCONNECT3.1 ZNETZ das alte ZERBERUS-Format RFC1036 oft nur 'UUCP' genannt, das News- Format wie es z.B. in UUCP-Systemen verwendet wird. X400 ISO/OSI Standard Mehrere Moeglichkeiten werden wie unter ARC erlaeutert dar- gestellt. MAPS optional Namen weiterer Userinnen, die Maps benutzen duerfen - zusaetzlich zur Systembetreuung, die bereits im SYSOP Hea- der benannt wird. Hier werden die Benutzerinnennamen von Cosysops aufgefuehrt (einem pro Header), die fuer dieses System auch Maps-Bestellungen abgeben duerfen.6 _________________________6 ZERBERUS Version 5.2 schneidet diese Zeile nach dem 40. Zeichen ab - ZERBERUS Version 5.3 akzeptiert hier 60 Zeichen II.5:_Header_fuer_Systeminformationen___________________________________ 19 PASSWD PAEicht Passwort, das benoetigt wird, um die Verbindung aufrecht- zuerhalten. Wird zwischen den beiden Systemen zum ersten Mal eine Verbindung aufgebaut und wurde noch kein Pass- wort ausgetauscht, so generiert der Sender ein Passwort, welches von der Empfaengerin uebernommen und ab dem naechsten Verbindungsaufbau verwendet wird. Das Pass- wort wird allerdings erst nach dem erfolgreichen Abschluss der Informationsphase gespeichert. Ist dagegen bei der Angerufenen ein Passwort deoniert, so muss dieses stim- men (Gross/Kleinschrift wird beachtet). Sendet die Anru- fende als Passwort 'GUEST' und ist sie der Angerufenen nocht nicht bekannt, so handelt es sich um einen einma- ligen Datenaustausch und die Anruferin wird nicht in die Systemliste der Angerufenen aufgenommen. Das Passwort ist maximal 10 Zeichen lang. PORT PAEicht Portnummer, auf der sich die aktuelle Anrufe- rin/Angerufene beondet. Falls ein System nur einen Port hat, gibt es '1' als Portnummer an. POST optional Vollstaendige Postadresse des Systems, falls jemand einen Brief per Post schicken moechte. PROTO +Portnummer, PAEicht Alle Uebertragungsprotokolle, die fuer die Uebertragung von Daten benutzt werden koennen (nicht alle koennen bei jedem Modem und/oder Anschluss genutzt werden, z.B. BiModem nicht im PEP-Modus). 20________________________________________Kapitel_II:_Die_Datenuebertragung_ _Kuerzel_____Uebertragungsprotokoll________ XMODEM Xmodem YMODEM Ymodem ZMODEM Zmodem SEALINK Sealink KERMIT-B Kermit im Binaermodus BIMODEM BiModem (bidirektional) HSLINK HighSpeedLink (bidirektional) ACOPY Acopy (ISDN Protokoll) HYDRA Bidirektionales Protokoll EFT ISDN-File-Transfer-Standard ZMODEM8K 8K-Variante des ZModem. NCOPY Network Copy Mehrere Moeglichkeiten werden durch je ein Leerzeichen oder Semikolon getrennt hintereinandergestellt. Hier gilt im uebrigen sinngemaess das unter ARC Gesagte (s.o.). SERNR Default: '0', optional Seriennummer der verwendeten Software. Jedes System kann bei der Auslieferung eine ID erhalten, die kein anderes System hat. Sollten zwei gleiche Seriennummern miteinan- der versuchen zu kommunzieren, wird der Versuch abgebro- chen. Sendet eines der Systeme diesen Header nicht, wird weiter kommuniziert. SYS PAEicht Sowohl Anruferin als auch angerufenes System muessen die- sen Header mit dem Systemnamen genau einmal senden, ansonsten wird die Verbindung abgebrochen. Die Anruferin prueft, ob das System, das sie mit dieser Verbindung errei- chen wollte, sich mit eben diesem Namen meldet. Geschieht das nicht, wird ebenfalls abgebrochen. SYSOP PAEicht Name der Userin in der Box, an die Fragen zum System u.s.w. geschrieben werden koennen, z.B. 'Postmaster', 'Zentrale' oder 'Sysop'. TEL +Portnummer, PAEicht Nummer des Telefonanschlusses. Die Telefonnummer wird nach internationaler Notation angegeben, also zuerst ein Pluszeichen, dann der Laendercode (z.B. 49 fuer BRD), ein II.5:_Header_fuer_Systeminformationen___________________________________ 21 Bindestrich, die Vorwahl ohne fuehrende Null, noch ein Bin- destrich und dann die Anschlussnummer. Beispiel: TEL:1 +49-521-19304\r TEL:2 +49-521-19300\r Fuer Datex-P oder Telex werden die Nummern nach den dort allgemein gueltigen Formen angegeben. TELEFON optional Die Voice-Telefonnumer, Format wie unter TEL: beschrie- ben, jedoch ohne die hier unsinnige Portnummer. Falls unter der angegebenen Telefonnummer ein Anrufbeantwor- ter vorhanden ist, wird der Nummer ein Q nachgestellt. Mehrere Nummern werden durch ein Semikolon oder durch Leerzeichen getrennt. LOGOFF optional Hiermit kann bei Unvertraeglichkeiten oder falschem Pass- wort eine Verbindungstrennung angekuendigt werden, die erfolgen wird, nachdem die Header BLK4/ACK4/TME4 ausgetauscht wurden. Der Logoff kann von beiden Systemen jederzeit angefordert werden. Als Para- meter wird der Grund der Verbindungstrennung als Klartext-Fehlermeldung uebergeben. Beispiele: 'Falsches Passwort' oder 'Seriennummern identisch'. Der Logoff kann von beiden Seiten jederzeit angefordert werden. Im folgenden nun ein Beispiel fuer einen korrekten Verbindungs- aufbau mit dem Austausch aller notwendigen Bloecke aus der Sicht der Anruferin. Die CRC-Checksummen der Datenbloecke stimmt dabei nicht immer, da teilweise eine Formatierung der Daten not- wendig war. Waehrend des Datenaustausch kann diejenige, die auf einem Block wartet, die Gegenseite mit einem NAK0-Header zu einer Wiederholung des jeweils zuletzt gesendeten Blockes (BLK1- BLK4) auffordern. Bei einer verstuemmelten Bestaetigung eines Blocks (ACK1-ACK4) wird der zuletzt gesendete Block nach spae- testens 30 Sekunden erneut wiederholt. Nach 15 Wiederholungen erfolgt ein Verbindungsabbruch. Empfangen: BEGIN BEGIN 22________________________________________Kapitel_II:_Die_Datenuebertragung_ Gesendet: Sys:SYSTEM1 Sysop:SYSOP SerNr:Z001 Post:Wolfgang Mexner, Strasse, Stadt Port:1 Tel:1 +49-5509-2556 Domain:zer.sub.org;zer Maps: ISO2:1 V.32bis V.32 V.22bis V.22 V.21 ISO3:1 V.42bis V.42 MNP5 MNP Arc:1 ZIP2 ZIP ARJ ARC ZOO LHA NONE Proto:1 HSLINK ZMODEM XMODEM BIMODEM Passwd:JMFP5Y5GZE Telefon:+49-5509-2556Q +49-5509-919010 Status:BLK1 ArcerOut:ZIP2 Mailer:1 ZCONNECT FIDO JANUS UUCP ZNETZ CRC:A304 Achtung: Der angegebene CRC stimmt nicht, da der Header von Hand bearbeitet wurde. Empfangen: Status:ACK1 CRC:EA3C Gesendet: Status:TME1 CRC:F974 An dieser Stelle trat ein Timeout bei der Angerufenen auf, der letzte Block wird daher wiederholt. Empfangen: Status:ACK1 CRC:EA3C Gesendet: Status:TME1 CRC:F974 Empfangen: Sys:SYSTEM2 Sysop:SYSOP SerNr:Z000 Post:ZERBERUS GmbH, Marktstr. 18, 33602 Bielefeld II.5:_Header_fuer_Systeminformationen___________________________________ 23 Port:1 Tel:1 +49-521-9680869 Tel:2 +49-521-68000 Domain:zer.sub.org;zer;comlink.de Maps: ISO2:1 ISDN ISO2:2 V.32bis V.32 V.22bis V.22 V.21 ISDN ISO3:1 V.42bis V.42 MNP5 MNP ISO3:2 V.42bis V.42 MNP5 MNP Arc:1 ZIP2 ZIP ARJ ARC ZOO LHA NONE Arc:2 ZIP2 ZIP ARJ ARC ZOO LHA NONE Proto:1 HSLINK ZSXW ZMODEM Proto:2 HSLINK ZMODEM XMODEM BIMODEM Telefon:0521/65566 Fax 61172 Status:BLK2 ArcerOut:ZIP MAILER:1 ZCONNECT FIDO JANUS UUCP ZNETZ MAILER:2 ZCONNECT FIDO JANUS UUCP ZNETZ CRC:9CF6 Achtung: Der angegebene CRC stimmt nicht, da der Header von Hand bearbeitet wurde. Gesendet: Status:ACK2 CRC:EA3F Empfangen: Status:TME2 CRC:F977 Gesendet: Proto:HSLINK Status:BLK3 ArcerIn:ZIP ArcerOut:ZIP2 CRC:8036 Empfangen: Block empfangen: Status:ACK3 CRC:EA3E Gesendet: Status:TME3 CRC:F976 24________________________________________Kapitel_II:_Die_Datenuebertragung_ Empfangen: Status:BLK4 CRC:4E85 Gesendet: Status:ACK4 CRC:EA39 Empfangen: Status:TME4 CRC:F971 II.6 Header zur Verbindungssteuerung in der Datenaustausch-Phase Nachdem die Systeminformationen ausgetauscht und bestaetigt wurden, beginnt der Datenaustausch (sofern nicht ein Logoff ange- fordert wurde). In der nun folgenden Phase werden die zuvor vereinbarten Packer und das Uebertragungsprotokoll nicht mehr veraendert. Die Steuerung des Datenaustausches erfolgt in dieser Phase immer durch das anrufende System. Die Anruferin hat nur die Moeglichkeit, einzelne Kommandos abzulehnen oder nur teil- weise auszufuehren. Bei einem Vollduplex-Protokoll werden immer gleichzeitig ein Empfangs- und ein Sendekommando abgearbeitet; bei einem Halbduplex-Protokoll werden sequentiell zunaechst alle Empfangs- und dann alle Sende-Kommandos abgearbeitet. Meh- rere Empfangs- bzw. Sende- Kommandos in einem BLK1 sind unzu- laessig, da die Daten nicht im Batch-Transfer uebertragen werden. Wird neben den bekannten Kommandos eine unbekannte Aktion gefordert, so wird diese vom angerufenen System ignoriert - evtl. erfolgt noch eine EXECUTE: N Meldung. Das ein Befehl nicht erkannt bzw. ausgefuehrt wurde, kann daran erkannt werden, dass anstelle des EOT4-Headers am Ende der Sequenz BLK1-BLK4 ein- fach ein TME4 gesendet wird. Bisher sind fuer die Anruferin folgende Kommandos fuer BLK1 deoniert: GET optional Die anrufende MailBox moechte Daten von der angerufenen abholen. II.6:_Header_zur_Verbindungssteuerung_in_der_Datenaustausch-Phase_______ 25 __Buchstabe___angeforderte_Mailpakete______________ P Persoenliche Mails und Mails mit sowohl Brett- als auch privaten Empfaengern abholen E nur Eilmails abholen. B Brettnachrichten sollen abgeholt werden. F Fehlermails abholen Die Buchstaben koennen auch kombiniert werden. Mit 'GET:PEBF' werden beispielsweise alle Mails angefordert. Auf das Kommando GET kann das angerufene System im Antwort-Block mit der Meldung PUT:PBEF der Anrufe- rin mitteilen, welche Mailtypen zur Abholung bereitliegen. Eine leere PUT- Antwort bedeutet, dass keine Daten von den mit GET gewuenschten Typen verfuegbar sind. Diese Option ist besonders wichtig, wenn die angerufene MailBox die Daten in Bloecken einer einstellbaren Groesse archiviert. So wird bei dem Kommando GET:PBEF nur ein Bruchteil der gespeicherten Daten uebertragen. Die Anruferin wird daher das Kommando GET:PBEF solange wiederholen, bis ein lee- rer PUT Header als Antwort kommt.7 PUT optional Format wie GET. Die anrufenden MailBox moechte Daten der Typen PBEF zur angerufenen uebertragen. Moechte eine anrufende MailBox also alle verfuegbaren Daten von einem System abholen, so wird sie zunaechst das Kommando GET:PBEF und dann das Kommando PUT:PBEF erteilen. DELETE optional Das einzige zusaetzliche Kommando, was jederzeit paral- lel zu einem Empfangs- und Sende-Kommando ausgefuehrt werden kann, ist das DELETE-Kommando. Dieses Kom- mando loescht alle Mails mit der Extension .PRV, .KOM, .BRT, .ERR oder .EIL _________________________ 7Aeltere Systeme schicken keinen PUT Header als Antwort auf einem GET-Header. Hier muss solange das GET-Kommando geschickt werden, bis Anstelle des EOT4-Headers zum Einleiten des Protokolltransfers ein TME4- Header geschickt wird 26________________________________________Kapitel_II:_Die_Datenuebertragung_ __Buchstabe___bewirkt_Loeschung_von________________ P Persoenliche Mails und Mails mit sowohl Brett- als auch privaten Empfaengern B Brettnachrichten (oeffentliche Mails) E Eilnachrichten F Zurueckgeschickte fehlerhafte Nachrichten Dies wird vom anderen System ignoriert, falls es sich um Mails handelt, die ueber dieses System an ein anderes gerou- tet werden sollen; Routmails (PMs) duerfen niemals geloescht werden. Dieses Kommando wird daher meist nur fuer Points verfuegbar sein. Das DELETE-Kommando hat Vorrang vor einem GET-Kommando. FORMAT optional, Default: `ZCONNECT' Dieser Header tritt nur zusammen mit einem PUT Header auf. Die Kennung gibt an, in welcher Form die Mails/News vorliegen. Dieser Header ist nur gueltig in der Datenphase der Online- Kommunikation. Es duerfen nur Formate angegeben werden, die von der Gegenseite im MAILER Header aufgefuehrt wur- den. Die Gegenseite kann (selbstverstaendlich) die Uebertra- gung ablehnen - es gibt aber keine Moeglichkeit, der ande- ren Seite ein anderes Datenformat vorzuschreiben oder eine Umkodierung anzufordern. Zwei ZCONNECT Systeme wer- den niemals vollautomatisch ein anderes Datenformat als ZCONNECT zur Kommunikation untereinander waehlen - dazu ist immer ein manueller Eingriff noetig. Die Kennung ist dabei kodiert wie bei MAILER. Hiermit koen- nen sich z.B. zwei UNIX-Systeme RFC-1036 Datenpakete oder Fido-Systeme FTS-Pakete uebermitteln. FILEREQ optional Datei von Empfaengerin laden. Hier werden UNIX- Pfadnamen8 verwendet. Der Dateiname '/INFO/INHALT' ist reserviert fuer die Gesamtuebersicht aller verfuegbaren Dateien. Es gibt keine Regeln fuer Dateinamen in diesem Zusammenhang, die Empfaengerin muss auf alles vorbereitet sein (z.B. Leerzeichen und Sonderzeichen) und entsprechend ihren lokalen Konventionen wandeln. _________________________8 also / statt \, genau wie bei ZERBERUS-Brettern II.6:_Header_zur_Verbindungssteuerung_in_der_Datenaustausch-Phase_______ 27 Die Namen, die mit /INFO beginnen, sind dabei fuer bestimmte Systeminformationen reserviert, die falls sie vorhanden sind den hier stehenden Inhalt haben: __Kennung___________Erlaeuterung___________________ /INFO/LOGIN Begruessungstext beim Login /INFO/MOTD Bulletin (Message of the Day) /INFO/Q-USAGE Kurzanleitung der Box (Quick Usage) /INFO/V-USAGE Grossanleitung der Box (Verbose Usage) /INFO/HINTS Bedienungshinweise (Hints & Twinkles) /INFO/INTRO Kurzanleitung fuer Gaeste und NeuUser /INFO/NETWORKS Verfuegbare Netze und deren 'Ziele' /INFO/SYSTEM Selbstdarstellung der Box /INFO/TIMES Login Zeiten /INFO/COSTS Benutzergebuehren etc /INFO/KNIGGE Nettikette(n) /INFO/INHALT Das Inhaltsverzeichnis des Fileservers. Aus Kompatibilitaetsgruenden sollte auch mit /INHALT das Inhaltsverzeichnis des Fileservers geliefert werden. FILESEND optional File bei der Empfaengerin speichern. Die Empfaengerin ent- fernt evtl. den Directory-Namen aus dem angegebenen Namen oder verbietet die Uebertragung. Fuer Dateinamen gilt das unter FILEREQ Gesagte. PGP-KEYREQ optional Mit diesem Header wird der ZCONNECT PGP-Key-Request realisiert. Hier wird die Adresse des Users angegeben, des- sen Public-Key bei der naechsten Uebertragung gesendet wer- den soll. Falls vorhanden wird der Key der angegebenen UserIn nach dem folgenden BLK4 als Datei uebertragen. Falls nicht wird die Ausfuehrung abgelehnt (EXECUTE:N). 28________________________________________Kapitel_II:_Die_Datenuebertragung_ Im Antwort-Block BLK2 reagiert das angerufene System auf das in BLK1 uebertragene Kommando. Es hat hierbei folgende Moeglich- keiten: EXECUTE PAEicht Mit diesem Header melden beide Systeme, ob sie zu den angeforderten Aktion bereit sind. Die Anruferin kann hier- bei die Ausfuehrung seines eigenen Kommandos ablehnen, wenn ihr z.B. die Bereitstellungszeit zu gross ist. Dieser Header kann daher sowohl von der angerufenen als auch der angerufenen MailBox gesendet werden. Er kann in BLK2-BLK4 als Antwort gesendet werden. Wird er mehrfach gesendet, so hat prinzipiell das Nein den Vorrang Soll ein Befehl von der angerufenen MailBox tatsaechlich ausgefuehrt werden oder nicht. __Buchstabe___Bedeutung____________________________ N Nein J Ja L Later. Soll spaeter (nach dem Logoff) ausgefuehrt werden. Wird EXECUTE:N bei einem kombinierten Empfangs/Sende- Kommando im Vollduplex-Betrieb vom angerufenen System gesendet, so ist nicht klar, ob beide Teilkomman- dos abgelehnt wurden. Daher muessen diese dann dem angerufenen System nochmals einzeln vorgelegt werden. Das EXECUTE:L Kommando sendet nur die Anruferin nach einer WAIT Meldung der Angerufenen, wenn die Online-Bereitstellung der Daten zu lange dauern wuerde. Die Daten werden in diesem Falle fuer den naechsten Anruf fertig bereitgelegt. WAIT optional Zeit in Sekunden, die wahrscheinlich fuer das Bereitstellen der Daten (z.B. wegen des Packens) gebraucht wird. Wenn dort ein 'N' steht koennen die Daten nicht bereitgestellt (bzw. jetzt uebertragen) werden. Bei einer WAIT:N Meldung wird ein Kommando prinzipiell abgelehnt - wenn z.B. ein bestimmtes Filerequest nicht moeglich ist. Bei der Meldung WAIT:N ist gleichzeitig ein EXECUTE:N verknuepft. BYTES optional Groesse des zu uebertragenen Files in Bytes. Diese Headerzeile kann von beiden Seiten gesendet werden. Hiermit kann der II.6:_Header_zur_Verbindungssteuerung_in_der_Datenaustausch-Phase_______ 29 Empfang eines zu grossen Files abgelehnt werden, bevor die Festplatte ueberlaeuft. FILE-CRC optional Der Header FILE-CRC ist optional und kann in jeder BLK3/BLK4-Phase nach Abschluss des Systemdatenaus- tauschs genau einmal gesendet werden. Falls er gesendet wird, gibt er (in Hex) den 32-bit CRC (nach CCITT/Z- MODEM Polynom) der nach BLK4 zu uebertragenden Datei an. Falls dieser Header gesendet wurde, sollte die Gegenseite den CRC der empfangenen Datei pruefen und bei Unstimmigkeiten LOGOFF oder RETRANSMIT anfordern (z.B. 2 mal RETRANSMIT, dann LOGOFF) LOGOFF optional Hiermit koennen beide Seiten jederzeit das Ende der Ver- bindung anfordern. Im Normalfall wird der Logoff nach dem Transfer des letzten Datenblockes von der Anruferin mit der Meldung 'Alle Daten uebertragen' angefordert. Genauso wie in der Info-Phase wird der Logoff-Text im Klartext uebertragen. RETRANSMIT optional Der Header RETRANSMIT ist optional und kann in dem BLK1 oder BLK2 Paket genau einmal gesendet werden, dass direkt auf eine Dateiuebertragung folgt (mit anderen Worten: des- sen gueltiger ACK/TME fuer die Gegenseite die Bestaetigung der erfolgreichen Datenuebertragung waere). Er erklaert die letzte Uebertragung als gescheitert und fordert eine erneute Uebertragung an. Die Gegenseite darf diese Datei daraufhin nicht loeschen. Sie muss sie aber nicht unbedingt sofort noch einmal uebertragen - dies kann nach Abschluss aller schon (lokal) geplanten Dateiuebertragungen geschehen oder sogar erst im naechsten Netcall. RETRANSMIT gibt wie LOGOFF den Grund fuer die nochmalige Uebertragung im Klartext an, z.B. RETRANSMIT:CRC failed RETRANSMIT kann auch aus beliebigen anderen Gruenden angefordert werden. Allerdings ist dabei Vorsicht geboten. Beispiel fuer einen klaren Missbrauch: RETRANSMIT:out of disk space 30________________________________________Kapitel_II:_Die_Datenuebertragung_ In diesem Fall waere ein schlichter Abbruch der Verbindung zu empfehlen - die Datei gilt auch dann als nicht korrekt uebertragen und wuerde in einem der naechsten Netcalls wie- der bereitstehen. Im folgenden nun ein Beispiel fuer einen kompletten Header- austausch in der Daten-Transferphase aus Sicht der Anruferin bei einem Vollduplex-Datentransfer. Die CRC-Summen sind hierbei wiederum der Form halber mit angegeben, stimmen aber nicht immer: Gesendet: Get:PEBF Put:PEBF Status:BLK1 CRC:9F7C Empfangen: Status:ACK1 CRC:EA3C Gesendet: Status:TME1 CRC:F974 Empfangen: Status:BLK2 Wait:120 Put:PB CRC:6C61 Gesendet: Status:ACK2 CRC:EA3F Empfangen: Status:TME2 CRC:F977 Gesendet: Execute:Y Status:BLK3 CRC:ED82 Empfangen: Block empfangen: Status:ACK3 II.6:_Header_zur_Verbindungssteuerung_in_der_Datenaustausch-Phase_______ 31 CRC:EA3E Gesendet: Status:TME3 CRC:F976 Empfangen: Execute:Y Status:BLK4 CRC:65E9 Gesendet: Status:ACK4 CRC:EA39 Empfangen: Status:EOT4 CRC:???? Status:EOT4 CRC:???? Status:EOT4 CRC:???? Ab hier werden die Daten nun gepackt - nur der angerufene brauchte Zeit. Nach dem Packen geht es nun weiter: Empfangen: Status:BEG5 CRC:???? Gesendet: Status:EOT5 CRC:???? Status:EOT5 CRC:???? Status:EOT5 CRC:???? Hier wird nun das Vollduplex-Protokoll aufgerufen. Nach dem Aufruf des Protokolles bringt die Angerufene mit einem NAK0- Header den Block-Austausch wieder in Gang: Status:NAK0 CRC:DA41 32________________________________________Kapitel_II:_Die_Datenuebertragung_ Gesendet: Get:PB Status:BLK1 CRC:9F7C Empfangen: Status:ACK1 CRC:EA3C Gesendet: Status:TME1 CRC:F974 Nach diesem Headeraustausch gelten die gesendeten und die empfangenen Daten als erfolgreich uebertragen und koennen nach dem Logoff verarbeitet werden. Empfangen: Status:BLK2 Put: CRC:6C61 Gesendet: Status:ACK2 CRC:EA3F Empfangen Status:TME2 CRC:F977 Gesendet: Execute:N Logoff:Alle Daten ausgetauscht Status:BLK3 CRC:ED82 Empfangen: Status:ACK3 CRC:EA3E Gesendet: Status:TME3 CRC:F976 Empfangen: Execute:N Status:BLK4 CRC:65E9 II.6:_Header_zur_Verbindungssteuerung_in_der_Datenaustausch-Phase_______ 33 Gesendet: Status:ACK4 CRC:EA39 Empfangen: Status:TME4 CRC:EA39 Und nun kann das Modem aufgelegt werden. In den `real exi- stierenden' ZCONNECT-Implementationen ist der Headeraustausch leider haeuog nicht so klar, inbesondere werden haeuog mehr Hea- der uebertragen, als eigentlich notwendig waeren. Es wird auch keine Garantie fuer die Vollstaendigkeit des beschriebenen Datentransfers uebernommen. 34________________________________________Kapitel_II:_Die_Datenuebertragung_ ________________________________________________________________________ Kapitel III: Das Datenformat ________________________________________________________________________ In diesem Kapitel moechten wir nun beschreiben, was mit den komplett transportierten Daten passiert und wie diese ausse- hen. Betrachten wir aber zunaechst, wie der gesamte Mechanis- mus zusammenarbeitet. III.1 Vor dem Transport In einem Server-System sammeln sich im Betrieb staendig Daten fuer die angeschlossenen Systeme. Je nach Philosophie der ein- gesetzten Software werden diese Nachrichten zwischengelagert (gespoolt) oder nur fuer den Transport vorgemerkt. Persoenliche Nachrichten werden in der Regel zwischengelagert, da sie in der Server-MailBox selbst nicht einsortiert werden. In regelmaessigen Abstaenden (z.B. alle 10 Minuten, alle halbe Stunde, jede Stunde oder - was aber nur bei Endsystemen sinnvoll ist - einmal taeglich kurz vor 18:00 Uhr) werden diese Daten dann zum Transport freigegeben. Das dafuer zustaendige Programm sam- melt entweder alle entsprechend markierten Daten aus der lokalen Datenbasis oder arbeitet das Zwischenlager (den Spool-Bereich) ab. Dabei enstehen dann Netcall-Dateien fuer alle angeschlossenen Systeme, getrennt nach Privatmails und oeffentlichen Nachrichten. Diese Netcalldateien werden nach ihrer Fertigstellung sofort mit dem fuer das System zuletzt eingestellten Packer an das bereits bereitliegende Netcall-Archiv angefuegt. Dabei werden Dateinamen benutzt, die nur aus folgenden Zei- chen bestehen: die Ziffern von 0 bis 9 sowie den Grossbuchstaben A bis Z. Es sind maximal acht Zeichen gefolgt von einem Punkt '.' und weiteren drei Zeichen erlaubt. Dies garantiert, dass die ZCONNECT- Archive auf allen Betriebssystemen ausgepackt wer- den koennen und beim Auspacken nicht Namenskollisionen ent- stehen (z.B. koennte ein UNIX-System die Dateien 'ArZk01' und 'ARZK01' einpacken, die dann auf einem DOS-System den glei- chen Namen haetten). 36____________________________________________Kapitel_III:_Das_Datenformat_ Die Endung des Dateinamens (die drei weiteren Zeichen nach dem `.') kennzeichnen die Art der in einer Netcall-Datei enthal- tenen Nachrichten. Hierbei gelten die folgenden Konventionen: *.brt, *.BRT Die Netcalldatei enthaelt ausschliesslich oeffentliche Nachrichten, d.h. Nachrich- ten, deren Empfaengerin ein Brett ist. *.prv, *.PRV Die Netcalldatei enthaelt ausschliesslich persoenliche Nachrichten (PRV steht fuer Privat) *.kom, *.KOM Die Netcalldatei enthaelt Nachrichten, die oeffentliche und private Empfaenger gemischt enthalten koennen. *.eil, *.EIL Wie *.KOM. Die Nachrichten sind aus- schliesslich Eilmails. *.err, *.ERR Die Netcalldatei enthaelt ausschliesslich nicht zustellbare (und deshalb zurueck- geschickte) Nachrichten. alle anderen Die Netcalldatei kann alle Nachrichten- typen gemischt enthalten (wie *.KOM) Unabhaengig vom Dateinamen muessen selbstverstaendlich alle abge- lieferten Dateien einsortiert werden. Eine moegliche Implementierung der Namensgebung fuer die ein- zelnen Datenpakete im Archiv ist folgende: beim Zusammenstellen der Datenpakete wird die Zeit im Standard-UNIX-Format (Sekun- den seit 1970) ermittelt. Diese wird dann in eine maximal acht- stellige Hexadezimalzahl konvertiert und als Dateiname fuer das neue Datenpaket benutzt.1 III.2 Nach dem Transport Angenommen, wir haben von einem anderen Netzwerksystem per ZCONNECT Daten empfangen. In der Regel beonden sich diese Daten alle gemeinsam in einem komprimierten Archiv. Der dazu verwendete Packer wird von ZCONNECT selbstaendig aktiviert, um die empfangenen Daten zu entpacken. Anschliessend onden wir ein vorher leeres Verzeichnis auf unserer Festplatte, in dem sich alle empfangenen Dateien beonden. Minimal beondet sich hier ueber- haupt keine Datei (das andere System hatte keine Daten fuer uns), meist werden aber eine oder mehrere Dateien zum Einsortieren bereitstehen._Jede_dieser_Dateien kann aus mehreren Nachrich- 1Dabei muss gewaehrleistet sein, dass dies nicht oefter als einmal pro Sekunde geschieht: : : III.3:_Inhalt___________________________________________________________37 ten bestehen. Die einzelnen Nachrichten stehen direkt, also ohne Trennzeichen, hintereinander. Ueblicherweise beonden sich in einer Datei nicht gleichzeitig oeffentliche und private Nachrichten dies ist jedoch nicht zwingend, jede Software muss daher in der Lage sein, auch gemischte Datenpakete einzulesen. Jede Nachricht besteht aus zwei Teilen: dem Header und dem Inhalt. Wir werden diese beiden Teile getrennt diskutieren. III.3 Inhalt Der Inhalt kann dabei aus beliebigen Zeichen bestehen, er muss von jeder Software unveraendert weitergegeben werden. Ausnahme: Gateways duerfen im Falle von Textnachrichten den Inhalt unter- suchen und gegebenenfalls Umlaut- und Sonderzeichenkonvertie- rungen vornehmen. Der Inhalt von Textnachrichten darf weder von der Software noch von der Systembetreiberin eingesehen bzw. interpretiert wer- den. Ausnahmen hiervon sind nur in technisch bedingten Notfael- len (z.B. bei unzustellbaren Nachrichten) erlaubt, in diesem Fall muss die Empfaengerin von der Kenntnisnahme durch die System- betreiberin informiert werden. Es ist also nicht erlaubt, Textzeilen zum Steuern des NachrichtenAEusses zu missbrauchen, z.B. ein 'To: ....' in der ersten Zeile der Nachricht zur Adressierung zu ver- wenden. Alle Informationen, die fuer den Transport der Nachricht noetig sind und die durch den Transport entstehen ('Diese Nach- richt wurde am xx.xx.xx um xx:xx Uhr von der geilsten MailBox in xxxx weitergeleitet'), sind im Header unterzubringen. Nachrichten gelten als Textnachricht, wenn im Header die Information 'TYP:' nicht enthalten ist. In diesem Fall besteht der Inhalt aus lesbaren Zeilen, die durch die Zeichenkombination (in dieser Reihenfolge) voneinander getrennt sind. Am Ende des Textes steht kein als Datei-Ende-Zeichen (gehoert zu den verbotenen Zeichen in Textnachrichten, siehe unten). Nur Textnachrichten koennen von Userinnen gelesen werden, alle anderen Dateitypen erfordern bestimmte Anzeigeprogramme (Viewer), die in der Regel nicht online benutzt werden koennen (z.B. fuer Tondateien oder Graoken). Die MailBox-Software kon- vertiert den unten deonierten Standard-Zeichensatz in den von swe Userin benoetigten Zeichensatz. 38____________________________________________Kapitel_III:_Das_Datenformat_ III.4 Header Vor dem Nachrichten-Inhalt steht der Header. Er ist vergleichbar mit dem Briefumschlag der herkoemmlichen Post. Die Informatio- nen des Headers duerfen (und muessen sogar) zum Transport der Nachricht interpretiert und teilweise sogar veraendert werden. Der Header besteht aus beliebig vielen Informationen, gefolgt von einer Leerzeile (also der Zeichenfolge ). Die einzelnen Informationen sind durch die Zeichenkombination getrennt.2 Jede Information besteht aus einer Kennung gefolgt von einem Doppelpunkt ':' und optional einem oder mehreren Leer- oder -Zeichen. Anschliessend folgt der eigentliche Informationsin- halt bis zum Ende der Zeile ( ). Die Laenge der Zeile ist nicht begrenzt, sie darf von keiner Software beim Transport der Nachricht beschraenkt werden. Innerhalb des Informationsinhaltes sind alle Zeichen- codes von 32- 255 erlaubt. Bei Informationsinhalten mit Text-Charakter (z.B. Betreff-Zeile) gelten die gleichen Zeichensatz-Einschraenkungen wie fuer den Inhalt von Standard- Textnachrichten. Die Kennung einer Information ist maximal 100 Zeichen lang. Sie besteht ausschliesslich aus den Buchstaben A-Z, den Ziffern 0-9 sowie dem Bindestrich '-'. Umlaute sind hier nicht erlaubt. Eine Kennung kann in Gross- oder Kleinschreibung oder auch beliebigen Kombinationen angegeben werden, die Analyse ist immer ohne Beruecksichtigung der Gross-/Kleinschreibung vorzunehmen. Im Header koennen Informationen in beliebiger Reihenfolge auf- treten. Einzelne Kennungen koennen dabei auch mehrfach auftre- ten, bei anderen (z.B. MID, der Message-ID) ist das unsinnig und in diesem Fall explizit verboten. Treten in einem eingelesenen Header Informationen mehrfach auf, ist die Reihenfolge dieser gleichen Informationen beizubehal- ten. Die Reihenfolge unterschiedlicher Informationen zueinander ist nicht deoniert. Einige Header sind PAEicht, das heisst, ohne sie wird die Nach- richt, wenn moeglich, zurueckgeschickt. Das gilt auch fuer Nachrich- ten, bei denen Header mehrfach auftreten, die nur einmal erlaubt sind. _________________________2 Manchmal wird die Information auch mit `Headerzeile' bezeichnet. III.5:_Adressen_________________________________________________________39 Dabei werden jedoch folgende Regeln beachtet: o Ist ein ERR Header vorhanden, handelt es sich bereits um eine zurueckgeschickte Mail. Diese wird auf keinen Fall zurueckge- schickt, sie sollte direkt geloescht werden, kann aber alterna- tiv auch an die Systembetreuung weitergereicht werden. o Ist (mindestens) ein EB Header vorhanden und ist des- sen Adresse anders als die Absenderadresse, geht eine negative Empfangsbestaetigung ('Nachricht nicht zustellbar. Grund: ....') sowie ein ERR Header an die in EB angegebene Adresse(n). o Ansonsten geht die Nachricht an den Absender zurueck. Zur Ermittlung der Adresse wird zunaechst der WAB-Header, dann ANTWORT-AN und zuletzt der ABS-Header ausgewertet. Falls keine gueltige Ruecksendeadresse ermittelt werden kann, wird die Nachricht geloescht. Beim Zurueckschicken wird die Fehlermeldung in einen ERR Hea- der geschrieben und die Nachricht samt Inhalt zurueckgeschickt! III.5 Adressen (siehe auch RFC-822) Netzadressen haben folgende Form: @. (Vor- Nachname) Hinter der eigentlichen Adresse (bis einschliesslich ) steht getrennt durch genau ein Leerzeichen in runden Klammern '(' ')' der zur Adresse gehoerende Realname. Dieser Teil ist optional, wenn kein Realname angegeben wird, endet die Adresse mit der Domain. Der Systemname und die Domain werden ohne Ruecksicht auf Gross-/Kleinschreibung interpretiert. Ein System wird ein- deutig durch eine Kombination aus Systemname und Domain beschrieben (d.h.: BIONIC.zer.de ist weltweit eindeutig), ein System kann aber mehrere Namen und Domains besitzen (z.B. BIONIC.comlink.de). Beim Weiterleiten von Nachrichten genuegt es nicht, nur den Systemnamen zu identiozieren. Beispielsweise gibt es im Z-Netz ein System namens 'SOL'. Schreibt nun eine Benutzerin der BIONIC eine Mail an 'joe@sol.edu', so ist damit natuerlich nicht die SOL im Z-Netz gemeint, sondern die in Californien. An die SOL im Z-Netz duerfen also nur Nachrichten mit Adres- sen wie '...@sol.ccc.de', '...@sol.zer.de' und Nachrichten ohne Domain-Angabe '...@sol' geschickt werden. 40____________________________________________Kapitel_III:_Das_Datenformat_ Empfaengerangaben werden komplett an das Zielsystem weiter- gereicht, sie kommen also z.B. als 'terra@sol.ccc.de' auf der SOL an. So kann die SOL entscheiden, ob sie selbst gemeint ist oder nicht, und gegebenenfalls die Nachricht fuer 'joe@sol.edu' ueber den naechsten fuer '.edu' zustaendigen Gateway (hier: die SOL selbst) weiterleiten. Ist ein Empfaengersystem dem lokalen System nicht bekannt (z.B. die sol.edu der BIONIC), leitet das System die Nachricht an den Domain-Server der angegebenen Domain (hier: .edu) weiter. Ist die Domain selbst nicht bekannt (z.B. .cs.ucb.edu) testet das System den Teil der Domain nach dem naechsten Punkt (hier: .ucb.edu) und gegebenfalls die Teile nach weiteren Punkten, bis eine bekannte Domain gefunden wird (hier: .edu). In den einzelnen Teilen einer Adresse gelten unterschiedliche Beschraenkungen des Zeichensatzes: Systemname und Domain Hier sind nur die Buchstaben `A' bis `Z', die Ziffern `0' bis `9' sowie der Bindestrich `-' erlaubt. lokaler Teil Hier sind alle Zeichen mit Codes von 33 `!' bis 124 `_' erlaubt, ausgenommen die Zeichen @<>/\()[]-"'`",. Zeichen ueber 126, also auch die Umlaute, sind hier nicht gestattet. Die Zeichen `!' und `%' sind erlaubt, aber reserviert und duerfen daher nicht im Namen einer Userin auftreten. Realname Hier sind alle ASCII-Zeichen von Leerzeichen (32) bis ` ' (126) erlaubt, lediglich die runden Klammern sind natuerlich ausgenommen. III.6 Brettnamen Die andere Form der Adressierung ist ein Brettname: hier wird die Nachricht nicht an eine einzelne Empfaengerin auf einem bestimm- ten System geschickt, sondern an alle Leserinnen eines oeffentlichen Brettes. Oeffentliche Nachrichten enthalten kein `@' in der Empfaenger- angabe (und keinen Realnamen). Es ist moeglich, eine Nachricht gleichzeitig an eine bestimmte Person und an ein oeffentliches Brett zu schicken. Fuer Brettnamen gelten folgende Regeln: o Erlaubt sind die grossen Buchstaben von `A' bis `Z', die Zif- fern `0' bis `9', sowie `/', `_', `!', `+' und `-'. Auch hier sind Umlaute nicht erlaubt. III.7:_Weiterleiten_____________________________________________________ 41 o Der Schraegstrich `/' dient zum Trennen von Brettern in Hierachieebenen. Ein Brettname beginnt immer mit einem `/', zwischen zwei `/' muss immer mindestens ein anderes Zeichen stehen. Ein Brettname endet nie mit einem `/'. Der Unterschied zwischen einer oeffentlichen Nachricht (Emp- faenger ist ein Brett) und einer persoenlichen Nachricht besteht darin, dass oeffentliche Nachrichten in der Regel kostenlos trans- portiert werden (also die Autorin nicht von der Systembetreiberin Gebuehren berechnet bekommt), waehrend persoenliche Nachrichten auf Wunsch und auf Kosten der Absenderin versandt werden. Eine denkbare Ausnahme hiervon ist z.B. ein Support-Brett, in dem Benutzerinnen von der Support-Anbieterin Gebuehren fuer das Stellen von Fragen berechnet werden. Eine persoenliche Nachricht kann als Empfaengeran- gabe auch ein Brett auf einem anderen System besitzen (/EIN/BRETT@IRGENDWO.do.main). Sie wird dennoch als persoenliche Nachricht abgerechnet. Im Zielsystem wird diese Nachricht zunaechst zensiert und muss von der Systembetreiberin freigeschaltet werden - falls das System einen derartigen Mechanismus unterstuetzt. Alternativ kann die Nachricht auch der Systembetreiberin zugestellt werden, die sie dann manuell in das gewuenschte Brett transportiert. Ist sie dazu nicht bereit, schickt sie die Nachricht mit einer entsprechenden Fehlermeldung an die Absenderin zurueck. Dieser Mechanismus ist notwendig, da ansonsten die Schreib- berechtigung in das gewuenschte Brett nicht kontrolliert werden kann. III.7 Weiterleiten Beim Weiterleiten darf die Originalnachricht keinesfalls bearbei- tet werden. Es ist lediglich erlaubt, einen Kommentar (mit Hilfe des KOM Headers) voranzustellen - die Nachricht selbst muss unver- aendert bleiben. Wird eine Nachricht manuell oder von einem Ver- teiler weitergeleitet, gibt es zwei Moeglichkeiten: Die Absenderan- gabe wird ausgetauscht oder die Absenderangabe wird nicht aus- getauscht. In beiden Faellen werden folgende Aktionen vorgenom- men: o Die Nachricht bekommt eine neue Message-ID. o Der Routweg im ROT Header wird geloescht und leer neu hinzugefuegt. 42____________________________________________Kapitel_III:_Das_Datenformat_ o Die urspruengliche Empfaengerin der Nachricht (kann auch ein Brettname sein) wird in den OEM Header kopiert, falls der OEM Header noch nicht existiert. Ansonsten bleibt der OEM Header unveraendert. o Wird an mehrere Empfaengerinnen weitergeleitet, muss der KOP-Header (Kopienempfaenger) entsprechend gesetzt wer- den. Im KOP Header sollten im Idealfall saemtliche Empfaen- gerinnen, die diese Nachricht irgendwann erhalten haben, aufgefuehrt sein. o Ein eventuell vorhandener ERR Header wird geloescht. o Ein eventuell vorhandener ZNETZ-Conf Header wird geloescht. o Falls der Header O-EDA nicht vorhanden ist, wird der Inhalt des EDA-Headers hier hinein kopiert. Anschliessend wird in EDA das aktuelle Datum gesetzt. o Der TRACE-Header wird geloescht. o Der VER-Header wird geloescht. o Der STAT-Header wird geloescht. o Der EB-Header wird geloescht. Die weitere Behandlung ist unterschiedlich. Falls die Absende- rinnenangabe beim Weiterleiten ausgetauscht wird, wird wie folgt verfahren: o Die Weiterleitende wird als Absenderin eingetragen, die absenderbezogenen Header ANTWORT-AN, MAILER, ORG, POST, PRIO, TELEFON werden geloescht und mit den neuen Werten der Absenderin besetzt. o Der WAB Header wird geloescht. o Die Absenderin der Originalnachricht wird in den OAB Hea- der kopiert, falls noch kein OAB Header vorhanden ist. Als Absenderin wird der ANTWORT-AN-Header verwendet, wenn er vorhanden ist, sonst der ABS-Header. Falls der OAB-Header vorhanden ist, wird er nicht veraendert. o Eventuelle PGP-Unterschriften entfernen. (Header SIGNED und PGP-SIG) Falls dagegen die Absenderangabe beim Weiterleiten beibehal- ten wird, wird weiterverfahren wie folgt: o Die Weiterleitende wird in den WAB Header eingetragen, ein evtl. vorhandener WAB Header wird zuvor geloescht. III.8:_Automatisches_Weiterleiten_(Mailing-Listen,_Netzwerk-Verteiler)__ 43 Es gibt keine Moeglichkeit, eine Nachricht weiterzuleiten, ohne die Message-ID zu aendern. Falls eine Systembetreiberin eine Nach- richt in ein anderes Brett verschieben moechte, kann sie dies mit einem entsprechenden Befehl tun (im ZERBERUS z.B. '#copy'). Dies ist aber eine auf die lokale MailBox beschraenkte Aktion, bei der nur folgendes geschieht: o Das Brett, in das diese Nachricht verschoben wird, wird als EMP Header eingetragen o Message-ID und Absenderangabe bleiben erhalten o Der Routestring (ROT Header) bleibt erhalten Diese verschobene Nachricht kann nicht mehr ueber das Netz transportiert werden, da sie die gleiche Message-ID behalten hat und daher von allen anderen Systemen (korrekterweise!) als Rekursion erkannt wuerde. III.8 Automatisches Weiterleiten (Mailing-Listen, Netzwerk-Verteiler) Eine MailBox oder auch eine externe Software kann die Moeglich- keit bieten, ueber das Netz an einen automatischen Verteiler Nach- richten zu schicken. Dieser Verteiler verschickt jede Nachricht an alle eingetragenen Benutzerinnen dieses Verteilers. Dieses Verfahren aehnelt einem oeffentlichen Brett, allerdings ist nicht erforderlich, dass alle Systeme, ueber die die Nachrichten transportiert werden, das Brett fuehren. Dem gegenueber steigen natuerlich die Kosten fuer eine solche Nachrichten-Verteilung, da alle Nachrichten, sowohl bis zum Verteiler als auch vom Verteiler zu den Benutzerinnen als PM verschickt werden. Beim Eintreffen einer Nachricht in einem solchen Verteiler geschieht folgendes: o Die Absenderin der Originalnachricht erhaelt eine Empfangs- bestaetigung - falls sie diese angefordert hatte (EB Header). Danach wird der EB-Header aus der Mail geloescht. o Alle Benutzerinnen des Verteilers werden ermittelt und als Empfaengerinnen eingetragen. o Die eingetragenen Kopienempfaengerinnen bleiben erhal- ten! Es wird keine Kopienempfaengerin hinzugefuegt, dies geschieht erst beim Routen der Nachricht. o Die Adresse des Verteilers wird in den OEM Header eingesetzt. 44____________________________________________Kapitel_III:_Das_Datenformat_ o Die Absenderin der Nachricht bleibt erhalten. Die E- Mail-Adresse der Betreuerin des Verteilers kann als WAB- Header eingesetzt werden. Dadurch gehen Antworten an den urspruenglichen Autor, Fehlermeldungen ueber falsche Ein- traege im Verteiler aber an dessen Verwalterin. o Der TRACE-Header wird geloescht. III.9 Weiterleitungen durch Netzwerk-Vertreter Bei Abwesenheit kann eine Benutzerin einer MailBox eine Vertre- teradresse in ihrer MailBox angeben. Saemtliche Nachrichten, die ihr Postfach erreichen werden (auf ihre Kosten) automatisch an die dort angegebene Adresse weitergeleitet. Beim Eintreffen einer Nachricht an eine Benutzerin, die einen Vertreter gesetzt hat, passiert folgendes: o Enthaelt die Nachricht eine Empfangsbestaetigung, so wird diese nicht versendet. Der Empfang wird durch die Vertre- terin bestaetigt. o Da es sich um eine persoenliche Nachricht handelt, braucht die Message-Id bei dieser Art der Weiterleitung nicht geaen- dert zu werden. o Die Empfaengeradresse (EMP-Header) wird in den VER-Header kopiert. o Der Header O-ROT wird geloescht und mit dem Routstring (Header ROT) der Nachricht gefuellt. o Danach wird der HeaderROT geleert, d.h. der Header wird geloescht und es wird der Name der weiterleitenden MailBox (mit Domain) eingetragen. III.10 Beispiel Beispiel fuer eine ZCONNECT-Nachricht (von Martin Husemann auf dem Point MARTIN der BIONIC an Martin Husemann auf dem System 'sisyphus.owl.de'): EDA: 19920607140703S+2 BET: Dies ist ein Routingtest MID: 70.54215@MARTIN.BIONIC.zer.de ABS: M.Husemann@BIONIC.zer.de (Martin Husemann) ROT: BIONIC.zer.de EB: EMP: M.Husemann@sisyphus.owl.de LEN: 103 III.11:_Moegliche_Header-Informationen__________________________________ 45 PRIO: 0 Hallo Martin, falls Du das hier ueber BI-LINK bekommst, stimmt das Routing. Gruss, Martin III.11 Moegliche Header-Informationen ABS Absenderin, PAEicht, nur einmal Die Adresse, ueber die die Absenderin erreichbar ist, kom- plett mit Absendersystem, Domainangabe und evtl. Real- name. ANTWORT-AN optional Eine private Antwort an die Absenderin ist nicht an die ABS-Adresse zu schicken, sondern an die hier angege- bene. Dies ermoeglicht Benutzerinnen mehrerer MailBoxen, alle Antworten an die 'Hauptadresse' schicken zu lassen. Auch bei automatisch generierten Nachrichten (Absende- rin 'Mailer-Daemon') kann so eine Ansprechpartnerin fuer Rueckfragen angegeben werden. BET Betreff, PAEicht, nur einmal Ein bei Antworten automatisch generierter Betreff ist so zu waehlen, dass vor den Betreff der Originalnachricht ein `Re: ' gesetzt wird, falls dort nicht bereits `Re: ' oder `RE: ' steht. Ansonsten wird der Betreff unveraendert uebernommen. Es gibt also nur 'Re: xxx', niemals aber 'Re: Re: xxx'. Die Verschachtelungstiefe der Antworten ist aus den BEZ Headern zu entnehmen. BEZ Bezug, optional, mehrfach Wenn diese Nachricht eine Antwort auf eine aeltere Nach- richt ist, gibt der Bezug die Message-ID der Originalnach- richt an. Wenn mehrere Bezuege enthalten sind, so stehen aeltere vor neueren. Stellt eine zu erzeugende Nachricht eine Antwort in welcher Form auch immer (automatisch, manuell, Fehler, etc.) dar, so ist die Message-ID der Nachricht, auf die geantwortet wird, in den Header BEZ zu setzen. Enthielt die ursprueng- liche Nachricht bereits einen oder mehrere BEZ, so ist der 46____________________________________________Kapitel_III:_Das_Datenformat_ neue Bezug als letzter an die bereits vorhandenen Bezuege anzuhaengen. Die Reihenfolge der bisherigen Bezuege darf nicht veraendert werden. CHARSET Zeichensatz, optional, nur einmal Mit diesem Header kann deoniert werden, welcher Zeichen- satz in einer Textnachricht verwendet wird. Moegliche Werte sind: ISO1, ISO2, ISO3, ISO4, ISO5, ISO6, ISO7, ISO8, ISO9, UNICODE. Hierbei meint ISO1 bis ISO9 den Zeichensatz ISO-8859-1 bis -9. Es wird dringenst empfohlen, mindestens ISO1 zu unterstuetzen. Hinweis: Ist der Header CHARSET nicht vorhanden, so gilt aus Kompatibilitaetsgruenden die Zeichensatzdeonition aus ZCONNECT Version 3.0. Der Header CHARSET wirkt sich nur auf den Body der Nach- richt aus, niemals auf den Header. Ein Nachrichten-Header ist immer im ASCII-7-Bit-Format. Der Parameter im Header ist nicht case sensetiv. CRYPT Crypter, optional, nur einmal Kennzeichnet diese Nachricht als verschluesselt. Dieser Hea- der enthaelt ein Schluesselwort, das das Verschluesselungsver- fahren angibt. Folgende sind bisher deoniert: PMCRYPT2 Ein von XPoint verwendetes Verfahren DES/ECB NSA LowTech: Electronic Code Book DES/CBC DES Cipher Block Chain DES/CFB DES Cipher Feedback DES/OFB DES Output Feedback PGP Pretty Good Privacy QPC QuickPoint Crypt Die Schluesselworte sind unabhaengig von Gross/Kleinschreibung auszuwerten. CRYPT-CONTENT-TYP optional, nur einmal Verschluesselte Nachrichten sind immer Binaernachrichten. Der urspruengliche Typ der Nachricht wird hierher ueber- nommen. III.11:_Moegliche_Header-Informationen__________________________________ 47 CRYPT-CONTENT-KOM optional, nur einmal Es wird immer alles verschluesselt und unterschrieben, was unter LEN: steht, also inklusive eines eventuelle Kom- mentars. Damit der korrekte Kommentar wieder rekon- struiert werden kann, wird KOM: beim Verschluesseln in CRYPT-CONTENT-KOM umbenannt. Selbstverstaendlich kann danach noch einmal ein Kommentar angehangen werden, zum Beispiel beim Weiterleiten einer fehlerhaften Nach- richt. DDA Dateidatum, optional, nur einmal Gibt das Datum der letzten Aenderung einer Datei an. Das Format des Datums ist unter EDA beschrieben. DISKUSSION-IN optional, auch mehrfach Gibt die Empfaengerin an, die bei oeffentlichen Antworten benutzt werden soll. Dies ist immer dann sinnvoll, wenn eine Nachricht in mehrere Bretter geschickt wird, die dar- auf folgende Diskussion aber auf ein Brett beschraenkt wer- den soll. Es koennen aber auch reine Informationsbretter von Diskussionsbeitraegen freigehalten werden, indem die Ant- worten auf ein passendes Diskussions-Brett dirigiert wer- den. Im Header DISKUSSION-IN koennen auch E-Mail-Adressen gesetzt werden. Das absendende System sollte dann aber sicherstellen, dass hier nur E-Mail-Adressen der Absenderin eingesetzt werden koennen, um Missbrauch keinen Vorschub zu leisten. EB optional, auch mehrfach Ist dieser Header vorhanden, verschickt das Zielsystem, sobald die Nachricht von ihm empfangen wird, eine Emp- fangsbestaetigung an die Absenderin. Benutzt die Empfaen- gerin einen Point und ist dieser auch mit ZCONNECT ange- schlossen, wird die Empfangsbestaetigung nicht beim Emp- fang in der MailBox ausgeloest, sondern erst vom Point. In allen anderen Faellen wird beim Einsortieren der Nachricht in die MailBox sofort die Bestaetigung verschickt. Bestaetigt wird der Empfang, nicht das Lesen der Nachricht (Daten- schutz!). Der EB Header kann auch eine Adresse enthalten, in diesem Fall geht die Empfangsbestaetigung nicht an die Absenderin, 48____________________________________________Kapitel_III:_Das_Datenformat_ sondern an die angegebene Adresse. Sind mehrere EB Hea- der vorhanden, erhaelt jede dort aufgefuehrte Adresse eine Bestaetigung. In der Bestaetigung ist im BEZ Header die Message-ID der bestaetigten Nachricht anzugeben. Weiterhin ist ein Header STAT: EB zu setzen. EDA Datum, PAEicht, nur einmal Das Erstellungsdatum wird dabei im Format JJJJMMTThhmmss[S/W](+/-offset) angegeben, wobei S oder W fuer Sommer bzw. Winterzeit steht, offset ist die Zeitzone als Unterschied in Stunden zur GMT. Dabei wird die Zeit immer als GMT angegeben, die Zeitzone/Sommerzeit ermoeglicht lediglich das Umrechnen dieser universellen Zeit auf die lokale Zeit der Absenderin. In Deutschland gelten die Zeitzonen MET und im Sommer MEST. Diese wuerden durch die Zusaetze 'W+1' bzw. 'S+2' dargestellt Durch die Darstellung als GMT sind die JJJJMMTThhmmss Angaben auch waehrend der Umstellung von Sommer- auf Winterzeit und umgekehrt kontinuierlich. Falls die lokale Uhrzeit nicht um ganze Stundenbetraege von GMT abweicht, wird dem Offset eine Minutenangabe zugefuegt. Beispiel: 'W-9:30' fuer die Zentral- Australische- Zeitzone. Siehe auch Anhang 'Zeitzonen'. EMP Empfaenger, PAEicht, mehrfach Die Netzadresse der Empfaengerin(nen). Tritt diese Information mehrfach auf, muss diese Nach- richt an jede dieser Empfaengerinnen weitergeleitet werden. Geschieht dies nicht ueber ein gemeinsames Routesystem, sind Kopien der Nachricht anzufertigen. Bei diesem Kopiervorgang bekommen die einzelnen Kopien nur noch die EMP Header, an die diese Kopie weitergehen soll. Alle uebrigen Empfaenger (die ueber ein anderes System erreicht werden sollen) werden als Kopienempfaenger (KOP Header) eingetragen, falls nicht STAT:NOKOP angegeben ist. Enthaelt eine der EMP-Angaben keinen '@', handelt es sich um eine oeffentliche Nachricht. Eine Nachricht kann in meh- rere oeffentliche Bretter geschickt werden, indem fuer jedes Brett eine EMP-Information eingesetzt wird. Physikalisch III.11:_Moegliche_Header-Informationen__________________________________ 49 wird natuerlich nur eine Kopie der Nachricht weitergereicht. Hier wird also - im Gegensatz zu den privaten Nachrichten - niemals kopiert. Hat ein System nicht alle der in EMP Headern angegebe- nen Bretter bestellt, muessen dennoch alle EMP Header wei- tergegeben werden! Das gleiche gilt, wenn auf dem lokalen System nicht jedes Brett, das in einem EMP Header aufge- fuehrt wird, existiert. Ein EMP Header darf auch einen Realnamen enthalten. ERR Error, optional, nur einmal Falls dieser Header vorhanden ist, wurde die Nachricht von einem Programm automatisch zurueckgeschickt - entweder weil die Nachricht fehlerhaft oder die Empfaengerin unbe- kannt war. Der Inhalt des ERR-Headers ist i.W. die Feh- lermeldung im Klartext. Optional kann der Fehler vor der Meldung durch eine Zahlenfolge identioziert werden: ERR: [ErrClass[;ErrNo[;...]]] [ErrMessage] Ein leerer ERR-Header ist unzulaessig. ErrMessage enthaelt einen nach Moeglichkeit englischspra- chigen Text, der den Fehler moeglichst treffend beschreibt. ErrMessage ist nur dann optional, wenn mindestens ErrClass deoniert ist. ErrClass enthaelt die Fehlerklasse. Dabei sind Werte 0 moeglich. Werte im Bereich 0 ErrClass 4 signalisieren hierbei, dass die Nachricht trotz Fehlern zugestellt worden ist; Der Bereich 5 ErrClass 9 signalisiert, dass die Nachricht nicht zugestellt werden konnte. Fuer ErrNo gilt folgende Belegung: 1 Versand nicht moeglich. 1;1 Konto ueberzogen. 1;2 Mail zu alt. 1;3 Netzzugriff fuer Absenderin gesperrt. 2 PM-Zustellung nicht moeglich. 2;1 Keine Empfaengerin der Nachricht angegeben. 2;2 Empfaengerin im Zielsystem unbekannt. 2;3 Verteiler schreibgeschuetzt. 3 PM-Routing nicht moeglich. 3;1 Routsystem unbekannt oder gesperrt. 50____________________________________________Kapitel_III:_Das_Datenformat_ 3;2 Direktmails & Routmails gesperrt. 3;3 Routing nicht moeglich da Mail zu lang. 3;4 System in Domainserver unbekannt. 3;5 Eingestellter Domainserver unbekannt. 3;6 PM-Rekursion. 3;7 Empfangssystem gesperrt. 3;8 Domain unbekannt. 4 Brett-Zustellung nicht moeglich. 4;1 Brett fuer Netcallempfang gesperrt. 4;2 Brettname unzulaessig. 4;3 Brett existiert nicht. 4;4 Brett gesperrt. 4;5 Kein Autoeintrag; mehrfache Brettangaben. 5 Verletzung von Regeln fuer den Header. 5;1 Ein nur einmal erlaubter Header tritt mehrfach auf. 5;2 Ein PAEichtheader ist nicht vorhanden. 5;3 Ein Header hat falsches Format. 5;x;1 ABS-Header, 1 x 3, siehe oben. 5;x;2 EMP-Header, 1 x 3, siehe oben. 5;x;3 EDA-Header, 1 x 3, siehe oben. 5;x;4 BET-Header, 1 x 3, siehe oben. 5;x;5 ROT-Header, 1 x 3, siehe oben. 5;x;6 GAB-Header, 1 x 3, siehe oben. 5;x;7 MID-Header, 1 x 3, siehe oben. 5;x;8 WAB-Header, 1 x 3, siehe oben. 5;x;9 KOP-Header, 1 x 3, siehe oben. 5;x;10 OAB-Header, 1 x 3, siehe oben. 5;x;11 OEM-Header, 1 x 3, siehe oben. 5;x;12 EB-Header, 1 x 3, siehe oben. 5;x;13 Antwort-An-Header, 1 x 3, siehe oben. 5;x;14 Diskussion-In-Header, 1 x 3, siehe oben. ERSETZT optional Gibt die Message-ID der Nachricht an, die von dieser ersetzt wird. Damit kann dafuer gesorgt werden, das von einer regel- maessig veroeffentlichten Information immer nur die aktuelle Version in einer MailBox vorhanden ist. Anwendungsbei- spiele: Serverstruktur, MailBox-Listen, ZMAPs, FAQs etc. Falls der Nachrichtentext der Nachricht leer ist, so ist die betreffende 'ersetzte' Nachricht zu loeschen. III.11:_Moegliche_Header-Informationen__________________________________ 51 Beide Anwendungsfaelle, Nachrichtenersetzung und netzweite Ruecknahme beduerfen einer Pruefung der Autorisierung. Dies kann beispielsweise durch die Pruefung der Identitaet der Absenderin oder mit Hilfe des oeffentlichen Schluessels der Absenderin geschehen. Bei der Implementation des ERSETZT-Headers ist es ausrei- chend, wenn bei der alten Nachricht notiert wird, dass diese inzwischen ersetzt wurde bzw. vom Autor zurueckgezogen wurde. FILE Filename, optional, nur einmal Gibt den Dateinamen (ohne Directory!) der Datei an - zum Beispiel fuer Binaernachrichten oder Graoken. ! ! Je nach Betriebssystem des Absende-Systems, kann dieser Dateiname beliebig lang sein und evtl. Sonderzeichen, Leer- zeichen sowie natuerlich mehrere Punkte enthalten! Jede Software, die diesen Header auswertet, um diese Nach- richt zu speichern, sollte darauf vorbereitet sein und entwe- der den Namen entsprechend kuerzen sowie ungueltige Zei- chen durch Ersatzdarstellungen ersetzen oder bei unguelti- gen Namen einen eigenen Namen generieren. KOM Kommentarlaenge, optional, nur einmal Laenge des Kommentars in Byte. Wird z.B. fuer Binaer- nachrichten, denen ein ASCII-Kommentar vorangestellt ist, gebraucht. Nach dem Header folgt der Kommentar in der angegebenen Laenge, dann erst die Binaerdaten. Die Binaer- datenlaenge ist also LEN minus KOM. Ein Kommentar kann aber auch bei allen anderen Nachrichtentypen vorangestellt werden. Fuer den Inhalt des Kommentars gelten immer die Regeln fuer Standard-Textnachrichten, auch wenn er einem Text mit alternativem Zeichensatz (und entsprechender TYP- Information) vorangestellt ist. KOP Kopienempfaengerin, optional, mehrfach Falls eine Nachricht an mehrere Personen geschickt wurde, kann diese Information die uebrigen Empfaengerinnen auf- listen. Gibt es mehrere Kopienempfaengerinnen, tritt diese Information mehrfach mit jeweils einer Empfaengeradresse auf (je eine KOP-Information pro Empfaengerin). ! ! Diese Information dient nur der Dokumentation fuer die Empfaengerinnen, sie wird nicht zum Steuern der Nachrich- 52____________________________________________Kapitel_III:_Das_Datenformat_ tenweiterleitung verwendet. Falls eine KOP Angabe gemacht wird, aber keine entsprechende EMP Angabe vorhanden ist, wird die routende Software sich nicht bemuehen, dieser KOP- Adressatin eine Kopie zuzusenden. Die Software wird viel- mehr davon ausgehen, dass diese Adressatin ihre Kopie bereits ueber einen anderen Routweg erhalten hat (bzw. erhalten wird). LANGUAGE Antwortsprache, optional, nur einmal Mit diesem Header kann die Absenderin einer Nachricht angeben, in welcher Sprache sie gerne ihre Antworten erhal- ten moechte. Dieses sollte auch und gerade bei automati- schen Nachrichten beruecksichtigt werden. LANGUAGE enthaelt einen Parameter. Dabei handelt es sich um den englischsprachigen Namen der betreffenden Spra- che, also GERMAN fuer Deutsch. Im folgenden eine Liste ver- wendbarer Kuerzel im LANGUAGE-Header: _Kuerzel______Sprache_____ GERMAN Deutsch ENGLISH Englisch SPANISH Spanisch FRENCH Franzoesisch GREEK Grichisch Kann eine Sprachpraeferenz nicht befriedigt werden, so sollte nach Moeglichkeit Englisch verwendet werden. Ist der Hea- der nicht vorhanden, kann die Antwort aus Kompatibili- taetsgruenden in Deutsch erfolgen. LDA Loeschdatum, optional, nur einmal Ein Datum, ab dem diese Nachricht automatisch geloescht werden soll/kann. Kann fuer Veranstaltungshinweise oder andere Nachrichten mit 'Verfallsdatum' (z.B. die urgent actions von amnesty international) verwendet werden. LEN Laenge, PAEicht, nur einmal Die Laenge des Inhalts (alles, was hinter dem Header noch zu dieser Nachricht gehoert) in Byte. Auch die Laenge 0 ist erlaubt. MAILER Mailer, optional, nur einmal Gibt den Namen des (von der Absenderin, bzw. vom kon- vertierenden Gateway) verwendeten Mailers an. (pure Wer- bung, aber immerhin fuer Userinnen unsichtbar) Dient der III.11:_Moegliche_Header-Informationen__________________________________ 53 Fehlererkennung im Netzwerk. Hier sollte eine eindeutige Kennung der Software incl. Versions- und Releasenummer stehen. MID Message-ID, PAEicht, nur einmal Die Message-ID muss wie eine gueltige Adresse (ohne Real- name) aussehen (siehe oben) und darf innerhalb von zwei Jahren weltweit nicht wiederholt werden. Dazu muessen Message-IDs eine Domain enthalten. Die Message-ID dient zur eindeutigen Identiokation die- ser Nachricht. Sollte innerhalb von zwei Jahren eine Nach- richt mit einer gleichen Message-ID noch einmal auftreten, ist dies eine Rekursion, d.h. die Nachricht ist ueber einen Umweg noch einmal zur MailBox gelangt und kann des- halb geloescht werden. Sie darf auf keinen Fall weitergeleitet werden. Eine praktische Implementationsmoeglichkeit ist es z.B., alle Message-IDs fuer 90 Tage aufzubewahren und alle ein- gehenden Nachrichten gegen diese Datenbank zu pruefen. Eingehende Nachrichten, die aelter als 90 Tage sind, koen- nen bedenkenlos entsorgt werden, ohne die Message-ID zu testen. Der Rekursionstest anhand der Message-ID muss von jeder Software durchgefuehrt werden! Oeffentliche Nachrichten, die als Rekursion erkannt wurden, duerfen nicht weitergeroutet werden. Persoenliche Nachrichten werden nicht auf Rekursion geprueft, lediglich das Zielsystem der Nachricht darf doppelte persoenliche Nachrichten ausoltern. In Message-IDs sind die Zeichen `<', `>' und `/' verboten. O-ROT Original-Routweg, optional, nur einmal Fuer diesen Header gelten dieselben Formatregeln, wie fuer den Header ROT. Bei Weiterleitungen durch Netzwerkvertreterinnen (siehe Abschnitt III.9 wird der Routstring (Header ROT) in die- sen Header kopiert. Hierdurch wird bei persoenlichen Nach- richten das faelschliche Melden von Ping-Pong-Routing ver- hindert. 54____________________________________________Kapitel_III:_Das_Datenformat_ O-EDA Original-Erstellungsdatum, optional, nur einmal Dieser Header enthaelt ein Nachrichtendatum. Es gelten die Regeln fuer Datumsangaben, die bei Header EDA erlaeutert wurden. Um das versehentliche Loeschen von weitergeleiteten Mails als 'zu alt' zu verhindern, muss bei Weiterleitungen ein aktuelles Nachrichtendatum eingesetzt werden. Damit das Original-Erstellungsdatum nicht verloren geht, wird es bei der ersten Weiterleitung der Nachricht (O-EDA existiert nicht) in diesen Header kopiert. OAB Original-Absenderin, optional, nur einmal Falls eine Nachricht manuell oder per Verteiler weitergelei- tet wurde, steht hier, wer die Nachricht original verschickt hat. OEM Original-Empfaengerin, optional, mehrfach Falls eine Nachricht manuell oder per Verteiler weitergelei- tet wurde, steht hier die urspruenglich angegebene Empfaen- gerin. ORG Organisation, optional, nur einmal Eine kurze, einzeilige Beschreibung der hinter der Absen- derin stehenden Organisation, z.B. 'Borland Deutschland GmbH, Starnberg, F.R.G.'. Wird eine solche Information eingesetzt und die Nachricht gibt nicht die oOEzielle Mei- nung der Organisation wieder, wird im Nachspann (Signa- tur) der Nachricht meist der 'Standard- Disclaimer' einge- fuegt: 'Meine Meinung ist nur meine Meinung. Sie wird von meiner Arbeitgeberin weder geteilt noch bezahlt.' PGP optional, mehrfach Enthaelt weitere Informationen bezueglich PGP- Verschluesselung. Diese Zeile kann auch bei nicht mit PGP bearbeiteten Nachrichten auftreten. Derzeit moegliche Werte: PLEASE Die/der AbsenderIn bittet die/den EmpfaengerIn, den im Header PGP-PUBLIC-KEY erhaltenen Public-Key (zur AbsenderInnenadresse) zu veriozieren. Gilt nicht in oeffentlichen Nachrichten. Das Pointprogramm sollte darauf aufmerksam machen, dass die Veriozierung eines Schluessels nur III.11:_Moegliche_Header-Informationen__________________________________ 55 durch persoenlichen Kontakt erfolgen sollte, also zum Beispiel ein Telefongespraech oder eine direkte Begegnung mit Abgleich des Fingerprints. REQUEST Fordert das Pointprogramm auf, den 'eigenen' Public-Key als Mail an die AbsenderInnenadresse zu schicken. Gilt nicht in oeffentlichen Nachrichten. PGP-ID optional, nur einmal Zu jedem PGP-Public-Key gehoert eine User-ID, die sich normalerweise aus Netzadresse und Realnamen zusammen- setzt, in der Form Real Name zusammen- setzt. Zum Beispiel: Christoph Teuber Weicht die PGP-UserId von dem aus der Adresse ermittel- baren Header ab, so kann die richtige ID in diesem Header transportiert werden. PGP-PUBLIC-KEY optional, nur einmal Enthaelt den PGP-Public-Key des Absenders. Genaueres siehe Abschnitt III.13.2. PGP-KEY-AVAIL optional, auch mehrfach Kann in jeder Nachricht stehen und signalisiert, dass die/der AbsenderIn die Nutzung von PGP anbietet und wie der oeffentliche Schluessel zu beziehen ist. Grundsaetzlich, also auch bei leerer Headerzeile, ist der zur AbsenderInnenadresse gehoerige oeffentliche Schluessel ueber eine private Nachricht mit gesetztem PGP:REQUEST zu erhalten. Zusaetzlich kann dort eine Zeile im Format +49-5202-88888 bi-link.owl.de martin@bi-link.owl.de Der Public-Key kann dann per ZCONNECT Key-Request abgeholt werden. Parameter: 1.Telefonnummer im internationalen Format einer Modem-Leitung dieser MailBox. 2.Systemname der MailBox, die den Key-Server betreibt. Wird weggelassen, wenn dies dem System der AbsenderInnenadresse entspricht. 3.UserInnenname, die Netzadresse, die im Key ange- geben ist. Dies wird im PGP-KEYREQ Header angege- 56____________________________________________Kapitel_III:_Das_Datenformat_ ben. Wird weggelassen, wenn dies der AbsenderInnen- adresse entspricht. 4.Optionaler Parameter ISDN, falls es sich bei der Tele- fonnummer um einen ISDN-Anschluss handelt. PGP-KEY-COMPROMISE optional, nur einmal Inhalt genau wie PGP-PUBLIC-KEY. Dieser Header enthaelt einen widerrufenen Key. Er darf nur zusammen mit dem neuen Key (als PGP-PUBLIC-KEY) auftreten. PGP-KEY-OWN optional, nur einmal Inhalt genau wie PGP-PUBLIC-KEY: Enthaelt den eigenen Schluessel mit einer neuen Unterschrift. Dies sollte als Ant- wort auf ein PGP:PLEASE generiert werden. PGP-SIG optional, nur einmal Falls die Nachricht mit PGP unterschrieben ist der Hea- der SIGNED:PGP ist vorhanden steht in diesem Header die BASE64-Codierung der PGP-Unterschriftsdatei. Diese Datei laesst sich mit PGP -sb erzeugen und analog zum Hea- der PGP-PUBLIC-KEY in einen Header umwandeln. POST Post-Adresse, optional, nur einmal Wenn die Absenderin einer Nachricht auch ueber andere Medien, z.B. per Post, erreichbar sein moechte, kann sie in diesem Header ihre postalische Anschrift unterbringen. Die einzelnen Anschriftenzeilen werden hintereinander geschrie- ben und jeweils durch Semikola ';' getrennt. PRIO Prioritaet, optional, nur einmal Ist dieser Headerinformation nicht angegeben, gilt PRIO:0. Gibt die Dringlichkeit der Zustellung an. Zur Zeit sind folgende Dringlichkeiten deoniert: 0 normal (per Routing) 10 direkt zum Zielsystem 20 Eilmail (direkt mit sofortiger Auslieferung) Nachrichten, die ueber den Routweg bei einem Serversystem eintreffen, duerfen jedoch immer auch per Routing weiter- verteilt werden. ROT Routweg, PAEicht, nur einmal Jedes System traegt sich hier ein, wenn es die Nachricht empfaengt. Eine Nachricht (auch eine PM) darf niemals an III.11:_Moegliche_Header-Informationen__________________________________ 57 ein System weitergereicht werden, dessen Name bereits im Routweg steht. Falls eine PM ueber ein System zugestellt werden muss, das bereits im Routweg steht, sollte diese Nachricht dem Sysop vorgelegt werden (Achtung: Datenschutz! Nur die Header, nicht der Nachrichteninhalt darf sichtbar sein!), da offenbar ein Ping-Pong-Routing besteht. Als erstes System traegt sich hier das Absender-System ein (damit auch dieses die Nachricht nicht noch einmal bekommt). Erreicht die Nachricht das naechste System, setzt dieses seinen eigenen Namen (incl. Domain) gefolgt von einem `!' vor den alten Inhalt dieser Information. Dazu ein Beispiel: auf der BIONIC.zer.de wird eine Nachricht erzeugt: ROT: BIONIC.zer.de Nun erreicht diese Nachricht die BI-LINK.owl.de: ROT: BI-LINK.owl.de!BIONIC.zer.de SIGNED optional, nur einmal Enthaelt Informationen darueber, wie und ob die Nachricht authentisiert wurde. Derzeit moegliche Werte PGP Die Nachricht ist mit PGP unterschrieben. Dies kann zusaetzlich zu einer Verschluesselung erfolgt sein (CRYPT:PGP ist dann ebenfalls gesetzt) oder einzeln. Falls die Nachricht nicht zusaetzlich verschluesselt ist, steht die Unterschrift in PGP-SIG. SPERRFRIST Gueltig ab, optional, nur einmal Ein Datum im Format wie EDA. Vor diesem Datum wird diese Nachricht nicht angezeigt. Damit kann z.B. eine Sperrfrist bei Pressemeldungen eingehalten werden. STAT Nachrichtenstatus, optional, mehrfach Beschreibt, was die Nachricht ist: Falls dieser Header fehlt, handelt es sich um eine normale Mail. Wenn der Header vorhanden ist, gibt es folgende Eintraege: 58____________________________________________Kapitel_III:_Das_Datenformat_ AUTO Nachricht ist eine automatisch und regelmaessig versandte Nachricht. Diese Information kann genutzt werden, um die fruehere Version zu loeschen. EB Nachricht ist eine automatisch ver- schickte Empfangsbestaetigung. CTL Nachricht ist eine Kontrollnachricht, die - auch wenn sie defekt ist - nicht zurueckgeschickt werden darf. TRACE Kennzeichnet eine Nachricht als TRACE- Nachricht. Beschreibung, siehe TRACE Header. NOKOP Bestimmt, dass beim Routen EMP- Header nicht in KOP-Header kopiert werden sollen. (siehe EMP-Header) NOCIPHER Bestimmt bei nicht verschluesselten Nachrichten, dass auch eventuelle Ant- worten darauf nicht automatisch ver- schluesselt werden. Die Schluesselworte sind unabhaengig von Gross/Kleinschreibung auszuwerten. STICHWORT Stichworte, optional, mehrfach Listet einzelne Stichworte zum Inhalt der Nachricht. Jeder STICHWORT-Heder enthaelt nur ein Stichwort. Die Suche nach Stichworten ist unabhaengig von der Gross/Kleinschreibung. Es sind nur die Zeichen von A-Z in diesem Header zugelassen. TELEFON Telefonnummer, optional, nur einmal Hier kann die Absenderin ihre Telefonnummer(n) unter- bringen. Es wird die internationale Schreibweise verwen- det, mit vorangestelltem 'V' fuer Voice, 'F' fuer Fax, 'P' fuer Pager (Cityruf) oder 'B' fuer MailBox (BBS). Bei Voice- Nummern wird ein 'Q' nachgestellt, wenn ein Anrufbeant- worter vorhanden ist. Alle Nummern werden durch Semi- kolon oder Leerzeichen getrennt. Beispiel: TELEFON: V+49-521-561345Q F+49-521-561785 B+49-521-193004 Bei kombinierten Nummern werden die Kennbuchstaben hintereinandergestellt. III.11:_Moegliche_Header-Informationen__________________________________ 59 TRACE optional, nur einmal Enthaelt eine E-Mail-Adresse, an die die Trace-Information gesendet werden soll. Jedes System, das eine so gekenn- zeichnete Nachricht empfaengt (bzw. weiterleitet) sendet eine Trace-Meldung an die angegebene Adresse. Die Trace- Meldung enthaelt (u.a.) die folgenden Header: BEZ: (orig-id) BET: Trace-Info (orig-id) STAT: CTL STAT: TRACE Der Inhalt ist eine Liste, an welche Systeme diese Nachricht mit welchen EMP: Headern weitergeleitet wurde. Um den Inhalt sprachunabhaengig parsbar zu machen, werden alle Systemnamen in < > gesetzt. Fuer jedes Routsystem gibt es einen Abschnitt bestehend aus der Identiokation dieses Systems (also ) gefolgt von einer Liste der zu die- sem System geschickten EMP Header. Die EMP Liste enthaelt einen EMP pro Zeile und beginnt mit einem Leerzeichen oder Tabulator. Sobald eine Zeile wieder direkt am Zeilenanfang beginnt, ist dies die naechste Routsystem-Zeile. Beispiel fuer eine Antwort-Mail: An gingen folgende EMP: Header: An gingen folgende EMP: Header: An gingen folgende EMP: Header: Die Trace-Information darf nur bei persoenlichen Nachrichten stehen (und auch nur dann beantwortet werden). Der TRACE- Header ist bei Weiterleitungen zu loeschen. TYP Typ, optional, nur einmal Naehere Beschreibung des Dateityps. Deoniert, um welche Art von Binaerdatei es sich handelt (z.B. TIFF, GIF, PCX, : :):. Alle unbekannten TYP Informationen werden als reine Binaernachricht aufgefasst. Deoniert sind die Typkennungen: 60____________________________________________Kapitel_III:_Das_Datenformat_ BIN allgemeine Binaernachricht TRANSPARENT Textnachricht ohne Umlautwandlung RFC1563 MIME-Subtype Text/Enriched von N. Borenstein aus RFC 1563 MIME Mime nach RFC 1341. Siehe auch Anmerkungen weiter unten. Beim Inhalt des TYP Headers wird nicht zwischen Gross- und Kleinschreibung unterschieden. Falls kein TYP-Header vorhanden ist, handelt es sich um eine Textnachricht. Hinweis: Die Kennungen RFC1563 und MIME: :w:aren bei Druckle- gung dieses Dokuments noch nicht beschlossen. Sie sind hier der Vollstaendigkeit halber mit beschrieben. Bitte lesen Sie genaueres in der README-Datei der beigefuegten Diskette. Falls der Typ MIME spezioziert ist, wird er folgendermassen in ZCONNECT integriert. Der Mime-Header MIME-Version wird bedeutungsgleich durch den ZCONNECT-Header MIME dargestellt. Fuer die anderen Mime-Header gelten folgende Namen: _MIME-Header_____________________Name_in_ZCONNECT___ Content-Type MIME-Type Content-Transfer-Enconding MIME-Encoding Content-ID MIME-ID Content-Description Zusammenfassung Diese Namens-Umwandlung betrifft nur die Mime-Header, die innerhalb des ZCONNECT-Headers auftauchen. Innerhalb von MIME-Nachrichten gelten die urspruenglichen Namen. VER Vertreter, optional, mehrfach Wenn eine persoenliche Nachricht durch eine Vertreterin automatisch an eine andere Adresse weitergeleitet wird, so wird hier die Adresse der Empfaengerin hinterlegt. Wird die Nachricht mehrfach durch Vertreterinnen weitergeleitet, so kann dieser Header auch mehrfach auftreten. VIA Route-Information, optional, auch mehrfach, Reihenfolge beachten Dieser Header war zur Drucklegung dieser Dokumentation noch nicht beschlossen. Bitte lesen Sie naeheres in der Datei README auf der beiliegenden Diskette nach. Durch diesen Header soll es moeglich sein, stockende per- soenliche Nachrichten besser in den Griff zu bekommen. Die III.12:_Weitere_Headerzeilen____________________________________________ 61 Reihenfolge dieses Header ist vorgeschrieben, und zwar fuegt jedes weitere System, welches eine persoenliche Nachricht transportiert, seinen VIA-Header hinter dem letzten vor- handenen VIA-Header ein. Die Behandlung ist unabhaengig von Gross/Kleinschreibung. Fuer das Format gilt: VIA: @. Das Datum wird dabei im Format wie bei EDA beschrieben angegeben. Fuer die Uhrzeit gilt: Handelt es sich bei dem System um das erste System in der Kette, also dem Absender-System bzw. dem Server des Point-Systems, so kann die Uhrzeit in dieser einen VIA:-Line auf 0 Uhr gesetzt werden. (Datenschutz) WAB Weiterleiten-Absender, optional, nur einmal Die Absenderin der letzten Weiterleitung der Nachricht. Es gelten die fuer Adressheader gueltigen Konventionen. (siehe Abschnitt III.5). Dieser Header wird beim Weiterleiten im Modul `Beibehalten des Absenders' mit der E-Mail-Adresse des Weiterleitenden gefuellt. ZUSAMMENFASSUNG optional, nur einmal Kann eine kurze Zusammenfassung der Nachricht enthal- ten. Wenn die Zusammenfassung im Umfang 10% der Nach- richt uebersteigt, kann der Spooler eine Zustellung mit dem Verdacht auf Umgehung der Routmailgrenzen verweigern. III.12 Weitere Headerzeilen Neue Headerzeilen koennen jederzeit deoniert werden. Jede Soft- ware muss ihr unbekannte Zeilen unveraendert weitergeben. Fuer lokale Erweiterungen wird garantiert, dass niemals eine Header- zeile mit 'X-' beginnen wird. Sie koennen also gefahrlos eigene Headerzeilen wie z.B. 'X-Euromail-Version: 22.5' erzeugen. Headerzeilen, die mit 'U-' beginnen, sind UUCP-Header, ent- sprechen also RFC822/1036 bzw. entsprechenden Nachfolgestan- dards. UUCP oder Internet-Gateways koennen auf diese Weise Informationen, fuer die es im ZCONNECT zur Zeit noch keine Ent- sprechung gibt, 1:1 durchreichen. Beispiel: U-Date: Thu, 12 Jan 1987 PDST entspricht der RFC-1036 Header-Zeile 62____________________________________________Kapitel_III:_Das_Datenformat_ Date: Thu, 12 Jan 1987 PDST In diesem Fall kann die Information jedoch gleichwertig mit dem EDA Header transportiert werden kann, es ist ja nur ein Beispiel: : : Headerzeilen, die mit 'F-' beginnen sind Header, die bei der Konversion von Nachrichten aus dem FTS0001-Format (und des- sen Weiterentwicklungen) entstanden sind. III.13 Verschluesselung von Nachrichten mit PGP Zum Verstaendnis dieses Dokumentes und vor allem zur sinnvollen Integration der hier beschriebenen Techniken in eine Point- oder MailBox-Software ist es unbedingt erforderlich, Phil Zimmerman's Anleitung (pgpdoc1.txt und pgpdoc2.txt) gelesen und verstan- den zu haben! Die Integration von PGP in eine MailBox unterliegt einem inhaerenten ZielkonAEikt. Alle UserInnen, die die hier vorgestellten Moeglichkeiten zur Verbreitung ihres Public-Key verwenden, mues- sen sich bewusst sein, dass sie entweder ihrem lokalen Sysop oder dem Hersteller der MailBox-Software trauen. So wie es Systembe- treiberInnen von ZERBERUS-MailBoxen unmoeglich ist, den Inhalt der persoenlichen Postfaecher ihrer UserInnen einzusehen oder gar zu manipulieren, kann eine MailBox-Software auch die Unantast- barkeit der in der MailBox hinterlegten Public-Keys gewaehrlei- sten. Es gibt (nicht standardisierte) Integrationen von PGP in andere Mail/News- Systeme. Die hier beschriebene Methode geht an vielen Stellen andere Wege, da ZCONNECT als neuer Standard noch nicht auf Tausende von Realisierungen Ruecksicht nehmen muss und deshalb eine vollautomatische Integration moeglich ist. Wichtige Hinweise: o Die in den folgenden Beispielen verwendeten Public Key's sind nicht und waren zu keinem Zeitpunkt gueltige Public Keys. o PGP und die im Anhang abgedruckten Beispielprogramme sind vom Autor in die Public Domain uebergebene Pro- gramme. Sie koennen sie ohne jede Bedingung frei fuer jeden beliebigen Zweck verwenden. o Die fuer die Beispiele verwendete PGP Version 2.3 enthielt schwerwiegende Fehler, die unter DOS z.B. zum Systemab- sturz fuehren koennen. Bitte benutzen Sie eine aktuelle PGP Version. III.13:_Verschluesselung_von_Nachrichten_mit_PGP________________________ 63 III.13.1 Ziele der PGP Integration Der grosse Vorteil eines Public-Key Verfahrens fuer den MailBox- Einsatz ist die freie Veroeffentlichbarkeit der Public-Keys. Die grosse Gefahr ist die Manipulation von Public-Keys. Wir haben daher zwei Verfahren vorgesehen, diese Key's zu verbreiten: o Der Public-Key wird mit anderen Nachrichten (oeffentliche und nichtoeffentliche) mitgeschickt. Diese Form der Verbei- tung unterliegt verschiedenen Manipulationsmoeglichkeiten. Keys, die ueber diesen Weg empfangen wurden, sollten ander- weitig (z.B. per Telefon und Fingerprint) verioziert werden. Programmierer von Pointprogrammen werden gebeten, die BenutzerInnen im Sinne einer eOEzienten Ausnutzung der Netzkapazitaet in ihrer Dokumentation zu einem sparsamen Umgang mit dieser Moeglichkeit aufzurufen. Die Moeglichkeit, den oeffentlichen Schluessel einer Gegenueber auf Anfrage auto- matisch zuzusenden, sollte eine einfache und breite Vertei- lung der oeffentlichen Schluessel gewaehrleisten. o Der Public-Key wird in der Heimat-MailBox der Benutzerin hinterlegt und kann von dort mit Hilfe eines ZCONNECT- Anrufes (auch Gast-Anruf ohne Passwort) abgerufen wer- den. Die Verfuegbarkeit eines Keys auf diesem Weg wird durch einen entsprechenden Status-Header in allen Nach- richten eines Users dokumentiert. Die Informationen in die- sem Header genuegen fuer einen Point, um automatisch einen Key-Request Anruf durchzufuehren. Auf diesem Weg sind Public-Keys recht sicher abrufbar - allerdings ist immer noch Vertrauen in die Heimat-MailBox noetig. UserInnen, die selbst kein PGP verwenden laufen Gefahr, dass der Sysop der Heimat-MailBox einen Key fuer die UserIn generiert und als verfuegbar markiert, obwohl die UserIn nichts davon weiss. Im Zweifelsfall sollte immer ein Abgleich der Fingerprints vorge- nommen werden. Neben der Key-Verteilung sind die uebrigen Ziele: o Einfache Aufnahme der empfangenen Keys in den eigenen Key-Ring: dies kann vollautomatisch geschehen. Durch das 'Introducer' Prinzip kann eine indirekte Authentisierung der Keys erfolgen. PGP verwaltet nicht-authorisierte Keys im Keyring selbst, so dass die UserIn sie spaeter (z.B. telefo- nisch) veriozieren kann. 64____________________________________________Kapitel_III:_Das_Datenformat_ o Transparente Anzeige empfangener verschluesselter oder unterzeichneter Nachrichten. Die UserIn soll keinen Unter- schied in der Bedienung beim Lesen solcher Nachrichten fest- stellen koennen - lediglich einen Status- Hinweis 'diese Nach- richt ist echt' bzw. 'diese Nachricht war verschluesselt'. III.13.2 Key Repraesentation PGP verwaltet Key's (sowohl oeffentliche als auch geheime) voll- staendig selbststaendig in einer geheimen und einer oeffentlichen Datenbank, sogenannten 'Key Rings'. Key's werden aus dieser Datenbank mit dem Kommando pgp -kx in eine externe Datei kopiert. Das Ergebnis ist eine Binaerdatei. Um das Verschicken von Key's auch in E-Mail Systemen ohne Binaernachrichten zu ermoeg- lichen, wird die verpackte ('armor') Form benutzt, diese erhaelt man mit dem Kommando 'pgp -kxa'. Mit 'Key' ist im folgenden immer die rein binaere Form gemeint, eine verpackte Kodierung ist fuer ZCONNECT nicht erfor- derlich, Key's koennen als Binaernachricht verschickt werden bzw. werden in der ZCONNECT Online-Phase als Binaerdatei uebertragen. Die verpackte Form des Headers entspricht der Base64 Kodie- rung gemaess RFC 11133, ergaenzt mit einer CRC Pruefsumme. Base64 unterteilt die Binaerdatei in 3-Byte-Gruppen und erzeugt daraus 4 6-bit Sextets, die als jeweils 1 Zeichen kodiert werden. Das Alphabet fuer diese Kodierung (siehe unten) ist so gewaehlt, dass es den Transport in allen gaengigen E-Mail Zeichensaetzen ueber- steht. RFC 1113 deoniert zusaetzlich noch zwei Zeichen: `=' dient als Fuellzeichen und ist beim Dekodieren zu ueberlesen, `*' ist ein Gruppenseparator und tritt in den hier relevanten Anwendungen nicht auf. Zeilen werden (bis auf die letzte natuerlich) nach genau 64 Zeichen umgebrochen. Ein Beispiel fuer einen verpackten PGP-Key: _________________________3 Siehe auch auf Diskette beigefuegten Mime-Standard (RFC 1341), dort ist die Base64-Codierung ebenfalls erklaert III.13:_Verschluesselung_von_Nachrichten_mit_PGP________________________ 65 ________________________________________________________________________ - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQCNAizSdXcAAAEEAKtB+PaAAnCDLdFGbp0K2f+OTw8ZdoqLqyZZeFz0KHBTIdxj geNlGYpRoxRuEE1OaQVu4jnE0tslOlz2QExEtw8qpAEOfI6EupLamtLa9aXVgZ67 +Nn6L55mUZlhfEAuTjSoMBetOLfPb6ojfLrQGT7ZkRBzfQWmajHmupmZcUdhAAUR tCdNYXJ0aW4gSHVzZW1hbm4gPG1hcnRpbkBiaS1saW5rLm93bC5kZT4= =yo/b - -----END PGP PUBLIC KEY BLOCK----- ________________________________________________________________________ Die inneren Zeilen dieses Blocks enthalten in den ersten vier Zeilen den Key. Dekodiert man die Base64 Kodierung, erhaelt man exakt den gleichen Key, wie ihn PGP mit `pgp -kx' ausgibt. In der fuenften Zeile (beginnend mit einem Fuell-`=') beondet sich eine 24 Bit CRC Pruefsumme der Binaerrepraesentation des Keys. Soll der obige Key in einem ZCONNECT Header transportiert werden, wird er in einer Header-Zeile als Base64 kodiert, ent- spricht also genau den ersten vier Zeilen des obigen Beispiels, nur ohne Zeilenumbrueche: PGP-PUBLIC-KEY: mQCNAizSdXcAAA....saW5rLm93bC5kZT4= Das Programm MKKEY.C erzeugt einen solchen Header aus der Binaerrepaesentation des Keys. Dieses Programm ist im Anhang abgedruckt. Die noetigen Routinen zur Dekodierung eine solchen Headers beonden sich in der Datei armor.c in den PGP-Sourcen, sind aber auch straightforward selbst entwickelbar. Damit ist es z.B. einem RFC Gateway moeglich, einen PGP-PUBLIC-KEY-Header in einen an die Nachricht angehaengten Public-Key Block zu verwandeln. III.13.3 Unterschriften Bei Nachrichten, die nur unterschrieben aber nicht verschluesselt sind, steht die Unterschrift in einem Header namens PGP-SIG. PGP unterstuetzt das mit den Optionen -sb, die eine vom Doku- ment getrennte Unterschrift erzeugen. Mit dieser Unterschriftsda- tei wird dann analog zur Binaerrepraesentation der Schluessel verfah- ren. Dies ermoeglicht auch das Unterschreiben von Binaerdateien. Bei oeffentlichen Nachrichten sollte diese Methode grundsaetz- lich benutzt werden, damit auch BenutzerInnen, die kein PGP installiert haben, die Nachricht lesen koennen. Es ist wenig sinnvoll, bei jeder derartigen Nachricht den eige- nen Public-Key (mit dem die Unterschrift verioziert werden kann), 66____________________________________________Kapitel_III:_Das_Datenformat_ in einem PGP-PUBLIC-KEY mitzuschicken. Wenn unterwegs die unterschriebene Nachricht gefaelscht wird, ist es auch kein Pro- blem, den anhaengenden Schluessel gleich mitzufaelschen. III.13.4 ZCONNECT Key Requests In der ZCONNECT Online-Phase kann (analog zum FILEREQ Header) mit dem Header PGP-KEYREQ der Key einer UserIn abge- fragt werden. Als Argument wird eine Adresse in ZCONNECT Notation angegeben. Falls vorhanden wird der Key der angegebe- nen UserIn als Datei uebertragen. Die UserIn muss dabei nicht unbedingt eine lokale Adresse auf der angerufenen MailBox haben, 'vertrauenswuerdige Server' koennen den Key-Request auch fuer UserInnen fremder MailBoxen anbieten. III.13.5 Durch PGP geaenderte Headerzeilen Nach dem Verschluesseln einer Nachricht kann es vorkommen, dass die Inhalte alter Header nicht mehr stimmen, nach dem Ent- schluesseln aber wieder benoetigt werden, zum Beispiel TYP:. Der Inhalt solcher (auch zukuenftiger) Header wird daher grundsaetz- lich in einen Header mit einem vorangestellten `CRYPT-CONTENT-' uebernommen. `CRYPT' deshalb, weil dieses Problem grundsaetzlich auch fuer andere Verschluesselungsverfahren gilt und die Benennung somit vereinfacht werden kann. ________________________________________________________________________ Anhang A: Empfehlung fuer den 'MAPS-Roboter' ________________________________________________________________________ In der Vergangenheit sind sehr sehr viele, oft zueinander inkom- patible Verfahrensweisen fuer automatische Brettbestellungen in verschiedene Software-Systeme eingebettet worden. Das Ergeb- nis war, dass Pointprogramme oft 5 oder mehr verschiedene Stan- dards fuer Brettbestellungen implementieren mussten. Um mit die- sem Chaos aufzuraeumen, wurde auf dem Z-Netz-Treffen, Ham- burg'94 ein Kompromiss erdacht, der in diesem Dokument als Anhang strengstens zur Implementierung empfohlen werden soll. Der hier beschriebene Standard ist so weit wie moeglich zu den bis- her geltenden Standards kompatibel und stellt insofern ein Mini- mum dar, das die verschiedenen ZCONNECT-Systeme zur Verfuegung stellen sollten. A.1 Allgemeines Die Steuernachrichten sind an den Usernamen 'MAPS@.' zu schicken. Die Anwei- sungen stehen grundsaetzlich im Betreff und ermoeglichen somit eine Erstellung von Anweisungen 'von Hand'. Benoetigt ein Befehl weitere Parameter, so bilden diese den Nachrichtentext. Ist ein Befehl unbekannt, so sendet das System den Hilfstext mit dem Betreff 'Your Help' an die Anfragende zurueck. Dieser Hilfetext sollte eine Liste saemtlicher Befehle und Anweisungen zur Extraktion weiterer Hilfen enthalten. Alle Befehle sind immer case insensitiv, so dass gilt 'Help' = 'help' = 'hELP' = : : : Die Antworten des Programms sollten den Betreff: 'Your ' erhalten und zur genaueren Referenzierung des Befehls mit dem BEZ-Header ausgestattet werden. A.2 Standardbefehle Dieser Abschnitt beschreibt die Befehle, die eine MAPS- Implementation mindestens akzeptieren muss, um sich ZCONNECT-MAPS-konform zu nennen. Dies sind die Befehle 68__________________________Anhang_A:_Empfehlung_fuer_den_'MAPS-Roboter'_ HELP zur Anforderung eines Hilfetextes, der Befehl LIST zur Anforderung einer Brettliste sowie die Befehle ADD und DEL zum Eintragen und Austragen von Brettern. A.2.1 HELP Dieser Befehl veranlasst das System einen Hilfstext an die Anfra- gende zu versenden. Der Betreff der Antwort ist 'Your HELP'. Im versendeten Hilfetext sollten alle verfuegbaren Befehle aufgeli- stet sein. Es sollte ausserdem beschrieben werden, wie u.U. weitere Hilfedateien angefordert werden koennen. A.2.2 LIST Dieser Befehl veranlasst das System eine komplette Liste der ver- fuegbaren Bretter an den Anfrager zurueckzusenden. Als Antwort wird eine Liste im oxen (!) Format uebergeben. Der Betreff der Antwort lautet 'Your LIST'. Die Laenge einer Zeile ist nicht begrenzt! Das Format deoniert sich wie folgt: Pos. 1 Steuerzeichen Pos. 2 Leerzeichen, Ascii 32. Pos. 3ff Brettname. Nach dem Brettnamen kann, vom Namen durch Leerzeichen abgetrennt, optional noch eine Brettbe- schreibung folgen. Folgende Steuerzeichen sind deoniert: `+' Brett ist derzeit bestellt. ` ' Brett ist derzeit nicht bestellt, aber bestellbar. `-' Brett ist nicht bestellbar. `!' Brett ist bestellt, kann aber nicht abbe- stellt werden (Zwangsanschluss). `;' Zeile enthaelt einen Kommentar. Unbekannte Steuerzeichen sollten wie eine Kommentarzeile behandelt werden. Der Brettname beginnt grundsaetzlich mit einem Slash `/'. Unterbretter sind ebenfalls mit einem Slash gekennzeichnet. Er wird komplett in Grossschreibung geliefert. Fuer die Beschreibung wird keine maximale Laenge festgelegt. Der fuer die Beschreibung gewaehlte Zeichensatz kann im Header CHARSET angegeben werden. A.3:_Erweiterte_Befehle_________________________________________________69 A.2.3 ADD Dieser Befehl veranlasst das System die angeforderten Bretter ein- zutragen, soweit zulaessig. Der Nachrichtentext enthaelt zeilenweise, beginnend am Zeilen- anfang die Brettnamen ohne Beschreibung. Die Namen werden case insensetiv behandelt. Ist das erste Zeichen einer Zeile kein Slash (`/'), so ist die Zeile nicht zu beruecksichtigen. Die Antwort enthaelt ein Protokoll, wobei das Format der Ant- wort von dem Befehl LIST entspricht. Protokolliert werden jedoch nur die angeforderten Bretter. Der Betreff der Antwort lautet 'Your ADD'. A.2.4 DEL Dieser Befehl veranlasst das System die angegebenen Bretter aus- zutragen, soweit zulaessig. Der Nachrichtentext enthaelt zeilenweise, beginnend am Zeilen- anfang die Brettnamen ohne Beschreibung. Die Namen werden case insensetiv behandelt. Ist das erste Zeichen einer Zeile kein Slash (`/'), so ist die Zeile nicht zu beruecksichtigen. Die Antwort enthaelt ein Protokoll, wobei das Format der Ant- wort von dem Befehl LIST entspricht. Protokolliert werden jedoch nur die angegebenen Bretter. Der Betreff der Antwort lautet 'Your DEL'. A.3 Erweiterte Befehle Dieser Abschnitt beschreibt erweiterte Befehle, die die Arbeit eines Point-Programmes vereinfachen. Werden diese Befehle alle unterstuetzt, so kann sich eine MAPS-Implementation ZCONNECT-MAPS-kompatibel nennen. A.3.1 HOLD Dieser Befehl ist die sogenannte Urlaubsfunktion. HOLD ON ver- anlasst das System an die Anfragende solange keine oeffentlichen Nachrichten mehr zu schicken, bis diese den Befehl HOLD OFF gesendet hat. Diese Funktion eignet sich auch bei Systemen, die eine gewisse Zeit nicht mehr angerufen haben (Plattencrash, vor- uebergehend oOine). 70__________________________Anhang_A:_Empfehlung_fuer_den_'MAPS-Roboter'_ Die Antwort hat den Betreff 'Your HOLD ON' bzw. 'Your HOLD OFF'. Sie enthaelt keinen Nachrichtentext. A.3.2 INDEX Dieser Befehl veranlasst das System, Daten ueber die in bestimmten Brettern vorhandenen Nachrichten zurueckzugeben. Diese Funktion sollte auch fuer system-fremde Anwenderinnen verfuegbar sein (Archiv-Systeme). Der Nachrichtentext enthaelt zeilenweise, beginnend am Zei- lenanfang die Brettnamen ohne Beschreibung. Die Namen wer- den unabhaengig von Gross/Kleinschreibung behandelt. Zeilen die nicht mit einem Brettnamen beginnen (/ in der ersten Textposi- tion) werden wie Kommentarzeilen behandelt. Ist das erste Zeichen einer Zeile kein Slash (`/'), so ist die Zeile nicht zu beruecksichtigen. Der Betreff der Antwort lautet 'Your INDEX'. Sie enthaelt die ZConnect-Header der entsprechenden Nachrichten, wobei gilt o Eine Leerzeile deoniert das Ende eines Headers o LEN enthaelt die tatsaechliche Groesse der Nachricht o Es wird nur derjenige EMP mitgeliefert, der aufgrund der Anfrage relevant ist. Alle anderen werden entfernt. o Alle mit F-, G-, U-, X-, Z- und ZNETZ- beginnenden Header sowie der ROT-Header, der GATE-Header sowie der MAILER- Header koennen, muessen aber nicht durch die Implementation geloescht werden. A.3.3 ORDER Mit diesem Befehl koennen gezielt Nachrichten bestellt werden, soweit vorhanden. Diese Funktion sollte auch fuer system-fremde Anwenderinnen verfuegbar sein (Archiv-Systeme). Die Parameter im Nachrichtentext haben folgendes Format: CrLf Beispiel: ________________________________________________________________________ /Z-NETZ/!WICHTIG fgsweeddssd.24@ldb.han.de /T-NETZ/ZCONNECT/DISKUSSION 12345@bionic.zer.de ________________________________________________________________________ A.4:_Anmerkungen_____________________________________________________71_ Der Brettname ist case-insensetiv und muss mit dem Slash (`/') beginnen. Die Message-Id ist bis zum '@' case-sensitiv, dahinter case-insensitiv. Die Antwortnachricht enthaelt als Betreff 'Your ORDER' und enthaelt einen ZConnect-Puffer, in dem diejenigen Nachrichten ent- halten sind, die bestellt wurden und geliefert werden konnten. Ein Protokoll (z.B. mit Kostenabrechnung etc.) kann dieser Nachricht als Kommentar (Header KOM) vorangestellt werden. Es koennen abhaengig von Route-Limits mehrere Nachrichten erstellt werden. Dabei darf aber nicht eine Nachricht in mehrere Teilnachrichten aufgeteilt werden. A.4 Anmerkungen Im Gegensatz zu der in den Wahlen verabschiedeten Version wird hier keine Implementation der Befehle ORDER-PM und FILES gefor- dert. Die Gruende dafuer sind: ORDER-PM unterscheidet sich nur durch verstuemmelte Header von ORDER, FILES dient zur Imple- mentation eines Fileservers. Der Fileserver kann aber wesent- lich eOEzienter durch den in Kapitel II beschriebenen ZCONNECT- Filerequest implementiert werden. 72__________________________Anhang_A:_Empfehlung_fuer_den_'MAPS-Roboter'_ ________________________________________________________________________ Index ________________________________________________________________________ ABS, 45 FILEREQ, 27 ANTWORT-AN, 45 FILESEND, 28 ARC, 15 FORMAT, 27 ARCERIN, 16 ARCEROUT, 16 GET, 25 Austausch Daten, 3 Headerverwaltung, 3 BET, 45 Implementation, 3 BEZ, 45 ISO2, 17 BYTES, 29 ISO3, 17 CHARSET, 46 KOM, 51 CR, 3 KOORDINATEN, 18 CRC-Routine, 3 KOP, 51 CRYPT, 16, 46 CRYPT-CONTENT-KOM, 46 LANGUAGE, 52 CRYPT-CONTENT-TYP, 46 LDA, 52 LEN, 52 Dateitransport, 3 LF, 3 Datenaustausch, 3 Login, 3 Angerufene MailBox, 6 Loginphase Anruferin, 4 Angerufene MailBox, 6 DDA, 47 Anruferin, 4 DELETE, 26 LOGOFF, 22, 30 DISKUSSION-IN, 47 Logoff, 3 DOMAIN, 17 Anruferin, 4 EB, 47 MAILER, 18, 52 EDA, 48 MAILFORMAT, 19 EMP, 48 MAPS, 19 ERR, 49 MID, 53 ERSETZT, 50 EXECUTE, 29 Nacharbeit Angerufene MailBox, 7 FILE, 51 Nacharbeiten FILE-CRC, 30 Anruferin, 6 74________________________________________________________________Index_ O-EDA, 53 Vorbereitungsphase O-ROT, 53 Anruferin, 3 OAB, 54 OEM, 54 WAB, 61 ORG, 54 WAIT, 29 Warenzeichen, i PASSWD, 19 PGP, 54 ZUSAMMENFASSUNG, 61 PGP-ID, 55 PGP-KEY-AVAIL, 55 PGP-KEY-COMPROMISE, 56 PGP-KEY-OWN, 56 PGP-KEYREQ, 28 PGP-PUBLIC-KEY, 65_ PGP-PUBLIC-KEY, 55 PGP-SIG, 56 PORT, 20 POST, 20, 56 PRIO, 56 PROTO, 20 PUT, 26 RETRANSMIT, 30 ROT, 56 SERNR, 21 SIGNED, 57 SPERRFRIST, 57 STAT, 57 STICHWORT, 58 SYS, 21 SYSOP, 21 Systeminformation, 3 Angerufene MailBox, 6 Anruferin, 4 TEL, 21 TELEFON, 22, 58 TRACE, 59 TYP, 59 VER, 60 VIA, 60