-Vorl„ufer-Draft-Vorl„ufer-Draft-Vorl„ufer-Draft-Vorl„ufer-Draft- Die komplette Dokumentation zu ZConnect 3.1 dem offenen Datenformat fr Mailboxnetze á-VERSION basierend auf ZConnect 3.0 (Zerberus GmbH) und den Beschlssen des ZConnect-Gremiums bis zum 1.10.1995 Diese Dokumentation darf frei aber nur komplett kopiert und weitergegeben werden. Žnderungen an ZConnect beschlieát das ZConnect-Gremium, Žnderungen an dieser Dokumentation nimmt ausschlieálich die Dokumentationskoordination vor. Vorschl„ge fr Žnderungen/Erg„nzungen o.„. bitte an DOKUKOO@bingo.comlink.de senden. -Vorl„ufer-Draft-Vorl„ufer-Draft-Vorl„ufer-Draft-Vorl„ufer-Draft- >>> 15.10.1995 <<< Anmerkungen zu diesem Vorl„ufer der endgltigen Version bitte in /T-NETZ/ZCONNECT/DISKUSSION posten. DOKUKOO ist derzeit noch nicht erreichbar, private Kommentare bitte an Sepro@bingo.comlink.de Abschnitte, die mit "#" in der ersten Spalte gekennzeichnet sind, bedrfen vor einer endgltigen Formulierung der Diskussion im Gremium. Abschnitte, die nicht so gekennzeichnet sind, werden m”glicherweise ebenfalls noch ge„ndert werden. Mit einiger Sicherheit enth„lt die folgende Dokumentation noch Fehler. Auáerdem sind komplette Kapitel "zur Diskussion" enthalten, so daá dieser Text _in dieser Form_ den Status von Sekund„rliteratur hat. -Vorl„ufer-Draft-Vorl„ufer-Draft-Vorl„ufer-Draft-Vorl„ufer-Draft- - ZConnect 3.1 --------------------------------------------------------------- *INHALTSVERZEICHNIS* 1. Hinweise zur Notation........................................... 4 2. Historie........................................................ 4 2.1. Vom Hausstandard der Zerberus GmbH zu einem freien Protokoll.. 4 2.2. Kurzhistorie des /Z-Netzes.................................... 4 2.3. Das ZConnect-Gremium.......................................... 5 2.4. Die ZConnect-Dokumentation.................................... 5 2.5. Rechte am Protokoll........................................... 6 3. Dokumentation................................................... 7 3.1. Onlinephase................................................... 7 3.2. šbertragene Dateien........................................... 8 3.3. Datenformat................................................... 9 3.3.1. Die Teile einer Nachricht................................... 9 3.3.1.1. Headerinformationen....................................... 9 3.3.1.1.1. Aufbau und Zeichensatz von Headerinformationen.......... 9 3.3.1.1.2. Adressenformat.......................................... 10 3.3.1.1.2.1. Zeichens„tze bei der Adresse.......................... 11 3.3.1.1.2.2. Private Nachrichten................................... 11 3.3.1.1.3. Brettnamenformat........................................ 11 3.3.1.1.3.1. ™ffentliche Nachrichten............................... 11 3.3.1.1.4. Datumsangaben........................................... 12 3.3.1.2. Form des Bodys............................................ 12 3.3.2. ZConnect-Headerinformationen................................ 13 3.3.2.1. Fest definierte Headerzeilen.............................. 13 3.3.2.2. Frei definierbare Headerzeilen............................151 3.3.2.3. Headerzeilen aus anderen Datenformaten....................151 3.3.2.3.1. UUCP....................................................151 3.3.2.3.2. Fido....................................................151 3.3.2.3.3. Z3.8....................................................151 3.3.2.4. Headerzeilenvorhersage....................................152 3.4. Zusammenh„nge.................................................152 3.4.1. Informationelle Selbstbestimmung und Datenschutz............152 3.4.1.1. Zeitangaben...............................................152 3.4.1.1.1. EDA.....................................................152 3.4.1.1.2. VIA.....................................................153 3.4.1.2. KOP.......................................................153 3.4.1.3. Wechsel von privaten Nachrichten ber Netzgrenzen hinweg..153 3.4.2. Dupe- und Rekursionscheck...................................154 3.4.2.1. Dupecheck anhand der Message-IDs..........................154 3.4.2.2. Rekursionscheck anhand des Routepfads (ROT)...............154 3.4.3. Weiterleiten................................................155 3.4.3.1. Manuelles Weiterleiten....................................155 3.4.3.1.1. Passives Weiterleiten...................................156 3.4.3.1.2. Aktives Weiterleiten....................................156 3.4.3.2. Automatisches Weiterleiten................................157 3.4.3.3. Weiterleiten im Netz: Umleiten............................158 3.4.4. Gemischtadressierung........................................159 3.4.5. Verschlsselung.............................................160 3.4.5.1. PGP.......................................................160 3.4.5.1.1. Grunds„tzliches.........................................160 3.4.5.1.2. Transport der Schlsselinformation......................161 3.4.5.1.3. Unterschriften..........................................162 3.4.5.2. QPC:......................................................163 3.4.6. Points......................................................163 - ZConnect 3.1 --------------------------------------------------------------- 3.5. Maps-Standard.................................................166 3.5.1. Die Maps-Befehle............................................166 3.5.1.1. Pflichtbefehle............................................167 3.5.1.2. Listenformat..............................................169 3.5.1.3. Optionale Befehle.........................................170 3.5.2. Kritik und Vorschl„ge.......................................175 3.5.2.1. Maps und die vergessene Onlinephase.......................175 3.5.2.2. Maps aus Sicht des angeschriebenen Systems................175 3.5.2.3. Schwierigkeiten bei der Umsetzung des Gedankens, Maps transparent zu gestalten..................................176 4. Erg„nzende Informationen........................................178 4.1. Datenschutzbestimmungen.......................................178 4.2. Fremdformate..................................................178 4.2.1. RFC.........................................................178 4.2.2. Z 3.8.......................................................178 4.2.3. Fido........................................................178 4.3. MIME..........................................................179 4.4. Einige softwaretechnische Vorschl„ge..........................179 4.4.1. Hashverfahren fr Rekursionscheck...........................179 5. Stand der Dinge.................................................180 Anh„nge............................................................181 A) Literaturverzeichnis............................................181 B) Glossar.........................................................183 C) ZC 3.1 Grammatik in BNF.........................................185 D) Datenformatsbersicht...........................................186 D) 1. Tabellarische šbersicht der Headerinformationen..............186 D) 2. Liste der Pflichtinformationen...............................188 D) 3. Liste der das Routing beeinflussenden Informationen..........189 E) Routing.........................................................190 F) Janus und verwandte Protokollvarianten..........................191 G) Zeichens„tze....................................................194 H) Zeitzonen.......................................................195 I) Liste der ZConnect-Programme....................................198 Fuánoten...........................................................199 - ZConnect 3.1 ----------------------------------------------------------- 4 - *1. HINWEISE ZUR NOTATION* Alle Zahlenangaben sind in dezimaler Schreibweise angegeben, sofern nicht ausdrcklich anderes ausgesagt wird. Ein Byte besteht aus acht Bits und deckt den Zahlenraum 0..255 ab. Literaturhinweise sind im flieáenden Text durch eckige Klammerung gekennzeichnet. Die Klammerinhalte sind der einfacheren Auffindbarkeit halber nicht schlicht durchnumeriert, sondern mit Krzeln versehen. "PM" verweist hierbei auf eine pers”nliche Mitteilung, "D" auf einen Teil der zugrundegelegten Ursprungsdokumentation und "B" auf eine Brettnachricht. Daneben sind einige wichtige Dokumente direkt mit ihrem Namen gekennzeichnet (z.B. [Netikette]). Die wichtigsten, im Zusammenhang mit ZConnect am h„ufigsten verwendeten Fachbegriffe werden im Anhang B in Form eines Glossars erl„utert. *2. HISTORIE* Zum Verst„ndnis vom ZConnect ist dessen Entstehungsgeschichte ein wichtiger Aspekt. Dieses Kapitel zeichnet die Entwicklung des Protokollumfelds bis zum heutigen Stand in Grundzgen nach. _2.1. Vom Hausstandard der Zerberus GmbH zu einem freien Protokoll_ Das ZConnect-Protokoll wurde nach Aussage von Mitarbeitern der Zerberus GmbH im wesentlichen von Martin Husemann entworfen ([PM1]). Es wurde als Nachfolger des Z3.8-Netcallformats konzipiert, welches im Anhang G beschrieben ist und teilweise, allerdings ausschlieálich im Rahmen der Janus-Protokollvarianten, noch immer Bedeutung hat. Die Zerberus GmbH implementierte ZConnect zun„chst fr ihr Hauptprodukt "Zerberus", ein Mailboxprogramm. Am 3. August 1993 ver”ffentlichte die Firma dann ZConnect 3.0 als gedruckte Dokumentation ([D3.0]), schon im Dezember 1992 wurde aber in /T-NETZ/SUPPORT/ZCONNECT von einer vorliegenden ZConnect-Dokumentation gesprochen ([B1]). _2.2. Kurzhistorie des /Z-Netzes_ Als privates Vernetzungsprojekt entstanden, verband das /Z-Netz in seinen Entstehungsjahren brgerrechtsbewegte Menschen miteinander. Dabei wurde in den ersten Jahren mit dem Z3.8-Netcallformat zwischen Systemen ausgetauscht, die sich als "/Z-Netz-System" betrachteten, sich also bestimmten Regeln unterwarfen, wie z.B. der noch heute bestehenden Verpflichtung, die Bretter des Netzes immer komplett anzubieten und weiterzureichen. Das /Z-Netz versteht sich heute noch als mehr als die gleichnamige Bretthierarchie; mittlerweile sind UserInnenwahlen eingefhrt worden, es gibt KoordinatorInnen (allgemein und technisch) und Benimmregeln, die in der [Netikette] formuliert sind. Nachdem Anfang 1994 das technische Verfahren der Datennavigation im /Z-Netz auf das im Internet bliche Domainrouting (s. Kapitel "Adressen") umgestellt und damit das vorher verwendete, manuell - ZConnect 3.1 ----------------------------------------------------------- 5 - erstellte und anhand von festen Pl„nen durchgefhrte Verfahren ersetzt wurde, stellt sich das Netz logisch als Teil des Internetadreáraums dar. Heute versteht sich das /Z-Netz als unabh„ngig von der eingesetzten Technik ([Netikette]), noch immer wird auf /Z-Netz-Systemen aber - vermutlich mehrheitlich - das Nachfolgeprotokoll der alten Z3.8-Technik, n„mlich ZConnect, eingesetzt. _2.3. Das ZConnect-Gremium_ Auf Vorschlag von Martin Husemann entstand Ende 1993 das anf„nglich aus zehn Personen bestehende ZConnect-Gremium ([B2]). Auf der Grundlage der Dokumentation der Protokollversion 3.0 begann dann dessen Arbeit. Das Gremium bestand und besteht aus Menschen, die an der Pflege ZConnects mitarbeiten und erweitert sich durch ein Wahlverfahren. Etwa zeitgleich wurde die Arbeit an ZConnect von /T-NETZ/SUPPORT/ZCONNECT nach /T-NETZ/ZCONNECT/* verlagert. In /T-NETZ/ZCONNECT/MELDUNGEN sind alle Wahlaufrufe und -ergebnisse, die aktuelle Liste der Gremiumsmitglieder ([Mitglieder]) und auch Listen von ZConnect-f„higen Programmen zu finden. Aktuelle Diskussionen sind in /T-NETZ/ZCONNECT/DISKUSSION mitzuverfolgen. Seit Existenz des Gremiums sind unter Leitung von Hinrich Donner (hd@wf-hh.shnet.org) fnf Wahlen zu ZConnect 3.1 durchgefhrt worden ([Wahl1]-[Wahl5]). Die Wahlen finden per geheimer Stimmabgabe an den/die Wahlleiter/in statt. Mit der fnften Wahl sollte die Version 3.1 geschlossen und mit der zur CeBIT'95 durch die Zerberus GmbH vorgestellte Print-Dokumentation ([D3.1Z]) abschlieáend dokumentiert werden. Jedoch geriet diese Dokumentation in die Diskussion, da sie sich nicht an alle Ergebnisse der erfolgten Wahlen (siehe Hinweise im folgenden bei den einzelnen Headerinformationen) h„lt und somit ---- nicht ZConnect-kompatibel ist. Die vom Gremium beschlossenen Žnderungen und Erweiterungen sind ohne šbergangsfristen verbindlich fr die AnwendungsprogrammiererInnen{1}. Frhestens nach sechs Monaten ist eine erneute Abstimmung ber eine abgestimmte Žnderungen zul„ssig ([Wahl1]). _2.4. Die ZConnect-Dokumentation_ Die ZConnect-Dokumentation ist ein verstreutes und manchmal auch etwas zerstreutes Gebilde. Sie bestand bis zum Erscheinen dieses Textes aus der jeweils letzten Dokumentation der Zerberus GmbH und den von diesem Zeitpunkt an beschlossenen Žnderungen durch das Gremium. In /T-NETZ/ZCONNECT/MELDUNGEN{2} waren und sind beschlossene Protokollbestandteile nachzulesen. Bisher muáte einE potentiellEr ProgrammiererIn die komplette Entwicklung mitverfolgen, [D3.0] zugrunde legen und die vereinzelt beschlossenen Žnderungen oder Erweiterungen darauf anwenden, wobei Žnderungen auch durchaus vorausgegangene Žnderungen betreffen. Diese arbeitsaufwendige Dokumentationsbeschaffung wurde etwas vereinfacht durch zwei Zusammenstellungen von verschiedenen Žnderungsst„nden. - ZConnect 3.1 ----------------------------------------------------------- 6 - Zum einen ist dies das ZConnect-3.1-Proposal von Martin Husemann, wie es in das Brett /T-NETZ/ZCONNECT/DISKUSSION verschickt wurde. Zum anderen existiert eine Zusammenstellung vom Wahlleiter der Gremiumswahlen, mit der Bezeichnung "Žnderungen ZConnect 3.1 M„rz bis Dezember '93". Der Status des Proposals ist dabei nie endgltig gekl„rt gewesen. Anhand eines vollst„ndigen Archivs aller Nachrichten in den einschl„gigen Brettern seit deren Bestehen ist es nachtr„glich als sachlich richtige Zusammenfassung zu best„tigen. Daher fand das Proposal als [D3.1P] Eingang in diese Dokumentation, die Zusammenfassung der Žnderungen als [D3.1M]. Die Beschreibung der Onlinephase hingegen liegt aktuell und zusammenh„ngend nur in der zur CeBIT'95 ver”ffentlichten Dokumentation "ZConnect 3.1" von der Zerberus GmbH ([D3.1Z]) vor. Diese Phase wurde seit Bestehen des Gremiums von diesem nicht nennenswert bearbeitet oder diskutiert (lediglich im Rahmen der PGP-Einbindung wurde eine neue Headerinformation fr die Onlinephase eingefhrt). Beim Datenformat steht der Begriff "die Dokumentation" im folgenden fr die Gesamtheit aus [D3.0], [D3.1P] und [D3.1M]. Auch [D3.1Z] beschreibt das ZConnect-Datenformat, weicht jedoch hierbei in einigen Punkten von den Gremiumsbeschlssen ab. Daher ist es in die Kapitel zum Datenformat nur in Zweifelsf„llen oder als Hinweisgeber fr sinnvolle Žnderungsvorschl„ge eingegangen. Die Bezugnahme auf frhere Dokumente dient vor allem dem Konsitenznachweis dieses Textes. Nach Beschluá durch das ZConnect-Gremium ersetzt dieser Text alle frher ver”ffentlichten Dokumentationsbestandteile zum Datenformat "ZConnect". _2.5. Rechte am Protokoll_ Mit der Ver”ffentlichung der Dokumentation zu ZConnect 3.0 ist das Protokoll fr die lizenzfreie Verwendung - auch in kommerziellen Anwendungen - freigegeben. Dies gilt auch fr die seitdem erfolgten Žnderungen. [D3.0] und [D3.1Z] verlangen aber, daá neben den Copyrightvermerken in Dokumentation und im ZConnect implementierendem Programm, ein Copyrightvermerk der Zerberus GmbH angegeben werden muá. Dies war schon bei ZConnect 3.0 strittig, bei 3.1 ist es das erst recht, da die Žnderungen in der Verantwortung des Gremiums und nicht in jener der Zerberus GmbH liegen. Hintergrund des Bestehens auf das Copyright ist, daá das Protokoll "ZConnect" fest definiert sein, also nicht von Produkten verwendet werden soll, die nicht den vollen Umfang der Spezifikation erfllen. In der Praxis erfllt jedoch keine Software den vollen Umfang der Spezifikation. - ZConnect 3.1 ----------------------------------------------------------- 7 - *3. DOKUMENTATION* _3.1. Onlinephase_ Der Datenaustausch zwischen zwei Systemen erfolgt bei ZConnect nach einem Store-And-Forward-Verfahren. Diese Tauschphase wird bei ZConnect Onlinephase genannt und folgt folgendem groben Schema: Verbindung aufbauen | v Systemdaten austauschen (Handshake) | v Daten austauschen (Transfer)<--. | | | v `---' Verbindung beenden (Logoff) Dieser fr W„hlleitungen entworfene Aufbau weist zwei Besonderheiten auf. Zum einen einigen sich die Systeme in der Handshakephase selbstt„tig auf zu verwendende šbertragungsprotokolle (z.B. XModem, ZModem), Packprogramme (z.B. ZIP, LHA) und mehr. Zum anderen kann die Transferphase mehrmals hintereinander ausgefhrt werden, so daá z.B. in einem Local Area Network in der Zwischenzeit neu bereitgestellte Daten noch w„hrend der bestehenden Verbindung bertragen werden k”nnen. Der Gedanke an W„hlleitungen und die bliche Tarifierung, bei der die Anruferin fr die Verbindung bezahlt, bedingen beim ZConnect-Design, daá die Anruferin ber den Ablauf des Austausches bestimmt. So kann sie jederzeit die von der Angerufenen angebotenen Daten ablehnen oder nur Teile davon abfordern. Umgesetzt wird dies durch ein umfangreiches Verfahren von Anfrage-Antwort-Ablehnung/Best„tigung-Ausfhrung. Hierbei gilt immer, daá bereits - auch teilweise - korrekt bertragene Daten m”glichst nicht noch einmal bertragen werden sollen. Als weiteres Ziel gibt [D3.1Z] vor, daá das Protokoll auch bei nicht vollst„ndig datentransparenten Verbindungen funktionieren muá. Auáerdem soll die Protokollspezifikation ohne gr”áeren Aufwand erweiterbar sein. Die Verbreitung der ZConnect-Onlinephase beschr„nkt sich auf die Orte im Netz, an denen das Zerberus Mailboxprogramm oder UNIX/Connect eingesetzt wird. Pointprogramme, die die Onlinephase untersttzen, gibt es derzeit nicht. Es wird berwiegend Janus und zunehmend dessen Derivat JanusPlus eingesetzt. Diese Protokolle sind im Anhang beschrieben. Die ZConnect-Onlinephase wird im Rahmen dieses Textes nicht n„her beschrieben. Sicher bedarf die Dokumentation der Onlinephase als solche dringend der neuen Ausarbeitung, insbesondere unter Erg„nzung von Ablaufdiagrammen und eindeutigen Zuordnungen der m”glichen Informationen zu den einzelnen Phasen der Kommunikation. Jedoch wurde im Hinblick auf den notwendigen Zeitaufwand fr diese Dokumentation der Schwerpunkt auf das weit verbreitete Datenformat gelegt. Sollte die ZConnect-Onlinephase den Status eines offenen Protokolls erlangen, - ZConnect 3.1 ----------------------------------------------------------- 8 - ist ber eine dokumentationstechnische Wiedervereinigung mit dem hier behandelten Datenformat neu zu entscheiden. _3.2. šbertragene Dateien_ In ZConnect ist fesgelegt, wie die Dateien heiáen mssen, die w„hrend der Onlinephase (auch der Onlinephase von JANUS, vgl. Anhang F) bertragen werden. Der Typ der Dateien wird von der DOS-blichen Extension, also den drei Zeichen nach dem einzigen Punkt im Dateinamen, abh„ngig gemacht. Sowohl Dateinamen selbst als auch Extensions sind ohne Bercksichtigung der Groá-/Kleinschreibung zu bearbeiten. Grunds„tzlich sollte beim Erzeugen nur Kleinschreibung verwendet werden. Definierte Extensions sind: .brt die so gekennzeichnete Pufferdatei enth„lt ausschlieálich ”ffentliche Nachrichten .eil Datei enth„lt ausschlieálich pers”nliche Nachrichten mit PRIO: 20 Headerinformation .kom Datei enth„lt private und ”ffentliche Nachrichten .prv Datei enth„lt ausschlieálich private Nachrichten Unbekannte Extensions mssen behandelt werden, als w„re die .kom-Extension angegeben. Keine Pufferdatei darf wegen eines Fehlers beim Namen von der Bearbeitung ausgenommen werden. Folgende Extensions sind laut [B9] definiert, die Verbindlichkeit ist jedoch noch nicht abschlieáend gekl„rt: .err Datei enth„lt ausschlieálich Nachrichten mit ERR- Headerinformation .dir Datei enth„lt ausschlieálich pers”nliche Nachrichten mit PRIO: 10 Headerinformation Da in frheren ZConnect-Implementationen und auch zu Z3.8-Zeiten der Pufferdateiname "puffer." verwendet wurde, ist dieser in [D3.1M] gesondert erw„hnt. Ein so benannter Puffer enth„lt Nachrichten im ZConnect-Datenformat, ber deren Empf„ngerInnen nichts ausgesagt wird (z.B. k”nnen ”ffentliche, private oder beide Adressierungsarten gemischt enthalten sein). Fr die Erzeugung des Dateinamens vor der Extension schl„gt [D3.1P] im Zusammenhang mit der JANUS-Beschreibung vor, UNIXTIME (Zeit in Sekunden seit 1970) als achtstellige Hexadezimalzahl zu verwenden. In [JanusPlus] wird fr JanusPlus eine besondere Namensgebung vorgeschrieben. - ZConnect 3.1 ----------------------------------------------------------- 9 - _3.3. Datenformat_ _3.3.1. Die Teile einer Nachricht_ Eine ZConnect-Nachricht wird eingeleitet durch den Header, welcher diverse Headerinformationen (s.u.) enth„lt. Beendet wird der Header durch eine einzelne CR/LF-Kombination (Leerzeile). Hierauf folgt der Nachrichtenk”rper, bezeichnet auch als Inhalt oder Body: +--------------------------------------------------+ | Nachrichtenheader | | +-----------------------------------------------+ | | Headerinformation (abgeschlossen durch CR/LF) | | +-----------------------------------------------+ | | ... | | +-----------------------------------------------+ | | Headerinformation (abgeschlossen durch CR/LF) | +--+-----------------------------------------------+ | Leerzeile (CR/LF) | +--------------------------------------------------+ | Nachrichtenk”rper | | +-----------------------------------------------+ | | Optional vorangestellter Kommentar | | +-----------------------------------------------+ | | | | | Text/Daten | | | | +--+-----------------------------------------------+ Im allgemeinen Sprachgebrauch wird fr eine einzelne Headerinformation fast immer der eigentlich besetzte Begriff "Header" verwendet. Um Verwirrungen zu vermeiden, ist dies in dieser Dokumentation nicht erfolgt. Da auch der Begriff "Inhalt" in einem anderen Kontext (beim Header) verwandt wird, wird die Bezeichnung "Nachrichtenk”rper" verwendet. Wird nicht ausdrcklich anderes erw„hnt, so gilt, daá der Text-/Datenanteil des Nachrichtenk”rpers nicht eingesehen, ver„ndert oder ausgewertet werden darf. Der Transport von Steuerinformationen im Nachrichtenk”rper (wie in anderen Netzen zur Umgehung von Schw„chen der Protokolldefinition durchaus blich) ist verboten. Aber auch fr das Vorlegen fehlerhafter Nachrichten bei der Systemadministration ergibt sich bereits aus dieser Vorschrift, daá der Nachrichtenk”rper bei privaten Nachrichten (s.u.) nicht mit vorgelegt werden darf. Beim Header sind Einsicht, Auswertung und Žnderungen dem Wesen nach vorgesehen. Einige Headerinformationen mssen von der behandelnden Software sogar ver„ndert (z.B. erg„nzt) werden, alle sind auszuwerten und i.d.R. drfen sie auch von der Systemadministration eingesehen werden. _3.3.1.1. Headerinformationen_ _3.3.1.1.1. Aufbau und Zeichensatz von Headerinformationen_ Die Headerinformationen in einem Header werden durch den in der DOS-Welt blichen Zeilenvorschub CR/LF (ASCII 13/10) voneinander abgetrennt. - ZConnect 3.1 ---------------------------------------------------------- 10 - Eine Headerinformation besteht aus der einleitenden, maximal 100 Zeichen langen Headerkennung; hierfr sind die Zeichen A bis Z, die Ziffern 0 bis 9 und der Bindestrich "-" erlaubt. Bei der Auswertung ist (auch gemischte) Groá-/Kleinschreibung zu ignorieren. Auf die Kennung folgt ohne Abstand ein Doppelpunkt. Es schlieáen sich beliebig viele (m”glicherweise auch null) Whitespaces, also entweder TAB (ASCII 9) oder Leerzeichen (ASCII 32), an. Danach folgt der Informationsinhalt, der beliebig viele Zeichen enthalten kann (also auch gar keine). Der gltige Zeichensatz hierfr besteht aus den ASCII-Codes 32-255. In [D3.0] ist w”rtlich formuliert: "Bei Informationsinhalten mit Text-Charakter (z.B. Betreff-Zeile) gelten die gleichen Zeichensatzeinschr„nkungen wie fr den Inhalt von Standard-Textnachrichten." Es wurde des ”fteren die Gltigkeit der CHARSET-Headerinformation fr die Informationsinhalte diskutiert und verneint. Bei Informationsinhalten mit Textcharakter drfen somit nur die Zeichen 9 (TAB), 10 (LF), 13 (CR) und 32-254 (255 wird als Leerzeichen gewandelt) gem„á ZConnect-Zeichensatz verwendet werden. _3.3.1.1.2. Adressenformat_ Bei ZConnect werden Adressen der Form @. verwendet{3}. Die Systemzugeh”rigkeit wird allgemein als "Domain" bezeichnet und kann mehrfach durch Punkte aufgeteilt sein. Dazu geh”rt optional ein realer, brgerlicher Name. Ist ein solcher "Realname" angegeben, so ist er durch genau ein Leerzeichen abzutrennen und in runden Klammern zu schreiben: @. () Groá- und Kleinschreibung finden keine Bercksichtigung. Gltige Beispiele w„ren also: R.Juhser@BINGO.comlink.de (Rainer Juhser) x99@bingo.ComLink.DE (Ix Neun Neun) ai@ai.bingo.comlink.de Der Teil hinter dem "@" (gelesen: at - "„tt") bezeichnet in seiner Gesamtheit weltweit eindeutig das System, zu welchem die Nachricht zugestellt werden soll. Die Auswertung erfolgt abh„ngig vom "Wissen" des routenden Systems (siehe Anhang E "Routing"). Daher sind auch Adresse ohne jedes "@" gltige Adressen, allerdings sind sie ausschlieálich auf dem absendenden System selber zustellbar (dessen Name nebst Domain werden implizit als angegeben vorausgesetzt). Wenn also z.B. eine Mail an Testi vom System BINGO.comlink.de aus geschickt wird, so ist Testi@BINGO.comlink.de damit gemeint. Wird eine Nachricht mit einem Bestimmungsort (also einer Empf„ngerinnenadresse) ohne Domain angeliefert, so wird die Pseudo-Systemzugeh”rigkeit (Pseudodomain) "zer" angenommen. Fr diese Domain ist das lokale System als - ZConnect 3.1 ---------------------------------------------------------- 11 - Smartserver{4} zu betrachten - es darf also nur an Systeme zustellen, die lokal bekannt sind. Diese Sonderregelung ist allerdings in Zeiten des Domainroutings anachronistisch. Zeitgem„áer ist hier eine Regelung, Adressen ohne Domain mit der Domain des routenden Systems aufzufllen (was also auf dem ersten System auf dem Routeweg gesch„he). Somit w„re nicht das routende System automatisch Smartserver, sondern der tats„chliche Smartserver wrde die Zustellung, sofern m”glich, bernehmen. Nachrichten drfen nur dann mit einer AbsenderInnenadresse mit der Domain "zer" versehen sein, wenn sie auf einem Z3.8-System abgesandt wurden. Seit [D3.1M] werden Z3.8-Netze jedoch als Fremdnetze betrachtet, daher ist auch diese Regelung nicht mehr im Rahmen ZConnects zu betrachten, sondern im Rahmen allgemeiner Gatewaybestimmungen. _3.3.1.1.2.1. Zeichens„tze bei der Adresse_ Fr das System und die Systemzugeh”rigkeit sind in ASCII-Codierung die Zeichen A bis Z, die Ziffern 0 bis 9 und der Bindestrich "-" zul„ssig. Die Groá-/Kleinschreibung ist dabei irrelevant. Der Lokalteil, also der Adreáanteil vor dem "@", darf die ASCII-Codes 35 bis 124 abzglich der Codes 64, 60, 62, 92, 28, 29, 39, 44, 91, 93, 96 und 123 enthalten. Die Codes 33, 37 und 47 (!%/) sind erlaubt, aber reserviert und drfen daher auch nicht in im Lokalteil enthaltenen UserInnennamen auftauchen. Der in Klammern eingeschlossene Realname darf abzglich eben dieser Klammern die ASCII-Code 32 bis 126 enthalten. _3.3.1.1.2.2. Private Nachrichten_ Eine private Nachricht ist definiert als Nachricht, die ausschlieálich Empf„ngerinnen (siehe EMP-Headerinformation) hat, in denen das Zeichen "@" vorkommt oder weder "@" noch "/" vorkommen. Es ist gerade bei gemischtadressierten Nachrichten leider bisher nicht blich, aber besser, dies zu beachten (vgl. unbedingt Kapitel Gemischtadressierung). _3.3.1.1.3. Brettnamenformat_ Brettnamen enthalten ASCII-codiert die Zeichen A bis Z, die Ziffern 0 bis 9, sowie die Zeichen 33, 43, 45, 47 und 95 (!+-/_); Umlaute und Kleinbuchstaben sind also nicht erlaubt. Der Schr„gstrich "/" trennt Hierarchieebenen eines Brettnamens. Ein Brettname beginnt immer mit einem solchen Schr„gstrich, endet hingegen nie mit einem. Zwischen zwei Schr„gstrichen steht mindestens eines der anderen zul„ssigen Zeichen. _3.3.1.1.3.1. ™ffentliche Nachrichten_ Eine ”ffentliche Nachricht ist definiert als Nachricht, die mindestens eine Empf„ngerin (siehe EMP-Headerinformation) hat, in der nicht das Zeichen "@" aber das Zeichen "/" vorkommt. - ZConnect 3.1 ---------------------------------------------------------- 12 - Es gibt eine Sonderform der Adressierung: /BRETTGRUPPE/BRETT@system.domain Diese Adressierung soll die Zustellung einer Nachricht in ein nur auf einem anderen System verfgbares ”ffentliches Brett erm”glichen, wird aber definitionsgem„á als private Nachricht behandelt und ggf. auch als solche abgerechnet. In der Praxis untersttzt nicht jede eingesetzte Software diese Art der Adressierung; anders ausgedrckt: eine solche Nachricht kommt mit hoher Wahrscheinlichkeit nicht an, wenn sie ber das Netz transportiert werden muá. Insbesondere wenn das empfangende System die ZConnect-Brettnotation nicht kennt (Slashes werden in den wenigsten technischen Netzen eingesetzt), ist nicht mit einer ordnungsgem„áen Zustellung zu rechnen. _3.3.1.1.4. Datumsangaben_ Datumsangaben enthalten bei ZConnect immer auch Zeitangaben und Zeitzone. Das Format ist JJJJMMTThhmmss[S|W][+|- ] wobei der Offset die Abweichung von GMT (Greenwich Meantime) angibt und im Bereich von -12 bis 12 liegt; ist die Abweichung allerdings nicht in ganzen Stunden zu messen, werden Minutenangaben nach einem Doppelpunkt hinzugefgt. Beispiele: 19950419000000 19990520111111S+1 19800101010101W-7:30 19851211020304+0 19840911232359S-12 In der Bundesrepublik Deutschland gilt die MET (Middle European Time) bzw. im Sommer die MEST (Sommerzeit). Die Abweichungen zu GMT lauten "W+1" (MET) bzw. "S+2" (MEST). Der Bezug auf GMT sorgt dafr, daá die ersten 14 Stellen der Datumsangabe kontinuierlich weiterlaufen; z.B. die Sommerzeit wird durch die "S+2"-Angabe angegeben, ohne daá die JJJJMMTThhmmss-Angabe springen wrde. Im Anhang H sind die relevanten Zeitzonen aufgelistet, wie sie in [D3.0] enthalten sind. Die Wechseltermine zu Winter- bzw. Sommerzeit sind gesetzlich geregelt, so daá ProgrammiererInnen diese Umstellung automatisieren k”nnen. Da ausgerechnet zum Zeitpunkt der Fertigstellung dieses Textes eine Gesetzes„nderung die Termine verschiebt, fehlen die Details an dieser Stelle. Um Erg„nzung qua Mail an DOKUKOO@bingo.comlink.de wird gebeten. _3.3.1.2. Form des Bodys_ Wenn im Header keine TYP-Headerinformation angegeben ist, handelt es sich beim Nachrichtenk”rper um reinen Text. In diesem sind Zeilen durch das bliche Paar ASCII 13/10 (CR/LF, die Reihenfolge ist vorgeschrieben) voneinander getrennt. Das in manchen - ZConnect 3.1 ---------------------------------------------------------- 13 - Programmumgebungen bliche Dateiendezeichen ASCII 26 ("Ctrl-Z") geh”rt zu den in Textnachrichten verbotenen Zeichen. Textnachrichten sind per Definition unmittelbar lesbar und erfordern keine besonderen Anzeigeprogramme. Jedoch muá die anzeigende Software den verwendeten Zeichensatz in einen auf dem lokalen Ger„t anzeigbaren umwandeln. Der Standardzeichensatz ist im Anhang G als ZConnect-Zeichensatz aufgelistet. Als Steuerzeichen sind darberhinaus ausschlieálich ASCII 9 (Tabulator) und 13/10 (Zeilenvorschub) zugelassen. _3.3.2. ZConnect-Headerinformationen_ Dieser Abschnitt befaát sich mit den einzelnen Headerinformationen. Diese unterteilen sich in fest definierte, frei definierbare und auf Fremdformate bezogene. Auáerdem wird ein Ausblick auf zuknftige Erweiterungen gegeben. _3.3.2.1. Fest definierte Headerzeilen_ Das Datenformat ZConnects zeichnet sich durch eine Mischung von Maschinen- und Menschenlesbarkeit aus. An manchen Stellen eingestreute Whitespaces machen es bearbeitender Software nicht unbedingt leichter, machen die Headerzeilen aber fr menschliche Augen lesbar. Die m”glichen Headerkennungen sind einer st„ndigen Entwicklung unterworfen. Aus diesem Grund und weil auch frei definierte Kennungen auftreten k”nnen, drfen Headerzeilen mit unbekannten Kennungen weder gel”scht noch in anderer Weise bearbeitet werden. Sie mssen vielmehr unver„ndert weitergegeben werden. _Verwendete Schreibweisen, Unterteilungen und Symbolisierungen_ Im folgenden sind alle fest definierten Headerinformationen mit allen dazugeh”rigen Informationen aufgelistet. Fr diesen zentralen Teil dieser Dokumentation werden folgende Schreibweisen, Unterteilungen und Symbolisierungen verwendet. Zeilenumbrche bei der Syntax der Kennung sind drucktechnisch bedingt und drfen in einem ZConnect-Header niemals innerhalb einer Header-Information auftauchen. In einfachen spitzen Klammern finden sich syntaktische Einheiten. Die spitzen Klammern geh”ren nicht zur gemeinten Information, sofern nicht explizit anderes ausgesagt wird. In eckigen Klammern sind optionale Parameter angegeben. Findet sich ein hochgestellter Stern neben der syntaktischen Einheit, kann diese gar nicht, einmal oder mehrfach angegeben werden. Die eckigen Klammern und der Stern geh”ren nicht zur Information. Beispiel: ERR [;]* [] Verbal beschrieben bedeutet das: Nach der Kennung ERR muá die Fehlerklasse angegeben werden (im erl„uternden Text wird in diesem Fall angegeben, wie eine Fehlerklasse notiert wird), dann durch Semikolon abgetrennt beliebig viele (das sagt der Stern), also evtl. - ZConnect 3.1 ---------------------------------------------------------- 14 - auch gar keine (das sagen die eckigen Klammern) Fehlernummern. Durch Leerzeichen abgetrennt kann dann genau ein Fehlermeldungsklartext nachgestellt werden, er kann aber auch ganz fehlen (das sagen wiederum die eckigen Klammern). Anstelle des "*" kann auch ein "+" stehen, was soviel bedeutet wie "beliebig oft, aber mindestens einmal". Ein senkrechter Strich "|" meint ein exklusives Oder und geh”rt nicht zur Information; vielmehr ist genau eine der durch solche Striche getrennten Varianten zu verwenden. Die in den rechtsstehenden K„sten mit Pfeilen (>>) versehenen Angaben sagen aus, ob die jeweilige Kennung unbedingt in jedem Header vorhanden sein muá (Pflicht) oder ob er wahlweise eingesetzt werden kann (Optional). +-----------------+ |>>Pflicht | Auáerdem ist angegeben, ob die Headerinformation | Optional | nur einmal oder auch mehrfach pro Header +-----------------+ auftauchen darf. Auch mehrfach bedeutet nicht, |>>Nur einmal | daá eine Information mehrfach vorkommen muá. Darf | Auch mehrfach | die Reihenfolge von mehrfach auftretenden | Stabil | Infomationen auf keinen Fall ge„ndert werden, so +-----------------+ ist stabil gekennzeichnet. Zwischen zwei - der |**Nur PM | Kennung nach - gleichen Headerinformationen +-----------------+ k”nnen aber beliebige Headerinformationen mit anderer Kennung auftreten. Manche Informationen drfen nur in den Headern privater Nachrichten eingesetzt werden. Bei diesen ist "Nur PM" gekennzeichnet. Ist eine Eigenschaft nicht eindeutig anzugeben, so verweist die Kennzeichnung ** auf eine Erl„uterung im Text. Unter den Zwischenberschriften findet sich die ausfhrlichere Beschreibung der _Funktion_ der Header-Information. Zumeist ist ein _Hinweis_ angegeben, der auf Unklarheiten oder Querbezge aufmerksam macht, Implementierungstips gibt oder einfach nur der Illustration dient. Die _Historie_ gibt an, wann der Header definiert wurde, und an welcher Stelle Modifikationen vorgenommen wurden. "D:" steht dabei fr "Definiert:" und benennt das Dokument mit der Erstdefinition. "M:" steht fr "Modifiziert:" und verweist auf das Dokument oder die Dokumente, in denen die Headerbedeutung abgewandelt, klargestellt oder in anderer Weise unmittelbar ge„ndert wurde (eine zus„tzliche Verwendung im Kontext der Einfhrung oder Ver„nderung einer anderen Headerkennung wird hier nicht vermerkt). Die Eintr„ge lesen sich [D3.0], [D3.1P] und [D3.1M]. "A:" steht fr "Anders bei:" und hat als m”glichen Eintrag derzeit nur [D3.1Z], die aktuelle Dokumentation der Zerberus GmbH, die in einigen Punkten von den Beschlssen des ZConnect-Gremiums abweicht und daher nur erg„nzenden Charakter hat. Ein schlichtes Datum schlieálich bezeichnet den Tag, an dem das ZConnect-Gremium die Žnderung beschlossen hat, wenn die Žnderung nicht in einem der zusammenfassenden Dokumente aufgefhrt ist. Die Notation unter der šberschrift _Siehe auch_: In GROáBUCHSTABEN wird auf verwandte oder im Kontext interessante Headerkennungen verwiesen. Normaler Satz verweist auf ein Thema aus dem allgemeinen - ZConnect 3.1 ---------------------------------------------------------- 15 - Teil dieses Textes. Durch umrahmende "*" symbolisierter *Fettdruck* sagt aus, daá der so dargestellte Querverweis unbedingt zu beachten ist, da er der gerade betrachteten Headerkennung wesentliche Informationen hinzufgt, die Funktion der Kennung abwandelt oder sie gar insgesamt verunm”glicht (manche Kennungen schlieáen sich gegenseitig aus). Fuánoten sind mit geschweiften Klammern gekennzeichnet und am Ende des Dokuments zusammengefaát. - ZConnect 3.1 ---------------------------------------------------------- 16 - - ZConnect 3.1 ---------------------------------------------------------- 17 - Kennung: ABS +-----------------+ |>>Pflicht | Kurzbeschreibung: Absenderin | Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: ABS: [()] Funktion: Die Absenderinangabe dient zum einen natrlich der Identifikation der Herkunft der Nachricht. In den meisten Netzen wird zudem die Angabe des brgerlichen Namens verlangt (nicht im /Z-Netz, aber auch dort wird mittlerweile berwiegend ein Realname angegeben). Bei Fehlern wird die Absenderin benachrichtigt (vgl. ANTWORT-AN). Fehlt die ABS-Information im Header, kann keine Fehlermeldung zugestellt werden; die Nachricht wird kommentarlos gel”scht. Hinweis: Der Realname muá sich selbstverst„ndlich an die Regeln fr den Headerzeichensatz halten, wird also insbesondere von einer CHARSET-Information nicht betroffen. Da die Zeichen, die beim Quoted-Printable-Zeichensatz (vgl. z.B. [RFC 1521]) zum Einsatz kommen, der ZConnect-Norm fr Zeichen im Header entsprechen, verwenden einzelne Personen eben jenen Zeichensatz zum Ausdrcken von Sonderzeichen im Namen. RFC->ZConnect Relays sollten diese Notation allerdings zum ZC-Zeichensatz hin aufl”sen. Historie: D: [D3.0] Siehe auch: *ANTWORT-AN*, OAB, WAB, Adressenformat, Weiterleiten - ZConnect 3.1 ---------------------------------------------------------- 18 - - ZConnect 3.1 ---------------------------------------------------------- 19 - Kennung: ANTWORT-AN +-----------------+ | Pflicht | Kurzbeschreibung: Private Antwortempf„ngerin |>>Optional | +-----------------+ | Nur einmal | |>>Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: ANTWORT-AN: Funktion: Wenn dieser Header angegeben ist, darf eine private Antwort auf die Nachricht nicht an die Absenderin geschickt werden, sondern muá an die hier angegebene Adresse gehen. Das gilt insbesondere fr automatisch erzeugte Antworten (z.B. Fehlermeldungen). Hinweis: Dieser Header ist fr BenutzerInnen gedacht, die unter mehreren Adressen schreiben, die Antworten aber gerne an nur einer Stelle gesammelt vorfinden m”chten. Auch Mailerdemons, welche auf allgemeine Rckfragen nicht antworten k”nnen, k”nnen hier einen sinnvollen Rckkanal vermerken. Mailinglistenserver, die den Originalabsender erhalten, w„hrend Antworten aber nicht an diesen, sondern wieder in die Mailingliste gehen sollen, sind ein weiterer typischer Anwendungsfall. Allerdings besteht hier die Problematik, daá auch Fehlermeldungen an die ANTWORT-AN-Empf„ngerin versandt werden und somit in der Liste landen. Eine m”gliche Abhilfe, die Einfhrung eines FEHLER-AN konnte sich bisher im Gremium nicht durchsetzen, so daá diese Problematik in ZConnect bisher nicht aufl”sbar ist. Es herrscht oft Verwirrung, in welchen F„llen ANTWORT-AN und in welchen DISKUSSION-IN wie eingesetzt bzw. ausgewertet werden soll. Letztere Kennung erlaubt ebenfalls die Angabe einer privaten Adresse als Argument. Diese scheinbare Redundanz ist aber einfach aufzul”sen: Die ANTWORT-AN Information ist ausschlieálich dann auszuwerten, wenn eine rein private Antwort auf eine Nachricht erstellt wird (unabh„ngig davon, ob die zu beantwortende Nachricht privat oder ”ffentlich ist). Ist bei DISKUSSION-IN eine private Adresse angegeben, so ist bei einer ”ffentlichen Beantwortung eine Kopie dieser Antwort an die private Adresse zu schicken (der Begriff "Kopie" ist natrlich unpassend, wenn ausschlieálich eine DISKUSSION-IN-Information mit privater Adresse als Argument vorliegt). Bei privaten Antworten ist DISKUSSION-IN nicht auszuwerten. - ZConnect 3.1 ----------------------------------------------------------- 20 - ANTWORT-AN darf auch mehrfach auftreten. In keinem Teil der Dokumentation ist auf diesen Fall n„her eingegangen worden. Die m”glichen Interpretationen sind die Auswahl einer der angegebenen Adressen fr die Antwort oder das Senden der Antwort an alle angegebenen Adressen. Beide Auslegungen sind sinnvoll; bei automatisch generierten Antworten sollte nur an eine der angegebenen Adresse geantwortet werden, um unn”tiges Datenaufkommen zu vermeiden. Augrund dieser Unsicherheit, aber auch aufgrund der Einstellung, einer Anwenderin darf nicht technisch vorgeschrieben werden, an wen eine Antwort geht, die sie schreibt, betrachten einige Pointprogramme die ANTWORT-AN-Information durchweg als Kann-Bestimmung. ANTWORT-AN-Adressen werden also als m”gliche AdressatInnen angezeigt, nicht aber automatisch verwendet. Historie: D: [D3.0] Siehe auch: ABS, DISKUSSION-IN, Adressenformat, Weiterleiten - ZConnect 3.1 ---------------------------------------------------------- 21 - Kennung: BET +-----------------+ |>>Pflicht | Kurzbeschreibung: Betreff | Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: BET: Funktion: Fr jede Nachricht ist eine Betreffzeile vorgeschrieben. Auch das Aussehen des Betrefftextes ist verbindlich geregelt: Handelt es sich um die Antwort auf eine vorausgegangene Nachricht, so ist dem Betrefftext ein "Re: "{5} voranzustellen, sofern dies dort noch nicht steht. "Re:Re:" darf also nicht vorkommen. Auch ist "Re^2: ", "Re^3: " usw. verboten. Ist eine Ordnungsnummer der Antwort gewnscht, so soll sie aus den BEZ-Informationen gewonnen werden. Hinweis: Unsch”n sind Betrefftexte, die mit "Re:Re:" starten. Auch ist z.B. bei Nachrichten im RFC-Format "Re^n: " verboten. Es ist insgesamt aber in der Praxis kaum gegeben, daá sich eine Software an die Regelung hielte, die Ordnungsnummer der Antwort aus den BEZ-Informationen zu gewinnen. Diese Problematik ist bei BEZ genauer erl„utert. Inkonsequent ist die Forderung nach Angabe von "Re: " im Betrefftext. Ist die Ordnungsnummer nur unzuverl„ssig aus den BEZ-Informationen zu gewinnen, so reicht aber das Vorhandensein einer BEZ-Information aus, um festzustellen, daá es sich um eine Antwort handelt. "Re: " kann also vom anzeigenden Programm generiert werden. Es gibt brigens keinen wirklich zwingenden, technischen Grund fr die Definition der BET-Information als Pflichtinformation. In dem Zusammenhang ist darauf hinzuweisen, daá leere Betreffzeilen vorkommen k”nnen Historie: D: [D3.0] M: [D3.1P] Siehe auch: *BEZ* - ZConnect 3.1 ---------------------------------------------------------- 22 - - ZConnect 3.1 ---------------------------------------------------------- 23 - Kennung: BEZ +-----------------+ | Pflicht | Kurzbeschreibung: Bezugsnachricht |>>Optional | +-----------------+ | Nur einmal | |>>Auch mehrfach | |>>Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: BEZ: Funktion: Wenn die zugeh”rige Nachricht eine Antwort auf eine vorhergegangene Nachricht ist, dann gibt BEZ die Message-ID von letzterer an. Es wird unterschieden zwischen direkten und indirekten Bezgen. Indirekte Bezge sind solche, die schon in der beantworteten Nachricht vorkamen und aus dieser bernommen wurden. Diese šbernahme ist erlaubt, nicht aber verpflichtend. Erfolgt sie, darf die Reihenfolge nicht ge„ndert werden. Die indirekten Bezge mssen im Header vor den direkten Bezgen angegeben werden. Dies ergibt nicht unbedingt eine chronologische Ordnung {6}. Hinweis: In [D3.1Z] ist sinnvollerweise vorgeschrieben, daá bei automatisch erzeugten Nachrichten grunds„tzlich eine BEZ-Information einzufgen ist. Eine Regelung, daá bei Antworten aller Art grunds„tzlich BEZ-Informationen einzufgen sind, es sei denn, die Anwenderin bestimmt Gegenteiliges, wird an dieser Stelle empfohlen. Eine stabile Reihenfolge von Bezgen zu vereinbaren, ist einerseits sinnvoll. Andererseits erlaubt die Syntax nicht, die tats„chliche Reihenfolge der Bezugsnachrichten festzustellen: so kann eine Nachricht mit zwei BEZ-Informationen zwei direkte oder einen direkten und einen indirekten Bezug transportieren. Dies ist die zentrale Problematik der BEZ- und damit auch der BET-Information. Die AutorInnen von [D3.1Z] l”sen dieses Problem abweichend von der Beschluálage des Gremiums, indem sie nur eine direkte BEZ-Information pro Mail zul„át. Dies verhindert in seiner Rigorosit„t allerdings, daá bei gleichzeitigem Antworten auf mehrere Nachrichten auch mehrere direkte Bezge gesetzt werden. Die programmiertechnische Schwierigkeit soll also mit einer Einschr„nkung der M”glichkeiten der AnwenderInnen erkauft werden. Die erlaubte, aber nicht zwingenden Mitnahme der indirekten Bezge verhindert die Erfllung der Forderung, daá das "Re^n:" fr den Betreff aus den - ZConnect 3.1 ----------------------------------------------------------- 24 - Bezgen zu generieren ist. Weder ist es sinnvoll, in den Beitr„gen z.B. zu einer Diskussion komplett alle direkten und indirekten Bezge mitzutransportieren, um die richtige Ordnungszahl des Replys zu errechnen, noch w„re dies dann berhaupt m”glich: Da nicht zwischen direkten und indirekten Bezgen unterschieden werden kann, enth„lt die Anzahl der BEZ-Informationen und selbst ein daraus gewonnener Kommentarbaum keine zuverl„ssige Information ber die Ordnungszahl einer Antwort und ist mithin ohne Aussage. Stand der Dinge: Alle Bezge vor dem zuletzt angegebenen mssen als indirekt interpretiert werden. Eine Auswertung darf keine chronologische Reihenfolge voraussetzen. Es ist besser, im Betreff auf Informationen ber die Verschachtelungstiefe zu verzichten, um dem ZConnect-Standard Folge zu leisten; ProgrammiererInnen, die eine Ordnungszahl wnschen, sollten X-REPLY-LEVEL (s.u.) untersttzen bzw. den Kommentarbaum als (aber nicht ganz zuverl„ssige) Quelle fr ihre Numerierung verwenden. Der Transport aller BEZ-Informationen eines Kommentarbaums wrde ohne echten Informationsgehalt zu aufgebl„hten Headern fhren. Mehrere direkte Bezge sind hingegen sinnvoll verwendbar. Einige Applikationen verwenden die erw„hnte frei definierte Information X-REPLY-LEVEL, um unabh„ngig von Bezugsverkettung und Betreff die Tiefe der Antwortverschachtelung zu transportieren. Es ist auch darauf hinzuweisen, daá der Transport von mehr als den direkten Bezgen ausschlieálich die Funktion hat, bei lokal nicht mehr verfgbaren Nachrichten (die Anwenderin hat sie z.B. mittlerweile gel”scht) trotzdem eine Verkettung mit vorhergehenden Diskussionsbeitr„gen herstellen zu k”nnen. Insofern ist der Transport der direkten und des im Header zuerststehenden und damit mit einer gewissen Wahrscheinlichkeit den Beginn der Diskussion kennzeichnenden, indirekten Bezugs die praxisn„heste L”sung. Der zus„tzliche Transport einer Zahl indirekter Bezge aus "der Mitte des Kommentarbaums" ist als redundante Information zurckhaltend zu dosieren. Bei der Erstellung des Kommentarbaums sollte auf den m”glichen Fehler einer gegenseitigen Bezugnahme zweier Nachrichten aufeinander geachtet werden. Historie: D: [D3.0] M: [D3.1P] A: [D3.1Z] Siehe auch: BET, MID - ZConnect 3.1 ---------------------------------------------------------- 25 - Kennung: CHARSET +-----------------+ | Pflicht | Kurzbeschreibung: Zeichensatzfestlegung |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: CHARSET: ISO1 | ISO2 | ISO3 | ISO4 | ISO5 | ISO6 | ISO7 | ISO8 | ISO9 | UNICODE Funktion: CHARSET legt den Zeichensatz fest, der fr den Nachrichtenk”rper gilt (nicht fr den Header!). Kann das anzeigende Programm den spezifizierten Zeichensatz nicht darstellen, so ist der Anwenderin dies nur mitzuteilen. Die Dokumentation empfiehlt in diesem Zusammenhang dringend, den ISO1-Zeichensatz zu untersttzen. Mit ISOx ist immer die ISO-8859-x gemeint. Groá-/Kleinschreibung ist bei den Parametern nicht relevant. Hinweis: Ist CHARSET nicht angegeben, gilt der normale ZConnect-Zeichensatz. CHARSET ist ausschlieálich fr Textnachrichten vorgesehen, also definitionsgem„á solche Nachrichten, die keine TYP-Kennung im Header haben. CHARSET wirkt nicht auf einen evtl. enthaltenen Kommentar. Der MIME-Standard wird zuknftig von ZConnect untersttzt werden. Genaue Regelungen sind noch nicht getroffen worden. Insbesondere ZConnect->RFC Relays sollten die M”glichkeiten MIMEs nutzen, um z.B. die CHARSET oder TYP: BIN F„higkeiten ZConnects sicher durch den RFC-Raum zu transportieren. UNICODE ist ein 16-Bit-Zeichensatz. Es ist nicht bekannt, daá ZConnect-f„hige Programme diesen Zeichensatz bereits untersttzen. Historie: D: [D3.1M] M: [D3.1Z] (Klarstellung) Siehe auch: CRYPT-CONTENT-CHARSET, Verschlsselung, *Zeichens„tze* - ZConnect 3.1 ---------------------------------------------------------- 26 - - ZConnect 3.1 ---------------------------------------------------------- 27 - Kennung: CONTROL +-----------------+ | Pflicht | Kurzbeschreibung: Nachricht mit Steuerfunktion |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: CONTROL: [CANCEL | ADD | DEL ] Funktion: Mit den CONTROL-Informationen lassen sich bereits verschickte Nachrichten l”schen ("canceln") und netzweit neue Bretter anlegen oder austragen. Es ist genau vorgegeben, wer diese Aktionen durchfhren darf (siehe bei den Einzelinformationen), da dieser Headerinformation eine nicht unerhebliche Sabotagegefahr innewohnt. Die Informationsinhalte sind unabh„ngig von ihrer Groá-/Kleinschreibung auszuwerten ("CANCEL" == "canCeL"). Zwischen Befehl (CANCEL/ADD/DEL) und dessen Parameter (/) sind beliebig viele Whitespaces (, Leerzeichen) zul„ssig, mindestens ist jedoch eines vorgeschrieben. CONTROL darf nur in Kombination mit STAT: CTL auftreten. STAT: CTL sorgt auch dafr, daá CONTROL-Nachrichten nur an Points und Systeme weitergereicht, nicht aber in Onlinedatenbest„nde einsortiert wird. Tritt CONTROL ohne STAT: CTL auf, ist die Nachricht fehlerhaft. CONTROL kann auch ohne Parameter angegeben werden. Genau wie bei einem unbekannten Informationsinhalt (also ungleich CANCEL/ADD/DEL) wird in diesem Fall die CONTROL-Information ignoriert. Die Nachricht beh„lt aber ihren STAT: CTL-Status und wird auch unver„ndert weitergegeben. Hinweis: Bei der Wahl wurde CONTROL als "optional, auch mehrfach" beschlossen, da dies aber nicht in die RFC-Welt bertragbar ist, wurde der Wahlausgang stillschweigend zu "optional, nur einmal" korrigiert. In manchen Netzen kann es per Netikette verboten sein, insbesondere CANCELs auszufhren. Applikationen mssen entsprechend konfigurierbar sein. Historie: D: [Wahl5] - ZConnect 3.1 ---------------------------------------------------------- 28 - Siehe auch: CONTROL: ADD, CONTROL: CANCEL, CONTROL: DEL, ERSETZT, *STAT: CTL*, Weiterleiten - ZConnect 3.1 ---------------------------------------------------------- 29 - Kennung: CONTROL: ADD +-----------------+ | Pflicht | Kurzbeschreibung: Nachricht zur automatischen Einrichtung |>>Optional | von Brettern +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: CONTROL: ADD Funktion: Mit einer CONTROL: ADD Information kann sehr leicht - z.B. netzweit - fr die Einrichtung eines Bretts gesorgt werden. Der als Parameter transportierte bezeichnet das Brett, daá auf dem empfangenden System eingerichtet werden soll. SystembetreiberInnen werden nicht jeder Absenderin gestatten, per Control-Nachricht Bretter einzurichten. Daher sind zwei M”glichkeiten der Legitimation vorgesehen. Die sicherste und einfachste M”glichkeit ist, CONTROL: ADD und CONTROL: DEL enthaltende Nachrichten grunds„tzlich der Systembetreuung zur Entscheidung vorzulegen. Eine elegantere wenngleich "gef„hrlichere" M”glichkeit ist es, ber eine lokal gefhrte Liste Absenderinnen zu bestimmen, deren Control-Nachrichten akzeptiert werden. Eine Nachricht mit CONTROL: ADD Information br„uchte theoretisch keine EMP Informationen, da sie empf„ngerinnenunabh„ngig umgesetzt wird. So dienen die EMPs dann auch lediglich der Verteilung der Control-Nachricht. Denkbar ist auch die private Adressierung, um auf einem ganz bestimmten System ein Brett einzurichten. Hinweis: Eine korrekte Nachricht mit CONTROL: ADD s„he z.B. so aus (Auszug): EMP: /Z-NETZ/KOORDINATION/EINSTELLUNGEN BET: Hier koemmt ein neues Brett ABS: koordination@ttb.aworld.de (Kerstin) STAT: CTL CONTROL: ADD /Z-NETZ/UNWICHTIG Fr die lokale Legitimationstabelle wird folgendes Format angeregt: ;Absenderin Brettgruppen PGP-Fingerprint kerstin@ttb.aworld.de /Z-NETZ/* ...irgendwas... postmaster@lokal.zc /* ...irgendwas... Bestimmten Brettgruppen sollte also zuzuordnen sein, welche Absenderinnen hierin Bretter einrichten (bzw. l”schen) drfen. Die Spalte "PGP-Fingerprint" ist - ZConnect 3.1 ----------------------------------------------------------- 30 - als Fingerzeig zu verstehen, daá z.B. mit einer PGP-Signatur geprft werden k”nnte, ob die jeweilige Absenderinnenangabe authentisch ist. Wo/wenn dies durchfhrbar ist, ist eine solche Tabelle natrlich das elegantaste _und_ sicherste Mittel. An ZConnect<->RFC-Relays ("Gateways") sollten CONTROL: ADD und das RFC-seitige "newgroup" ineinander bersetzt werden. Historie: D: [Wahl5] Siehe auch: *CONTROL*, STAT: CTL - ZConnect 3.1 ---------------------------------------------------------- 31 - Kennung: CONTROL: CANCEL +-----------------+ | Pflicht | Kurzbeschreibung: Nachricht zur L”schung einer frher |>>Optional | versandten Nachricht +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: CONTROL: CANCEL Funktion: Die mit der bezeichnete Nachricht soll gel”scht werden. Dies kann die Absenderin der zu l”schenden Nachricht veranlassen (also ABS oder, falls vorhanden, WAB), darberhinaus die SYSOP und POSTMASTER Accounts des Absendesystems der zu l”schenden Nachricht sowie bestimmte Absenderinnen, die in einer lokal gefhrten Legitimationsliste dazu berechtigt werden (z.B. Netzkoordination). Eine Nachricht mit CONTROL: CANCEL Information transportiert in ihren EMP-Informationen die Aussage, in welchen Brettern die zu l”schende Nachricht gel”scht werden soll. Ist die Ursprungsnachricht also z.B. in zwei Brettern verteilt worden und enth„lt die CANCEL-Nachricht nur eine der EMP-Informationen der Ursprungsnachricht, so bliebe diese in einem Brett erhalten. Jede CONTROL: CANCEL enthaltende Nachricht enth„lt auch eine BEZ-Information, die auf die Nachricht verweist, die auch in der CONTROL: CANCEL- Information bezeichnet ist. Fehlt diese Information, ist die CANCEL-Aufforderung fehlerhaft und darf nicht durchgefhrt werden. Hinweis: Die Fehlerhaftigkeit einer Nachricht mit CONTROL: CANCEL-Information aber ohne redundante BEZ-Information ist in [Wahl5] nicht eindeutig gekl„rt. U.U. kann es sinnvoll sein, hier nicht zu streng zu reagieren. Beispiel einer Ursprungsnachricht (Auszug): EMP: /BRETT/EINS EMP: /BRETT/ZWEI MID: Ursprung@system.zc ABS: User@system.zc (Originalabsender) WAB: Userin@system.zc (Ursprungsabsenderin) BET: Ursprungsnachricht - ZConnect 3.1 ----------------------------------------------------------- 32 - Beispiel ein gltigen CANCEL-Nachricht dazu (Auszug): EMP: /BRETT/ZWEI ABS: Userin@system.zc (Cancelabsenderin) BEZ: Ursprung@system.zc STAT: CTL CONTROL: CANCEL Ursprung@system.zc BET: Cancelnachricht Hiermit wrde die Ursprungsnachricht nur aus /BRETT/ZWEI gel”scht. Die L”schende ist identisch mit der Weiterleiterin der Ursprungsnachricht, also ist das Canceln erlaubt (mensch beachte die unterschiedlichen Realnames, die hierauf keinen Einfluá haben) - wichtig ist, daá User@system.zc _nicht_ canceln drfte. Noch ein gltiges CANCEL-Beispiel (Auszug): EMP: /BRETT/EINS EMP: /BRETT/ZWEI ABS: POSTMASTER@system.zc (Systemadministration) BEZ: Ursprung@system.zc STAT: CTL CONTROL: CANCEL Ursprung@system.zc Hier cancelt also die Systemadministration des Systems, von dem die Ursprungsnachricht kommt, komplett. Es ist zu beachten, daá die ZConnect-Festlegung der Systemadministrationsnamen auf SYSOP oder POSTMASTER der Realit„t nicht entspricht. Es sollte besser eine Liste der m”glichen Systemadministrationsnamen gefhrt werden. Eine Minimall”sung w„re, nur den POSTMASTER-Account zuzulassen, da dieser im "Internet" auf _jedem_ System vorhanden sein muá. Zu beachten ist, daá die tats„chliche Absenderin der Cancel-Nachricht legitimiert sein muá. Ggf. ist also auch bei dieser auf die Existenz einer WAB-Information zu achten. Dies ist sehr wichtig, weil sonst mit Konstrukten wie EMP: /BRETT/EINS EMP: /BRETT/ZWEI ABS: POSTMASTER@system.zc (Trick 17) WAB: Kicher@system.zc (Boeses Mensch) BEZ: Ursprung@system.zc STAT: CTL CONTROL: CANCEL Ursprung@system.zc BET: Cancelnachricht der Sicherungsmechanismus ausgehebelt werden k”nnte. Ein m”gliches Format einer Legitimationsliste ist bei CONTROL: ADD beschrieben. Es ist natrlich auch - ZConnect 3.1 ---------------------------------------------------------- 33 - denkbar, daá fr alle Arten der Control-Nachricht eine eigene Legitimationstabelle gefhrt wird. Historie: D: [Wahl5] Siehe auch: *CONTROL*, STAT: CTL - ZConnect 3.1 ---------------------------------------------------------- 34 - - ZConnect 3.1 ---------------------------------------------------------- 35 - Kennung: CONTROL: DEL +-----------------+ | Pflicht | Kurzbeschreibung: Nachricht zur automatischen L”schung |>>Optional | von Brettern +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: CONTROL: DEL Funktion: Mit einer CONTROL: DEL Information kann sehr leicht - z.B. netzweit - fr die L”schung eines Bretts gesorgt werden. Der als Parameter transportierte bezeichnet das Brett, daá auf dem empfangenden System ausgetragen werden soll. SystembetreiberInnen werden nicht jeder Absenderin gestatten, per Control-Nachricht Bretter zu l”schen. Daher sind zwei M”glichkeiten der Legitimation vorgesehen, die bei CONTROL: ADD n„her beschrieben sind. Eine Nachricht mit CONTROL: DEL Information br„uchte theoretisch keine EMP Informationen, da sie empf„ngerinnenunabh„ngig umgesetzt wird. So dienen die EMPs dann auch lediglich der Verteilung der Control-Nachricht. Denkbar ist auch die private Adressierung, um auf einem ganz bestimmten System ein Brett auszutragen. Hinweis: Eine korrekte Nachricht mit CONTROL: DEL s„he z.B. so aus (Auszug): EMP: /Z-NETZ/KOORDINATION/EINSTELLUNGEN BET: Hier verschwindet gleich ein Brett ABS: koordination@ttb.aworld.de (Kerstin) STAT: CTL CONTROL: DEL /Z-NETZ/WICHTIG Fr die lokale Legitimationstabelle wird ein Format angeregt, das bei CONTROL: ADD beschrieben ist. An ZConnect<->RFC-Relays ("Gateways") sollten CONTROL: DEL und das RFC-seitige "rmgroup" ineinander bersetzt werden. Historie: D: [Wahl5] Siehe auch: *CONTROL*, *CONTROL: ADD*, STAT: CTL - ZConnect 3.1 ---------------------------------------------------------- 36 - - ZConnect 3.1 ---------------------------------------------------------- 37 - Kennung: CRYPT +-----------------+ | Pflicht | Kurzbeschreibung: Nachrichteninhalt ist verschlsselt |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ |>>Nur PM | +-----------------+ Syntax: CRYPT: Funktion: Der zugeh”rige Nachrichtentext ist verschlsselt. Bisher definiert sind folgende Werte fr die Verschlsselungskennung (case-insensitive): 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 PGP2.1 Pretty Good Privacy (h”here Versionen mit entsprechend erh”hter Versionskennzahl) PMCRYPT2 Von Peter Mandrella vorgeschlagenes Verschlsselungsverfahren QPC QuickPoint Crypt Hinweis: Die aktuelle Dokumentation wankt offensichtlich hinsichtlich der Kennzeichnung von PGP. Das verarbeitende Programm sollte derzeit mit allen Kennungen rechnen. Das pure "PGP" als Kennung ist als aktuellste Version zu werten, da diese im Rahmen des PGP-Gesamtkonzepts genannt wird. [D3.1Z] best„tigt diese Auffassung. Zu PMCRYPT2 teilte Peter Mandralla mit, daá es nie implementiert wurde ([PM2]). Zu DES/* wird auf Sekund„rliteratur verwiesen (z.B. gibt [DES] einen leicht verst„ndlichen šberblick ber die Funktionsweise des Verfahrens). QuickPoint Crypt stammt von der Urmutter aller /Z-NETZ-Pointprogramme QuickPoint. Es handelt sich um ein sehr einfaches Verfahren, welches beim QuickPoint-Programmierer erfragt werden kann (siehe Kapitel Verschlsselung). Der Einsatz von CRYPT fr ”ffentliche Nachrichten kann sinnvoll sein, z.B. fr geschlossene BenutzerInnengruppen. Historie: D: [D3.1P] - ZConnect 3.1 ---------------------------------------------------------- 38 - Siehe auch: CRYPT-CONTENT..., PGP..., SIGNED, STAT, Verschlsselung - ZConnect 3.1 ---------------------------------------------------------- 39 - Kennung: CRYPT-CONTENT-CHARSET +-----------------+ | Pflicht | Kurzbeschreibung: Zeichensatz der in der verschlsselten |>>Optional | Nachricht enthaltenen Originalnachricht +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ |>>Nur PM | +-----------------+ Syntax: CRYPT-CONTENT-CHARSET: Funktion: Enthielt eine verschlsselte Nachricht eine CHARSET-Headerinformation, so muá diese nach dem Entschlsseln wieder bercksichtigt werden. CRYPT-CONTENT-CHARSET gibt also bei beliebigen Verschlsselungsarten an, welche CHARSET-Information zum entschlsselten Inhalt geh”rt. Die Zeichensatz-ID kann entsprechend der Dokumentation von CHARSET folgende Werte (Groá-/Kleinschreibung irrelevant) annehmen: ISO1, ISO2, ISO3, ISO4, ISO5, ISO6, ISO7, ISO8, ISO9 oder UNICODE. Hinweis: Dieser Header taucht bisher nicht explizit in der Dokumentation auf. Er ergibt sich jedoch ohne jeden Zweifel aus der beschlossenen PGP-Dokumentation zu ZConnect. In [D3.1M] ist unter der šberschrift "Zeichensatz verschlsselter Nachrichten" w”rtlich geregelt: "Sollte einmal ein Zeichensatzheader eingefhrt werden, muá auch dabei das Original vor der Verschlsselung mit einem vorangestellten 'CRYPT-CONTENT' erhalten bleiben." Die eingefhrte Zeichensatzheaderinformation heiát CHARSET, also existiert die gltige und beschlossene Information CRYPT-CONTENT-CHARSET. Es ergibt sich auch hier das bei CRYPT-CONTENT-KOM n„her erl„uterte Problem der Verschlsselungsrekursion. Historie: D: [D3.1P] A: [D3.1Z] (definiert CRYPT-...-CHARSET nicht) Siehe auch: *CHARSET*, *CRYPT-CONTENT-KOM*, Verschlsselung - ZConnect 3.1 ---------------------------------------------------------- 40 - - ZConnect 3.1 ---------------------------------------------------------- 41 - Kennung: CRYPT-CONTENT-KOM +-----------------+ | Pflicht | Kurzbeschreibung: Verschlsselung enth„lt einen Kommentar |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ |>>Nur PM | +-----------------+ Syntax: CRYPT-CONTENT-KOM: Funktion: Das derzeitige PGP-Konzept sieht vor, daá der Nachrichtenk”rper im vollen Umfang (also entsprechend der LEN-Headerinformation) verschlsselt wird. Dies kann auch fr andere Verschlsselungsverfahren gelten. Um dann beim Entschlsseln einen ehemaligen Kommentar (genauer: die KOM-Information) wiederherzustellen, ist der Transport dessen ehemaliger L„nge mit CRYPT-CONTENT-KOM vorgeschrieben (diese Auffassung best„tigt [D3.1Z]). Diese Headerinformation ist im Zusammenhang mit CRYPT Pflicht, wenn eine KOM-Information in der Ursprungsnachricht enthalten war. Ist eine Nachricht inklusive Kommentar ersteinmal verschlsselt und die L„nge in CRYPT-CONTENT-KOM codiert, so kann die Nachricht neuerlich mit einer KOM-Headerinformation versehen werden. Hinweis: Wird eine Nachricht, die bereits verschlsselt ist, mit einem neuerlichen Kommentar versehen und dann z.B. nocheinmal unterschrieben, so bricht die Logik der ZConnect-PGP-Einbindung zwangsl„ufig auseinander. Nun máte ein CRYPT-CONTENT-CRYPT-CONTENT-KOM eingesetzt werden, was vielleicht machbar w„re (sogar nach derzeitiger Dokumentation, welche allerdings - hier schnell verbrauchte - maximal 100 Zeichen fr die Headerkennung vorsieht), aber sicher nicht wnschenswert ist. Die Einbindung hat hier eine grunds„tzlichen Schw„che. Die Erzeugung von "Verschlsselungsrekursion" sollte also unbedingt vermieden werden. Andererseits ist auf jeden Fall mit einem KOM # zus„tzlich zu CRYPT-CONTENT-KOM zu rechnen. Es wird # von der Dokumentation nicht vorgeschlagen, wie beim # Entschlsseln die zwei m”glichen Kommentare # behandelt werden sollen. Es bietet sich an, diese zusammenzufassen. Da am Nachrichtenk”rper keine Žnderung vorgenommen werden darf, verbietet sich hierbei eine naheliegende optische Trennung der beiden Kommentare. - ZConnect 3.1 ---------------------------------------------------------- 42 - Historie: D: [D3.1P] M: [D3.1Z] (Klarstellung) Siehe auch: *CRYPT: PGP*, CRYPT-CONTENT-CHARSET, CRYPT-CONTENT-TYP, KOM, Verschlsselung - ZConnect 3.1 ---------------------------------------------------------- 43 - Kennung: CRYPT-CONTENT-TYP +-----------------+ | Pflicht | Kurzbeschreibung: Typ der in einer verschlsselten |>>Optional | Nachricht enthaltenen Originalnachricht +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ |>>Nur PM | +-----------------+ Syntax: CRYPT-CONTENT-TYP: Funktion: Enthielt eine verschlsselte Nachricht eine TYP-Headerinformation, so muá diese nach dem Entschlsseln wieder bercksichtigt werden. CRYPT-CONTENT-TYP gibt also bei beliebigen Verschlsselungsarten an, welche TYP-Information zum entschlsselten Inhalt geh”rt. Die m”glichen Nachrichtentypen sind bei TYP beschrieben. Hinweis: Das im Kontext auftretende Problem der Verschlsselungsrekursion ist bei CRYPT-CONTENT-KOM genauer beschrieben. Historie: D: [D3.1P] Siehe auch: *CRYPT-CONTENT-KOM*, TYP, Verschlsselung - ZConnect 3.1 ---------------------------------------------------------- 44 - - ZConnect 3.1 ---------------------------------------------------------- 45 - Kennung: DDA +-----------------+ | Pflicht | Kurzbeschreibung: Dateidatum |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: DDA: Funktion: Wenn die Nachricht eine Datei repr„sentiert, kann hiermit das Datum der letzten Žnderung angegeben werden. Das Datum enth„lt auch die Uhrzeit und ggf. die Zeitzone. Das Format ist im Kapitel "Datumsangaben" beschrieben. Hinweis: Laut Dokumentation ist diese Headerinformation nicht auf Bin„rnachrichten beschr„nkt. Jedoch sollte mensch bedenken, daá die EDA-Headerinformation bei jeder Nachricht ohnehin vorhanden ist. Historie: D: [D3.0] Siehe auch: EDA, FILE, TYP, Datumsangaben - ZConnect 3.1 ---------------------------------------------------------- 46 - - ZConnect 3.1 ---------------------------------------------------------- 47 - Kennung: DISKUSSION-IN +-----------------+ | Pflicht | Kurzbeschreibung: Umleitung von ”ffentlichen Antworten |>>Optional | +-----------------+ | Nur einmal | |>>Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: DISKUSSION-IN: | Funktion: DISKUSSION-IN leitet die ”ffentliche Antwort auf eine Nachricht um. Die ”ffentliche Antwort landet also nicht im selben Brett wie die beantwortete Nachricht, sondern wird in die bei DISKUSSION-IN spezifizierten Brettern geleitet. Die Angabe einer ZConnect-Adresse hat laut Dokumentation die "Semantik von: 'Followup-To poster'". šbersetzt bedeutet dies, daá die Antwort auf eine ”ffentliche Nachricht in ein Postfach umgeleitet werden kann. Wenn also ein DISKUSSION-IN: zusammen mit einem DISKUSSION-IN: angegeben ist, hat dies die Funktion einer Kopie ins Postfach (z.B.) der Absenderin der Nachricht. Hinweis: Den Beantwortenden sollte die M”glichkeit gegeben werden, eine private Adresse als einzigen Ort eines Diskussionsbeitrags abzulehnen, um dem Mehrwegecharakter der Netze gerecht zu werden. Es ist m”glich, diese Headerinformation auch bei privaten Nachrichten einzusetzen. Wenn BenutzerInnen eine ”ffentliche Antwort unter Bezugnahme auf eine private Nachricht in ein bestimmtes Brett schreiben k”nnen sollen, so ist die Angabe einer DISKUSSION-IN-Information eine M”glichkeit. šblicherweise wird DISKUSSION-IN gesetzt, wenn eine Nachricht in ein reines Informationsbrett gestellt wird, und etwaige Diskussionen daher in einem anderen Brett stattfinden sollen. Eine Nachricht kann so in vielen Brettern eine Diskussion anregen, die dann aber nur in einem gefhrt werden soll. # [D3.1Z] erl„utert, daá das absendende System # verhindern sollte, daá eine andere ZConnect-Adresse # als die der Absenderin bei einem DISKUSSION-IN # eingesetzt wird, um Miábrauch zu verhindern. # Andererseits verhindert eine solche Einschr„nkung # natrlich die sinnvollen Anwendungsm”glichkeiten von # z.B. mehreren DISKUSSION-IN: oder # im Zusammenhang mit Mailinglisten. Da im Gremium # hierzu kein Beschluá vorliegt, sollten # ProgrammiererInnen ihre Implementierungsentscheidung - ZConnect 3.1 ---------------------------------------------------------- 48 - # sorgf„ltig abw„gen. Von der Befolgung der Regelung # aus [D3.1Z] wird an dieser Stelle aber strikt # abgeraten. Historie: D: [D3.0] M: [D3.1P] (Klarstellung) A: [D3.1Z] (s.o.) Siehe auch: *ANTWORT-AN*, EMP, Adressenformat, Brettnamenformat - ZConnect 3.1 ---------------------------------------------------------- 49 - Kennung: EB +-----------------+ | Pflicht | Kurzbeschreibung: Empfangsbest„tigung anfordern |>>Optional | +-----------------+ | Nur einmal | |>>Auch mehrfach | | Stabil | +-----------------+ |>>Nur PM | +-----------------+ Syntax: EB: [] Funktion: Fr die Reaktion auf EB sind zwei F„lle vorgesehen: Ist das Endsystem ein Point, der mit ZConnect angeschlossen ist, so wird erst von ihm die Empfangsbest„tigung erzeugt. Ist die Mailbox{7} dagegen das letzte ZConnect-System auf dem Weg zur Empf„ngerin, so muá bereits sie (beim Einsortieren) die Best„tigung verschicken. Die Empfangsbest„tigung ist von der Aussagekraft her w”rtlich zu nehmen: Das best„tigende System verr„t nicht, ob die Nachricht gelesen wurde, sondern nur, daá sie bei ihm angekommen ist. Dies k”nnte aus Sicht des Datenschutzes auch gar nicht anders sein. Wird bei der EB-Headerinformation eine Adresse mitgeschickt, so ist die Empfangsbest„tigung nicht an die Absenderin, sondern an eben jene Adresse zu schicken. Hiermit erkl„rt sich auch, warum die Information mehrmals vorkommen darf (mehrere EB-Kennungen ohne Argument sind allerdings sinnlos). WICHTIG: Wird keine Adresse mitgeschickt, so ist die Best„tigung an eine eventuell vorhandene ANTWORT-AN-Adressatin zu schicken. Ist diese nicht angegeben, so wird sie an die WAB-Absenderin versandt. Sind beide nicht vorhanden, wird gegenber der in der ABS-Headerinformation angegebenen Adresse best„tigt. Einige Details der Prozedur der Empfangsbest„tigung sind vorgeschrieben: * Die best„tigende Nachricht erh„lt die STAT: EB Headerinformation * Die Message-ID der best„tigten Nachricht wird als BEZ-Headerinformation eingefgt. Hinweis: Janus-Points sind im engeren Sinn der Regelung fr Empfangsbest„tigungen nicht als ZConnect-Systeme zu werten, erzeugen also keine Empfangsbest„tigungen. Es werden hierzu auch andere Meinungen vertreten ([B3], [PM3]). In der Praxis ist das Softwareverhalten so unterschiedlich wie die Meinungen. - ZConnect 3.1 ---------------------------------------------------------- 50 - Die EB-Headerinformation bleibt unabh„ngig von der eventuellen Abarbeitung durch die Mailbox auf dem Weg zur Anwenderin erhalten. Gel”scht wird sie hingegen beim Weiterleiten (Ausnahme: Umleiten), beim Zurckschicken im Fehlerfall, beim Antworten etc.. Wenn es auch nicht verboten w„re, die indirekten Bezge in die Empfangsbest„tigung zu bernehmen, so wrde dies doch wenig Sinn machen. Manche Pointprogramme verschicken die Empfangsbest„tigung mit einer einstellbaren Anzahl Tage Verz”gerung. Dies ist unter Datenschutzaspekten eine „uáerst sinnvolle Erw„gung. Historie: D: [D3.0] Siehe auch: ABS, BEZ, STAT: EB, MID, Adressenformat, Points, Weiterleiten - ZConnect 3.1 ---------------------------------------------------------- 51 - Kennung: EDA +-----------------+ |>>Pflicht | Kurzbeschreibung: Erstellungsdatum | Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: EDA: Funktion: Jede Nachricht muá mit einem Erstellungsdatum versehen werden. Das Datum enth„lt wie immer auch Zeit und ggf. Zeitzone. Hinweis: Beim Einsetzen des Erstellungsdatums sind unbedingt Datenschutzaspekte zu beachten. AnwenderInnen mssen die M”glichkeit haben, zumindest die Angabe der Uhrzeit der Erstellung zu verweigern. Es empfiehlt sich, das automatische Setzen der Uhrzeit auf generell 0:00 Uhr (oder einen anderen, beliebigen, immer gleichen Wert) zu erm”glichen. Historie: D: [D3.0] Siehe auch: DDA, Datenschutz, Datumsangaben - ZConnect 3.1 ---------------------------------------------------------- 52 - - ZConnect 3.1 ---------------------------------------------------------- 53 - Kennung: EMP +-----------------+ |>>Pflicht | Kurzbeschreibung: Empf„ngerin | Optional | +-----------------+ | Nur einmal | |>>Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: EMP: | [()] Funktion: Diese Headerinformation gibt die Empf„ngerin der Nachricht an. Es kann sich um ein Brett oder eine private Adressatin handeln. EMP kann mehrfach vorkommen, also ist es auch m”glich, daá beide M”glichkeiten im selben Header gemischt auftreten (vgl. Kapitel Gemischtadressierung). Unver„ndert gilt die ZConnect 3.0-Regelung, daá eine private Empfangsadresse mit Realname in der blichen Schreibweise versehen sein darf. Bei ”ffentlichen Nachrichten, die aus dem Netz kommen{8}, und die ins Netz gehen{9}, darf niemals (es existiert keine Ausnahme von der Regel) eine ”ffentliche Empf„ngerin zu einer Kopienempf„ngerin werden, also *keine* Wandlung von EMP nach KOP stattfinden. Bei privaten Empf„ngerinnen ist dies hingegen ausdrcklich vorgesehen. Wird also z.B. ein Mischcrossposting an einer Stelle aufgetrennt in die private Nachricht und die ”ffentliche Nachricht, so tauchen in der privaten Nachricht alle ”ffentlichen Empf„ngerinnen als KOPs auf. In der abgetrennten ”ffentlichen Nachricht taucht die private Kopienempf„ngerin ebenfalls als KOP auf (wenn nicht STAT: NOKOP angegeben wurde). Wenn ein System eines oder mehrere der in einer EMP-Information aufgefhrten Bretter nicht fhrt oder nicht bestellt hat, drfen dennoch keine EMP-Informationen gel”scht werden. Insbesondere drfen in diesem Fall auch bei Nachrichten, die aus dem Netz kommen, und die in das Netz gehen, EMPs nicht in KOPs gewandelt werden. Hinweis: Weist die EMP-Headerinformation einer Nachricht auf ein Brett, welches lokal auf Schreibverbot (z.B. geschlossene BenutzerInnengruppe) steht, so sollte die Nachricht nicht in das Brett gestellt, aber auch nicht mit einem KOP-Header versehen werden. Vielmehr sollte sie komplett zensiert, also z.B. den SystemverwalterInnen zur Entscheidung vorgelegt werden. - ZConnect 3.1 ---------------------------------------------------------- 54 - Crosspostings, also Nachrichten mit mehreren EMPs, sind mittlerweile eher die Regel als die Ausnahme. H„ufig ist Verwirrung hinsichtlich der Regelung fr das Ersetzen von EMP durch KOP festzustellen. Dieses Thema wird daher bei KOP ausfhrlich behandelt. Historie: D: [D3.0] M: [D3.1P] (Klarstellung), [D3.1M] (Klarstellung) Siehe auch: *DISKUSSION-IN*, EB, *KOP*, STAT: NOKOP, Adressenformat, Brettnamenformat, *Gemischtadressierung*, Points - ZConnect 3.1 ---------------------------------------------------------- 55 - Kennung: ERR +-----------------+ | Pflicht | Kurzbeschreibung: Fehlerkennung |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ |>>Nur PM | +-----------------+ Syntax: ERR: [;]* [] Funktion: Eine Nachricht mit dieser Headerinformation befindet sich auf dem Rckweg von einem System, welches einen Fehler in ihr bemerkt hat (z.B. Empf„ngerin unbekannt, Fehler im Header). ERR enth„lt mindestens eine Fehlerklasse. Die m”glichen Klassen sind im folgenden aufgelistet: Klasse | Typ | Bedeutung -------+---------+---------------------------------------- 0 | Warnung | anwenderdefiniert 1-4 | Warnung | Zustellung trotz Problemen erfolgt 5-9 | Fehler | Zustellung wegen Fehlern nicht erfolgt >=10 | Panik | anwenderdefiniert Die Fehlerklassen 0 und >=10 sind nur lokal zu verwenden und sollten nicht ber das Netz gehen. Grunds„tzlich sind alle natrlichen Zahlen inkl. der 0 m”glich. Als Zahlentyp schl„gt [D3.1M] w”rtlich "intern mindestens [...] 4 Byte (LongInt)" vor. Die Fehlerklassifizierung soll insbesondere der Software zwischen Warnungen und Fehlern unterscheiden helfen. Zus„tzlich sind beliebig (!) viele Fehlernummern m”glich. Optional, aber nur bei vorangegangener Fehlerklasse (und evtl. vorangegangenen Fehlernummern), ist ein Fehlermeldungsklartext enthalten, fr den in der Dokumentation die englische Sprache nahegelegt wird. Numerische Werte werden durch ein Semikolon voneinander getrennt, der Klartext hingegen ist durch ein Leerzeichen abgetrennt. Eine Nachricht mit ERR-Headerinformation darf nicht erneut fehlerbehandelt werden. Sollte keine Empf„ngerin angegeben sein, ist die Nachricht zu entsorgen. Ist bei einer Nachricht eine Weiterleitabsenderin (WAB) oder eine ANTWORT-AN-Adresse angegeben, so sind diese statt der Absenderin von dem aufgetretenen Fehler zu unterrichten. ANTWORT-AN hat hierbei h”here Priorit„t. - ZConnect 3.1 ---------------------------------------------------------- 56 - Hinweis: Aus der Dokumentation ist nicht ersichtlich, ob zur # Abtrennung des Klartextes ein beliebiges Whitespace # verwendet werden darf, oder ob ein Leerzeichen # verpflichtend ist. Es ist sinnvoll, mit Whitespaces # zu rechnen, aber in der eigenen Software ein # Leerzeichen zu erzeugen. # # Die ZConnect 3.1 Spezifikation der # ERR-Headerinformation ist nicht abw„rtskompatibel zu # ZConnect 3.0, welches ausschlieálich Klartext als # Argument vorsah (3.0-Systeme verstehen zwar # 3.1-ERR-Informationen, 3.1-Systeme aber nicht die # von 3.0-Systemen). Vermutlich aus diesem Grunde # beschreibt [D3.1Z] die Syntax der ERR-Information, # unter der Maágabe, daá eine ERR-Information ohne # Parameter unzul„ssig ist, wie folgt: # # ERR: [[;]*] [] # # Eine ERR-Information mit reinem Klartext w„re demnach # nachwievor zul„ssig. Vermutlich durch einen # Cut&Paste-Fehler widerspricht [D3.1Z] sich hier aber # fnf Zeilen sp„ter und benennt wieder die von [D3.1M] # beschriebene Syntax als gltig. # # [D3.1Z] definiert auch Fehlernummern, die das Gremium # bisher nicht beschlossen hat, die vermutlich dem # Ist-Stand beim Zerberus-Programm entliehen und zudem # von vielen Gremiumsmitgliedern abgelehnt werden ([B4]): # # Fehlernummer | Bedeutung # -------------+---------------------------------------------- # 1 | Versand nicht m”glich # 1;1 | Konto berzogen # 1;2 | Nachricht zu alt # 1;3 | Netzzugriff fr Absenderin gesperrt # | # 2 | Private Nachricht kann nicht zugestellt werden # 2;1 | Keine Empf„ngerin angegeben # 2;2 | Empf„ngerin beim Zielsystem unbekannt # 2;3 | Zieladresse ist ein Verteiler, und der ist # | Zschreibgeschtzt # | # 3 | Private Nachricht kann nicht geroutet werden # 3;1 | Routesystem unbekannt oder gesperrt # 3;2 | Direktmails und Routemails gesperrt # 3;3 | Nachricht zu lang # 3;4 | System beim Domainserver unbekannt # 3;5 | Domainserver unbekannt # 3;6 | Rekursion aufgetreten # 3;7 | Empfangssystem gesperrt # 3;8 | Domain unbekannt # | # 4 | Zustellung in Brett nicht m”glich # 4;1 | Brett nur fr Onlinezugriff # 4;2 | Brettname unzul„ssig # 4;3 | Brett existiert nicht # 4;4 | Brett gesperrt - ZConnect 3.1 ---------------------------------------------------------- 57 - # 4;5 | Kein Autoeintrag; mehrfache Brettangaben # | # 5 | Fehlerhafte Headerinformationen # 5;1 | Nur einmal erlaubter Header tritt mehrfach auf # 5;1;1 | ABS # 5;1;3 | EMP # 5;1;4 | BET # 5;1;5 | ROT # 5;1;6 | LEN # 5;1;7 | MID # 5;1;8 | WAB # 5;1;10 | OAB # 5;2 | Ein Pflichtheader ist nicht vorhanden # 5;2;1 | ABS # 5;2;2 | EMP # 5;2;3 | EDA # 5;2;4 | BET # 5;2;5 | ROT # 5;2;6 | LEN # 5;2;7 | MID # 5;3 | Eine Headerinformation hat ein falsches Format # 5;3;1 | ABS # 5;3;2 | EMP # 5;3;3 | EDA # 5;3;4 | BET # 5;3;5 | ROT # 5;3;6 | LEN # 5;3;7 | MID # 5;3;8 | WAB # 5;3;9 | KOP # 5;3;10 | OAB # 5;3;11 | OEM # 5;3;12 | EB # 5;3;13 | ANTWORT-AN # 5;3;14 | DISKUSSION-IN # # In der Tabelle sind etliche Widersprche zu # konstatieren: Die Fehlernummern 1;x bis 4;x sind # schwerlich s„mtlich als "Warnung" interpretierbar # (vgl. Tabelle der Fehlerklassen), da teilweise die # Zustellung aus technischen Grnden unm”glich ist. # Eine Fehlernummer wie 4;5 ist ohne weitere # Erl„uterungen schwer nachvollziehbar. # # Zudem ist von einer "GAB"-Headerinformation die # Rede, welche es natrlich nicht gibt. Sicher handelt # es sich um einen Druckfehler; aus der Logik der # Fehlernummernvergabe ergibt sich, daá es sich an den # entsprechenden Stellen um die LEN-Information # handeln máte, wie in der obigen Tabelle # dargestellt. Historie: D: [D3.0] M: [D3.1M] A: [D3.1Z] Siehe auch: Aufbau und Zeichensatz von Headerinformationen, Weiterleiten - ZConnect 3.1 ---------------------------------------------------------- 58 - - ZConnect 3.1 ---------------------------------------------------------- 59 - Kennung: ERSETZT +-----------------+ | Pflicht | Kurzbeschreibung: Nachrichtenaktualisierung |>>Optional | +-----------------+ | Nur einmal | |>>Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: ERSETZT: Funktion: Die Nachricht mit der ERSETZT-Headerinformation ersetzt die Nachricht mit der als Argument angegebenen Message-ID. Dies ist zugleich Anweisung und Information. Die zu ersetzende Nachricht (z.B. eine aktuelle Brettliste) wird von der ERSETZT-Nachricht berschrieben. Anschlieáend steht die Headerinformation dann fr die Aussage, daá ersetzt wurde. Hinweis: ERSETZT wird von mehreren Programmen als Cancelmail{10}-Ersatz verwendet. Dies ist insofern eine Zweckentfremdung, als die Cancelmail dann anstelle der Originalmail tritt, statt sie zu l”schen. [D3.1Z] ist bemht, ERSETZT zu einem vollwertigen Cancelmail-Ersatz umzudokumentieren. Dazu wird definiert, daá abweichend von den Gremiumsbeschlssen eine Nachricht mit leerem Nachrichtenk”rper und ERSETZT im Header die zu ersetzende Nachricht l”scht, ohne an ihre Stelle zu treten. Zudem sei eine Autorisierungsprfung notwendig, deren Durchfhrung aber nicht n„her erl„utert wird. Seit der Einfhrung der CANCEL-Headerinformation hat sich die Diskussion um die Verwendung von ERSETZT als Cancelmail-Ersatz erledigt. # Ohne eine Autorisierung ist die # ERSETZT-Headerinformation problematisch, da sie als # Sabotagemittel geeignet ist. Dies ergibt sich # daraus, daá ERSETZT mehrfach angegeben werden kann. # So kann eine einzige Nachricht theoretisch das # gesamte Netzleben lahmlegen. Bei [D3.1Z] ist angemerkt, daá es fr die Umsetzung von ERSETZT in die Praxis ausreichen wrde, der alten, zu ersetzenden Nachricht einen Hinweis anzufgen, daá diese ersetzt worden sei. Angesichts der Tatsache, daá Nachrichtenk”rper nicht ge„ndert werden drfen, ist nur das Hinzufgen eines Kommentars nebst KOM-Headerinformation m”glich. BenutzerInnenschnittstellen sollten unter Beachtung des Umstandes implementiert werden, daá ERSETZT in - ZConnect 3.1 ---------------------------------------------------------- 60 - den Datenbestand einer Anwenderin eingreift, wenn es auf einem Endsystem ausgewertet wird. Die Umsetzung von ERSETZT sollte also sorgf„ltig erwogen werden. STAT: AUTO ist eng verwandt mit ERSETZT. Als Unterschied ist ausschlieálich zu nennen, daá zur Identifizierung der zu aktualisierenden Information bei STAT: AUTO andere (FILE und EMP) Headerinformationen herangezogen werden als die Message-ID. Historie: D: [D3.0] A: [D3.1Z] Siehe auch: BEZ, CANCEL, MID, STAT: AUTO - ZConnect 3.1 ---------------------------------------------------------- 61 - Kennung: FILE +-----------------+ | Pflicht | Kurzbeschreibung: Dateiname |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: FILE: Funktion: Enth„lt die Nachricht eine Datei (z.B. bei einer Bin„rnachricht), so kann mit FILE ein Dateiname angegeben werden. Dieser darf keine Directoryinformationen enthalten, ist aber je nach Betriebsystem unterschiedlich lang. Der Dateiname kann wegen seiner unbestimmten Herkunft jederzeit auch beliebige Sonderzeichen (z.B. auch Leerzeichen, Hochkommata, mehr als einen Punkt) enthalten. Die verarbeitende Software muá hierauf vorbereitet sein und evtl. eine Umwandlung vornehmen oder einen neuen Namen generieren. Hinweis: Angesichts der Tatsache, daá der Dateiname absolut beliebige Zeichen (Einschr„nkung: Zeichensatz in Headerinformationen) enthalten darf, ist das Verbot von Directoryinformation natrlich haupts„chlich beim Erzeugen zu bercksichtigen; es ist dabei auf eine m”glichst betriebsystem-”kumenische Namensgebung zu achten. Wenn ein Betriebsystem zwischen Groá- und Kleinschreibung nicht unterscheidet, wird die Angabe des Dateinamens in Kleinbuchstaben empfohlen. Historie: D: [D3.0] Siehe auch: DDA, STAT: AUTO, TYP: BIN - ZConnect 3.1 ---------------------------------------------------------- 62 - - ZConnect 3.1 ---------------------------------------------------------- 63 - Kennung: KOM +-----------------+ | Pflicht | Kurzbeschreibung: Kommentarl„nge |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: KOM: Funktion: Der Nachrichtenk”rper einer Nachricht kann unterteilt sein in Kommentar und eigentliche Nachricht (z.B. ausfhrliche Dateibeschreibung als Kommentar und anschlieáende Bin„rnachricht). In diesem Fall gibt KOM die Anzahl Bytes an, die der Kommentar in der Mail ausmacht. Der Kommentar selber steht am Anfang des Nachrichtenk”rpers. Fr den Inhalt des Kommentars gelten die Standardregeln fr den Nachrichtenk”rper allgemein. Das bedeutet insbesondere, daá eine CHARSET- oder eine TYP-Headerinformation auf den Kommentaranteil keine Wirkung hat! Die LEN-Information ist die Summe aus der L„nge des Kommentaranteils und der L„nge des Rests des Nachrichtenk”rpers. Graphisch dargestellt: Ú-----------------------+ | Header | +-----------------------+-. --. | Kommentar | |- KOM | +-----------------------+-' | | | |- LEN | Daten/Text | | | | | +-----------------------+ --' Hinweis: Der Kommentar kann nicht nur einem Bin„rteil vorangestellt werden. Insbesondere kann er auch in einer normalen Textnachricht vorkommen. Es ist mit KOM: 0 zu rechnen. Historie: D: [D3.0] Siehe auch: LEN, *CRYPT-CONTENT-KOM* - ZConnect 3.1 ---------------------------------------------------------- 64 - - ZConnect 3.1 ---------------------------------------------------------- 65 - Kennung: KOP +-----------------+ | Pflicht | Kurzbeschreibung: Kopienempf„ngerin |>>Optional | +-----------------+ | Nur einmal | |>>Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: KOP: | Funktion: Bei Nachrichten mit mehreren Empf„ngerinnen kann es unter bestimmten Voraussetzungen zur Ersetzung von EMPs durch KOPs kommen. Eine KOP-Headerinformation sagt aus, daá eine Kopie der Nachricht an die angegebene Empf„ngerin gegangen ist. Die KOP-Information hat keine Steuerfunktion. Sie ist ein Dienst fr die menschliche Adressatin der Nachricht. Diese ist die einzige Instanz, die mithilfe der BenutzerInnenschnittstelle irgendwelche Schlsse aus KOPs ziehen darf; z.B. darf der Inhalt der KOP-Headerinformationen niemals zu Routingzwecken herangezogen werden. Hinweis: Aus Datenschutzgrnden wurde die Headerinformation STAT: NOKOP eingefhrt, mit welcher der Einsatz von KOP im Zusammenhang mit privaten Nachrichten untersagt werden kann. Dies ist sehr sinnvoll, kompliziert aber auf den ersten ProgrammiererInnenblick die Implementierung. Daher erfolgt bereits an dieser Stelle die Einbeziehung von STAT: NOKOP in die Erl„uterung; der Querverweis sollte dennoch nicht bersehen werden, da es weitere Details zu beachten gilt. Bei der Erl„uterung von EMP in [D3.1M] ist das Einsetzen von KOP-Headerinformationen bei Privatnachrichten, die von einer gemischt adressierten Nachricht abgetrennt werden, als Pflicht beschrieben. Der Einsatz von KOPs zun„chst einmal dem Sinn nach aufgeschlsselt: * Bei gemischtadressierten Nachrichten hat die private Empf„ngerin evtl. ein Interesse daran, zu erfahren, daá und in welche ”ffentliche Bretter Kopien gegangen sind. Auch ist diese Information nicht schutzwrdig, da die ”ffentlichen Kopien jedermensch lesen kann. * Bei Crosspostings, die (auch) an mehrere private Empf„ngerinnen geht, kann die Absenderin berechtigte Einw„nde dagegen haben, daá die Empf„ngerinnen erfahren, an wen private Kopien - ZConnect 3.1 ---------------------------------------------------------- 66 - gegangen sind. Dies entspricht einem konsequenten Datenschutzgedanken. * Bei Crosspostings, die (auch) ”ffentliche Empf„ngerinnen haben, kann die Absenderin vermeiden wollen, daá im ”ffentlich werdenden Header zu lesen ist, an wen private Kopien gegangen sind (Datenschutz). * Auch eine private Empf„ngerin k”nnte etwas dagegen einzuwenden haben, daá ”ffentlich oder anderen privaten Empf„ngerinnen kundgetan wird, daá sie eine Kopie erhalten hat. Jedoch liegt es dann "wie im richtigen Leben" bei der Empf„ngerin, sich mit der Absenderin auseinanderzusetzen. Das Protokoll darf der Absenderin nur technisch Notwendiges vorschreiben. Das Pointprogramm (z.B.) k”nnte aber sinnvollerweise STAT: NOKOP als Normalfall behandeln und seine Nicht-Verwendung explizit ausw„hlen lassen. Vor den technischen Schluáfolgerungen zun„chst eine sprachliche Definition: Die Ursprungsnachricht wird aufgeteilt in die Abspaltung und den Rest. Die Abspaltung ist der fortan selbst„ndig auf den (Route-) Weg geschickte Teil mit einer oder mehreren privaten Empf„ngerinnen{11}. Der Rest ist die brigbleibende, ”ffentliche Nachricht (eine Nachricht ist dann ”ffentlich, wenn eine der Empf„ngerinnen nicht privat ist). Es wird also immer der Moment betrachtet, in dem rein private Nachrichten entstehen. Zwei Logiktabellen machen im folgenden deutlich, wie die Programmierung aussehen muá. Zun„chst eine Logiktabelle fr die Behandlung des Rests: - ZConnect 3.1 ---------------------------------------------------------- 67 - | EMP- | | | Typen | | | im | | | Rest | | | | S | | P | ™ | T | | r | f | A | | i | f | T | | v | e | : | | a | n | | | t | t | N | | | l | O | | | i | K | | | c | O | | | h | P | | Aktion +---+---+---+ +-------------------------------- | | x | | -> | Abgespaltener EMP wird zu KOP | | x | x | -> | Abgespaltener EMP verschwindet | x | | | -> | Abgespaltener EMP wird zu KOP | x | | x | -> | Abgespaltener EMP verschwindet | x | x | | -> | Abgespaltener EMP wird zu KOP | x | x | x | -> | Abgespaltener EMP verschwindet Es ist deutlich, daá beim Rest sehr einfach vorgegangen werden kann: Ist STAT: NOKOP gesetzt, so wird kein KOP erzeugt, die Information des abgetrennten EMPs verschwindet. Ist STAT: NOKOP nicht gesetzt, werden aus abgetrennten EMPs KOPs. Die Logiktabelle fr die Abspaltung: | EMP- | | | Typen | | | im | | | Rest | | | | S | | P | ™ | T | | r | f | A | | i | f | T | | v | e | : | | a | n | | | t | t | N | | | l | O | | | i | K | | | c | O | | | h | P | | Aktion +---+---+---+ +---------------------------------------- | | x | | -> | Alle EMPs des Rests werden zu KOPs | | x | x | -> | Alle EMPs des Rests werden zu KOPs | x | | | -> | Alle EMPs des Rests werden zu KOPs | x | | x | -> | Die EMPs des Rests verschwinden | x | x | | -> | Alle EMPs des Rests werden zu KOPs | x | x | x | -> | Alle ”ffentlichen EMPs des Rests werden | | | | | zu KOPs, alle privaten EMPs verschwinden Hier stellt sich die Aufgabe ebenfalls sehr bersichtlich dar: Ist STAT: NOKOP nicht gesetzt, so - ZConnect 3.1 ---------------------------------------------------------- 68 - werden alle nach der Abtrennung brigbleibenden EMPs des Restes zu KOPs der Abspaltung. Bleiben drei F„lle, in denen STAT: NOKOP gesetzt ist, und die sich ganz einfach so zusammenfassen lassen: Die ”ffentlichen EMPs des Rests (sofern vorhanden) werden zu KOPs der Abspaltung, die privaten EMPs des Rests (sofern vorhanden) nicht. Eine neue Message-ID muá brigens fr die ja rein private Abspaltung nicht erzeugt werden, da der ZConnect-Rekursionscheck (und auch andere Netzstandards, z.B. die RFC-Suite) den Dupecheck bei privaten Nachrichten nicht vorsieht. Bei der Auftrennung gemischtadressierter Nachrichten ist, wegen des Designproblems ZConnects in diesem Kontext (siehe Kapitel Gemischtadressierung), zu beachten, daá Headerinformationen wie PGP: PLEASE, VIA, STAT: TRACE, EB usw. nicht in einer rein ”ffentlich adressierten Nachricht weitergereicht werden, soweit dies vermeidbar ist. Historie: D: [D3.0] M: [D3.1P] (Klarstellung), [D3.1M] (Klarstellung) Siehe auch: EMP, *STAT: NOKOP*, Adressen, Brettnamen, *Gemischtadressierung*, Points, Dupecheck - ZConnect 3.1 ---------------------------------------------------------- 69 - Kennung: LANGUAGE +-----------------+ | Pflicht | Kurzbeschreibung: Nachrichtensprache |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ |>>Nur PM | +-----------------+ Syntax: LANGUAGE: Funktion: Die Absenderin einer Nachricht kann mit dieser Headerinformation angeben, in welcher Sprache sie gerne die Antwort bekommen wrde. Kann die gewnschte Sprache nicht angeboten werden, so empfiehlt die Dokumentation, die englische zu benutzen. Als Parameter sind die englischsprachigen Bezeichnungen der jeweiligen Sprache zugelassen. Also z.B. GERMAN fr Deutsch, ENGLISH fr Englisch, AMERICAN ENGLISH fr amerikanisches Englisch, CUCKOOISH fr das Piepsen der Kuckucks, SPANISH, GREEK, FRENCH... Hinweis: Diese Headerinformation ist in der derzeitigen Fassung nur fr automatisch generierte Antworten sinnvoll. # Eine weitere Anwendung fr einen dann aber erweitert # zu definierendes LANGUAGE ist denkbar: Abseits von # der technischen CHARSET-Regelung ist es fr die # Empf„ngerin m”glicherweise von Interesse, in welcher # Sprache eine Nachricht geschrieben ist. Aus # japanischen Zeichen l„át sich z.B. auch bei # gegebener Darstellbarkeit fr Laien nicht erkennen, # ob es sich z.B. um Katakana, Hiragana oder etwas # ganz anderes handelt. # # Auch w„re vorstellbar, daá eine Empf„ngerin bei # einer imagin„ren Pointsoftware einstellt, daá sie # nur franz”sischsprachige Nachrichten berhaupt # angezeigt bekommen m”chte. Oder, um der Vision des # Globalen Dorfes eine linguistische Dimension zu # geben, es k”nnte auch Pointsoftware geben, die # automatisch šbersetzungen vornimmt. Dies ist schon # heute teilweise, insbesondere fr die englische # Sprache, realistisch, z.B. durch Einbindung eines # externen šbersetzungsprogramms. Denkbar ist auch das # Angebot eines automatischen šbersetzungsservices # ber per eMail oder Onlineverbindungen erreichbare # Netzautomatismen. Umsetzungen werden bereits erprobt # [B5]. Historie: D: [D3.1M] - ZConnect 3.1 ---------------------------------------------------------- 70 - Siehe auch: Points, Weiterleiten - ZConnect 3.1 ---------------------------------------------------------- 71 - Kennung: LDA +-----------------+ | Pflicht | Kurzbeschreibung: L”schdatum |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: LDA: Funktion: Verfallsdatumangabe :-) Ab dem angegebenen Datum soll die Nachricht automatisch gel”scht werden. Ntzlich fr Veranstaltungshinweise oder z.B. auch die Urgent Actions von amnesty international. Hinweis: Ein Pointprogramm sollte nicht ohne Einwilligung der Inhaberin des Datenbestands in diesem l”schen. LDA kann also bestenfalls zusammen mit einer Rckfrage bei der Benutzerin einen Automatismus ergeben. Anders sieht es in Onlinedatenbest„nden aus, hier kann LDA im Rahmen der automatischen Pflege bearbeitet werden. Historie: D: [D3.0] Siehe auch: Datumsangaben, Points, Weiterleiten - ZConnect 3.1 ---------------------------------------------------------- 72 - - ZConnect 3.1 ---------------------------------------------------------- 73 - Kennung: LEN +-----------------+ |>>Pflicht | Kurzbeschreibung: Nachrichtenl„nge | Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: LEN: Funktion: LEN gibt die Anzahl der Bytes an, die nach dem Header noch folgen und zur Nachricht geh”ren (sprich: die L„nge des Nachrichtenk”rpers). Hinweis: Die L„nge Null ist in der Dokumentation explizit als erlaubt definiert. Negative L„ngen sind verboten. Historie: D: [D3.0] Siehe auch: KOM - ZConnect 3.1 ---------------------------------------------------------- 74 - - ZConnect 3.1 ---------------------------------------------------------- 75 - Kennung: MAILER +-----------------+ | Pflicht | Kurzbeschreibung: Name des Mailerprogramms |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: MAILER: Funktion: Hiermit kann sich der Mailer der Absenderin und/oder ein Gate identifizieren. Die Kennung sollte eindeutig sein (Versionsnummer usw.). Gedacht ist diese Headerinformation fr das Ausfindigmachen von fehlerhafter Software. Hinweis: MAILER wird nicht von Software ausgewertet, das Format ist also frei. # Mailboxsoftware h„ngt meistens an bereits bestehende # MAILER-Zeilen ein "via Mailboxsoftware XYZ" an. # Dieses Vorgehen ist nicht berall gern gesehen, wird # aber geduldet, wenn die Mailerinformation nicht # allzu lang ger„t. Sinnvoll w„re es, wenn sich alle # Gatewayprogramme in „hnlicher Weise benennen wrde, # da sie sehr h„ufig Quelle von Fehlern sind. Historie: D: [D3.0] Siehe auch: Headerzeichensatz, Weiterleiten - ZConnect 3.1 ---------------------------------------------------------- 76 - - ZConnect 3.1 ---------------------------------------------------------- 77 - Kennung: MID +-----------------+ |>>Pflicht | Kurzbeschreibung: Message-ID | Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: MID: Funktion: Die Message-ID muá so erzeugt werden, daá sie weltweit fr mindestens zwei Jahre eindeutig ist. Tritt eine Message-ID innerhalb von zwei Jahren zum wiederholten Mal bei einer Nachricht auf, handelt es sich um eine zu l”schende Rekursion. Das Aussehen der Message-ID ist recht genau vorgeschrieben: Sie muá wie eine ZConnect-Adresse ohne Realname aussehen und unbedingt eine Domain enthalten (falls das absendende System keine Domain hat, ist ".zer.sub.org" zu verwenden). Fr Points wird vorgeschlagen, die Message-ID in der Form lokale_id@pointname.systemname.domain aufzubauen. Der Teil vor dem '@' wird h„ufig und sinnvollerweise aus der von vielen Compiler-Standardbibliotheken gelieferten "Unixtime" (Zeit in Sekunden seit 1970) und einer laufenden Nummer gebildet. Diese Daten sind dann aber noch geeignet zu verfremden, um das Datenschutzbedrfnis der Absenderin (vgl. EDA) nicht auszuhebeln. # Ein weiterer, „uáerst sinnvoller und daher bitte nicht # zu ignorierender Vorschlag in der Dokumentation ist, # bei Points, die mehr als ein System als Tor zum Netz # verwenden, den Teil nach dem '@' nicht systemabh„ngig # zu generieren. Fr System A und System B lautet es dann # also lokale_id@point.A.domain. Dies verhindert Dupes # (die andernfalls entstnden, sobald einE BenutzerIn auf # den Gedanken k„me, dieselbe Mail in mehrere Boxen zu # schicken, z.B. damit sie sich schnell verbreitet). Die Zeichen '<', '>' und '/' sind in Message-IDs verboten. Aus dem fr Header zul„ssigen Zeichensatz ergibt sich aber z.B., daá deutsche Sonderzeichen enthalten sein k”nnten. Hinweis: Die Message-ID ein und derselben Mail darf niemals ver„ndert werden! Der frher bliche Umbau der Point-Message-ID bei der ersten Mailbox auf dem Routeweg hat zu erheblichen Problemen und Dupewellen gefhrt. - ZConnect 3.1 ---------------------------------------------------------- 78 - Auf Rekursionen muá jede Software prfen und diese dann entsprechend behandeln. N„heres ist im Kapitel Rekursionscheck erl„utert. # Es findet sich in der Dokumentation kein Hinweis # darauf, ob die Groá-/Kleinschreibung bei einer # Message-ID zu beachten ist. In der Spezifikation zum # MAPS-Standard (in [D3.1M]) wird beim ORDER-Befehl # beschrieben, bei der Message-ID sei die # Groá-/Kleinschreibung zu beachten. [D3.1Z] hingegen # bestimmt in gleichem Kontext, die Message-ID sei bis # zum "@" case sensitive und dahinter case insensitive. # Angesichts der Definition von Mailadressen, die hinter # dem "@" case insensitive zu behandeln sind, und # angesichts deren Eingang in die Bildung der Message-ID, # trifft die Beschreibung durch [D3.1Z] zu. Historie: D: [D3.0] M: [B5], [D3.1M]/[D3.1Z] (Klarstellung) Siehe auch: BEZ, ERSETZT, Adressenformat, *Dupecheck* - ZConnect 3.1 ---------------------------------------------------------- 79 - Kennung: MIME +-----------------+ | Pflicht | Kurzbeschreibung: Art der MIME-Codierung |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ |>>Nur PM | +-----------------+ Syntax: MIME: . Funktion: Gibt fr Nachrichten mit TYP: MIME an, welche MIME-Version und Unterversion verwendet wurden. Hinweis: MIME ist in [RFC 1521] definiert. ACHTUNG: S„mtliche Diskussionen um die MIME-Integration in ZConnect und auch die vom Gremiumswahlleiter hierzu versandten Texte weisen eindeutig daraufhin, daá dringend davon abzuraten ist, aufgrund der derzeitigen MIME-Beschluálage eine Implementierung vorzunehmen. Es wird mit Sicherheit gr”áere Žnderungen geben, potentiell werden dabei s„mtliche bisherigen Beschlsse zu ZConnect-MIME aufgehoben. Historie: D: [Wahl5] Siehe auch: TYP: MIME, Kapitel "MIME" - ZConnect 3.1 ---------------------------------------------------------- 80 - - ZConnect 3.1 ---------------------------------------------------------- 81 - Kennung: O-EDA +-----------------+ | Pflicht | Kurzbeschreibung: Originalempfangsdatum |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: O-EDA: Funktion: Die EDA-Headerinformation einer weiterzuleitenden Nachricht kann auf diese Weise in der Weiterleitung, welche eine eigene EDA-Information haben muá, berleben. Hinweis: [D3.1Z] erl„utert, daá O-EDA nur bei der ersten Weiterleitung aus der verlorengehenden EDA-Information erzeugt wird. Hintergrund sei, daá fr weiterzuleitende Nachrichten eine neue EDA-Headerinformation erzeugt werden muá und die Originalerstellungszeit dadurch verloren ginge. # O-EDA wird nur beim manuellen Weiterleiten eingesetzt, # da beim automatischen Weiterleiten und beim Umleiten # davon ausgegangen wird, daá private Nachrichten # transportiert werden, fr die weder eine neue # Message-ID (zur Vermeidung einer irrtmlichen # Rekursionsdetektion) noch ein neues EDA (zur Vermeidung # einer L”schung als "zu alt") erforderlich sind. Dies # ist jedoch eine unzul„ssige Annahme, da beim # automatischen Weiterleiten einer PM, z.B. einer # Nachricht aus einer Mailingliste, in ein (z.B. lokales) # Brett, die Nachricht verlorengehen k”nnte, weil die # Systemsoftware ein zu hohes Alter diagnostiziert (vgl. # MID, Rekursionscheck: Nachrichten, die „lter als 90 # Tage sind, werden gel”scht). Historie: D: [D3.1P] M: [D3.1Z] (Klarstellung) Siehe auch: EDA, Rekursionscheck, *Weiterleiten* - ZConnect 3.1 ---------------------------------------------------------- 82 - - ZConnect 3.1 ---------------------------------------------------------- 83 - Kennung: O-ROT +-----------------+ | Pflicht | Kurzbeschreibung: Originalrouteweg |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: O-ROT: Funktion: Beim Weiterleiten muá der Routeweg der weiterzuleitenden Nachricht gel”scht werden, da die Weiterleitung eine neue ROT-Headerinformation erh„lt. Mittels O-ROT kann der alte Routeweg in der Weiterleitung transportiert werden. Hinweis: [D3.1Z] erl„utert, daá dieser Header bei Weiterleitungen ber einen Vertreter (VER-Headerinformation) aus der ROT-Information erzeugt werden soll, um bei privaten Nachrichten das vermeintliche Feststellen eines Pingpongroutings zu vermeiden. Dies wrde passieren, wenn unter Beibehaltung der ROT-Information eine Nachricht wieder auf den Weg ins Netz geschickt und dabei wieder ber Systeme geroutet werden wrde, die bereits auf dem Weg zum weiterleitenden System passiert wurden. # Mit dieser Begrndung ist es entgegen der bisherigen # Dokumentation auch erforderlich, O-ROT beim # automatischen Weiterleiten einzusetzen (vgl. # Weiterleiten). Historie: D: [D3.1P] M: [D3.1Z] (Klarstellung) Siehe auch: O-EDA, ROT, VER, *Weiterleiten* - ZConnect 3.1 ---------------------------------------------------------- 84 - - ZConnect 3.1 ---------------------------------------------------------- 85 - Kennung: OAB +-----------------+ | Pflicht | Kurzbeschreibung: Originalabsender |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: OAB: Funktion: Beim manuellen, aktiven Weiterleiten wird in die OAB-Headerinformation der Weiterleitung der ABS der weitergeleiteten Nachricht bernommen, sofern noch keine OAB-Information im Header enthalten ist. Historie: D: [D3.0] Siehe auch: ABS, WAB, *Weiterleiten* - ZConnect 3.1 ---------------------------------------------------------- 86 - - ZConnect 3.1 ---------------------------------------------------------- 87 - Kennung: OEM +-----------------+ | Pflicht | Kurzbeschreibung: Originalempf„ngerin |>>Optional | +-----------------+ | Nur einmal | |>>Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: OEM: | Funktion: Beim automatischen und beim manuellen Weiterleiten mssen die Empf„ngerInnen der weiterzuleitenden Nachricht als OEMs aufgefhrt werden. Beim manuellen Weiterleiten wird dies nicht durchgefhrt, wenn bereits OEM-Informationen im Header enthalten sind. Historie: D: [D3.0] Siehe auch: EMP, *Weiterleiten* - ZConnect 3.1 ---------------------------------------------------------- 88 - - ZConnect 3.1 ---------------------------------------------------------- 89 - Kennung: ORG +-----------------+ | Pflicht | Kurzbeschreibung: Organisation |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: ORG: Funktion: Wenn die Absenderin sich einer Organisation zugeh”rig fhlt, dann kann sie in der ORG-Information eine einzeilige Beschreibung angeben (z.B. "PoeM e.V., Vorstand"). Hinweis: BenutzerInnen von ORG sollten z.B. durch einen Hilfstext darauf aufmerksam gemacht werden, daá durch die Angabe einer Organisation geschriebene Nachrichten als Meinung der Organisation verstanden, also ggf. miáverstanden werden k”nnen. Historie: D: [D3.0] Siehe auch: POST, TELEFON, Weiterleiten - ZConnect 3.1 ---------------------------------------------------------- 90 - - ZConnect 3.1 ---------------------------------------------------------- 91 - Kennung: PGP +-----------------+ | Pflicht | Kurzbeschreibung: PGP-Aufforderung |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ |>>Nur PM | +-----------------+ Syntax: PGP: PLEASE | REQUEST Funktion: PGP: PLEASE fordert die Empf„ngerin auf, den ebenfalls im Header enthaltenen PGP Public Key (!) zu unterschreiben. Der Empf„ngerin sollte dieses Ansinnen nicht ohne den Hinweis vorgetragen werden, daá eine Unterschrift unter einen PGP Public Key eine Aktion von weittragender Bedeutung ist. Es ist unbedingt darauf hinzuweisen, daá ein pers”nlicher Kontakt erforderlich ist, um z.B. anhand eines Fingerprints sicher sagen zu k”nnen, daá der zu unterschreibende Key zu der Absenderin geh”rt. Fr die Antwort auf PGP: PLEASE sollte die Headerkennung PGP-KEY-OWN verwendet werden. PGP: REQUEST bittet die Empf„ngerin um die Zusendung von deren Public Key. Sowohl PGP: PLEASE als auch PGP: REQUEST drfen nicht bei ”ffentlichen Nachrichten eingesetzt werden. Hinweis: Das Verbot des Einsatzes dieser Information bei ”ffentlichen Nachrichten ist bei der Auftrennung von gemischtadressierten Nachrichten zu beachten! Bei strenger Auslegung (gemischtadressierte Nachrichten sind ”ffentliche Nachrichten) heiát das, daá diese Informationen bei gemischtadressierten Nachrichten nicht eingesetzt werden drfen. PGP: REQUEST ist auch bei Non-PGP-Nachrichten sinnvoll und kann und darf daher auch bei ihnen auftreten. Fr PGP: PLEASE gilt „hnliches, allerdings ist zu beachten, daá hier der Einsatz nur Sinn macht, wenn auáerdem eine PGP-PUBLIC-KEY-Headerinformation im Header enthalten ist (natrlich w„re es auch denkbar, daá PGP: PLEASE die formalisierte Aufforderung an eine Empf„ngerin ist, die den Public Key der Absenderin bereits hat - die Dokumentation sieht dies nicht vor). Auch wenn eine groáe Verbreitung des eigenen Public Keys zu dessen F„lschungs"sicherheit" beitr„gt, sollte ihn das Pointprogramm - „hnlich wie bei Empfangsbest„tigungen - nicht ohne Rckfrage bei der Benutzerin versenden. - ZConnect 3.1 ---------------------------------------------------------- 92 - Es ist darauf hinzuweisen, daá die ZConnect-PGP-L”sung sich sehr rasch verbreitet. Aufgrund der ohne Untersttzung durch die BenutzerInnenschnittstelle nicht verarbeitbaren Schlsselcodierungen im Header wird dringend empfohlen, ZConnect-PGP zu implementieren. Historie: D: [D3.1P]/[D3.1M] Siehe auch: PGP-KEY-OWN, *Gemischtadressierung*, *Verschlsselung*, Weiterleiten - ZConnect 3.1 ---------------------------------------------------------- 93 - Kennung: PGP-ID +-----------------+ | Pflicht | Kurzbeschreibung: PGP Userinnen-ID |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: PGP-ID: <> Ein Hinweis auf einem Sonderfall in der Notation: Einfache, spitze Klammern um die Netzadresse sind ausnahmsweise tats„chlich anzugeben. Eine gltige PGP-ID-Information s„he also so aus: Ce Brunke Funktion: Normalerweise ist die in der PGP Userinnen-ID enthaltene Nutzinformation bereits durch die ZConnect-Pflichtheader im Header vertreten. Die Dokumentation sieht PGP-ID fr den Fall vor, daá "dies einmal nicht m”glich ist". Hinweis: Der Fall, daá "dies einmal nicht m”glich ist", ist z.B. dann gegeben, wenn die Absenderin normalerweise auf die Angabe des Realnames zu verzichten wnscht, diesen in der ID aber angeben m”chte. Zu beachten ist, daá die šbergabe der PGP-ID an PGP in Hochkommata erfolgen sollten, da PGP Leerzeichen als Trenner zwischen mehreren Empf„ngerInnen betrachtet. Historie: D: [D3.1P]/[D3.1M] Siehe auch: *Verschlsselung*, Weiterleiten - ZConnect 3.1 ---------------------------------------------------------- 94 - - ZConnect 3.1 ---------------------------------------------------------- 95 - Kennung: PGP-KEY-AVAIL +-----------------+ | Pflicht | Kurzbeschreibung: PGP Public Key erh„ltlich |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: PGP-KEY-AVAIL: [ [Systemname des Keyservers] [Adressenanteil der PGP-Userinnen-ID]] Funktion: Die Absenderin gibt mit dieser Kennung an, daá sie den Bezug ihres Public Keys anbietet. Wird PGP-KEY-AVAIL ohne Parameter angegeben, kann bei der Absenderin nur mittels PGP: REQUEST dieser Public Key erbeten werden. PGP-KEY-AVAIL ist auch ein Bindeglied zwischen Onlinephase und Datenformat. Hierzu dient der Parameter der Kennung, welcher in angibt, bei welchem System online (per ZConnect-Onlinephase mit deren Headerinformation PGP-KEYREQ) der Public Key der Absenderin requestet werden kann. Ein Beispiel fr die Parameter von PGP-KEY-AVAIL fr den Keyrequest: +49-40-6912028 bingo.comlink.de Sepro@bingo.comlink.de +------------+ +--------------+ +--------------------+ | | | Systemtelefon- | | nummer in | | internationalem | | Forma | | Systemname des | Key-Servers | Adressenanteil der PGP-Userinnen-ID Die Systemtelefonnummer bezeichnet die Rufnummer der Box, bei der per ZConnect-Onlinephase der Public Key der Absenderin requestet werden kann. Die Syntax folgt dabei weitestgehend dem Format der TELEFON-Headerinformation: Lediglich die vorangestellten Buchstaben (fr Voice/Box/Fax) entfallen. Der Systemname ist optional. Ist er nicht angegeben, handelt es sich bei dem servenden System um jenes, welches auch in der Adresse der Absenderin enthalten ist. - ZConnect 3.1 ---------------------------------------------------------- 96 - Auch die Adresse, die Teil der PGP User-ID ist, welche zum zu requestenden Public Key geh”rt. ist optional. Fehlt sie, ist diejenige der Absenderin der Nachricht zu verwenden. Hinweis: Die BINGO ist kein ZConnect-System (sondern verwendet Janus[Plus]), es ist also wenig erfolgversprechend, das Beispiel auszuprobieren ;-) Es wird empfohlen, die Parameterkomponenten durch je genau ein Leerzeichen voneinander zu trennen, von anderer Software aber eine beliebige Anzahl Whitespaces (mindestens eines) zu erwarten. # [D3.1Z] definiert PGP-KEY-AVAIL abweichend als auch # mehrfach vorkommend. Dies ist durchaus sinnvoll, # aber vom Gremium nicht so beschlossen. Auch sieht # [D3.1Z] einen vierten optionalen Teil der Parameter # der PGP-KEY-AVAIL-Information vor, welcher als # "ISDN" spezifiziert wird und aussagen soll, daá es # sich bei der vorausgegangenen Telefonnummer um eine # ISDN-Nummer handelt. Im Zusammenspiel mit der # M”glichkeit, mehrere PGP-KEY-AVAIL-Informationen # angeben zu k”nnen, ebenfalls sinnvoll - aber nicht # beschlossen. Historie: D: [D3.1P]/[D3.1M] A: [D3.1Z] Siehe auch: *Verschlsselung*, Weiterleiten - ZConnect 3.1 ---------------------------------------------------------- 97 - Kennung: PGP-KEY-COMPROMISE +-----------------+ | Pflicht | Kurzbeschreibung: Widerrufener PGP Public Key |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ |**Nur PM | +-----------------+ Syntax: PGP-KEY-COMPROMISE: Funktion: PGP-KEY-COMPROMISE darf nur zusammen mit PGP-PUBLIC-KEY auftauchen. Auf diese Weise kann der zu widerufende Public Key durch den neuen ersetzt werden. Aus dem Kontext ergibt sich, daá PGP-KEY-COMPROMISE nur bei privaten Nachrichten eingesetzt werden darf - mit der bei PGP-PUBLIC-KEY beschriebenen Einschr„nkung. Hinweis: Es gibt aus dem PGP Konzept heraus keinen Grund dafr, daá ein zurckgezogener Public Key durch einen neuen ersetzt werden máte. Nur ZConnect schreibt dies vor. Historie: D: [D3.1P]/[D3.1M] Siehe auch: *Gemischtadressierung*, *Verschlsselung*, Weiterleiten - ZConnect 3.1 ---------------------------------------------------------- 98 - - ZConnect 3.1 ---------------------------------------------------------- 99 - Kennung: PGP-KEY-OWN +-----------------+ | Pflicht | Kurzbeschreibung: Unterschriebener PGP Public Key |>>Optional | der Empf„ngerin; +-----------------+ Antwort auf PGP: Please |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ |>>Nur PM | +-----------------+ Syntax: PGP-KEY-OWN: Funktion: PGP-KEY-OWN ist i.d.R. die Antwort auf PGP: PLEASE. PGP-KEY-OWN enth„lt den Schlssel der Empf„ngerin mit einer neuen Unterschrift, wahrscheinlich, aber nicht unbedingt jener der Absenderin. Historie: D: [D3.1P]/[D3.1M] Siehe auch: *Gemischtadressierung*, *Verschlsselung*, Weiterleiten - ZConnect 3.1 --------------------------------------------------------- 100 - - ZConnect 3.1 --------------------------------------------------------- 101 - Kennung: PGP-PUBLIC-KEY +-----------------+ | Pflicht | Kurzbeschreibung: PGP Public Key der Absenderin |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ |**Nur PM | +-----------------+ Syntax: PGP-PUBLIC-KEY: Funktion: Die Absenderin transportiert in dieser Headerinformation ihren PGP Public Key. Die Empf„ngerin kann ihn fr die Verschlsselung zuknftiger Kommunikation benutzen. Hinweis: Der Public Key sollte nicht mit jeder ”ffentlichen Nachricht versendet werden. Fr die Verbreitung des Keys mag das zwar ntzlich sein, die Kopflastigkeit des ZConnect-Datenformats steigert es jedoch dabei sehr. Umgekehrt kann diese Headerinformation fr private Nachrichten technisch nicht verboten sein, da es durchaus sinnvoll ist, in bestimmten, dafr vorgesehenen Brettern den Public Key in einer ”ffentlichen Nachricht zu versenden. Historie: D: [D3.1P]/[D3.1M] Siehe auch: PUBLIC-KEY, *Gemischtadressierung*, *Verschlsselung*, Weiterleiten - ZConnect 3.1 --------------------------------------------------------- 102 - - ZConnect 3.1 --------------------------------------------------------- 103 - Kennung: PGP-SIG +-----------------+ | Pflicht | Kurzbeschreibung: PGP-Signatur |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: PGP-SIG: Funktion: Ist eine Nachricht mit PGP unterschrieben (SIGNED: PGP), wird die Signatur(datei) der Absenderin als PGP-SIG in BASE64-Codierung transportiert. So k”nnen auch Bin„rnachrichten unterschrieben werden. Hinweis: Um mit PGP eine vom Dokument abgel”ste Unterschrift zu erzeugen, werden die Parameter "-sb" verwendet. Bei ”ffentlichen Nachrichten ist m”glichst die Abtrennung der Unterschrift vorzunehmen, um auch LeserInnen ohne PGP das Lesen zu erm”glichen. Ist hingegen die Nachricht ohnehin PGP-verschlsselt, kann die Unterschrift auch als Teil der Verschlsselung transportiert werden. Es ist nicht sinnvoll, in einer unterschriebenen Nachricht zugleich den Public Key der Absenderin zu versenden, da bei einer F„lschung der Unterschrift unterwegs auch der Public Key gef„lscht werden kann. Historie: D: [D3.1P]/[D3.1M] Siehe auch: *SIGNED*, *Verschlsselung*, Weiterleiten - ZConnect 3.1 --------------------------------------------------------- 104 - - ZConnect 3.1 --------------------------------------------------------- 105 - Kennung: POST +-----------------+ | Pflicht | Kurzbeschreibung: Postanschrift |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: POST: Funktion: Es gibt nicht nur das Netz... Die Absenderin kann ihre postalische Adresse in der POST-Headerinformation unterbringen. Die Zeilen einer Postanschrift werden dabei nebeneinander geschrieben, durch Semikola getrennt. Beispiel: POST: Wachtelstr. 6; 22305 Hamburg Historie: D: [D3.0] Siehe auch: ORG, TELEFON, Weiterleiten - ZConnect 3.1 --------------------------------------------------------- 106 - - ZConnect 3.1 --------------------------------------------------------- 107 - Kennung: PRIO +-----------------+ | Pflicht | Kurzbeschreibung: Priorit„t |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: PRIO: Funktion: Definiert sind bisher drei Dringlichkeitsstufen, die als Kennzahl hinter der PRIO-Kennung auftauchen k”nnen: 0 - Normales Routing 10 - Direktversand 20 - Eilversand (sofortige Auslieferung) Ist der Header nicht vorhanden, wird die Priorit„t Null angenommen. Hinweis: Direktversand bedeutet, daá bei bestehende Direktverbindung zwischen zwei Systemen eine mit PRIO: 10 versehene Nachricht direkt ausgetauscht wird, auch wenn sie nach einer Routingtabelle einen anderen Weg nehmen wrde. Beispiel: Die Systeme A und B haben eine Verbindung zum gemeinsamen Domainserver S und auch eine Direktverbindung untereinander. Normalerweise wrden private Nachrichten von A nach B nicht ber die Direktverbindung sondern ber den (zumeist schnelleren, weil aus frequenteren Verbindungen bestehenden) Umweg ber S geschickt. PRIO: 10 wrde bewirken, daá die Nachricht w„hrend der n„chsten Direktverbindung direkt von A an B zugestellt wird. Eilversand ist z.B. bei Einsatz der ZConnect-Onlinephase, die den Kontakt zwischen sich unbekannten Systemen definiert, m”glich. Eine mit PRIO: 20 versehene Nachricht kann vom routenden System durch einen direkten Anruf beim Zielsystem zugestellt werden, sofern die Rufnummer ihm bekannt ist. Priorit„ten sind grunds„tzlich, wegen der m”glicherweise verursachten Kosten oder nicht gegebener Direktverbindungen, als Wunsch zu verstehen, nicht als Vorschrift. Bei anderer Interpretation muá eine ERR-Nachricht bei nicht beachteter PRIO-Information erzeugt werden. PRIO ist insgesamt auch fr ”ffentliche Nachrichten sinnvoll verwendbar. - ZConnect 3.1 --------------------------------------------------------- 108 - Historie: D: [D3.0] M: [D3.1M] Siehe auch: ERR, Weiterleiten - ZConnect 3.1 --------------------------------------------------------- 109 - Kennung: PUBLIC-KEY +- - - - - - - - -+ | Pflicht | Kurzbeschreibung: PGP Public Key |>>Optional | +- - - - - - - - -+ |>>Nur einmal | VERALTET Auch mehrfach | Stabil | +- - - - - - - - -+ |**Nur PM | +- - - - - - - - -+ Syntax: PUBLIC-KEY: Funktion/Hinweis: Keine mehr. Durch das durchg„ngige # ZConnect-PGP-Konzept ist diese Headerkennung # eigentlich nicht mehr zu verwenden. Die # Dokumentation vers„umt diesen Hinweis, aber auch # [D3.1Z] erw„hnt diese Headerinformation nicht mehr. Historie: D: [D3.1P] A: [D3.1Z] Siehe auch: *PGP-PUBLIC-KEY*, Verschlsselung - ZConnect 3.1 --------------------------------------------------------- 110 - - ZConnect 3.1 --------------------------------------------------------- 111 - Kennung: ROT +-----------------+ |>>Pflicht | Kurzbeschreibung: Routepfad | Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: ROT: [] Funktion: Im Routeweg tragen sich alle das ZConnect-Datenformat untersttzende Systeme, ber die die Nachricht geroutet wurde, im Moment des Empfangs ein. Der Eintrag in den Routestring erfolgt inklusive Domainangabe (falls keine bekannt ist, dann "zer.sub.org"), wobei das gerade empfangende System seinen Namen an den Anfang des Routewegs schreibt und ein Ausrufungszeichen als Trenner verwendet. Kam eine Mail also mit der Headerinformation ROT: bingo.comlink.de beim System CL-HH an, so fgt letzteres seinen Namen ein, und ROT: cl-hh.comlink.de!bingo.comlink.de entsteht. Points mssen bei ausgehenden Nachrichten einen leeren Routeweg einsetzen (sie empfangen ja nicht). Mailboxsoftware sollte die Einhaltung dieser Regel prfen und muá sich als erstes System in den Routeweg eintragen. Steht ein System bereits im Routestring, darf die Nachricht (”ffentlich oder privat) nicht nochmals an dieses weitergereicht werden. Handelt es sich bei der aufgrund eines solchen Rekursionschecks aufgefallenen Nachricht um eine private Nachricht, sollte der Header den SystembetreiberInnen vorgelegt werden (Datenschutz: nicht die komplette Nachricht!), damit diese ein evtl. vorliegendes Pingpongrouting abstellen k”nnen. Hinweis: Es kann bei Žnderungen von Routwegen wegen neuer Beziehungen von Systemen untereinander vorkommen, daá zuf„llig und unsch„dlich ein System mehrfach in den Routestring ger„t. Auch gibt es schonmal durch Konfigurationsfehler, z.B. von Mailinglistenmechanismen, doppelte Eintr„ge in der ROT-Information. Implementationen sollten daher selber diesen Fehler vermeiden, ihn von anderen Implementationen jedoch erwarten. Sinnvoll ist hier - ZConnect 3.1 --------------------------------------------------------- 112 - z.B. eine Rekursionsdetektion erst bei dreifachem Eintrag. Die Pseudodomain "zer.sub.org" ist ein Hilfskonstrukt aus der Anfangszeit des Domainroutings im /Z-Netz. "zer.sub.org" war eine auf dem A-LINK-H-System verwaltete Domain, die alten Z3.8-Systemen die Teilnahme am Domainrouting erm”glichen sollte. Voraussetzung war eine geringe monatliche Zahlung und der Verzicht auf internationalen Datenverkehr. Da diese Bedingungen von vielen Systemen miáachtet wurden, ist die "zer.sub.org"-Regelung heute ohne jede protokollstrategische Bedeutung. Historie: D: [D3.0] M: [B5] Siehe auch: Points, Rekursionscheck - ZConnect 3.1 --------------------------------------------------------- 113 - Kennung: SIGNED +-----------------+ | Pflicht | Kurzbeschreibung: Nachricht wurde unterschrieben |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: SIGNED: [PGP] Funktion: Wenn die Nachricht mit PGP unterschrieben wurde, ist diese Headerinformation gesetzt (andere Parameter als PGP gibt es derzeit nicht) Wenn die Nachricht nicht zus„tzlich PGP-verschlsselt ist (CRYPT: PGP nicht gesetzt), ist die zugeh”rige Unterschrift in der PGP-SIG-Information zu suchen, andernfalls kann sie bei PGP Teil der verschlsselten Nachricht sein. Hinweis: Ein SIGNED: ohne Parameter ist nicht definiert aber auch nicht verboten. Tauchte eine solche Information auf, wrde sie besagen, daá die Nachricht nicht unterschrieben wurde und somit berflssig sein. # CrossPoint ab Version 3.1 verwendet # SIGNED: PGPCLEAR, wenn die Nachricht unterschrieben # ist, diese Unterschrift aber nicht mittels PGP-SIG # sondern als Klartext im Nachrichtenbody # transportiert wird. Dies ist eigentlich eine # unn”tige Abweichung vom Standard, da SIGNED: PGP im # Zusammenhang mit einem fehlenden PGP-SIG nichts # anderes als SIGNED: PGPCLEAR aussagt. Historie: D: [D3.1P]/[D3.1M] Siehe auch: CRYPT: PGP, PGP-SIG, Verschlsselung, Weiterleiten - ZConnect 3.1 --------------------------------------------------------- 114 - - ZConnect 3.1 --------------------------------------------------------- 115 - Kennung: SPERRFRIST +-----------------+ | Pflicht | Kurzbeschreibung: Frhester Zeitpunkt der Anzeige |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: SPERRFRIST: Funktion: Wie bei einer Pressemitteilung kann auch bei Nachrichten eine Sperrfrist gesetzt werden, also ein Datum, vor dem die Ver”ffentlichung nicht gestattet ist. Fr ZConnect-Programme heiát das, daá AnwenderInnen die so gekennzeichnete Nachricht erst zum angegebenen Zeitpunkt angezeigt bekommen drfen. Hinweis: Richtiger w„re es, eine mit Sperrfrist versehene Nachricht berhaupt erst zum spezifizierten Zeitpunkt an Endsysteme zuzustellen. Die Logik einer Sperrfrist bei Pressemitteilung w„re erst dann richtig und sinnvoll abgebildet, wenn SPERRFRIST fr private Nachrichten lediglich ein Hinweis fr die Empf„ngerin w„re und fr ”ffentliche Nachrichten die Zustellung an Points bzw. die Anzeige online erst ab dem angegebenen Ver”ffentlichungsdatum erfolgen wrde. ZConnect definiert all dies nicht. Wie beschrieben verbietet es die Anzeige, nicht aber die Zustellung vor einem bestimmten Zeitpunkt. Fr den Pointbetrieb ist dies unhaltbar, da der Anwenderin nicht zugemutet werden kann, Daten auf dem eigenen Massenspeicher zu halten, von deren Existenz sie nicht einmal informiert ist (eine sich strikt an ZConnect haltende Implementierung sollte sich mit dieser Argumentation auseinandersetzen und evtl. zumindest den Header der gesperrten Nachricht zusammen mit dem Sperrvermerk anzeigen und die L”schung zulassen). Historie: D: [D3.0] Siehe auch: Datumsangaben, Points, Weiterleiten - ZConnect 3.1 --------------------------------------------------------- 116 - - ZConnect 3.1 --------------------------------------------------------- 117 - Kennung: STAT +-----------------+ | Pflicht | Kurzbeschreibung: Status der Nachricht |>>Optional | +-----------------+ |**Nur einmal | |**Auch mehrfach | | Stabil | +-----------------+ |**Nur PM | +-----------------+ Syntax: STAT: AUTO | CTL | DES | EB | NOCIPHER | NOKOP | PGP | TRACE Funktion: Die derzeit acht Stati haben unterschiedliche Semantiken. Teilweise charakterisieren sie eine Nachricht (z.B. CTL fr Control-Nachricht), teilweise modifizieren sie deren Behandlung in bestimmten F„llen (z.B. NOKOP, welches das Verhalten von ZConnect-Software bei Crossposting „ndert), teilweise haben sie Konsequenzen fr eine etwaige Antwort (z.B. NOCIPHER legt fr eine Nachricht und die Antwort darauf fest, daá diese nicht in irgendeiner Form verschlsselt sein sollen) und teilweise beschreiben sie (redundant, vgl. CRYPT), daá die Nachricht verschlsselt ist (z.B. DES weist auf das Verschlsselungsverfahren "Data Encryption Standard" hin). STAT darf beliebig oft vorkommen, die unterschiedlichen Parameter von STAT drfen aber je nur einmal pro Header vorkommen (z.B. nicht zweimal die Information STAT: NOCIPHER). Sie sind unabh„ngig von Groá-/Kleinschreibung auszuwerten. Hinweis: Die m”glichen Stati sind auf den folgenden Seiten einzeln erl„utert, da eine gemeinsame Darstellung aufgrund der grunds„tzlich unterschiedlichen Typen von STAT-Headerinformationen nicht sinnvoll m”glich ist. Z.B. sind manche Stati nur bei PMs, andere auch bei ”ffentlichen Nachrichten einsetzbar. # Gem„á Dokumentation darf STAT beliebig oft # eingesetzt werden. Eine ZConnect-konforme Software # muá damit rechnen, daá DES und PGP gleichzeitig # gesetzt sind, ohne daá die Reihenfolge des Einsatzes # der Verschlsselungsverfahren erkennbar ist. Aus # diesem Grunde sind STAT: DES und STAT: PGP # angesichts der Existenz der CRYPT-Information (die # nur einmal vorkommen darf) auf keinen Fall mehr zu # verwenden, auch wenn sie hier aufgez„hlt werden # mssen, weil sie nie offiziell zurckgezogen wurden. Historie: D/M: siehe bei Einzelerl„uterungen - ZConnect 3.1 --------------------------------------------------------- 118 - Siehe auch: EB, ERSETZT, CONTROL, CRYPT, KOP, STAT: AUTO, STAT: CTL, STAT: DES, STAT: EB, STAT: NOCIPHER, STAT: NOKOP, STAT: PGP, STAT: TRACE, Verschlsselung, Weiterleiten - ZConnect 3.1 --------------------------------------------------------- 119 - Kennung: STAT: AUTO +-----------------+ | Pflicht | Kurzbeschreibung: Regelm„áige Nachricht |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: STAT: AUTO Funktion: Die so gekennzeichnet Nachricht ist eine regelm„áig aktualisierte und ins Netz geschickte Information. Identifiziert wird sie am Parameter der FILE- oder # der EMP-Kennung (keine Details in der Dokumentation # enthalten). Die BET-Information darf nicht ausgewertet werden. Kommt eine Nachricht mit STAT: AUTO und einer bestimmten FILE- oder EMP-Kennung an, so kann darauf z.B. mit der Umleitung in ein lokales Brett oder ein Verzeichnis reagiert werden. Die Dokumentation sieht vor, daá hierbei ggf. eine ERSETZT-Kennung eingefgt wird. Historie: D: [D3.1P] Siehe auch: STAT - ZConnect 3.1 --------------------------------------------------------- 120 - - ZConnect 3.1 --------------------------------------------------------- 121 - Kennung: STAT: CTL +-----------------+ | Pflicht | Kurzbeschreibung: Steuernachricht |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: STAT: CTL Funktion: Die so gekennzeichnete Nachricht ist eine Steuernachricht. Diese darf, auch wenn sie defekt ist, niemals an die Absenderin zurckgeschickt werden. Hinweis: STAT: CTL kommt in TRACE-Antworten zum Einsatz. Da solche auch mit STAT: TRACE versehen sind, ist STAT: CTL hier redundant. Darberhinaus wird STAT: CTL derzeit nur fr Nachrichten mit CONTROL-Headerinformation eingesetzt. # Fr die Zukunft sind weitere Anwendungen denkbar. # Z.B. lieáe sich die Programmierung von ZConnect # orthogonalisieren, wenn alle Nachrichten, die # Steuercharakter haben und nicht zurckgeschickt # werden drfen, eine STAT: CTL Headerinformation # erhalten wrden (also z.B. auch eine Nachricht mit # ERR-Kennung). Dann w„re mit einer einzigen Prfung # das Verhalten der Software steuerbar. Historie: D: [D3.0] Siehe auch: CONTROL, STAT, TRACE - ZConnect 3.1 --------------------------------------------------------- 122 - - ZConnect 3.1 --------------------------------------------------------- 123 - Kennung: STAT: DES +- - - - - - - - -+ | Pflicht | Kurzbeschreibung: Nachricht ist mit DES verschlsselt |>>Optional | +- - - - - - - - -+ |>>Nur einmal | VERALTET Auch mehrfach | Stabil | +- - - - - - - - -+ |>>Nur PM | +- - - - - - - - -+ Syntax: STAT: DES Funktion/Hinweis: Zeigt an, daá die Nachricht mit dem DES (Data # Encryption Standard) verschlsselt wurde. Diese # Headerinformation ist durch die aktuellere # CRYPT-Kennung ersetzt. [D3.1Z] untersttzt diese # Auffassung, indem sie STAT: DES nicht mehr erw„hnt. Historie: D: [D3.0] A: [D3.1Z] Siehe auch: *CRYPT*, STAT, Verschlsselung - ZConnect 3.1 --------------------------------------------------------- 124 - - ZConnect 3.1 --------------------------------------------------------- 125 - Kennung: STAT: EB +-----------------+ | Pflicht | Kurzbeschreibung: Nachricht ist eine Empfangsbest„tigung |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ |>>Nur PM | +-----------------+ Syntax: STAT: EB Funktion: Diesen Status fhrt eine automatisch generierte Empfangsbest„tigung, die auf dem Weg zur Best„tigungsempf„ngerin ist. Historie: D: [D3.0] Siehe auch: *EB*, STAT - ZConnect 3.1 --------------------------------------------------------- 126 - - ZConnect 3.1 --------------------------------------------------------- 127 - Kennung: STAT: NOCIPHER +-----------------+ | Pflicht | Kurzbeschreibung: Antworten auf unverschlsselte Nachricht |>>Optional | drfen nicht verschlsselt werden +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ |>>Nur PM | +-----------------+ Syntax: STAT: NOCIPHER Funktion: STAT: NOCIPHER hat eine doppelte Bedeutung: Zum einen sagt diese Headerinformation aus, daá die Nachricht, deren Header sie enth„lt, nicht verschlsselt ist. Zum anderen, und das ist die im Vordergrund stehende Bedeutung, wird fr Antworten jede Verschlsselung untersagt. Hinweis: Es ist zwar ein guter Gedanke, KommunikationspartnerInnen formalisiert den Wunsch mitteilen zu k”nnen, daá die Antwort unverschlsselt sein sollte. Dies kann der antwortenden Person aber unm”glich vorgeschrieben werden. ProgrammiererInnen von BenutzerInnenschnittstellen sollten sich hierber Gedanken machen. Historie: D: [D3.1P]/[D3.1M] Siehe auch: STAT, Points, Verschlsselung - ZConnect 3.1 --------------------------------------------------------- 128 - - ZConnect 3.1 --------------------------------------------------------- 129 - Kennung: STAT: NOKOP +-----------------+ | Pflicht | Kurzbeschreibung: Private Empf„ngerinnen der Nachricht |>>Optional | drfen nirgendwo in KOPs +-----------------+ gewandelt werden |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: STAT: NOKOP Funktion: STAT: NOKOP wirkt auf die Umwandlung von EMPs zu KOPs, z.B. bei der Auftrennung privater Crosspostings. Ist STAT: NOKOP gesetzt, drfen private EMPs nicht in KOPs gewandelt werden. Auf ”ffentliche KOPs hat dieses Flag keinen Einfluá. Hinweis: Die Auswirkung von STAT: NOKOP ist bei KOP detailliert erl„utert. Historie: D: [D3.1M] Siehe auch: KOP, STAT - ZConnect 3.1 --------------------------------------------------------- 130 - - ZConnect 3.1 --------------------------------------------------------- 131 - Kennung: STAT: PGP +- - - - - - - - -+ | Pflicht | Kurzbeschreibung: Nachricht ist mit PGP verschlsselt |>>Optional | +- - - - - - - - -+ |>>Nur einmal | VERALTET Auch mehrfach | Stabil | +- - - - - - - - -+ |>>Nur PM | +- - - - - - - - -+ Syntax: STAT: PGP Funktion/Hinweis: Dieser Status ist durch das aktuelle PGP-Konzept # nicht mehr aktuell. CRYPT: PGP tritt an seine # Stelle. [D3.1Z] best„tigt diese Auffassung. Historie: D: [D3.0] A: [D3.1Z] Siehe auch: *CRYPT*, STAT, Verschlsselung - ZConnect 3.1 --------------------------------------------------------- 132 - - ZConnect 3.1 --------------------------------------------------------- 133 - Kennung: STAT: TRACE +-----------------+ | Pflicht | Kurzbeschreibung: Nachricht ist eine Antwort auf eine |>>Optional | TRACE-Kennung +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ |>>Nur PM | +-----------------+ Syntax: STAT: TRACE Funktion: STAT: TRACE kennzeichnet eine TRACE-Antwortmail. Systeme auf dem Routeweg einer Nachricht erzeugen als Antwort auf die TRACE-Anforderung Nachrichten eines wie folgt definierten Formats: STAT: TRACE gesetzt STAT: CTL gesetzt BEZ: verweist auf Message-ID der ausl”senden Nachricht mit TRACE-Headerkennung BET: enth„lt den Text "Trace-Info " und danach die Message-ID der ausl”senden Nachricht Nachrichtenk”rper enth„lt eine parsebare Liste der Systeme und der Empf„ngerinnen, an die die Nachricht geroutet wurde Das Format der Liste sieht pro System, an das geroutet wird, einen Abschnitt vor. Innerhalb dieses Abschnitts ist dann fr jede Empf„ngerin eine Zeile einzutragen. Systemname wie Empf„ngerinnennamen mssen durch spitze Klammern ('<', '>') geklammert sein. Abschnitte beginnen mit einer Zeile, an deren erster Stelle ein Non-Whitespace steht. Zeilen mit Empf„ngerinneneintr„gen hingegen beginnen mit einem Whitespace (Leerzeichen oder Tabulator). - ZConnect 3.1 --------------------------------------------------------- 134 - Beispiel fr eine korrekte Nachricht mit STAT: Headerinformation: EMP: SYSOPTEAM@bingo.comlink.de ABS: Zerberus@cl-hh.comlink.de BEZ: 12345678@sysopteam.bingo.comlink.de BET: Trace-Info 12345678@sysopteam.bingo.comlink.de MID: 42@cl-hh.comlink.de STAT: TRACE STAT: CTL EDA: 19950401000000W+0 An System gingen die folgenden EMPs: An System gingen die folgenden EMPs: Historie: D: [D3.1P] Siehe auch: STAT, STAT: CTL, TRACE - ZConnect 3.1 --------------------------------------------------------- 135 - Kennung: STICHWORT +-----------------+ | Pflicht | Kurzbeschreibung: Stichwort zum Nachrichteninhalt |>>Optional | +-----------------+ | Nur einmal | |>>Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: STICHWORT: Funktion: Die Absenderin kann pro STICHWORT-Kennung ein Stichwort zum Nachrichteninhalt angeben. Die beliebig vielen Stichworte k”nnen dann z.B. bei Suchfunktionen ausgewertet werden. Hinweis: [D3.1Z] definiert, daá Groá-/Kleinschreibung nicht # ausgewertet werden darf, und nur die Zeichen von A-Z # zul„ssig sind. Definiert mensch das Leerzeichen als zul„ssiges Zeichen im Stichwort selbst (und abgesehen von [D3.1Z] widerspricht dem derzeit nichts), w„re eine Stichwortzeile mit mehreren Begriffen legitim. Mittlerweile gibt es aber keine bekannte Software mehr, die sich diese Interpretation leistet. Aufgrund des Einsatzes „lterer Software (z.B. CrossPoint 3.0x) ist jedoch mit solchen Abweichungen vom Standard zu rechnen. Historie: D: [D3.1P] A: [D3.1Z] Siehe auch: ZUSAMMENFASSUNG - ZConnect 3.1 --------------------------------------------------------- 136 - - ZConnect 3.1 --------------------------------------------------------- 137 - Kennung: TELEFON +-----------------+ | Pflicht | Kurzbeschreibung: Telefonnummer(n) der Absenderin |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: TELEFON: [;]* Funktion: Die Absenderin kann in dieser Headerinformation ihre Telefonnummer(n) in internationaler Schreibweise. Diese Notation folgt folgender Syntax: [V|F|B]++--[Q] 'V' steht dabei fr "Voice", 'F' fr "Fax" und 'B' fr "Box". Mindestens eine der Kennungen ist anzugeben, es k”nnen aber auch alle gleichzeitig (in beliebiger Reihenfolge) angegeben werden. Ist an der Leitung ein Anrufbeantworter angeschlossen, kann dies durch das optional nachgestellte 'Q' symbolisiert werden. Sollen mehrere Nummern angegeben werden, so werden diese jeweils durch ein Semikolon getrennt. Statt des Semikolons ist auch ein Leerzeichen gestattet. Beispiel: TELEFON: VF+49-40-6910419Q B+49-40-6912028 Hinweis: Es sollten als Trennzeichen zwischen den Rufnummern # beliebige Whitespaces erwartet werden. Fr neue # Dienste, wie z.B. SCall der Deutschen Telekom, ist # zwar nicht per Wahl eine Kennung vereinbart worde, # fr solche und „hnliche Dienste wurde aber das "P" # fr "Pager" vorgeschlagen und mangels Protesten fr # eingefhrt erkl„rt ([B6]). Nur sehr wenige Programme testen die ZConnect-Konformit„t der Parameter von TELEFON. Dies sollte fr ProgrammiererInnen Anlaá sein, es korrekter zu handhaben, umgekehrt aber nicht von korrekten TELEFON-Headerinformationen auszugehen. Historie: D: [D3.0] Siehe auch: ORGANISATION, POST, Weiterleiten - ZConnect 3.1 --------------------------------------------------------- 138 - - ZConnect 3.1 --------------------------------------------------------- 139 - Kennung: TRACE +-----------------+ | Pflicht | Kurzbeschreibung: Routinganalyse |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: TRACE: Funktion: Durch die Angabe der TRACE-Headerinformation kann die Absenderin jedes ZConnect-System auf dem Routeweg auffordern, eine Information ber dessen Verfahren mit der Nachricht an die angegebene Adresse zu senden. Das Format der Antwort der Systeme auf dem Routeweg ist vorgeschrieben und bei STAT: TRACE beschrieben. Hinweis: Es ist nicht vorgesehen, daá TRACE ohne Argument angegeben wird. Mensch k”nnte sich aber gut vorstellen, daá in einem solchen Fall einfach die Adresse der Absenderin genommen werden kann, aktuelle Implementationen handhaben dies aber definitiv nicht so{12}. Die Dokumentation weist darauf hin, daá der Header sparsam eingesetzt werden und auch nicht von jeder Benutzerschnittstelle aus erzeugt werden k”nnen soll. Historie: D: [D3.1P] M: [D3.1Z] (Klarstellung) Siehe auch: *STAT: TRACE*, Adressen, Weiterleiten - ZConnect 3.1 --------------------------------------------------------- 140 - - ZConnect 3.1 --------------------------------------------------------- 141 - Kennung: TYP +-----------------+ | Pflicht | Kurzbeschreibung: Typ des Nachrichtenk”rpers |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ |**Nur PM | +-----------------+ Syntax: TYP: Funktion: Die TYP-Information gibt Auskunft ber die Beschaffenheit des Nachrichtenk”rpers. Definierte Bedeutung haben die Kennungen "BIN" (fr Bin„rnachricht), "TRANSPARENT" (fr Nachrichtenk”rper, in denen keine Umlaute gewandelt werden drfen), "MIME" (fr Nachrichten, die nach dem MIME-Standard aufgebaut sind - bitte nicht benutzen, Begrndung siehe bei Headerinformation MIME) und "RFC1563" (siehe vorige Klammerbemerkung). Darberhinaus sind aber beliebige weitere Kennungen erlaubt (z.B. "TIFF", "GIF", "WAV", "ZIP"). Ist die angegebene Kennung dem ausgebenden Programm unbekannt, wird die Nachricht wie eine normale Bin„rnachricht behandelt. Ist keine TYP-Information angegeben, handelt es sich um eine Textnachricht. Hinweis: Aktuell wird eine Einfhrung der MIME-Kodierung diskutiert. An dieser Stelle wird sich also fr ZConnect > 3.1 eine gr”áere Žnderung ergeben. Es ist in diesem Kontext u.U. damit zu rechnen, daá manche TYP-Informationen nur in PMs erlaubt sind. # Die TYP-Information sagt gleichzeitig etwa ber den # Nachrichten- und den Nachrichtenk”rpertyp aus. Genau # diese Verquickung ist dafr verantwortlich, daá fr # textuelle Nachrichtentypen, deren K”rper aber z.B. # Steuerinformationen fr "enriched Text" (vgl. # [RFC1563]) enthalten, als Bin„rnachrichten # gehandhabt werden mssen. Hier w„re eine # syntaktische Trennung, die die semantische # nachvollzieht, sinnvoll. Historie: D: [D3.0] Siehe auch: CHARSET, *MIME*, Kapitel "MIME", Zeichens„tze - ZConnect 3.1 --------------------------------------------------------- 142 - - ZConnect 3.1 --------------------------------------------------------- 143 - Kennung: VER +-----------------+ | Pflicht | Kurzbeschreibung: Vertreterinlokalisierung |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ |>>Nur PM | +-----------------+ Syntax: VER: Funktion: Insbesondere private Nachrichten werden h„ufig per Vertreterin an den Point weitergeleitet. Dies kann unter Umst„nden auf einem ganz anderen System geschehen als jenem, an dem der Point angeschlossen ist. Verbreitet ist z.B. der "Nachsendeauftrag", wenn ein Point das System wechselt. Die VER-Information nimmt dann die Adresse auf, an die die Zustellung ursprnglich erfolgte. Hinweis: [D3.1Z] definiert VER abweichend als auch mehrfach # m”glich. Zur Begrndung wird richtigerweise # angemerkt, daá eine Weiterleitung durch # Vertreterinnen ebenfalls mehrfach erfolgen kann. Historie: D: [D3.1P] A: [D3.1Z] Siehe auch: Adressen, Weiterleiten - ZConnect 3.1 --------------------------------------------------------- 144 - - ZConnect 3.1 --------------------------------------------------------- 145 - Kennung: VIA +-----------------+ | Pflicht | Kurzbeschreibung: Bestimmung von Routeweg und -zeit |**Optional | +-----------------+ | Nur einmal | |>>Auch mehrfach | |>>Stabil | +-----------------+ |>>Nur PM | +-----------------+ Syntax: VIA: Funktion: VIA erm”glicht im Gegensatz zu ROT, die Stationen auf dem Routeweg einer Nachricht mit einem Zeitstempel zu versehen, was dem Aufspren von Datensenken oder Verz”gerungsgrnden dienen soll.. Die case-insensitive Routinginformation besteht aus der Systemzeit im ZConnect-Format (wie bei EDA), einem anschlieáenden '@' und der Systemadresse. Z.B. also VIA: 19950401000000W+0@bingo.comlink.de Die VIA-Information muá auf jedem ZConnect-System fr private Nachrichten erzeugt werden. Aus Grnden der Abw„rtskompatiblit„t wurde VIA jedoch nicht als Pflichtinformation eingefhrt. Es ist in ZConnect nicht vorgesehen, daá neue Pflichtinformationen eingefhrt werden. Die erste VIA-Information wird vom ersten ZConnect 3.1 kompatiblen System/Point auf dem Routeweg eingefgt. Bei dieser ersten VIA-Information im Header ist die Systemzeit fest auf 0:00 Uhr des jeweiligen Tages zu setzen (Datenschutz). Hinweis: Die obenstehende Funktionsweise ist eine # Interpretation, die durch eine g„nzlich unklare # Beschreibung in der Dokumenation notwendig ist. Aus # dem Originaltext wird nicht klar, welche Funktion # und welche Funktionsweise VIA hat. Die # VIA-Information wurde auf dem /Z-NETZ-Treffen 1994 # in Hamburg beschlossen, Nachfragen bei den daran # Beteiligten hinsichtlich der Intention von VIA # ergaben eindeutig oben dargestellte Sichtweise [B7]. Historie: D: [B8] M: [B7] (Klarstellung) Siehe auch: ROT, Datenschutz, Weiterleiten - ZConnect 3.1 --------------------------------------------------------- 146 - - ZConnect 3.1 --------------------------------------------------------- 147 - Kennung: WAB +-----------------+ | Pflicht | Kurzbeschreibung: Adresse der Weiterleitenden |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: WAB: Funktion: Beim manuellen, passiven Weiterleiten wird der ABS nicht ver„ndert und die Weiterleitende in die WAB-Headerinformation eingetragen. Beim aktiven Weiterleiten wird eine vorhandene WAB-Information hingegen gel”scht. Der WAB-Parameter kann auch mit einem Realnamen versehen sein. Hinweis: Bei der Wandlung von ZConnect- nach Z3.8-Datenformat wird laut „lterer Dokumentation (die Z3.8-Regelungen sind mit [D3.1M] aus ZConnect ausgegliedert worden) die Weiterleitabsenderin der ZConnect-Nachricht als Absenderin der Z3.8-Nachricht eingesetzt. Da noch immer an wenigen Stellen im Netz tats„chlich Gatewaysoftware die strikt verbotene Wandlung ZConnect->Z3.8->ZConnect vornimmt, kann dies sehr verwirrend wirken und sollte von GatewayprogrammiererInnen berdacht werden. Die bei ZConnect getroffene Unterscheidung zwischen Point und System hat u.a. die Auswirkung, daá die meiste Systemsoftware die Absenderinnenadresse der beim System angeschlossenen Points prft und ggf. ersetzt. Wenn also der Point A@System als B@System schreibt, ersetzt die Systemsoftware ungefragt B@System durch A@System. Dies soll Miábrauch, insbesondere das Schreiben unter falscher Adresse verhindern. Das passive Weiterleiten definiert, daá hierbei die ABS-Information und beinahe alle anderen Headerinformationen ebenfalls erhalten bleiben, w„hrend eine WAB-Information hinzugefgt wird. Wenn A@System also als B@System schreibt, dann ist zu prfen, ob nicht WAB: A@System angegeben und die fremde ABS-Angabe somit legitim ist. Einige Systemprogramme machen dies zum aktuellen Zeitpunkt leider falsch, teilweise wird sogar bei der Ersetzung der Realname der Absenderin mit der Adresse der Weiterleiterin gemischt, weil angesichts geduldeter unterschiedlicher Realnamen fr dieselbe Mailadresse dieser nicht mitersetzt wird. - ZConnect 3.1 --------------------------------------------------------- 148 - Historie: D: [D3.0]/[D3.1P] M: [D3.1M] Siehe auch: ABS, OAB, Adressen, Weiterleiten - ZConnect 3.1 --------------------------------------------------------- 149 - Kennung: ZUSAMMENFASSUNG +-----------------+ | Pflicht | Kurzbeschreibung: Einzeilige Nachrichtenkurzfassung |>>Optional | +-----------------+ |>>Nur einmal | | Auch mehrfach | | Stabil | +-----------------+ | Nur PM | +-----------------+ Syntax: ZUSAMMENFASSUNG: Funktion: Die Absenderin kann ihre Nachricht in einer Zeile zusammenfassen. Pointprogramme k”nnen dies z.B. in einer šbersichtsdarstellung oder fr Suchoperationen nutzen. Hinweis: [D3.1Z] verweist auf die Gefahr, daá durch eine umfangreiche Zusammenfassung die Grenzen fr Nachrichtenl„ngen oder deren Abrechnung umgangen werden k”nnten. Vorgeschlagen wird daher eine Gr”áenbegrenzung auf 10% der Gesamtnachrichtenl„nge, oberhalb welcher die bearbeitende Software das Routen ablehnen kann. Jede beliebige frei definierte Headerinformation birgt jedoch die Gefahr des Miábrauchs des Headers zum Transport von Inhaltsdaten - eine Implementation, die solchen Miábrauch ausschlieáen soll, muá das Problem also an grunds„tzlicherer Stelle l”sen, z.B. durch fest vorgegebene Maximalgr”áen oder -verh„ltnisse von Header und Nachrichtenk”rper. Historie: D: [D3.1P] Siehe auch: STICHWORT, Frei definierbare Headerzeilen ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - ZConnect 3.1 --------------------------------------------------------- 150 - - ZConnect 3.1 --------------------------------------------------------- 151 - _3.3.2.2. Frei definierbare Headerzeilen_ Eine offizielle ZConnect-Headerkennung wird niemals mit "X-" beginnen. Dies ist der fr lokale Erweiterungen reservierte Kennungspr„fix, den jede Software beliebig erzeugen und auch verschicken darf. Manche Programme bertragen hierin Informationen, die auf der Gegenseite ausgewertet werden, wenn dort mit dem gleichen Programm gearbeitet wird (z.B. X-REPLY-LEVEL bei einigen Pointprogrammen fr die Anzeige der Kommentarbaumtiefe). Frei definierte Headerzeilen k”nnen natrlich auch zum Transport von Daten miábraucht werden, die normalerweise im Nachrichtenk”rper bef”rdert und somit z.B. kostenpflichtig sein wrden. Soll diese Problematik gel”st werden, sind z.B. feste maximale Headergr”áen oder Gr”áenverh„ltnisse Header/Nachrichtenk”rper einstellbar zu machen. Dieses Problem kann nur durch lokale Einstellungsm”glichkeiten gel”st werden, darf dabei aber keinesfalls so auf die Implementierung abgebildet werden, daá die nicht vorhandene Gr”áenbeschr„nkung, wie sie der ZConnect-Standard vorschreibt, ausgehebelt wird. Es ist zu beachten, daá fatalerweise einige, definitiv fehlerhafte aber im Einsatz befindliche Gateways den Transport von Headerzeilen mit "X-"-Pr„fix nicht garantieren. _3.3.2.3. Headerzeilen aus anderen Datenformaten_ _3.3.2.3.1. UUCP_ Headerkennungen, die mit dem Pr„fix "U-" versehen sind, sind sog. "UUCP-Header". Dies beschreibt Headerzeilen nach RFC822/1036 und ggf. deren Nachfolgerinnen. In diesen Headerzeilen k”nnen Informationen aus dem Usenet unbeschadet durch ZConnectsysteme transportiert werden. Sie sollten aber nur fr Kennungen eingesetzt werden, zu denen es bei ZConnect wirklich keine Entsprechung gibt. Beispielsweise sollte "Date: Thu, 12 Jan 1987 PDST" nicht als "U-DATE: ..." transportiert, sondern nach EDA gewandelt werden (auch wenn dadurch vielleicht die ursprngliche Notation des Datums nicht wiederherstellbar ist - die transportierte Information ist es auf jeden Fall). "Lines: 256" hingegen wrde als "U-LINES: 256" sinnvoll transportiert werden k”nnen. _3.3.2.3.2. Fido_ Mit dem Pr„fix "F-" beginnen Headerkennungen, die direkt aus dem FTS0001-Format oder ggf. dessen Nachfolgern und anderen Formaten aus der Fido-FTS/FSC-Welt bernommen wurden. Es ist an dieser Stelle nicht sinnvoll, die Erfordernisse von Fido-ZConnect-Gateways zu beschreiben. Zu beachten ist aber, daá es die aus dem Fido kommende "Kludgeline", die in [D3.1M] als "^A" (ASCII 1) beschreibt, in ein einfaches "F-" ohne dahinter stehenden weiteren Buchstaben bersetzt wird. _3.3.2.3.3. Z3.8_ Ab [D3.1M] werden Nachrichten im Z3.8 Format als ZConnect-fremd betrachtet und somit nicht mehr im Rahmen von ZConnect beschrieben. Headerzeilen aus Z3.8 erhalten den Pr„fix "ZNETZ-", mehr wird hierzu nicht mehr ausgesagt. - ZConnect 3.1 --------------------------------------------------------- 152 - _3.3.2.4. Headerzeilenvorhersage_ Die PGP-Integration in ZConnect schreibt vor, daá Headerinformationen, die durch Verschlsselungsprogramme beeinfluát werden (z.B. CHARSET, welcher nicht mehr gilt, wenn der Nachrichtentext z.B. durch PGP in das Base64-Alphabet bersetzt wird), mit einem vorangestellten CRYPT-CONTENT- weitertransportiert werden mssen. Wird also eine neue Headerinformation XYZ eingefhrt, deren Informationsgehalt nach einer Verschlsselung nicht mehr gegeben oder falsch und nicht rekonstruierbar (wie etwa LEN) ist, so gilt automatisch auch CRYPT-CONTENT-XYZ als eingefhrt. Es wird voraussichtlich bald ber eine komplette Einbindung des MIME-Standards in ZConnect abgestimmt werden. Hier wird eine Flut von neuen Headerinformationen n”tig sein. Die Diskussion hierzu ist in /T-NETZ/ZCONNECT/DISKURS mitzuverfolgen. Die einschl„gigen RFCs lauten 1521, 1522 und 1563. _3.4. Zusammenh„nge_ Dieser Abschnitt beschreibt technische Verfahren und Besonderheiten ZConnects. Neben Datenschutzaspekten werden Rekursionscheck, Weiterleitungsmechanismen, Probleme der Gemischtadressierung, Veschlsselung und die Besonderheiten von Points bei ZConnect angeprochen. _3.4.1. Informationelle Selbstbestimmung und Datenschutz_ Der Datenschutzgedanke basiert auf dem Grundrecht zur informationellen Selbstbestimmung. Bei der Betrachtung von ZConnect muá Datenschutz daher nicht nur von gesetzlichen Regelungen ausgehen (die aber notwendig sind, um SystembetreiberInnen die M”glichkeit zu geben, im Gegensatz z.B. zu Fido-SystembetreiberInnen{13}, datenschutzrechtskonform zu arbeiten), sondern schon die ProgrammiererInnen auf sensiblen Umgang mit der Privatsph„re der NutzerInnen verpflichten. Hier spielt ZConnect eine Vorreiterrolle, die im Gremium nicht unumstritten ist (zuletzt bei der Diskussion um die Einfhrung der VIA-Headerinformation, s.u.). Es handelt sich jedoch um ein handfestes Argument fr den Einsatz des ZConnect-Protokolls nicht nur bei privaten Vernetzungsprojekten. Daher mssen die bereits vorhandenen Regeln strikt eingehalten (und daher hier nochmal # zusammengefaát), und es sollte die šbereinkunft getroffen werden, im # Zweifelsfall fr die informationelle Selbstbestimmung der UserInnen # zu votieren. _3.4.1.1. Zeitangaben_ Zeitangaben in Nachrichten erlauben ohne technische Notwendigkeit die Erstellung eines BenutzerInnenprofils hinsichtlich Netzanrufverhalten u.„.. Die mit Zeiangaben versehenen Headerinformationen ZConnects sind also Gegenstand besonderer Betrachtung. _3.4.1.1.1. EDA_ Jede Nachricht im ZConnect-Datenformat ist mit einem Erstellungsdatum versehen. Dieses Datum sagt ber die (z.T. berflssige) technische - ZConnect 3.1 --------------------------------------------------------- 153 - Information hinaus etwas ber die Gewohnheiten der Absenderin aus. Auf dem Routeweg kann ein Anwenderinnenprofil aufgrund der Erstellungsdaten von Nachrichten erstellt werden. Die Anwenderin kann dies durch Verschlsselung nicht verhindern, auch w„re dies bei ”ffentlichen Nachrichten kein einsetzbares Mittel. Grunds„tzlich muá sich die Anwenderin bewuát sein, daá ein aus ”ffentlichen Nachrichten gewonnenes BenutzerInnenprofil nicht mit Datenschutzbestimmungen kollidiert. Umso wichtiger ist es, ihr alle M”glichkeiten in die Hand zu geben, vermeidbare Informationen (sofern sie denn vermieden werden sollen) zurckzuhalten. Dies geschieht im Zusammenhang mit dem Erstellungsdatum, indem optional der Uhrzeitanteil weggelassen wird (bei privaten wie bei ”ffentlichen Nachrichten); diese Detailinformation ist fr den Transport nicht von Bedeutung, behindert also nicht die Funktionalit„t ZConnects. _3.4.1.1.2. VIA_ Die VIA-Headerinformation erneuert das fr EDA gel”ste Problem: Sortiert das erste System auf dem Weg der Nachricht sofort nach dem Netcall ein, l„át dies bei Store- and Forward Netzen, fr welche ZConnect eingesetzt wird, Rckschlsse auf das Netcallverhalten der Anwenderin zu. # Anders als bei EDA l„át sich diese Schwierigkeit nicht dadurch aus # dem Weg r„umen, daá das erste System den Zeitanteil der # Datumsangabe fest auf 0 Uhr setzt, wie ZConnect dies vorsieht. Denn # zum einen liegt dies nicht im Einfluábereich der Absenderin (auch # der Verzicht auf Datenschutz geh”rt zur informationellen # Selbstbestimmung), zum anderen kann auch das zweite System - z.B. # in einem LAN - unmittelbar nach dem Netcall der Absenderin # einsortieren und die Schutzfunktion hinf„llig machen. # Eine Statusinformation STAT: NOVIA w„re hilfreich. _3.4.1.2. KOP_ ZConnect kennt seit einiger Zeit das Flag STAT: NOKOP, welches das Umwandeln privater Empf„ngerinnen in die rein informativen KOP-Headerinformationen unterbindet. Bei ”ffentlichen Nachrichten bleibt dies aber ohne Wirkung. Es ist nicht zu vermeiden, daá ver”ffentlichte Informationen fr die ™ffentlichkeit auswertbar sind. # Jedoch sollten die BenutzerInnen soweit wie m”glich bei der # Entstehung ”ffentlicher Daten die Kontrolle haben, also auch # hierbei STAT: NOKOP mit entsprechenden Auswirkungen setzen k”nnen. # Dies bedrfte beim derzeitigen Stand jedoch einer Žnderung durch # das Gremium. _3.4.1.3. Wechsel von privaten Nachrichten ber Netzgrenzen hinweg_ Soweit anhand der Zieladresse feststellbar, sollte die Software den UserInnen mitteilen, wenn sie eine Nachricht in ein "Fremdnetz" schicken. Diese Spezifikation berfordert aber einen technischen Standard. Es ist also darber nachzudenken, ob z.B. eine einfache Standardverschlsselung fr private Nachrichten den Protokollcharakter festigen und unabh„ngig von abstrakten Netzgebilden bewahren kann. - ZConnect 3.1 --------------------------------------------------------- 154 - # Bereits eine primitive, synchrone Verschlsselung (z.B. XOR 1 # byteweise) wrde nach bundesdeutschem Datenschutzrecht dafr # sorgen, daá ein Geheimhaltungsinteresse von dem/der Absender/in # unterstellt wird, dessen Unterlaufen - und sei es noch so einfach - # strafbar ist ([Netzrecht]). Die Verschlsselung máte natrlich auf ausdrcklichen Wunsch des/der Anwender/in abschaltbar sein. _3.4.2. Dupe- und Rekursionscheck_ Dupe- bzw. Rekursionscheck erfolgt, um das Netz nicht mit Nachrichten zu belasten, die aufgrund technischer Fehler mehrfach dasselbe System passieren oder erneut auf den Routeweg gelangt sind. _3.4.2.1. Dupecheck anhand der Message-IDs_ Ein routendes System muá anhand der Message-IDs ”ffentlicher Nachrichten einen Dupecheck durchfhren, bei privaten Nachrichten ist dies untersagt. Fr eine Message-ID gilt per Definition, daá sie innerhalb von zwei Jahren nur einmal weltweit erzeugt wird. Hat eine Nachricht eine Message-ID, welche innerhalb der letzten beiden Jahre bereits das routende System passiert hat, handelt es sich um eine zu l”schende Rekursion. Nun ist es unrealistisch, die Message-IDs von zwei Jahren aufzubewahren und zum Dupecheck heranzuziehen. Es wird empfohlen, die IDs von 90 Tagen aufzubewahren und Nachrichten, die „lter als 90 Tage sind, per default als "zu alt" zu l”schen. Tats„chlich erzeugen auf einem groáen System bereits die Message-IDs von 90 Tagen groáe Probleme - weniger aufgrund des nicht zu untersch„tzenden Platzbedarfs, vielmehr aufgrund der ben”tigten Rechenzeit fr den Dupecheck selber. Manche Software fhrt diesen Check tats„chlich linear durch. Andere Implementierungen verwenden eine Art Hashverfahren ohne Kollisionsbehandlung, also mit m”glicherweise zu unrecht als Dupe gel”schten Nachrichten. Im Kapitel "Softwaretechnische Vorschl„ge" ist ein leistungsf„higes, vollst„ndiges Hashverfahren ohne systembedingte Fehler beschrieben. _3.4.2.2. Rekursionscheck anhand des Routepfads (ROT)_ Ein System, an welches eine Nachricht (privat oder ”ffentlich) weitergereicht werden soll, darf noch nicht im Routepfad der Nachricht stehen. Andernfalls ist die Nachricht nicht weiterzureichen; betrifft dies eine private Nachricht, so ist die Systembetreuung zu informieren (vgl. Spezifikation von ROT), um ein eventuelles Ping-Pong-Routing abzustellen. Bei privaten Nachrichten ist aber zu beachten, daá es aufgrund von Routingumstellungen durchaus ohne sch„dliche Auswirkung passieren kann, daá ein System mehrfach im ROT-String auftaucht. Es wird daher empfohlen, frhestens bei der dritten Rekursion die Systembetreuung einzuschalten. - ZConnect 3.1 --------------------------------------------------------- 155 - _3.4.3. Weiterleiten_ ZConnect kennt mehrere Formen des Weiterleitens, die davon abh„ngen, wer mit welcher Intention weiterleitet. Eine Žnderung am Nachrichtenk”rper darf dabei nur mithilfe eines Kommentars (KOM-Headerinformation) erfolgen. Die Message-ID muá bei ”ffentlichen Nachrichten beim Weiterleiten immer ver„ndert werden, um die weitergeleitete Nachricht vor einer L”schung als vermeintlicher Dupe zu bewahren. Die an dieser Stelle aktuellste Dokumentation [D3.1Z] unterscheidet automatisches, manuelles und Netzwerk-Weiterleiten (letzteres ist eigentlich eher ein Umleiten). _3.4.3.1. Manuelles Weiterleiten_ Fr das manuelle Weiterleiten einer Nachricht gibt es zwei Verfahren, die bei ZConnect bisher nur dem Verfahren nach unterschieden werden, ohne ihnen unterschiedliche Bedeutungen zuzuweisen. Die Verfahren unterscheiden sich wesentlich in der Behandlung der ABS-Headerinformation und k”nnen als *aktives* bzw. *passives* *Weiterleiten* umschrieben werden. In beiden F„llen sind aber folgende Schritte auszufhren: 1. Die Weiterleitung bekommt eine eigene Message-ID (diejenige der Originalnachricht darf also nicht bernommen werden, auch wenn dies bei privaten Nachrichten ohne Auswirkung w„re) 2. ROT wird gel”scht und neu erzeugt, als ob es sich um eine neu erstellte Nachricht handeln wrde 3. Existieren noch keine OEM-Headerinformationen, so werden die EMP-Headerinformationen in OEMs umgewandelt 4. Existiert noch keine O-EDA-Headerinformation, so wird aus der EDA-Headerinformation O-EDA, und es wird eine neue EDA-Information erzeugt. Dies ist immer erforderlich, um die Entsorgung einer als ”ffentliche Nachricht weitergeleiteten Nachricht als "zu alt" zu verhindern (vgl. MID, Rekursionscheck) 5. Sind CONTROL-, ERR-, ZNETZ-CONV-*, TRACE-, VER-, STAT-, VIA- und/oder EB-Headerinformation vorhanden, werden sie jeweils gel”scht Dann wird je nach Form des Weiterleitens unterschiedlich vorgegangen. Da es hierbei in der Vergangenheit immer wieder Interpretationsschwierigkeiten gegeben hat, werden die beiden Formen hier als aktives und passives Weiterleiten benannt. - ZConnect 3.1 --------------------------------------------------------- 156 - _3.4.3.1.1. Passives Weiterleiten_ Das passive Weiterleiten wird definiert als Ausdruck fr das Anliegen der Weiterleiterin, einer Nachricht eine neue Richtung zu geben, sie also unver„ndert zu belassen auáer der Tatsache, daá sie wieder auf die Netzreise geschickt wird (wobei natrlich aus technischer Sicht sehr wohl Žnderungen, z.B. an der Message-ID, vorgenommen werden). 6. Alle weiteren Headerinformationen bleiben unver„ndert, da die weiterzuleitende Nachricht dem Wesen nach original (also insbesondere mit den personenbezogenen Informationen der ursprnglichen Absenderin) erneut verschickt werden soll. 7. Es wird eine WAB-Information eingefgt, die die Adresse der Weiterleiterin enth„lt. _3.4.3.1.2. Aktives Weiterleiten_ Fr das aktive Weiterleiten wird definiert, daá die Weiterleiterin sich den Inhalt der Weiterleitung zu eigen macht. Zwar darf auch hier der Nachrichtenk”rper nicht ver„ndert werden (sonst handelt es sich nicht mehr um eine Weiterleitung), aber es ist z.B. m”glich, den Betreff zu wandeln, auf die Person der Weiterleitenden bezogene Informationen (wie POST, TELEFON) in den Header einzufgen, eine ZUSAMMENFASSUNG einzufgen oder zu „ndern, STICHWORTe hinzuzufgen oder die Nachricht mit dem eigenen PGP-Key zu unterschreiben; letzteres illustriert besonders deutlich die Zueigenmachung der Weiterleitung. Umgekehrt folgt aus diesen šberlegungen, daá beim aktiven Weiterleiten alle auf die Originalabsenderin bezogenen Headerinformationen zu l”schen sind, wobei dieser Punkt insofern kritisch ist, als einer „lteren Software unbekannte, neue personenbezogene Headerinformationen hinzugekommen sein k”nnen. Da dieses Problem nicht aufzul”sen ist (es sei denn, das aktive Weiterleiten wrde g„nzlich anders definiert), ist zumindest bei zuknftigen Erweiterungen die Dokumention an dieser Stelle nachzufhren. Aktuell ist beim aktiven Weiterleiten folgendes zu tun: 6. ANTWORT-AN, LANGUAGE, LDA, MAILER, ORG, PGP, PGP-ID, PGP-KEY-AVAIL, PGP-KEY-COMPROMISE, PGP-KEY-OWN, PGP-PUBLIC-KEY, PGP-SIG, POST, PRIO, SIGNED, SPERRFRIST und TELEFON sind zu entfernen. LDA und SPERRFRIST sind hierbei mit Vorsicht zu behandeln und sollten z.B. der Weiterleiterin explizit zum L”schen/Beibehalten vorgelegt werden. Sofern veraltete Headerinformationen bercksichtigt werden, ist auch PUBLIC-KEY zu l”schen - ZConnect 3.1 --------------------------------------------------------- 157 - 7. Nur wenn noch keine OAB-Information vorhanden ist, wird sie aus der ANTWORT-AN-Information oder, wenn diese nicht oder im Gegenteil mehrfach angegeben ist, aus der ABS-Information erzeugt 8. Die Adresse der Weiterleitenden wird als ABS-Information eingefgt 9. Eine evtl. vorhandene WAB-Information wird gel”scht _3.4.3.2. Automatisches Weiterleiten_ Das automatische Weiterleiten erfolgt z.B. bei Mailinglistenverteilern. Ein solcher Verteiler verschickt jede an ihn gerichtete Nachricht an alle beim Verteiler akkreditierten Mailadressen. Dies hat die Wirkung eines ”ffentlichen Brettes, welches aber nicht ”ffentlich transportiert wird, z.B. weil es weltweit zuwenige InteressentInnen gibt. Natrlich sind die versandten Nachrichten technisch betrachtet in beiden Richtungen private Nachrichten. Eine beim Verteiler eingehende Nachricht wird wie folgt behandelt: 1. Wenn eine Empfangsbest„tigung angefordert wurde (EB-Information), wird diese verschickt und die EB-Information aus dem Header gel”scht 2. Die EMP-Information (also die Adresse des Verteilers) wird in die OEM-Information gewandelt 3. Alle akkreditierten Mailadressen werden als Empf„ngerinnen eingetragen (entsprechend viele EMP-Informationen) 4. Die Absenderinangabe bleibt erhalten. Hat der Verteiler eine Betreuerin, so kann deren Mailadresse als WAB-Information eingetragen werden, was zu einer Zustellung von evtl. Fehlermeldungen an die Weiterleiterin fhrt, aber auch privat in die Liste verschickte Beitr„ge wrden so f„lschlicherweise bei der Betreuerin landen: Da die "”ffentlichen" Nachrichten des Verteilers als private Nachrichten bei der Anwenderin erscheinen, antwortet diese h„ufig auch privat, wenn sie eigentlich in den Verteiler schreiben will. Es ist absolut blich, ANTWORT-AN auf die Verteileradresse zu setzen, was aber, schlechter noch als bei Verwendung von WAB, eine private Antwort an die Absenderin und die sinnvolle Zustellung von Fehlermeldungen verhindert (vgl. Spezifikation ANTWORT-AN). ZConnect sieht dies aber nicht unbedingt vor; ein Newsreader sollte vielmehr bei einer privaten Antwort Weiterleitabsenderin und Absenderin als Adressatinnen zur Auswahl vorlegen. In jedem Fall ist es sinnvoll, eine DISKUSSION-IN-Information auf die Adresse des Verteilers weisen zu lassen, um den Mailinglisten-Charakter als privat verteiltes ”ffentliches Brett zu unterstreichen. 5. Evtl. vorhandene KOP-Informationen werden nicht gel”scht 6. Evtl. vorhandene TRACE- und VIA-Informationen werden gel”scht - ZConnect 3.1 --------------------------------------------------------- 158 - # Es kann notwendig sein, EDA als O-EDA weiterzutransportieren und # ein neues EDA zu erzeugen, da die Annahme, daá bei einer # automatischen Weiterleitung immer nur private Nachrichten betroffen # sind, fahrl„ssig ist. Bei der automatischen Umleitung privater # Nachrichten in ein ”ffentliches Brett (z.B. Nachrichten an den # Postmaster-Account in ein vom SystembetreuerInnenteam gelesenes # Brett oder bei der Umsetzung einer Mailingliste in ein lokales # Brett) kann eine pflichtbewuáte Systemsoftware die entstehende # Nachricht potentiell als "zu alt" entsorgen. Sinngem„á Gleiches gilt fr ROT/O-ROT. _3.4.3.3. Weiterleiten im Netz: Umleiten_ Ist in einem System fr die Empf„ngerin einer privaten Nachricht eine Vertreterin angegeben (z.B. kann dies bei einem Nachsendeantrag eines Points bei Systemwechsel der Fall sein), so wird das umleitende System wie folgt vorgehen: 1. Keine Empfangsbest„tigung versenden, daá tut erst das laut Vertreterineintrag empfangende System 2. Keine Žnderung der Message-ID vornehmen, da es sich immer um PMs handelt, fr die ein Dupecheck nicht stattfindet 3. Die EMP-Information wird in die VER-Information umgewandelt (VER kann nach [D3.1Z] mehrfach vorkommen, was sinnvoll ist; laut „lteren Gremiumsbeschlssen máte aber ein bereits vorhandenes VER gel”scht werden, da diese Headerinformation dort als "nur einmal" beschrieben ist). Es kann nur eine EMP-Information im Header enthalten sein, da es sich um eine private Nachricht handelt, die am vorl„ufigen Ende ihres Routewegs angelangt ist 4. Die neue Empf„ngerin wird in die EMP-Headerinformation eingetragen 5. Eine evtl. vorhandene Information O-ROT wird gel”scht (hier zeigt sich eine Inkonsistenz der Žnderung auf "auch mehrfach" bei der VER-Information: mehrfache Routepfade k”nnen nicht transportiert werden) 6. ROT wird in O-ROT umgewandelt 7. Eine neue ROT-Information wird so angelegt, als sei die Nachricht auf dem umleitenden System geschrieben worden (also mit dem umleitenden System nebst Domain als ersten Eintrag) # Es ist bisher keine O-VIA-Headerinformation fr die Verwendung # beim VER-Umleiten definiert. Dies (vgl. O-ROT) k”nnte eine # sinnvolle Erweiterung darstellen. Allerdings wrden beim aktuellen # Vorgehen bereits vorhandene VIA-Headerinformationen nicht gel”scht, # so daá in Kombination mit der VER-Information selber ersichtlich # wird, welche VIA-Informationen zu welchem Teil des Routeweges # geh”ren. Der Logik folgend, daá erst das endgltige Empfangssystem die Empfangsbest„tigung versendet, darf auch eine evtl. vorhandene TRACE-Headerinformation nicht gel”scht werden. - ZConnect 3.1 --------------------------------------------------------- 159 - _3.4.4. Gemischtadressierung_ In ZConnect ist vorgesehen, daá eine Nachricht gleichzeitig private und ”ffentliche Empf„ngerinnen haben darf. Gleichzeitig gibt es in ZConnect sehr viele Headerinformationen, die nur fr den Einsatz bei privaten Nachrichten bestimmt sind (z.B. PGP-KEY-OWN, PGP-PUBLIC-KEY, EB, O-ROT, PGP: PLEASE | REQUEST, TRACE, VIA). Die Absenderin einer gemischtadressierten Nachricht wird bei Einsatz solcher Informationen deren Zustellung an die privaten Empf„ngerinnen, nicht aber an die ”ffentlichen im Sinn haben. Bei der Aufsplittung der gemischtadressierten in eine private und eine potentiell wieder gemischtadressierte oder rein ”ffentliche Nachricht ergibt sich jedoch eine unaufl”sbare Schwierigkeit: Die routende Software máte testen, welche der Headerinformationen nur fr Privatnachrichten gedacht sind, diese in den privaten Header kopieren und aus dem ”ffentlichen l”schen (in einer gemischtadressierten Abspaltung máten sie hingegen verbleiben). Dies erforderte jedoch, mangels einer grunds„tzlichen Attributierung von Headerkennungen in ZConnect, daá die Software eine Liste der Headerinformationen zur Verfgung haben máte, welcher die Eigenschaft "nur in privaten Nachrichten erlaubt" zu entnehmen w„re. Aber auch dies l”ste das Problem nicht grundlegend, da jederzeit neue Headerinformationen beschlossen werden k”nnen, die nur in privaten Nachrichten erlaubt sind. Es wrde auch immer Software geben, die mindestens nicht auf dem aktuellsten Stand der Dinge ist. Auch eine Umspezifizierung der Regelung, daá manche Headerzeilen nicht in ”ffentlichen Nachrichten auftreten drfen, in eine Festlegung, daá nur das Auswerten bestimmter Headerinformationen bei ”ffentlichen Nachrichten nicht erfolgen sollen, l”st das Problem nicht. Zum einen wrden unn”tig Daten transportiert, die recht volumin”s sein k”nnen (z.B. im Zusammenhang mit PGP). Zum anderen kann auch eine komplette Nachricht als ”ffentliche Nachricht verboten sein. Z.B. ist die vor der Einfhrung nach ZConnect stehende MIME-Spezifikation ausschlieálich fr private Nachrichten erlaubt. MIME definiert eine Nachrichtenk”rperform, die in ”ffentlichen Sendungen unerwnscht ist. In diesem Fall w„re eine gemischtadressierte Nachricht insgesamt zu unterbinden, da ”ffentliche Empf„ngerinnen nicht erlaubt sind. Bei einer gemischtadressierten Nachricht wird bei der Aufteilung keine neue ID fr den privaten Anteil erzeugt. Begrndung ist, daá es keinen Dupecheck fr private Nachrichten gibt. Tats„chlich ist einige Routesoftware hier nicht standardkonform und fhrt den Check auch fr private Nachrichten durch. Aus Sicht dieser fehlerhaften Software ist eine aufgetrennte, ehemals gemischtadressierte Nachricht also automatisch ein Dupe. Aber auch ohne fehlerhafte Software ergeben sich Probleme z.B. fr die lokale Kommentarverkettung: Zwei de facto nicht identische Nachrichten (daá sie den gleichen Nachrichtenk”rper haben, bedeutet keine technische Gleichheit) liegen potentiell mit derselben Message-ID in der lokalen Nachrichtendatenbank. # ZConnect wohnt eine einfache L”sung fr all diese Probleme inne, # die bisher kaum beachtet wird, es aber unbedingt werden sollte: Es # ist festgelegt, daá eine Nachricht privat ist, wenn ihre s„mtlichen # Empf„ngerinnen privat sind. Also ist eine gemischtadressierte # Nachricht als ”ffentliche Nachricht zu interpretieren. In einer - ZConnect 3.1 --------------------------------------------------------- 160 - # solchen ist dann alles verboten, was nur fr private Nachrichten # erlaubt ist. Dies schr„nkt zwar auf den ersten Blick den Komfort # fr die Absenderin ein. Aber die Teilung von privaten und # ”ffentlichen Empf„ngerinnen kann unaufwendig schon bei der # Erzeugung der Nachricht von der BenutzerInnenschnittstelle # automatisch durchgefhrt werden. An dieser Stelle ist auch noch # leicht zu unterscheiden, welche Headerinformationen in welchem Teil # der Sendung erlaubt sind. _3.4.5. Verschlsselung_ Grunds„tzlich verfolgt ZConnect die Absicht, Verschlsselungen im Standard zu erfassen, um sie automatisch durch Software behandelbar zu machen. Dies drckt sich in der Positionierung von Verschlsselungsinformationen im Header aus. An dieser Stelle unterscheidet sich ZConnect sehr von anderen Standards der Netzwelt, was insbesondere fr Gateways nicht ganz einfach ist. Angesichts der M”glichkeit, z.B. das manuell umst„ndlich zu verwendende PGP dadurch beinahe fr die Anwenderin transparent in eine Software zu integrieren, ist dies aber eindeutig als Vorsprung ZConnects zu werten und damit besonderes Augenmerk wert. Durch die Verschlsselung werden Headerinformationen wie CHARSET, TYP und KOM z.T. ihrer Aussage beraubt. Evtl. „ndern sich Zeichensatz und Typ, der Kommentar wird blicherweise mitverschlsselt. Daher werden diese Header fr die Decodierung mit dem Vorspann CRYPT-CONTENT- versehen (vgl. Datenformat CRYPT-CONTENT-CHARSET ff.). _3.4.5.1. PGP_ Pretty Good Privacy, kurz: PGP, ist ein nach heutigen Maást„ben sicherer Verschlsselungsmechanismus fr Nachrichten. In ZConnect wird er auf Headerebene eingebunden. _3.4.5.1.1. Grunds„tzliches_ Auf die Funktionsweise von PGP soll an dieser Stelle nicht n„her eingegangen werden. Hierzu empfiehlt sich vor einer Implementierung dringend die Lektre der Dokumentation vom Autoren des Programms, Philip Zimmerman. Diese wird mit den PGP-Komplettpaketen verteilt. PGP ist ein als Public Domain freigegebenes Verfahren, dessen Verwendung in ZConnect und auch in jedem anderen Kontext ohne Bedingungen gestattet ist. Der Public Key ist beim PGP-Verfahren nicht nur problemlos frei ver”ffentlichbar, er gewinnt sogar an Sicherheit und Brauchbarkeit, je weiter er verbreitet ist. Zwar kann ein Public Key jederzeit gef„lscht werden, aber zum einen sieht PGP Mechanismen vor, die dies wirksam erkennen lassen, zum anderen ist die F„lschung umso schwieriger, je weiter ein korrekter, ”ffentlicher Schlssel verbreitet ist. ZConnect sieht zwei M”glichkeiten vor, Public Keys zu verbreiten. Zum einen ist dies das Versenden des Public Keys im Header einer Nachricht, mit der jederzeit gegebenen Gefahr der Manipulation. Zum anderen ist es der Abruf mithilfe der ZConnect-Onlinephase in einer Mailbox, z.B. jener der Heimat-Mailbox der Anwenderin, deren Schlssel gewnscht ist, mit der ebenfalls jederzeit gegebenen Gefahr, daá die MailboxbetreiberInnen Schlssel f„lschen oder fr UserInnen - ZConnect 3.1 --------------------------------------------------------- 161 - generieren, die PGP gar nicht verwenden. Zwischen beiden Methoden existiert ein Bindeglied, welches im Kopf einer Nachricht lediglich anzeigt, daá und wo der Public Key der Absenderin per ZConnect-Onlinephase abzurufen ist (vgl. Datenformat: PGP-KEY-AVAIL bzw. Onlinephase: PGP-KEYREQ). Die Anwenderin sollte m”glichst von der Software zu einem verantwortungsvollen Umgang mit den PGP-M”glichkeiten ZConnects hingefhrt werden. Das bedeutet zum einen die Vermeidung von bertrieben groáem Datenaufkommen, wie es durch Mitschicken des eigenen Public Keys in jeder ”ffentlichen Mail entstnde. Zum anderen sollte auf die Gefahren aufmerksam gemacht und z.B. auf die šberprfungsm”glichkeit per Telefon und Fingerprint hingewiesen werden. Aus Protokollsicht soll die PGP-Integration die Zusammenarbeit mit dem PGP-Programm vollautomatisch erm”glichen, insbesondere also die Weitergabe von Keys in die Public Key Verwaltung von Philip Zimmermans PGP. Aus UserInnensicht sollte m”glichst nichts Verschlsseltes oder durch Unterschrift Codiertes auf dem Bildschirm erscheinen. Vielmehr sollte die Software soweit wie m”glich Entschlsselung und Unterschriftenprfung automatisieren und z.B. nur Statusmeldungen wie "Nachricht war PGP-verschlsselt" oder "Nachricht war unterschrieben, Unterschrift geprft" anzeigen. PGP verschlsselt Daten so, daá auch die Absenderin sie nicht mehr lesen kann. Soll die versandte Nachricht fr die Absenderin lesbar bleiben (was ein gewisses Sicherheitsleck bedeutet), gibt es eine bessere L”sung fr dieses Problem als die getrennte Speicherung des Klartextes. PGP untersttzt die Verschlsslung an zwei Empf„ngerinnen - n„mlich die wirkliche Empf„ngerin und (in diesem Fall) die Absenderin mit dem Befehl "pgp -e dateiname UserID1 UserID2". So kann unter Eingabe des Paáwortsatzes auch die Absenderin die eigenen Nachricht noch entschlsseln. _3.4.5.1.2. Transport der Schlsselinformation_ Die Schlsselinformation wird, dem eingangs erw„hnten Konzept folgend, im Header einer Nachricht transportiert (die M”glichkeit des Keyrequests hier einmal auáer acht gelassen). Hierzu wird nicht die "verpackte" (bei PGP "amor" genannt) Version verwendet, welche PGP mit dem Kommando "pgp -kxa" liefert, sondern die die reine Schlsselinformation, wie sie (bei angenommener Nicht-Existenz eines Armor vorschreibenden Configfiles) "pgp -kx" produziert; diese wird allerdings Base64-codiert. Die Base64-Codierung ist ein einfaches Verfahren zur 6-Bit-Codierung, welche einen problemlosen Transport ber wohl s„mtliche Netzgrenzen hinweg garantiert. Drei Bytes … 8 Bit werden hierbei in vier Bytes … 6 Bit{14} aufgeteilt. Das verwendete 6-Bit-Alphabet harmoniert mit dem ZConnect-Zeichensatz fr den Header: "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/". Darberhinaus ist im ZConnect-Kontext nur noch das Fllzeichen '=' zu beachten, welches beim Dekodieren zu berlesen ist. Der auf der beiliegenden CD enthaltene Source MKKEY.C illustriert das Vorgehen beim Codieren. Aus dem PGP-Sourcepaket stammt die Routine ARMOR.C, welche fr das Decodieren zust„ndig ist. - ZConnect 3.1 --------------------------------------------------------- 162 - ZConnect-Headerinformationen sind einzeilig; dies gilt natrlich auch fr solche, die einen Public Key oder eine Unterschrift enthalten. Im Gegensatz zum Armor-Format wird also nicht nach 64 Zeichen umgebrochen. Beispiel: Der Public Key von Sepro@bingo.comlink.de in Armor-Darstellung von PGP: -----BEGIN PGP PUBLIC KEY BLOCK---- Version: 2.6 mQCNAi4bNc0AAAEEAOc6GczyLdnA4FtHjqIzDHetafHO6nnNAkMZNBIbu7aXFcj1 sGo9X5NUmKcC2nb33l5BDeKjql7leSTmxtvrABcd6clndd+YOKCo0DMtU8o2Z/+y 75hssRZAhLEJWM/d+qGP712jg6vMJmKiDBbop+N/FNxnXXMauQqcFQabFzW9AAUR tCJDZSBCcnVua2UgPFNlcHJvQGJpbmdvLmNvbWxpbmsuZGU+iQBVAgUQLz+cI/95 3NsQf2DxAQGQGgH6AlpZuYCAPHDx2Cxl0qGTZx5WMp6PM63ZJMtKZe1LJSEWv1vh 8KLWwsFH+KGV/ExkRPC5eVSA1Flwaigrex9F8YkAlQMFEC8qhcQKnBUGmxc1vQEB BC8EAJO2RcXB7ppRIMi70PQsEANbTzgfSbRvTsT8T0XqZIooLu6/ALBZSVNTir8R X1eXJT1YKDm8/r7/TsraqMJ52feGvHMwGf6Jrs1+6VblANu8DQqyPWQ0wRwjBWz+ sqKk4boJrbK7Qy9RZXP2Tw83ADquViQjlTiMqeTOsRMr4pavtClDYXJzdGVuIEJy dW5rZSA8U2Vwcm9AQW10cmFzaC5jb21saW5rLmRlPokAlQIFEC7i0pYKnBUGmxc1 vQEBhnkD/1Rc+xVaJNkN3Mw7DIHpMLBh0rCChb70PHsfUGOk/TBt00ujuuyyR9SF worS9GJANkyiGKDYC+tCbYRriBlBLvhvR3xQRntdQIcNwwJBdaa3zXCIEx/lUtF0 YJCH9+hLdGUH6kILpfj2+YMKpBjh2HulBqVesOXpGoC9HgFWn3QMiQBVAgUQLj59 HkHx4UColTddAQH7iwH/d79Dhd8GYjgWzR1zmCf6g9loKOQsbEHG4/ivAPznJ2y+ s5rCaNbpg8yavGrhp3iV6f5Wncw7/637J7Qb6nft2A== =vGi/ ----END PGP PUBLIC KEY BLOCK----- Die bin„re Entsprechung (bin) erg„be sich, als C-Pseudocode formuliert, mit einer ord-Funktion gem„á Base64-Alphabet, exemplarisch, ohne Bercksichtigung der Fllzeichen, fr das erste Armor-Quadrupel (armor) wie folgt: bin[0] = (ord(armor[0])<<2) | (ord(armor[1])>>4) bin[1] = (ord(armor[1])<<4) | (ord(armor[2])>>2) bin[2] = (ord(armor[2])<<6) | ord(armor[3]) Und der umgekehrte Weg mit einer chr-Funktion gem„á BASE64-Alphabet: armor[0] = chr(bin[0] >> 2) armor[1] = chr(bin[0] << 4) | chr(bin[1] >> 4) armor[2] = chr((bin[1] & 0xF) << 2) | chr(bin[2] >> 6) armor[3] = chr(bin[2] & 0x3F) _3.4.5.1.3. Unterschriften_ Wenn eine Nachricht verschlsselt und unterschrieben ist, ist die Signatur in der Verschlsselung enthalten, braucht also nicht einzeln transportiert zu werden. Nur wenn eine Nachricht nur unterschrieben wurde, wird die Unterschrift in der Headerinformation PGP-SIG transportiert. PGP kann die Unterschrift auch direkt auf den zu unterschreibenden Text anwenden. Dieser wird dabei zugleich ins Armor-Format umgewandelt und somit ohne PGP unlesbar, was nicht der Sinn einer Unterschrift ist. Es ist daher unbedingt sinnvoll, zumindest bei ”ffentlichen Nachrichten, die ZConnect-Methode des Transportes der abgel”sten - ZConnect 3.1 --------------------------------------------------------- 163 - Unterschrift im Header zu verwenden. "PGP -sb" erzeugt eine Bin„rdatei, die die solit„re Unterschrift enth„lt, welche „quivalent zur Behandlung der Public Keys Base64 codiert und einzeilig in den Header geschrieben wird. # Die M”glichkeit PGPs, Signaturen als Klartext im Nachrichtenk”rper # unterzubringen, wie sie teilweise von Pointprogrammen verwandt # wird, ist besonders relaykompatibel (gatetauglich), paát aber nicht # zu ZConnect-PGP-Regelung. Was haupts„chlich bedeutet, daá die # ZConnect-Regelung einer grunds„tzlichen šberarbeitung bedarf. Es ist nicht sinnvoll, mit einer unterschriebenen Nachricht immer auch den Public Key mitzuschicken: Wer unterwegs die Unterschrift f„lschen kann, wird dies mit dem Key auch tun k”nnen. Unn”tiges Datenaufkommen sollte hier vermieden werden. _3.4.5.2. QPC:_ QPC:, kurz fr QuickPointCrypt, ist fr das Pointprogramm QuickPoint entwickelt worden. Es ist sehr einfach zu implementieren und mit ebenso einfachen kryptographischen Methoden angreifbar. Um es als schnelle, umschlag„hnliche Codierung einzusetzen, k”nnen ProgrammiererInnen sich bei Marc Zimmermann (75240.1241@compuserve.com), dem QuickPoint-Autor, die Dokumentation zu QPC: besorgen. QPC: wird von mehreren Pointprogrammen angeboten; !!MessageBase bietet eine Abwandlung an, die auch bin„re Dateien verschlsseln kann, was mit QPC: sonst nicht m”glich ist. Auch fr dieses abgewandelte Verfahren ist bei obiger Mailadresse eine Dokumentation erh„ltlich. _3.4.6. Points_ In der Welt der privaten Vernetzung, welche bis vor nicht allzu langer Zeit fast ausschlieálich mit FIDO-, Z-Netz- und unz„hligen sich mehr oder weniger „hnelnden Protokollen betrieben wurde, gab es berwiegend die Unterscheidung zwischen routenden Systemen (Mailbox) und Endsystemen. Ursprnglich w„hlten sich die UserInnen online in eine Mailbox ein, um dort z.B. Nachrichten zu lesen oder auch unter ihrem UserInnennamen zu schreiben. Dieses Vorgehen ist kostspielig und unkomfortabel, daher wurden Offlinereader entwickelt, mit denen regelm„áig oder auch nur ab und zu eine Mailbox angerufen und en block die bis dahin neu aufgelaufenen Nachrichten/Daten auf den heimischen Computer bertragen werden konnte. In vielen Netzen bildete sich fr diese Offlinereader der Begriff Point. Technisch stellt der Point also die einfachere Alternative zu einer Systemsoftware dar, hat aber seinen Ursprung in der Automatisierung der Datenbertragung vom System zu den AnwenderInnen. Hierin liegt begrndet, warum noch immer, z.B. bei ZConnect, Unterschiede zwischen einem System und einem Point existieren und Points nicht einfach nur nicht anrufbare Systeme sind, wie es vielfach im RFC-Bereich der Fall ist. Es gibt keinen protokolltechnisch zwingenden Grund fr die Aufteilung in Systeme und Points. Faktisch ist denn auch bei ZConnect der - ZConnect 3.1 --------------------------------------------------------- 164 - Unterschied heute nicht mehr sehr groá. Besonderheiten ergeben sich aus der Sichtweise von Points als Quelle bzw. letzte Lagerst„tte einer Nachricht und aus der zwingenden Zuordnung von PointuserInnen zu einem System. Die Zuordnung zu einem System bedeutet, daá der Routepfad aus ZConnect-Sicht erst ab dem ersten System beginnt. Points mssen also einen leeren ROT-Pfad erzeugen. Auch berprft ein System, ob "seine" Points unter der dem System bekannten AbsenderInnenadresse schreiben. Dies ist zwar nicht ZConnect-immanent, es wird aber von allen ZConnect-Mailboxprogrammen so gehandhabt, daá, wenn Point A@box.do.main als B@box.do.main schreibt, die Mailboxsoftware ohne jede Rckfrage oder Fehlermeldung A@box.do.main daraus macht. Insbesondere bei weitergeleiteten Nachrichten fhrte dieses Vorgehen, welches die Verifizierbarkeit einer Absenderin erh”hen soll, in der Vergangenheit immer wieder zu weittragenden Fehlern, die den Netzfrieden gef„hrdeten. Z.B. hat Mailboxsoftware bei einer passiv weitergeleiteten Nachricht den Adreáanteil der ABS-Information ver„ndert, den Realnamenanteil jedoch unver„ndert gelassen. Dies zeigt auch, daá das "Eigentumverh„ltnis" zwischen Point und System gerade aus protokolltechnischen Grnden unhaltbar ist: Sollte in der Zukunft eine neue Art der Weiterleitungsinformation beschlossen werden, in der die Weiterleiterin z.B. in der Headerinformation MODERATORIN untergebracht ist, wird „ltere Software f„lschlicherweise eine "gef„lschten" Absenderinangabe erkennen und selbst die eigentliche F„lschung vornehmen. Fr das erste System auf dem Routeweg ist auch der "Notfall" vorbehalten, welcher fr die Erlaubnis der Ersetzung von EMPs durch KOPs (vgl. bei KOP) eintreten muá. Dieses erste System (und nur dieses!) darf ausnahmsweise EMPs in KOPs wandeln, wenn lokale Begebenheiten dies unausweichlich machen. Wenn eine Nachricht mit einem Brett als Empf„ngerin aufwartet, das fr die Absenderin nicht beschreibbar ist, sollte die Nachricht bevorzugt der Systembetreuung zur Entscheidung vorgelegt werden, auch in diesem Fall also auf die Ersetzung verzichtet werden. Hintergrund ist, daá die Absenderin andernfalls nie erf„hrt, daá ihre Nachricht nicht dort angekommen ist, wo sie plaziert werden sollte. Auf der anderen Seite wird ein Point als letztes Glied in der Kette eines Nachrichtenwegs betrachtet. Aus diesem Grund legt das Zerberus-Mailboxprogramm eine sehr eigene Interpretation der EMP/KOP-Regelung an den Tag. Wenn eine Nachricht von einem Zerberussystem zum Point geschickt wird, werden alle EMPs, die nicht mit der Liste der vom Point beim System bestellten Bretter bereinstimmen, zu KOPs gewandelt. Tats„chlich kann dies fr NutzerInnen einer weniger intelligenten Pointsoftware sehr hilfreich sein, da solche Software die ankommende Nachricht h„ufig genau so oft einsortiert, wie EMP-Angaben vorhanden sind. Bei einer hohen Zahl von EMP-Informationen kann dies sehr unhandlich geraten. Technisch ist gegen diese Art der EMP/KOP-Wandlung nichts einzuwenden, da die Nachricht ihren Bestimmungsort erreicht hat und somit keine Routinglcken mehr entstehen k”nnen. Faktisch k”nnen die meisten Pointprogramme heute mit Crosspostings sehr gut umgehen (insbesondere seit Einfhrung des ZConnect-Maps-Standards), so daá Systemsoftware Klimmzge wie die beschriebenen unterlassen sollte. - ZConnect 3.1 --------------------------------------------------------- 165 - Innerhalb des Datenbestands eines Pointprogramms kann die Benutzerin beliebig verfahren. Sobald fr eine Nachricht kein weiteres Routing erforderlich ist, sind Software und Mensch in ihrem Vorgehen frei, drfen also intern beliebig EMPs in KOPs wandeln. Bei internen Verschiebungen oder Kopien muá auch die Message-ID nicht gesondert betrachtet werden, es sei denn, die Pointsoftware selber erfordert dies. Es ist sehr fraglich, ob die Headerinformationen SPERRFRIST und LDA von Pointprogrammen automatisch ausgefhrt werden sollten. Hier zeigt sich dann auch ein eklatanter Unterschied zwischen Points und OnlineuserInnen: Fr den Onlinedatenbestand eines Systems sind Informationen wie die genannten schlicht Hilfsmittel fr die automatische Datenverwaltung. Fr eine Pointsoftware gilt jedoch, daá die Daten in den exklusiven Verfgungsbereich der Anwenderin bergegangen ist. Ein Automatismus, der in diesem Verfgungsbereich ungefragt Daten l”scht, ist abzulehnen. Im Rahmen dieser šberlegung sind auch LANGUAGE und STAT: NOCIPHER nur als Empfehlungen zu interpretieren. Es ist zu jeder Zeit davon auszugehen, daá oberhalb der ISO-Schicht 7 unter anderem menschliche Entscheidungen angesiedelt sind, so daá technisch nicht notwendige Bevormundungen als schlechter Stil zu werten sind. Ein ZConnect-f„higer Point antwortet auf die Anforderung einer Empfangsbest„tigung (sofern die Anwenderin dies nicht abgeschaltet hat). Fr nicht-ZConnect-f„hige Points bernimmt dies das ZConnect-System. Diese Regelung ist insofern v”llig unklar, als es derzeit keine ZConnect-f„higen Points gibt (nur ZConnect-Datenformat-f„hige). De facto werden derzeit Empfangsbest„tigungen von Pointprogrammen und nicht von Systemen verschickt. - ZConnect 3.1 --------------------------------------------------------- 166 - _3.5. Maps-Standard_ Die Handhabung von Brett(ab)bestellungen beim servenden System, sei es von einem anderen System oder vom Point aus, erfolgt h„ufig ber einen Automatismus, der im Anschreiben einer automatischen Userin besteht, die darauf mit Brettlisten, An- und Abbestellung und, je nach Implementation, auch mit weiteren Funktionen zu Diensten ist. Die Syntax dieser Automatismen war fr verschiedene Systeme immer nur beinahe gleich. Der am weitesten verbreitete Name fr den Automatismus ist MAPS - oft, aber eben nicht immer muá die Anwenderin eine Nachricht an Maps@box.domain schicken, bekommt von dieser eine Antwort und muá diese Antwort wieder selber interpretieren. Auf dem /Z-NETZ-Treffen 1994 in Hamburg entwarfen die Anwesenden aus dem Gremium einen Standard fr dieses Verfahren. Dies soll Programmen erm”glichen, die Kommunikation mit der Autouserin auch Anwenderinnenseitig zu automatisieren, also die Anwenderin vom Schreiben und auch Lesen dieser eigentlich technischen Informationen zu entlasten. Stattdessen kann z.B. ein graphischer Dialog zur Brettbestellung verwendet werden, welcher dann vom Userinneninterface in entsprechende Maps-Anweisungen umgesetzt werden kann. Damit w„re auch schon gesagt, wie Maps zuknftig bei ZConnect heiáen wird: Maps. Maps ist von beliebiger Stelle aus dem Netz unter der Adresse MAPS@System.Domain erreichbar, wird aber manche Antworten nur lokalen AnwenderInnen oder besonders als Maps-berechtigt vermerkten UserInnen aus dem Netz geben. _3.5.1. Die Maps-Befehle_ Befehle an Maps stehen grunds„tzlich in der Betreffzeile und k”nnen eine beliebige Groá-/Kleinschreibung aufweisen. Die Parameter stehen im Nachrichtenk”rper. Auch bei ihnen muá mit beliebiger Groá-/Kleinschreibung gerechnet werden, auch wenn oder gerade weil die Dokumentation an dieser Stelle keine eindeutige Aussage trifft. Parameter im Betreff werden grunds„tzlich ignoriert! Empf„ngt Maps einen unbekannten oder nicht implementierten Befehl, wird eine Antwort mit dem Betreff "Your Help" generiert, die einen Hilfstext mit allen dem antwortenden Maps bekannten Befehlen nebst deren Erl„uterung enth„lt. Antworten auf bekannte Befehle erhalten zwingend den Betreff "Your ", also z.B. "Your ADD", "Your LiSt" (auch hier keine Festlegung der Groá-/Kleinschreibung!) und eine BEZ-Information, welche zur Message-ID der beantworteten Nachricht einen Bezug herstellt. - ZConnect 3.1 --------------------------------------------------------- 167 - _3.5.1.1. Pflichtbefehle_ Um eine Maps-Implementation ZConnect-konform nennen zu drfen, bedarf es zus„tzlich zum bisher Beschriebenen der vollst„ndigen Implementierung der folgenden Pflichbefehle: ----------------------------------------------------------------------------- ADD Funktion: dient der Bestellung von Brettern fr das absendende System oder Point beim angeschriebenen System. Das angeschriebene System wird natrlich die Berechtigung zur Bestellung einzelner Bretter prfen. Nachrichtenk”rper: enth„lt zeilenweise, beginnend mit einem Slash ('/') die Brettnamen, die bestellt werden sollen, wobei Groá-/Kleinschreibung zu ignorieren sind. Zeilen ohne Slash am Beginn werden ignoriert. Antwort: enth„lt ein Protokoll ber die angeforderten Bretter (also den Erfolg/Miáerfolg der Bestellung) in dem unter "Listenformat" beschriebenem Format (s.u.) Hinweis: das Ergebnisprotokoll enth„lt genau diejenigen Bretter, die in der Anforderung aufgez„hlt wurden ----------------------------------------------------------------------------- DEL Funktion: dient der Abbestellung von Brettern. Falls das angeschriebene Systeme Pflichtbretter kennt, wird es deren Abbestellung negativ bescheiden. Nachrichtenk”rper: enth„lt zeilenweise, beginnend mit einem Slash ('/'), die Brettnamen, die abbestellt werden sollen, wobei Groá-/Kleinschreibung zu ignorieren sind. Zeilen ohne Slash am Beginn werden ignoriert. Antwort: enth„lt ein Protokoll ber die angegebenen Bretter (also den Erfolg/Miáerfolg der Abbestellung) in dem unter "Listenformat" beschriebenem Format (s.u.) Hinweis: das Ergebnisprotokoll enth„lt genau diejenigen Bretter, die in der Abbestellung aufgez„hlt wurden - ZConnect 3.1 --------------------------------------------------------- 168 - HELP Funktion: dient der Anforderung eines kompletten Hilfstexts Nachrichtenk”rper: wird ignoriert Antwort: ein fr menschliche Rezipienten gedachter Klartext, der alle Informationen ber den eingesetzten Maps enth„lt. ----------------------------------------------------------------------------- LIST Funktion: dient der Anforderung einer Liste von verfgbaren Brettern Nachrichtenk”rper: wird ignoriert Antwort: enth„lt eine Liste mit den fr die Anfragende verfgbaren Bretter in dem unter "Listenformat" beschriebenen Format (s.u.) - ZConnect 3.1 --------------------------------------------------------- 169 - _3.5.1.2. Listenformat_ Das fr verschiedene F„lle genutzte Listenformat wird hier als Grammatik in BNF formuliert ('|' bedeutet "oder" und trennt Alternativen voneinander; 'e' heiát Epsilon und steht fr "nichts"; zu starten ist bei "Zeilen"). Zu beachten ist, daá es keine L„ngenbeschr„nkung gibt, insbesondere auch nicht fr die L„nge einer Zeile. Zeilen = Zeile Zeilen | e Zeile = Steuerzeichen Brettbeschreibung Zeilenende Steuerzeichen = '+' | '-' | ' ' | '!' | ';' Brettbeschreibung = [Whitespace]+ | e Zeilenende = Whitespace = | ist der Name des gewnschten Bretts in Groábuchstaben (!), beginnend mit einem Slash ist eine beliebige Beschreibung des Bretts, kann also seinerseits Whitespaces (auch am Ende) enthalten und geht bis zum abschlieáenden Zeilenende steht fr das Leerzeichen (ASCII 32) steht fr Carriage Return (ASCII 13) steht fr Linefeed (ASCII 10) steht fr den Hard Tab Stop (ASCII 9) [Whitespace]+ bedeutet mindestens ein Whitespace Die Steuerzeichen haben folgende Bedeutung: '+' Brett ist bestellt bzw. bestellbar '-' Brett ist nicht bestellbar ' ' Brett ist nicht bestellt aber bestellbar '!' Brett ist bestellt und nicht abbestellbar (Pflichtbrett) ';' Zeile ist ein Kommentar Eine Beispielantwort auf eine ADD-Nachricht, die obiger Grammatik folgt: ; ZC-Maps Version 3.1 ; ; Antwort von auf Sendung ; vom 11.11.99 ; + /TESTNETZ/BEISPIEL1 Dies ist ein Kommentar + /Testnetz/BEISPIEL2 Kommentare sind - /Forbiddennet/Group durch beliebig - /Schubi/DU viele Whitespaces abgetrennt Eine Beispielantwort auf eine DEL-Nachricht: ; ZC-Maps Version 3.1 ; SuperMapsio 3 (c)SEPROductions ! /LOKAL/WICHTIG /LOKAL/NICHT/SO/WICHTIG /LOKAL/AUCH/NICHT/SO/WICHTIG /LOKAL/ABBESTELLT ! /Z-NETZ/WICHTIG /T-NETZ/SEX ; Und tschá - ZConnect 3.1 --------------------------------------------------------- 170 - Eine Beispielantwort auf eine LIST-Nachricht: ; ZC-Maps Version 3.1 + /Bestelltes/Brett /Bestellbares/Nicht/bestelltes/Brett ! /Bestelltest/Nicht/Abbestellbares/Brett ; Kommentar /Bestellbares/Brett mit Kommentar _3.5.1.3. Optionale Befehle_ Idealerweise sollte eine Maps-Implementation auch alle folgenden Befehle zur Verfgung stellen. [D3.1Z] will einen Maps erst dann "ZConnect-kompatibel" nennen, wenn dies geschehen ist, nimmt aber selber die Befehle ORDER-PM und FILES aus. Dazu mehr im n„chsten Abschnitt "Kritik und Vorschl„ge". ----------------------------------------------------------------------------- FILES Funktion: dient der Bestellung beliebig vieler Dateien Nachrichtenk”rper: enth„lt zeilenweise die Namen der Dateien, die bestellt werden sollen. Optional kann, durch mindestens ein Whitespace abgetrennt, ein Paáwort (Groá-/Kleinschreibung ist nicht beachten) angegeben werden. Statt eines konkreten Dateinamens kann auch ein sogenanntes "Magic" angegeben werden. Folgende Magics sind definiert: HELP Hilfstext zur Bedienung des Fileservers ALLFILES Liste aller verfgbaren Dateien (auf CD + anderen Datentr„gern) CDFILES Liste aller verfgbaren Dateien, die nur auf CD vorhanden sind FILES Liste aller verfgbaren Dateien, die auf anderen Datentr„gern vorhanden sind NEWFILES Liste aller "neuen" Dateien Antwort: Der Betreff der Antwort ist hier um den Dateinamen erweitert, also "Your Files: ". Dies impliziert, daá pro versandter Datei genau eine Bin„rnachricht zu erzeugen ist. Fr jede nicht bediente Anforderung ist eine Nachricht mit dem Betreff "Your Files: Failed " zu erzeugen. Das Format der per Magic angeforderten Listen wird nicht spezifiziert, es wird aber vorgeschlagen folgenden Zeilenaufbau zu w„hlen: Dateiname.Extension Gr”áe Datum Uhrzeit Beschreibung - ZConnect 3.1 --------------------------------------------------------- 171 - Es ist m”glich, ein Protokoll zusammen mit der oder den Bin„rnachricht(en) zu verschicken. Dieses Protokoll wird immer als Kommentar (vgl. KOM-Headerinformation) vorangestellt; und zwar entweder genau einer der Bin„rnachrichten oder genau einer extra verschickten Nachricht ohne Inhalt (Informationen nur als Kommentar!) mit dem Betreff "Your Files: Costs". Das vorgeschlagene Format des Protokolls ist am besten in Form eines Beipiels zu beschreiben: ZC-MAPS Version 3.1 Order of Ordered (x bytes) (x.x ). ... Found x files (x bytes). Sent x files (x bytes). Denied x files (x bytes). Total cost for this order: x.x . Die erste Zeile dient dabei der Kennung des Maps-Standards und ist fest vorgeschrieben. Copyrightmeldungen der eigenen Implementierung k”nnen als Kommentare eingefgt werden, die durch ein Semikolon an der ersten Position in der Zeile gekennzeichnet werden. Die zweite Zeile ist vielleicht auf MultiuserInnensystemen sinnvoll. Die sollte daher mit deren Mailadresse angegeben werden. Die dritte bis n-te Zeile z„hlt die bearbeiteten Anforderungen auf, die positiv, also mit Zusendung der Datei beschieden wurden; die Angaben von Kosten und Nachrichtengr”áen k”nnen in diesen Zeilen von hinten nach vorne weggelassen werden (also nur L„ngenangabe oder gar keine Angabe m”glich). In den letzten vier Zeilen, die wiederum von hinten nach vorne weggelassen werden k”nnen, k”nnen statistische Angaben untegebracht werden. Die W„hrungskennzeichen sind nicht spezifiziert, sollten aber die in den zu den W„hrung geh”rigen L„ndern blichen Abkrzungen darstellen. Der fragwrdige Sinn des Vorschreibens der Form des Protokolls ist, eine automatische Auswertung (z.B. Prfung) zu erm”glichen. Hinweis: Dieser Befehl wird von [D3.1Z] mit der Begrndung abgelehnt, daá er nicht nach ZConnect passe, weil Fileserver ber die Onlinephase realisiert werden k”nnen. Dieser Einwand ist nur in dem Maáe richtig, wie er fr den gesamten ZConnect-Maps gilt. Hierzu mehr im Abschnitt "Kritik und Vorschl„ge" in diesem Kapitel. Im brigen ist FILES vom Gremium beschlossen worden und hat somit Gltigkeit - ZConnect 3.1 --------------------------------------------------------- 172 - HOLD ON bzw HOLD OFF Funktion: stellt eine Art "Urlaubsfunktion" dar. Mit diesem Befehl bestellt die Anwenderin alle Bretter ab (HOLD ON), kann aber z.B. Wochen sp„ter wieder mit einer einzigen Anweisung an Maps (HOLD OFF) genau die Bretter bestellen, die zum Zeitpunkt der Abbestellung bestellt waren, da das System sich diese merkt. Nachrichtenk”rper: wird ignoriert Antwort: hat einen leeren Nachrichtenk”rper ----------------------------------------------------------------------------- INDEX Funktion: dient der Anforderung eines Brettinhaltsverzeichnisses. Nachrichtenk”rper: enth„lt pro Zeile einen Brettnamen (Groá-/Kleinschreibung wird nicht beachtet), beginnend mit einem Slash. Zeilen ohne Slash an der ersten Position werden ignoriert. Antwort: enth„lt im Nachrichtenk”rper die ZConnect-Header aller Nachrichten in den in der Anfrage angegebenen Brettern (sofern zul„ssig, also z.B. Bretter nicht gesperrt sind). Diese Header werden jeweils durch eine Leerzeile voneinander getrennt. Genauer gesagt wird gefordert, daá Header durch eine Leerzeile abgeschlossen sein mssen - das bedeutet einerseits, daá beliebig viele Leerzeilen zwischen zwei Headern stehen k”nnen und andererseits, daá auch hinter dem letzte Header eine Leerzeile eingefgt werden muá. Die Header werden nicht ganz unbehandelt belassen: 1. Alle EMPs bis auf den angefragten (also den denjenigen Brettnamen enthaltenden EMP, der angefragt wurde) werden gel”scht 2. Optional k”nnen ROT, F-*, G-*, U-*, X-*, Z-*, ZNETZ-*, GATE, MAILER und nicht definierte Headerinformationen gel”scht werden - ZConnect 3.1 --------------------------------------------------------- 173 - ORDER Funktion: dient der Anforderung von Nachrichten aus Brettern, die beim angeschriebenen System archiviert werden. Nachrichtenk”rper: enth„lt zeilenweise eine Beschreibung der gewnschten Nachrichten. Die Beschreibung folgt folgender Syntax: Der Brettname muá wie immer mit einem Slash beginnen und wird ohne Bercksichtigung der Groá-/Kleinschreibung behandelt. Als Whitespace, welches genau einmal auftritt, ist ASCII 9 (TAB) oder 32 (Leerzeichen) zul„ssig. Bei der Message-ID wird fr den Teil vor dem "@" die Groá-/Kleinschreibung beachtet, fr den Teil dahinter hingegen nicht (vgl. Headerinformation MID). Antwort: ist eine Bin„rnachricht und enth„lt einen ZConnect-Puffer mit den angeforderten Nachrichten. Es drfen auch mehrere Bin„rnachrichten erzeugt werden, eine einzelne bestellte Nachricht sollte dann aber nicht ber mehrere Antwortnachrichten verteilt sein. [D3.1Z] m”chte dies sogar verboten wissen. Genau einer der Antwortnachrichten kann ein Protokoll als Kommentar vorangestellt werden (vgl. KOM-Headerinformation). Das vorgeschlagene Format ist beinahe identisch zu jenem beim Maps-Befehl FILES beschriebenen: Lediglich die "Ordered"-Zeile folgt nun folgender, ver„nderter Syntax: Ordered (x bytes) (x.x ) - ZConnect 3.1 --------------------------------------------------------- 174 - ORDER-PM Funktion: entspricht jener von ORDER, unterscheidet sich nur im Format der Antwort. Nachrichtenk”rper: wie bei ORDER beschrieben Antwort: besteht aus mehreren Textnachrichten. Die angeforderten Nachrichten werden einzeln als private Nachricht an die Anfordernde verschickt. Dabei wird folgender Minimalheader vorgeschlagen wird: EMP: OEM: ABS: MAPS@ OAB: STAT: CTL MID: @ Genau betrachtet w„re diese Headerspezifikation ein weiterer Fall des automatischen Weiterleitens, bei dem die vorgeschlagene Headerinformation STAT: CTL allerdings etwas fehl am Platze anmutet. Da es sich um einen Vorschlag handelt, wird an dieser Stelle vorgeschlagen, STAT: CTL nicht einzusetzen. Die vermutlich geplante Anwendung, der anfordernden Software die automatische Behandlung der Antworten zu erm”glichen, erbrigt sich, da ORDER-PM in seiner Gesamtheit nicht fr ZConnectsysteme konzipiert ist. Das bei ORDER beschriebene Protokolllayout gilt auch fr ORDER-PM, wird hier aber nicht als Kommentar einer Antwortnachricht vorangestellt, sondern als einzelne Textnachricht versandt. Eine Abweichung in der Beschreibung des Protokolls bei [D3.1M] weist darauf hin, daá daran gedacht gewesen sein k”nnte, pro ORDER-PM Befehl nur die Bestellung genau einer Nachricht zu erm”glichen. Dies mag eine vorsichtige, strenge Implementierung bercksichtigen, sinnvoll erscheint es hingegen nicht. Hinweis: Dieser Befehl wird von [D3.1Z] mit der Begrndung abgelehnt, er unterscheide sich "nur durch verstmmelte Header von ORDER". Das Format des Headers ist beim ZConnect-Maps jedoch ausdrcklich nur als Vorschlag definiert. Tats„chlich bricht ORDER-PM mit der Absicht von ZConnect-Maps, maschinenlesbare Antworten zu produzieren. Dies tut HELP allerdings auch. Die genannte Anwendung des Requests ber das Netz von AnwenderInnen, die das ZConnect-Datenformat nicht verarbeiten k”nnen, ist jedoch Grund genug, die - ZConnect 3.1 --------------------------------------------------------- 175 - Spezifikation von ORDER-PM in diese Aufz„hlung aufzunehmen. Zudem ist der Befehl vom Gremium beschlossen worden. ----------------------------------------------------------------------------- _3.5.2. Kritik und Vorschl„ge_ _3.5.2.1. Maps und die vergessene Onlinephase_ Die (Ab-)Bestellung von Brettern ber Mails an eine automatische Userin ist hinsichtlich Brettbestellungen beim eigenen Server ein Relikt aus Zeiten, als ohne Protokoll„nderungen die neu erkannte Notwendigkeit der Bestimmung bezogener Bretter durch die AnwenderInnen selbst (also ohne Eingriff der SystembetreiberInnen) eingefhrt werden sollte. In Store-And-Forward verwendenden Netzen ist dies fr die Kommunikation mit entfernten Systemen nachwievor sinnvoll. Bei Direktverbindungen, wie sie zwischen zwei direkt miteinander z.B. per Telefonleitung telefonieren und hierbei die ZConnect-Onlinephase einsetzen, w„re hingegen eine Integration der meisten Maps-Befehler in diese Onlinephase sinnvoll. ADD- und DEL-Listen k”nnten online bertragen und beantwortet werden (ggf. im Nach-Logoff - vgl. EXECUTE: L). LIST und HELP sind gar problemlos durch Definition neuer Magics fr den FILEREQ-Header integrierbar. Auch die Online-Verwendung von ORDER und INDEX ist gut denkbar. ADD und DEL als Maps-Kommandos haben jedoch nicht nur in Protokollvarianten wie Janus ihre Daseinsberechtigung. Es ist durchaus denkbar, daá ein System seinen UserInnen erlaubt, fr das System Bretter beim Server zu bestellen (wobei das Serversystem diese Erlaubnis technisch umsetzen k”nnen muá, was derzeit nicht gegeben sein drfte - s.u.). Jedoch w„re es dem ZConnect-Datenformat und dem Anliegen des ZConnect-Maps, UserInnen weitgehend von der technischen Seite der Maps-Kommunikation zu entlasten, angemessen, wenn Nachrichten von und an Maps regelm„áig das STAT: CTL Flag erhalten wrden. Am Fehlen dieses Flags w„ren dann auch Anfragen/Antworten alter, nicht ZConnect-kompatibler Maps-Implementationen zu erkennen. Unabh„ngig von einer m”glichen Einfhrung von ORDER und INDEX in die Onlinephase sind diese und ORDER-PM (welches online unsinnig ist, da das anrufende System mit Sicherheit ZConnect-f„hig ist) auch als Maps-Kommandos sinnvoll. Mit ihnen kann ber Systemgrenzen hinweg z.B. auf die Daten von Archivsystemen zugegriffen werden. Der HOLD Befehl wird immer nur gegenber dem direkt servenden System eingesetzt werden. Fr Janus-Protokollvarianten ist dieser Befehl daher sinnvoll, bei einem kompletten ZConnect geh”rt er jedoch eindeutig in die Onlinephase. _3.5.2.2. Maps aus Sicht des angeschriebenen Systems_ Die herk”mmliche Sichtweise, nur bestimmten UserInnen fremder Systeme die "Mapsberechtigung" einzeln (manuell oder per Onlinephase) zuzuteilen, muá berdacht werden, da der ZConnect-Maps systembergreifend konzipiert ist. Denkbar w„re, daá ein Mailboxsystem seine UserInnen berechtigt, bei einem Serversystem beliebig Bretter fr das Mailboxsystem zu bestellen. - ZConnect 3.1 --------------------------------------------------------- 176 - Die Einstellungsm”glichkeiten von Systemen mssen also sehr erweitert werden. So mssen bei einigen Maps-Befehlen Anfragen von beliebigen Absenderinnen beantwortet (z.B. ORDER) werden und bei anderen (z.B. ADD) m”glicherweise nur diejenigen, die von bestimmten, autorisierten Systemen aus abgesandt wurden. _3.5.2.3. Schwierigkeiten bei der Umsetzung des Gedankens, Maps_ _transparent zu gestalten_ Die Antwort auf den HELP-Befehl kann nur insofern durch z.B. ein Pointprogramm verarbeitet werden, als der empfangene Hilfstext nicht als normale Mail sondern als Text mit einer bestimmten Zugeh”rigkeit bewertet und z.B. nicht in das Postfach der Empf„ngerin einsortiert sondern gesondert gespeichert wird. Fr eine sinnvolle und zugleich m„chtige Implementierung von ZConnect-Maps fehlt jedoch eine Funktion, die es einem UserInneninterface erlaubt, den konkreten Befehlsumfang eines Maps abzufragen. # Ein solches Interface k”nnte natrlich testweise alle theoretisch # m”glichen Maps-Befehle abschicken und die Antworten auswerten. Dies # ist aber wohl als unsch”n abzulehnen. Daher wird an dieser Stelle # ein weiterer Maps-Pflichtbefehl vorgeschlagen, ber den das Gremium # abstimmen sollte: - ZConnect 3.1 --------------------------------------------------------- 177 - FEATURES Funktion: dient der Feststellung des Befehlsumfangs der mit diesem Befehl konfrontierten Maps-Implementation. Nachrichtenk”rper: wird ignoriert Antwort: enth„lt zeilenweise ohne Leerzeilen eine Aufz„hlung der dem Maps bekannten Befehle. Es wird pro Zeile nur ein Befehl angegeben. Groá-/Kleinschreibung ist zu ignorieren. Kommentarzeilen sind m”glich; sie werden durch ein Semikolon in der ersten Spalte gekennzeichnet. Es gibt keine Zeilenl„ngenbegrenzung, Whitespaces sind verboten. Zeilen werden durch das bliche CR/LF (ASCII 13/10) voneinander getrennt oder enden mir dem Dateiende. Wenn die aufgelisteten Befehle den Namen einer der ZConnect-Maps-Befehle tragen, so kann die anfragende Applikation davon ausgehen, daá sich der Befehl so verh„lt, wie der ZConnect-Maps-Standard es festlegt. Mit der šbertragung von unbekannten Befehlen muá gerechnet werden, auch mit solchen, die aus mehreren W”rtern bestehen - entsprechend der Vorschrift, daá Whitespaces verboten sind, k”nnen solche Befehlslisteneintr„ge als fehlerhafte Zeilen ignoriert oder aufgrund besonderer Vereinbarung ausgewertet werden. Ein Befehl wie "LIST MY BRETTER" darf aber niemals als "LIST" miáverstanden werden. Hinweis: Die m”gliche šbertragung einer Versionsnummer des ZConnect-Maps' erscheint nicht unbedingt unn”tig (die zuknftige Bedeutung oder Antwortform eines Befehls k”nnte sich mit neuen Maps-Spezifikationen „ndern). Jedoch ist der Transport bei den derzeit bekannten Befehlen mal als Kommentar (vgl. LIST), mal als eigenst„ndige Zeile (vgl. ORDER) definiert oder besser: undefiniert geblieben. Fr FEATURES wird vorgeschlagen, die erste Zeile der Feature-List grunds„tzlich der Versionsangabe vorzubehalten. Das Format sollte hierbei dem des Antwortprotokolls beim FILES-Befehl folgen. - ZConnect 3.1 --------------------------------------------------------- 178 - *4. ERGŽNZENDE INFORMATIONEN* Dieser Teil der Dokumentation besteht bis auf wenige Ausnahmen aus komplett anzuheftenden Fremdtexten. Diese Vervollst„ndigung soll nicht Bestandteil der Aufgabenstellung sein, unter den einzelnen šberschriften ist aber angegeben, welche Informationen gemeint sind, und, sofern bekannt, wo diese erh„ltlich sind. Bei einigen Fremdtexte, z.B. RFCs, ist eine Anheftung der Originaltexte sinnfrei, da diese frei erh„ltlich sind. Bei besonders wichtigen Texten w„re aber eine deutschsprachige šbersetzung durchaus angebracht. _4.1. Datenschutzbestimmungen_ Datenschutzbestimmungen sind im Globalen Dorf eine sehr volumin”se Angelegenheit. In der Bundesrepublik sind sie zudem zum gr”áten Teil L„ndersache. Die jeweils gltigen Datenschutzgesetze k”nnen bei den Landesdatenschutzbeauftragten zumeist kostenlos angefordert werden. An dieser Stelle soll eine grundlegende Zusammenfassung der wichtigsten Grundregeln erfolgen, also insbesondere auf die zeitlich begrenzte Zul„ssigkeit von Logdateien und Protokollen ber die UserInnenaktivit„t hingewiesen werden. Dazu geh”rt hierher eine šbersicht ber die Anschriften der Landesdatenschutzbeauftragten, welche ihrerseits bei den Einzelnen Beauftragten erh„ltlich ist. _4.2. Fremdformate_ Es ist nicht Aufgabe einer reinen ZConnect-Dokumentation alle Konkurrenzprotokolle aufzulisten und zu beschreiben. Beschreibungen von Fremdformaten sind jedoch insbesondere da hilfreich, wo klare Bezugspunkte zu ZConnect bestehen (z.B. Z3.8 als Vorg„ngerprotokoll oder die RFC-Suite als Weltstandard). _4.2.1. RFC_ Aus dem RFC-Bereich sind insbesondere die Nummern 822 (Mail), 1036 (News), 1521 (MIME), 1522 (MIME Part 2) und 1563 (text/enriched) interessant. _4.2.2. Z 3.8_ Das Z3.8 Netcallverfahren besteht wie ZConnect aus einer Login-/ Datentauschphase und einem Datenformat. Letzteres hat heute keinerlei Bedeutung mehr. An dieser Stelle wird daher nur auf das "Hitchhiker's Guide to the /Z-NETZ" ([Hitchhiker]) hingewiesen. Das Loginverfahren von Z3.8 wird bei den sehr weit verbreiteten JANUS-Protokollvarianten verwendet und ist daher im Abschnitt "Janus und verwandte Protokollvarianten" ausfhrlich beschrieben. _4.2.3. Fido_ Die Regelungen fr Fido-Datenaustausch und -format sind umfangreich und sollten an dieser Stelle nur soweit grob beschrieben werden, daá die "F-"-Headerzeilen ZConnects dadurch illustriert werden. - ZConnect 3.1 --------------------------------------------------------- 179 - _4.3. MIME_ Nach Diskussion und Entscheidungsfindung durch das Gremium ist es von groáer Wichtigkeit, MIME ausfhrlich zu beschreiben. Anspruch sollte dabei sein, die Lektre der einschl„gigen RFC-Regelungen berflssig zu machen, um den "einfacheren" Charakter von ZConnect aufrecht zu erhalten. _4.4. Einige softwaretechnische Vorschl„ge_ Die L”sung einiger Standardprobleme bei der Implementierung von ZConnect kann die Datensicherheit im Netz beeinflussen. Insbesondere schnelle, fehlerfreie Dupecheckalgorithmen k”nnen helfen, eine "beliebte" Fehlerquelle auszuschlieáen. _4.4.1. Hashverfahren fr Rekursionscheck_ An dieser Stelle soll ein auf einem, Nicht-InformatikerInnen meistens unbekannten, Hashverfahren aufbauender Check auf doppelte Message-IDs zumindest im Pseudocode beschrieben werden. Evtl. kann dabei aufgezeigt werden, wie die Forderung von "90 Tagen Aufbewahrungsfrist" fr Message-IDs mit schnellem Check kombiniert werden kann. Da einige ProgrammiererInnen bereits dazu bergehen, nicht mehr die komplette Message-ID zu prfen, sondern aus "Effizienzgrnden" bereits „hnliche IDs, die z.B. dieselbe CRC-Summe ergeben, als Dupe zu l”schen, scheint ein entsprechender Verfahrensvorschlag geboten. - ZConnect 3.1 --------------------------------------------------------- 180 - *5. STAND DER DINGE* An dieser Stelle sollte immer der aktuelle Stand der Dokumentation und unmittelbar bevorstehende Entscheidungen des Gremiums erw„hnt werden. ZC 3.1 ist mit dem Ende der fnften Gremiumswahl am 5.3. geschlossen worden. Zur CeBIT'95 erschien daraufhin [D3.1Z], welches in der Folge zu Irritationen wegen Widersprchen zwischen Gremiumsbeschlssen und [D3.1Z] gefhrt hat. Es herrscht Einigkeit und Wille, eine grundlegend neue Dokumenation zu schaffen. Dieser Text soll dazu die Grundlage stellen. In der Diskussion ist, wie die Entwicklung von ZConnect weiter verlaufen soll. Dabei geht u.a. um die Frage, ob ZConnect in Zukunft noch ZConnect heiáen soll, und wie die Bindung der Zerberus GmbH zu ZConnect vollst„ndig getrennt werden kann, um das Kompetenzwirrwarr zu entwirren und gleichzeitig Copyright-Fragen eindeutig zu beantworten. - ZConnect 3.1 --------------------------------------------------------- 181 - *ANHŽNGE* _A) Literaturverzeichnis_ _Verwendete Quellen_ [PM1] Mndliche, pers”nliche Mitteilung von Felix Heine (Zerberus GmbH) vom 25.2.1995 [PM2] Pers”nliche Mitteilung von Peter Mandrella (Crosspoint-Autor) vom 16.5.1995 [PM3] Pers”nliche Mitteilung von Holger Lembke (!!MessageBase-Autor) vom 25.5.1995 [D3.0] Zerberus GmbH: "ZConnect, das Datenaustauschformat fr Mailbox-Netze, Version 3.0", Verlag Art d'Ameublement, Bielefeld 1993 [D3.1M] Žnderungssammlung M„rz bis Dezember 1993, z.B. als Nachricht von hd@wf-hh.sh.sub.de vom 23.02.1995, Message-ID 5gPrhK4WbB@p-alf.wf-hh.sh.sub.de [D3.1P] ZConnect-Proposal, zusammengestellt von Martin Husemann, z.B. als Nachricht von h.fricke@laguna.han.de vom 15.2.1995, Message-ID: 5FuuqDhpZQB@ncbmail-development-labs.laguna.han.de [D3.1Z] Zerberus GmbH: "ZConnect. Datenaustauschformat fr Mailboxnetzwerke Version 3.1", Verlag Art d'Ameublement, Bielefeld 1994 [B1] Nachricht von H. Fricke (H.Fricke@laguna.zer) vom 5.12.1992, Message-ID: 4rGKpeGhwz@LAGUNA [B2] Nachricht von martin%bi-link.owl.de@UUCP.ZER (Martin Husemann) vom 30.7.1993 in /T-NETZ/SUPPORT/ZCONNECT, Message-ID: CB01q1.744@bi-link.owl.de [B3] Nachricht von Martin Husemann in /T-NETZ/SUPPORT/ZCONNECT, Message-ID: idC8LJqA.DB9@bi-link.owl.de [B4] Nachrichten in /T-NETZ/ZCONNECT/DISKUSSION: (zB. von Packbart@people-s.people.sub.org, Message-ID: 5KO_df2ufRB@point47.people-s.people.sub.org und holger_lembke@laguna.han.de, Message-ID: r0mrmjb8je33h6ob877SKgxholger_lembke@holger.laguna.han.de [B5] Nachricht von GATEKOO@heather.hanse.de vom 4.7.1994, Message-ID: 17.10937@heather.hanse.de [B6] Nachricht von hd@wf-hh.sh.sub.de in /T-NETZ/ZCONNECT/MELDUNGEN vom 23.2.1995, Message-ID: 5g0d4-pW3bB@p-alf.wf-hh.sh.sub.de [B7] Nachricht von holger_lembke@laguna.han.de (Holger Lembke) vom 1.6.1995, Message-ID: 58cp7w8eqf33qey8e3fsyhsholger_lembke@holger.laguna.han.de [B8] Nachricht von hd@wf-hh.sh.sub.de vom 14.3.1995, Message-ID: 5hqnSF0_WbB@p-alf.wf-hh.sh.sub.de [B9] Nachricht von hd@wf-hh.shnet.org vom 1.10.1995, Message-ID: 5v1oc-Y$WbB@p-alf.wf-hh.shnet.org [Hitchhiker] Hitchhikers Guide to the /Z-NETZ, z.B. erh„ltlich in der Crosspoint-Supportbox (Telefonnummer 06241-592184) [JanusPlus] Nachricht von h.fricke@laguna.han.de vom 1.6.1995, Message-ID: 5n0MZ0D_ZQB@ncbmail-developement-labs.laguna.han.de [Netikette] Netikette, in der aktuellen Fassung regelm„áig im Brett /Z-NETZ/WICHTIG als Nachricht von KERSTIN@TTB.aworld.de zu finden - ZConnect 3.1 --------------------------------------------------------- 182 - [Mitglieder] Liste der Gremiumsmitglieder, in der aktuellen Fassung regelm„áig im Brett /T-NETZ/ZCONNECT/MELDUNGEN zu finden, z.B. als Nachricht von hd@wf-hh.shnet.org vom 15.6.1995, Message-ID: 5nrR_6T_WbB@p-alf.wf-hh.shnet.org [Netzrecht] Gnther Freiherr von Gravenreuth: "Netze in den Maschen der Gesetze", Compulaw-Verlag, Mnchen 1993, S. 10ff [RFC822] RFC822 definiert das Aussehen und die Behandlung von Internet-Messages, geschrieben von David H. Crocker, 13. August 1982 [RFC1521] RFC1521 definiert die Multipurpose Internet Mail Extension, geschrieben von N.Borenstein et al, September 1993 [RFC1563] RFC1563 definiert den MIME-Content-Type text/enriched, geschrieben von N.Borenstein et al, Januar 1994 [Wahl1] Ergebnis der ersten Wahl des Gremiums zu ZConnect, im Brett /T-NETZ/ZCONNECT/MELDUNGEN zu finden, z.B. als Nachricht von hd@wf-hh.shnet.org vom 7.6.1995, Message-ID: 5nPL4bJ_WbB@p-alf.wf-hh.shnet.org [Wahl2] Siehe [Wahl1], Message-ID: 5nPL5f0_WbB@p-alf.wf-hh.shnet.org [Wahl3] Siehe [Wahl1], Message-ID: 5nPL6EMKWbB@p-alf.wf-hh.shnet.org [Wahl4] Siehe [Wahl1], Message-ID: 5nPL6i14WbB@p-alf.wf-hh.shnet.org [Wahl5] Siehe [Wahl1], Message-ID: 5nPL7gq4WbB@p-alf.wf-hh.shnet.org und zus„tzlich das Addendum zur fnften Wahl, die Nachricht mit der Message-ID:5vlod264WbB@-alf.wf-hh.shnet.org _Empfohlene Literatur_ [DES] A.K. Dewdney: "Computer-Kurzweil", in: Spektrum der Wissenschaft, Januar 1989, S. 6 bis 10 [RFC1036] Standard for interchange of USENET messages, geschrieben von M.R. Horton und R.Adams, Dezember 1987 [RFC1522] MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text, geschrieben von K. Moore, September 1993 - ZConnect 3.1 --------------------------------------------------------- 183 - _B) Glossar_ Ein Glossar soll die verwendeten unausweichlichen Fachtermini erl„utern. Darberhinaus sollen auch Begriffe, die in der Dokumentation selber keine Verwendung finden, hier untergebracht werden. Aktuell werden nur diejenigen Begriffe hier erl„utert, die ZConnect-spezifisch sind oder h„ufig verwendet werden. Brett Siehe GABELN Control-Nachricht Nachricht eines bestimmten Formats, die z.B. fr das L”schen von Nachrichten, das Einrichten eines Bretts o.„. sorgt Crossposting (Physikalisch) eine Nachricht mit mehreren Empf„ngerInnenangaben Dupe Doppelt vorhandene Nachricht Dupecheck Testen auf doppelt vorhandene Nachrichten (bei ZConnect anhand der Message-ID). Gefundene Dupes werden blicherweise gel”scht GABELN Gruppen, Areas, Bretter, Echos, Listen, Newsgroups - Kunstbegriff, welcher die in verschiedenen Netzzusammenh„ngen gebr„uchlichen Bezeichnungen fr offentliche Nachrichtenforen zusammenfaát kreuzvernetzt /Z-NETZ/FORUM/NETZWESEN und de.soc.netzwesen sind kreuzvernetzt. Das heiát, daá die in eines dieser ->Bretter geschickte Nachricht sowohl im deutschsprachigen Usenet als auch im /Z-Netz verteilt wird, ohne als ->Crossposting verschickt werden zu mssen. Wird in kreuzvernetzte Bretter ein Crossposting verschickt, kommt es zu ->Nopes Mail Begriff aus der ->RFC-Welt fr eine private Nachricht. Synonym: PM (private Mail) Mailbox Per Modem anrufbares System, welches blicherweise fr mehrere ->Points und/oder ->OnlineuserInnen den Netzanschluá gew„hrleistet, indem es Nachrichten fr sie entgegennimmt bzw. verteilt News Begriff aus der ->RFC-Welt fr eine ”ffentliche Nachricht. Synonym: Brettnachricht Nope Verkrzt gesagt das Gegenstck zu einem ->Dupe, also eine gar nicht vorhandene Nachricht. Ein Nope hebt sich von einer normalen, nicht vorhandenen Nachricht dadurch ab, daá er nicht als Nope gedacht war :-). Er entsteht, wenn eine Nachricht irrtmlich als Dupe entsorgt wird. Dies kann passieren, wenn eine Nachricht auf mehreren Wegen gleichzeitig in ein ->kreuzvernetztes ->Brett geschickt wird. Wird also z.B. eine - ZConnect 3.1 --------------------------------------------------------- 184 - Nachricht nach /Z-NETZ/FORUM/NETZWESEN und de.soc.netzwesen geschickt, wobei die Message-ID gleich ist (z.B. durch ein fehlerhaftes Gateway), entsteht ein Nope, weil auf Systemen die beide Bretter fhren, die sp„ter ankommende Variante als Dupe gel”scht wird. Dann bekommen z.B. die LeserInnen von de.soc.netzwesen die Nope-Nachricht nicht zu Gesicht, w„hrend sie in /Z-NETZ/FORUM/NETZWESEN vorhanden ist OnlineuserIn UserIn, der/die in physikalischer Verbindung z.B. zu einer Mailbox steht, etwa um Nachrichten zu lesen Point UserIn, der/die nur kurz und periodisch zu einer Mailbox Kontakt aufnimmt, um paketweise fr ihn/sie bestimmte Daten abzuholen und diese nach Trennung der Verbindung zu verarbeiten (z.B. Nachrichten zu lesen) RFC Request For Comment, mit diesem Krzel werden Texte gekennzeichnet, die fr die Verwendung im Internet gedachte Festlegungen enthalten - ZConnect 3.1 --------------------------------------------------------- 185 - _C) ZC 3.1 Grammatik in BNF_ Auch wenn eine Protokollspezifikation nicht kontextfrei und die Semantik nur schwer formal zu beschreiben ist, sollte zum Zwecke der Eindeutigkeit der Notation die Syntax ZConnects in Backus Naur Form notiert werden. Fleiáarbeit. - ZConnect 3.1 --------------------------------------------------------- 186 - _D) Datenformatsbersicht_ Die folgende, tabellarische Aufstellung gibt eine šbersicht ber alle ZConnect-Headerinformationen. Die Spalte "Minimal-ZC" stellt den Versuch dar, diejenigen Headerinformationen zu kennzeichnen, die eine Implementation minimal auswerten/erzeugen k”nnen muá, um sich ZConnect-kompatibel nennen zu drfen. Naturgem„á geh”ren alle Pflichtinformationen dazu, genauso naturgem„á reicht aber eine Untersttzung der Pflichtinformationen nicht aus, um ZConnect-Nachrichten korrekt handhaben zu k”nnen. _D) 1. Tabellarische šbersicht der Headerinformationen_ Kennung | P | N | S | N | M | | f | u | t | u | i | | l | r | a | r | n | | i | | b | | i | Legende: | c | e | i | P | m | | h | i | l | M | a | x = Ja | t | n | | | l | - = Nein | | m | | | - | E = Erzeugen | | a | | | Z | A = Auswerten | | l | | | C | * = Siehe Dokumentation ----------------------+---+---+---+---+---+ v = veraltet ABS | x | x | - | - | x | ----------------------+---+---+---+---+---+ ANTWORT-AN | - | - | - | - | x | ----------------------+---+---+---+---+---+ BET | x | x | - | - | x | ----------------------+---+---+---+---+---+ BEZ | - | - | x | - | E | ----------------------+---+---+---+---+---+ CHARSET | - | x | - | - | A | ----------------------+---+---+---+---+---+ CONTROL: ADD | - | x | - | - | A | ----------------------+---+---+---+---+---+ CONTROL: CANCEL | - | x | - | - | A | ----------------------+---+---+---+---+---+ CONTROL: DEL | - | x | - | - | A | ----------------------+---+---+---+---+---+ CRYPT | - | x | - | x | - | ----------------------+---+---+---+---+---+ CRYPT-CONTENT-CHARSET | - | x | - | x | - | ----------------------+---+---+---+---+---+ CRYPT-CONTENT-KOM | - | x | - | x | - | ----------------------+---+---+---+---+---+ CRYPT-CONTENT-TYP | - | x | - | x | - | ----------------------+---+---+---+---+---+ DDA | - | x | - | - | - | ----------------------+---+---+---+---+---+ DISKUSSION-IN | - | - | - | - | A | ----------------------+---+---+---+---+---+ EB | - | - | - | x | - | ----------------------+---+---+---+---+---+ EDA | x | x | - | - | x | ----------------------+---+---+---+---+---+ EMP | x | - | - | - | x | ----------------------+---+---+---+---+---+ - ZConnect 3.1 --------------------------------------------------------- 187 - Kennung | P | N | S | N | M | | f | u | t | u | i | | l | r | a | r | n | | i | | b | | i | Legende: | c | e | i | P | m | | h | i | l | M | a | x = Ja | t | n | | | l | - = Nein | | m | | | - | E = Erzeugen | | a | | | Z | A = Auswerten | | l | | | C | * = Siehe Dokumentation ----------------------+---+---+---+---+---+ v = veraltet ERR | - | x | - | x | A | ----------------------+---+---+---+---+---+ ERSETZT | - | - | - | - | - | ----------------------+---+---+---+---+---+ FILE | - | x | - | - | - | ----------------------+---+---+---+---+---+ KOM | - | x | - | - | A | ----------------------+---+---+---+---+---+ KOP | - | - | - | - | - | ----------------------+---+---+---+---+---+ LANGUAGE | - | x | - | x | - | ----------------------+---+---+---+---+---+ LDA | - | x | - | - | - | ----------------------+---+---+---+---+---+ LEN | x | x | - | - | x | ----------------------+---+---+---+---+---+ MAILER | - | x | - | - | - | ----------------------+---+---+---+---+---+ MID | x | x | - | - | x | ----------------------+---+---+---+---+---+ MIME | - | x | - | x | - | ----------------------+---+---+---+---+---+ O-EDA | - | x | - | - | E | ----------------------+---+---+---+---+---+ O-ROT | - | x | - | - | E | ----------------------+---+---+---+---+---+ OAB | - | x | - | - | E | ----------------------+---+---+---+---+---+ OEM | - | - | - | - | E | ----------------------+---+---+---+---+---+ ORG | - | x | - | - | - | ----------------------+---+---+---+---+---+ PGP | - | x | - | x | - | ----------------------+---+---+---+---+---+ PGP-ID | - | x | - | - | - | ----------------------+---+---+---+---+---+ PGP-KEY-AVAIL | - | x | - | - | - | ----------------------+---+---+---+---+---+ PGP-KEY-COMPROMISE | - | x | - | * | - | ----------------------+---+---+---+---+---+ PGP-KEY-OWN | - | x | - | x | - | ----------------------+---+---+---+---+---+ PGP-PUBLIC-KEY | - | x | - | * | - | ----------------------+---+---+---+---+---+ PGP-SIG | - | x | - | - | - | ----------------------+---+---+---+---+---+ - ZConnect 3.1 --------------------------------------------------------- 188 - Kennung | P | N | S | N | M | | f | u | t | u | i | | l | r | a | r | n | | i | | b | | i | Legende: | c | e | i | P | m | | h | i | l | M | a | x = Ja | t | n | | | l | - = Nein | | m | | | - | E = Erzeugen | | a | | | Z | A = Auswerten | | l | | | C | * = Siehe Dokumentation ----------------------+---+---+---+---+---+ v = veraltet POST | - | x | - | - | - | ----------------------+---+---+---+---+---+ PUBLIC-KEY | v | v | v | v | v | ----------------------+---+---+---+---+---+ ROT | x | x | - | - | x | ----------------------+---+---+---+---+---+ SIGNED | - | x | - | - | - | ----------------------+---+---+---+---+---+ SPERRFRIST | - | x | - | - | * | ----------------------+---+---+---+---+---+ STAT: AUTO | - | x | - | - | - | ----------------------+---+---+---+---+---+ STAT: CTL | - | x | - | - | x | ----------------------+---+---+---+---+---+ STAT: DES | v | v | v | v | v | ----------------------+---+---+---+---+---+ STAT: EB | - | x | - | x | - | ----------------------+---+---+---+---+---+ STAT: NOCIPHER | - | x | - | x | * | ----------------------+---+---+---+---+---+ STAT: NOKOP | - | x | - | - | A | ----------------------+---+---+---+---+---+ STAT: PGP | v | v | v | v | v | ----------------------+---+---+---+---+---+ STAT: TRACE | - | x | - | x | E ---> falls TRACE empfangen ----------------------+---+---+---+---+---+ STICHWORT | - | - | - | - | - | ----------------------+---+---+---+---+---+ TELEFON | - | x | - | - | - | ----------------------+---+---+---+---+---+ TRACE | - | x | - | - | A | ----------------------+---+---+---+---+---+ TYP | x | x | - | * | x | ----------------------+---+---+---+---+---+ VER | - | x | - | x | - | ----------------------+---+---+---+---+---+ VIA | * | - | x | x | E | ----------------------+---+---+---+---+---+ WAB | - | x | - | - | x | ----------------------+---+---+---+---+---+ ZUSAMMENFASSUNG | - | x | - | - | - | ----------------------+---+---+---+---+---+ _D) 2. Liste der Pflichtinformationen_ ABS, BET, EDA, EMP, LEN, MID, ROT, TYP, VIA (vgl. Dokumentation) - ZConnect 3.1 --------------------------------------------------------- 189 - _D) 3. Liste der das Routing beeinflussenden Informationen_ ABS.............. Hierhin sind ggf. Fehlermeldungen zu schicken ANTWORT-AN....... Hierhin sind ggf. Fehlermeldungen zu schicken CONTROL: CANCEL.. Hierauf ist ggf. mit L”schung zu reagieren DISKUSSION-IN.... Hierhin muá ein Pointprogramm ”ffentliche Antworten umleiten EMP.............. Hierhin soll die Nachricht ERR.............. Es handelt sich um eine ohne Rcksicht auf Verluste zu routende Fehlermeldung (LDA)............ Evtl. ist eine Nachricht nicht mehr zu routen, wenn sie das LDA-Alter berschreitet MID.............. Dupecheck ROT.............. Rekursionscheck (SPERRFRIST)..... Evtl. ist eine Nachricht nicht vor der SPERRFRIST an Endsysteme zu routen STAT: CTL........ Evtl. handelt es sich um eine auszuwertende Nachricht (CONTROL: CANCEL) STAT: NOKOP...... Bei Auspaltungen gemischtadressierter bzw. privater Nachrichten zu beachten TRACE............ Hierauf ist von Systemen eine Antwort zu generieren WAB.............. Hierhin sind ggf. Fehlermeldungen zu schicken - ZConnect 3.1 --------------------------------------------------------- 190 - _E) Routing_ Das Thema Routing ist sehr komplex. An dieser Stelle sollten Teile von RFC822 (Abschnitt "address specification") und die komplette RFC 1711 ("Classification in eMail Routing"), m”glichst in deutsche Sprache bersetzt, eingebunden werden. Wer immer diesen Anhang mit einem Text fllen m”chte, ist dringend dazu aufgefordert, diesen bei der DOKUKOO vorzustellen. - ZConnect 3.1 --------------------------------------------------------- 191 - _F) Janus und verwandte Protokollvarianten_ _JANUS_ Das Loginverfahren von Z3.8 hat Eingang in die JANUS-Protokollvariante von ZConnect gefunden. JANUS transportiert reines ZConnect-Datenformat, regelt Login und Pufferaustausch aber nicht per ZConnect-Onlinephase sondern nach im folgenden beschriebener Methode (vgl. [3.1P]). Die verwendeten šbertragungsprotokolle (ZModem o.„.) und Packprogramme (ZIP o.„.) mssen von den beteiligten Parteien zuvor mit einem menschlichen Protokoll vereinbart worden sein. Die "Z3.8-Onlinephase" wird aus Sicht der Anruferin beschrieben, die Sicht der Angerufenen ergibt sich entsprechend: 0. Verbindung aufbauen 1a. Auf den String "Username:" warten 1b. mit dem String "JANUS" und anschlieáendem CR (ASCII 13) antworten 2a. auf den String "Systemname:" warten 2b. eigenen Systemnamen bzw. Pointnamen (nicht UserInnennamen!) senden In [3.1P] wird empfohlen, die Reihenfolge von 1 und 2 beliebig zu erwarten. Groá- und Kleinschreibung sind zu beachten, der abschlieáende Doppelpunkt dient als hinreichende Unterscheidung zum vielleicht vor dem Login auftauchenden Text "Username" ohne Doppelpunkt. 3a. auf den String "Passwort:" oder "Password" warten 3b. mit dem Systempaáwort-String und abschlieáendem CR antworten 4. wenn nicht "Running ARC...." empfangen wird, entweder auflegen oder wieder bei 1a beginnen. Sollte das angerufene System "Netzzugriff verweigert" senden, ist auf jeden Fall aufzulegen 5. wenn nicht innerhalb einer voreingestellten Zeit (10 Minuten wird empfohlen) ein NAK (ASCII 21) oder ein ACK (ASCII 6) empfangen wird, dann auflegen. Andere empfangene Zeichen sind zu ignorieren. Auf ACK wird mit dem Fortfahren bei 5. reagiert, auf NAK mit dem Senden einer Seriennummer. Diese Seriennummer besteht aus vier beliebigen Bytes plus einem fr eine Prfsumme. Auf diese Weise prfen manche Produkte auf eventuelle Raubkopien (identische Seriennummer bei Senderin und Empf„ngerin). Software, die diesen Mechanismus nicht nutzen m”chte, sollte fnf Nullen (ASCII 0) senden. Es sollte nur eine begrenzte Zahl von NAKs akzeptiert werden (z.B. 10). Das Timeout kann ab dem ersten empfangenen NAK auf eine Minute oder weniger eingestellt werden. Zur Illustration als C++-Konstrukt beschrieben: - ZConnect 3.1 --------------------------------------------------------- 192 - void online (void) { // ... diverser Code ... BOOL bo_exit = false, bo_ok = false; word w_nakcount = 0; while (bo_exit) { switch (LeseZeichen()) { case ACK : bo_ok = bo_exit = true; break; case NAK: set_timeout(60); w_nakcount++; if (w_nakcount>10) { bo_exit = true; break; } sende_seriennummer(); default: } } if (!bo_ok) { // Auflegen, -r„umen und solche Sachen } else { // Weiter bei 6. } } 6. šbertragungsprotokoll starten zum Senden der einen (!) Datei mit allen Daten, die gesendet werden sollen. Die zu sendende Datei heiá "CALLER" und wird mit einer DOS-blichen Extension von DOS-blichen Packprogrammen versehen, also z.B. ".ZIP" oder ".ARJ" 7. Wenn das verwendete šbertragungsprotokoll eine Init-Sequenz hat, also das Senden mit einer bestimmten Bytesequenz ankndigt, dann auf diese Sequenz warten (genauso ist die Empf„ngerin w„hrend Phase 5 der šbertragung vorgegangen), andernfalls direkt weiter bei 8. - ZConnect 3.1 --------------------------------------------------------- 193 - 8. šbertragungsprotokoll starten zum Empfangen der einen (!) Datei mit allen Daten, die die Angerufene zu bertragen hat. Die zu empfangende Datei heiá "CALLED" und ist mit einer DOS-blichen Extension von DOS-blichen Packprogrammen versehen, also z.B. ".ZIP" oder ".ARJ" 9. Verbindung trennen 10. Wenn irgendeine Phase dieses Austausches nicht ordnungsgem„á durchgefhrt werden konnte, ist der gesamte Netcall als gescheitert zu betrachten. Insbesondere sind (evtl. erfolgreich) gesendete Nachrichten beim n„chsten Netcall erneut zu senden und empfangene Daten komplett zu l”schen. Dies gilt fr Anruferin und Angerufene gleichermaáen. Die empfangenen bzw. gesendeten Pakete sind ZConnect-Puffer. D.h. daá nach dem Auspacken beliebig viele Dateien mit den bekannten Dateinamen (siehe Kapitel "šbertragene Dateien") einzusortieren sind. _JANUS+_ JANUS+ ist als Reaktion auf die umst„ndliche Onlinephase ZConnects entstanden. Es verbreitet sich immer mehr, seine Dokumentation ([JanusPlus]) sollte daher im Rahmen der ZConnect-Dokumentation aufgenommen werden. Das Gremium entscheidet derzeit ber die Aufnahme des JanusPlus-Logins in den ZConnect-Standard. - ZConnect 3.1 ---------------------------------------------------------- 194 - _G) Zeichens„tze_ Hier sollten alle Zeichens„tze in Tabellenform aufgelistet werden, die im Rahmen von ZConnect relevant sind. Neben dem im Folgenden enthaltenen Standardzeichensatz sind dies vor allem (vgl. CHARSET) ISO1-9. Die IBM Codepages 437 und die internationale 850 sind von informativem Wert. Unicode als Zwei-Byte-Code ist sehr umfangreich und vermutlich nicht im Rahmen der ZConnect-Beschreibung dokumentierbar. - ZConnect 3.1 ---------------------------------------------------------- 195 - _ZConnect Standardzeichensatz_ In Textnachrichten sind folgende Zeichen erlaubt: 9 (), 13 (), 10 () sowie die folgenden Zeichen: IBM ISO Zeichen IBM ISO Zeichen 32 32 80 80 P 33 33 ! 81 81 Q 34 34 " 82 82 R 35 35 # 83 83 S 36 36 $ 84 84 T 37 37 % 85 85 U 38 38 & 86 86 V 39 39 ' 87 87 W 40 40 ( 88 88 X 41 41 ) 89 89 Y 42 42 * 90 90 Z 43 43 + 91 91 [ 44 44 , 92 92 \ 45 45 - 93 93 ] 46 46 . 94 94 ^ 47 47 / 95 95 _ 48 48 0 96 96 ` 49 49 1 97 97 a 50 50 2 98 98 b 51 51 3 99 99 c 52 52 4 100 100 d 53 53 5 101 101 e 54 54 6 102 102 f 55 55 7 103 103 g 56 56 8 104 104 h 57 57 9 105 105 i 58 58 : 106 106 j 59 59 ; 107 107 k 60 60 < 108 108 l 61 61 = 109 109 m 62 62 > 110 110 n 63 63 ? 111 111 o 64 64 @ 112 112 p 65 65 A 113 113 q 66 66 B 114 114 r 67 67 C 115 115 s 68 68 D 116 116 t 69 69 E 117 117 u 70 70 F 118 118 v 71 71 G 119 119 w 72 72 H 120 120 x 73 73 I 121 121 y 74 74 J 122 122 z 75 75 K 123 123 { 76 76 L 124 124 | 77 77 M 125 125 } 78 78 N 126 126 ~ 79 79 O 127 127  - ZConnect 3.1 ---------------------------------------------------------- 196 - IBM ISO Zeichen IBM ISO Zeichen 128 199 € 183 192 + 129 252 184 169 + 130 233 ‚ 189 162 + 131 226 ƒ 190 165 + 132 228 „ 198 227 + 133 224 … 199 195 | 134 229 † 207 164 - 135 231 ‡ 208 240 + 136 234 ˆ 209 208 - 137 235 ‰ 210 202 + 138 232 Š 211 203 + 139 239 ‹ 212 200 + 140 238 Œ 214 205 + 141 236 215 206 + 142 196 Ž 216 207 + 143 197 221 166 + 144 201 222 204 + 145 230 ‘ 224 211 à 146 198 ’ 225 223 á 147 244 “ 226 212 â 148 246 ” 227 210 ã 149 242 • 228 245 ä 150 251 – 229 213 å 151 249 — 230 181 æ 152 255 ˜ 231 222 ç 153 214 ™ 232 254 è 154 220 š 233 218 é 155 248 › 234 219 ê 156 163 œ 235 217 ë 157 216 236 253 ì 160 225   237 221 í 161 237 ¡ 238 175 î 162 243 ¢ 239 180 ï 163 250 £ 240 173 ð 164 241 ¤ 241 177 ñ 165 209 ¥ 243 190 ó 166 170 ¦ 244 182 ô 167 186 § 245 167 õ 168 191 ¨ 246 247 ö 169 174 © 247 184 ÷ 170 172 ª 248 176 ø 171 189 « 249 168 ù 172 188 ¬ 250 183 ú 173 161 ­ 251 185 û 174 171 ® 252 179 ü 175 187 ¯ 253 178 ý 181 193 + 182 194 | Diese Zeichen werden gem„á dem IBM-PC Zeichensatz interpretiert. Das Zeichen mit dem Code 255 wird bei Konvertierungen in ein # Leerzeichen gewandelt. Das Zeichen mit dem Code 254 ist in der # ZConnect-Ausgangsdokumentation nicht erw„hnt. Obige Tabelle zeigt in der Spalte "Zeichen" die gewnschte Darstellung auf dem Bildschirm, in der Spalte "ISO" den dafr n”tigen Code im ISO-1-Zeichensatz und in der Spalte "IBM" den in Textnachrichten verwendeten Code. Nicht aufgefhrte Codes sind verboten. - ZConnect 3.1 --------------------------------------------------------- 197 - _H) Zeitzonen_ Zone W/S Diff. Name NT W -11:00 Nome Time AHST W -10:00 Alaska-Hawaii Standard Time YST W -9:00 Yukon Standard Time PST W -8:00 Pacific Standard Time MST W -7:00 Mountain Standard Time PDT S -7:00 Pacific Daylight Time CST W -6:00 Central Standard Time MDT S -6:00 Mountain Daylight Time EST W -5:00 Eastern Standard Time CDT S -5:00 Central Daylight Time AST W -4:00 Atlantic Standard Time EDT S -4:00 Eastern Daylight Time NST W -3:30 Newfoundland Standard Time GST W -3:00 Greenland Standard Time ADT S -3:00 Atlantic Daylight Time AT W -2:00 Azores Time WAT W -1:00 West Africa Time UT W +0:00 Universal Time Z W +0:00 Universal Time GMT W +0:00 Greenwich Mean Time BST S +1:00 British Summer Time CET W +1:00 Central European Time MET W +1:00 Middle European Time MEWT W +1:00 Middle European Winter Time SWT W +1:00 Swedish Winter Time FWT W +1:00 French Winter Time HFH W +1:00 Heure Francais d'Hiver MEST S +2:00 Middle European Summer Time EET W +2:00 Eastern European Time SST S +2:00 Swedish Summer Time FST S +2:00 French Summer Time HFE S +2:00 Heure Francais d'Ete BT W +3:00 Bagdad Time ZP4 W +4:00 GMT 4 hours ZP5 W +5:00 GMT 5 hours IST W +5:30 Indian Standard Time ZP6 W +6:00 GMT 6 hours WAST W +7:00 West Australian Standard Time JT W +7:30 Java Time WADT S +8:00 West Australian Daylight Time CCT W +8:00 China Coast Time JST W +9:00 Japan Standard Time CAST W +9:30 Central Australien Standard Time SAST W +9:30 South Australien Standard Time EAST W +10:00 East Australien Standard Time CADT S +10:30 Central Australian Daylight Time SADT S +10:30 South Australien Daylight Time EADT S +11:00 East Australien Daylight Time NZT W +12:00 New Zealand Time NZST W +12:00 New Zealand Standard Time NZDT S +13:00 New Zealand Daylight Time - ZConnect 3.1 --------------------------------------------------------- 198 - _I) Liste der ZConnect-Programme_ Die folgende Liste ist eine von Hinrich Donner regelm„áig in /T-NETZ/ZCONNECT/MELDUNGEN ver”ffentlichte Liste der bekannten ZConnect-Programme und ihrer ProgrammiererInnen. [Dieser Anhang macht in der ASCII-Doku keinen Sinn, w„re nur in einer gedruckten Variante von Belang.] - ZConnect 3.1 --------------------------------------------------------- 199 - _Fuánoten_ In der Dokumentationsendversion werden diese Fuánoten in der N„her des Verweises auf sie untergebracht werden. {1} In der Praxis sind einige sehr weit verbreitete Anwendungen heute aufgrund sehr langer Innovationszyklen nicht sehr nah am Standard. Umgekehrt sorgt ihre hohe Verbreitung fr einen Defacto-Standard, den andere Applikationen bercksichtigen mssen. {2} T-NETZ steht fr "teilvernetztes /Z-NETZ" und beschreibt eine Brettgruppe, die unter Systemen auf freiwilliger Basis getauscht werden; die Namensgebung leitet sich also aus dem Pflichtbezug der /Z-NETZ-Hierarchie ab. šber eine Umwandlung von /T-NETZ nach /Z-NETZ/ALT wird aktuell heftig diskutiert. {3} [D3.0] verweist hierzu auf [RFC 822] {4} Als Smartserver wird dasjenige System bezeichnet, zu welchem das lokale System s„mtliche Nachrichten schickt, die es selber nicht oder nicht ber einen anderen Weg zustellen kann. Voraussetzung ist, daá die Empf„ngerInnenadresse syntaktisch korrekt ist. {5} "Re" krzt "Reply" ab, meint also "Antwort". {6} Es kann nicht tats„chlich von einer Chronologie gesprochen werden, da die Reihenfolge von Antworten nicht unbedingt eine chronologische Ordnung aufweisen muá. Insbesondere kann beim Antworten auf mehrere Nachrichten gleichzeitig keine chronologische Reihenfolge der bernommenen BEZ-Informationen festgestellt werden. {7} Die in der deutschsprachigen Netzlandschaft gebr„uchliche Bezeichnung "Mailbox" wrde im sprachlichen Herkunftsland des Begriffs auf Unverst„ndnis stoáen. Die dort blichere Bezeichnung ist "Bulletin Board System" (kurz: BBS). Da ZConnect zum allergr”áten Teil im deutschsprachigen Raum eingesetzt wird, soll dennoch von Mailboxen gesprochen werden. {8} Das erste System auf dem Routeweg (ROT-Information also leer) einer Mail darf EMPs in KOPs wandeln, wenn es wegen Schreibverboten in bestimmte Bretter unbedingt notwendig ist. Von diesem Recht Gebrauch zu machen, ist unbedingt als absoluter Notfall zu betrachten und gilt selbst dann noch als schlechter Stil. {9} Endsysteme, also solche Systeme, von denen die Nachricht nicht an ein anderes System weitergereicht wird, drfen mit den Nachrichten natrlich machen, was sie wollen. {10} Steuernachricht, welche zum Zwecke der L”schung ein zuvor versandten Nachricht dieser nachgesandt wird. {11} Auch wenn im folgenden von "der" abgespaltenen Empf„ngerin die Rede ist, so kann es trotzdem immer auch sein, daá die Abspaltung wiederum eine Nachricht an mehrere Empf„ngerinnen ist, wenn auch immer eine mit ausschlieálich privaten solchen. - ZConnect 3.1 --------------------------------------------------------- 200 - {12} Entsprechende Versuche ergaben, daá Systeme, die blicherweise auf TRACE antworten, dies bei fehlenden Parametern nicht tun. Dies l„át sich insbesondere fr die aktuelle Version 5.2, Release 3.0, des Zerberus-Mailboxprogramms aussagen. {13} Im FIDO-Netzwerk ist es blich, die Existenz privater Nachrichten zu verneinen. Aus diesem Grund sind z.B. Verschlsselungsprogramme wie Pretty Good Privacy verboten und werden die NetMails (Bezeichnung fr private Nachrichten) von SystembetreiberInnen eingesehen oder gar zensiert. Nach Ansicht netzerfahrener Datenschtzer ist die Interpretation privater Nachrichten als "”ffentliche Nachrichten mit nur einem/einer Empf„nger/in" unhaltbar. {14} Ein Byte hat nicht zwangsl„ufig acht Bit.