TheAnswer III

Das Amiga^{1} Point–Programm für Z–Netz^{1} und ZConnect^{1} kompatible Datennetze

Deutsche Dokumentation über

Header und Formate

Nachrichtenheader in TheAnswer und ZConnect vom 20.12.1993

Autoren und Verantwortliche:

Felix Heine, Martin Husemann, Matthias Jung, Wolfgang Mexner, padeluun, Hartmut Schröder und Rena Tangens

TheAnswer-Spezifikationen und LaTex-Satz: Toni Günzel–Peltner

ZERBERUS(R) ist ein eingetragenes Warenzeichen von Wolfgang Mexner. ZCONNECT(R) ist ein eingetragenes Warenzeichen der ZERBERUS GmbH.

1Copyrights in der Einleitung und in der Hauptdokumentation zu TheAnswerIII

Inhaltsverzeichnis

1 Einleitung 2 1.1 Das Copyright der TheAnswer-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Das Copyright von ZConnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Benutzung von Header-Variablen 3 2.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3 Bedingte Verzweigung durch IF/ENDIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4 Konstante Hilfsvariablen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Die möglichen Header–Informationen 6 3.1 ZConnect-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Weitere Headerzeilen von TheAnswer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3 Lokale Headerzeilen von TheAnswer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4 Weitere Headerzeilen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Index 14

Kapitel 1

Einleitung

Diese Dokumentation beschreibt Format und Aufbau von Header-Zeilen in ZConnect-Nachrichten-Headern. TheAnswerIII benutzt dieses Format für die Datenübertragung unter ZConnect und zur internen Datenverwaltung.

Hier werden alle unter ZConnect Version 3.00 und, bis zum Erscheinungsdatum bekannten, ZConnect Version 3.10 benutzten Nachrichtenheader beschrieben. Für Benutzer von TheAnswerIII ist diese Kenntnis notwenidg, wenn die frei definierbaren Header-Dateien und ihre Variablen, die sich an ZConnect-Header anlehnen, verändert werden sollen.

1.1 Das Copyright der TheAnswer-Header

Alle Rechte liegen bei Toni Günzel-Peltner. Lokale TA-Header dürfen unverändert in allen (auch kommerziellen) Applikationen lizenzfrei implementiert werden. In diesem Fall muß in der jeweiligen Dokumentation ein Copyright-Hinweis auf die TheAnswerIII-Header erfolgen.

1.2 Das Copyright von ZConnect

Dieser Copyright-Hinweis betrifft die vollständige ZConnect-Dokumentation, auch wenn hier nur die Header-Formate erklärt werden.

Alle Rechte liegen bei den Autorinnen. Dieses Dokument darf beliebig vervielfältigt und unverändert weitergegeben werden. ZCONNECT darf unverändert in allen (auch kommerziellen) Applikationen lizenzfrei implementiert werden. In diesem Fall muß in der jeweiligen Dokumentation und im jeweiligen Programm an gleicher Stelle, wie die Nennung der Programmautorinnen der Hinweis: “\begin{matrix}c \\ ◯ \end{matrix}< jahreszahlen > für ZCONNECT: ZERBERUS GmbH, Friedland (FRG). ZCONNECT ist ein eingetragenes Warenzeichen der ZERBERUS GmbH, Friedland (FRG)“ beziehungsweise eine Übersetzung in der Landessprache des jeweiligen Programms erscheinen. Werden in einem Programm keine Autorinnen oder Rechte genannt, muß der Hinweis an angemessener Stelle erfolgen. Die Dokumentation kann im Buchhandel unter der internationalen Bestellnummer ISBN 3–9802182–3–6 oder via BTX über die Bestellseiten des FOEBUD# oder direkt bei der ZERBERUS GmbH bestellt werden (Vorkasse, Scheck oder bar). Die Doku ist im Format DIN A 4, gebunden, mit einer Diskette versehen und kostet 30 DM.

Benutzung von Header-Variablen

2.1 Format

Header, die in einer Kopfdatei von TheAnswerIII benutzt werden, haben die Aufgabe einer Variablen. Sie werden, wenn die Datei von TheAnswerIII eingelesen wird, mit den Daten des Headers der aktuellen Nachricht gefüllt. Das Format lautet dabei:

%HeaderID: Zuerst kommt das Prozentzeichen (%), um TheAnswerIII mitzuteilen, daß nun eine Variable folgt. Danach folgt ohne Leerzeichen o.ä. die HeaderID, also ein Wort, daß den Header identifiziert. z.B. bedeutet ”EMP” Nachrichten-Empfänger. Welche Header-IDs möglich sind, ist in den nächsten Kapiteln aufgelistet. Nach der HeaderID folgt ein Doppelpunkt (:), um TheAnswerIII mitzuteilen, daß die Variable nun zu Ende ist. Ist eine Header-ID mehrfach in einer Nachricht, werden alle Einträge untereinander angezeigt.

2.2 Parameter

Besondere Variablen benötigen teilweise Parameter, andere Variablen können mit Hilfe bestimmter Parameter formatiert werden. Ein Parameter wird wie eine Variable in die Header-Datei geschrieben:

%Parameter: Also Prozentzeichen, Parametername, Doppelpunkt. Wird ein Parameter angegeben, so wird er auf die nächste Variable, die in der gleichen Zeile kommt angewandt. Wieviel Text dazwischen steht ist TheAnswerIII egal.

TheAnswerIII kennt folgende Parameter:

DATUM  Datum aus Datum/Zeit-Header filtern.

Verschiedene Header speichern ein Datum. Diese Daten haben ein sehr schlecht lesbares Format. (siehe z.B. EDA). Wird nun vor eine Datumsvariable dieser Parameter gesetzt, filtert TheAnswerIII aus dem nachfolgenden Header das Datum aus und gibt es im Format Tag TT.MM.JJJJ aus. Als Tag wird der Wochentag mit zwei Buchstaben angegeben, danach folgt Tag, Monat und Jahr in Zahlenform. Beispiel: ”%DATUM:%EDA:” gibt das Absendedatum einer Nachricht aus.

ZEIT  Uhrzeit aus Datum/Zeit-Header filtern.

Hier gilt das gleiche, wie bei ”DATUM”, nur wird aus der Variablen die Uhrzeit im Format SS.MM.SS gefiltert. (Stunde, Minute, Sekunde). Beispiel: ”%ZEIT:%EDA:” gibt die Absendeuhrzeit einer Nachricht aus.

NAME  Namen aus Netzadresse filtern

Filtert aus der nächsten Variablen den Usernamen aus, wenn diese eine Netzadresse ist. Beispiel: ”%NAME:%ABS:” filtert den Namen aus der Absenderadresse und macht so aus ”WEGAR@AMC.zer.sub.org” ein ”Wegar”. Bei der Wandlung ”NAME” werden alle Buchstaben, bis auf den ersten in Kleinschrift gewandelt, um besser auszusehen. Ist im Namen ein Sonderzeichen, wie bei ”P.FROEHLICH” ein Punkt, so wandelt TheAnswerIII den ersten Buchstaben nach dem Sonderzeichen wieder groß: P.Froehlich.

USER  Usernamen aus Netzadresse filtern

Filtert aus der nächsten Variablen den Usernamen aus, wenn diese eine Netzadresse ist. Beispiel: ”%USER:%ABS:” filtert den Namen aus der Absenderadresse und macht so aus ”WEGAR@AMC.zer.sub.org” ein ”WEGAR”. Im Gegensatz zu NAME wird die Schreibweise nicht verändert und auch eventuelle Gate-Adressierungen werden erhalten. Ein ”WEGAR%TURBO@AMNET.zer.sub.org” würde mit NAME formatiert ”Wegar” und mit USER formatiert ”WEGAR%TURBO” ergeben.

SERVER  Mailboxnamen aus Netzadresse filtern

Filtert aus der nächsten Variablen den Namen der Serverbox heraus, wenn diese eine Netzadresse ist. Beispiel: ”%SERVER:%ABS:” filtert den Server aus der Absenderadresse und macht so aus ”WEGAR@AMC.zer.sub.org” ein ”AMC”.

DOMAIN Netzdomain aus Netzadresse filtern

Filtert aus der nächsten Variablen die Domain Serverbox heraus, wenn diese eine Netzadresse ist. Beispiel: ”%DOMAIN:%ABS:” filtert die Domain aus der Absenderadresse und macht so aus ”WEGAR@AMC.zer.sub.org” ein ”zer.sub.org” ohne vorangestellten Punkt!

2.3 Bedingte Verzweigung durch IF/ENDIF

Mit TheAnswerIII können Header-Files durch eine einfache IF/ENDIF-Kombination bestimmte Abschnitte aus Header ausgeklammert werden, wenn eine Bedingung zutrifft. IF und ENDIF beginnen genau wie Variablen oder Parameter mit einem Prozentzeichen (%) und enden mit einem Doppelpunkt (:). IF hat nur eine Aufgabe in TheAnswerIII-Header-Files: Es prüft, ob der danach folgende Header in der Nachricht ist oder nicht. Findet TheAnswerIII den Header wird IF ignoriert, anderfalls arbeitet The-AnswerIII erst ab der Stelle weiter, ab der ein ENDIF gefunden wird. IF-Schleifen können nicht verschachtelt werden. Bevor ein neues IF folgt, muß das Vorgänger-IF mit ENDIF beendet sein. Beispiel:

%IF:%Z-NETZ-ABS:
ZNetz V 3.8-Nachricht:
Z-Netz-Emp  : %X-TA-ZNETZ-EMP:
Z-Netz-Abs  : %ZNETZ-ABS:
Z-Netz-ID   : %X-TA-ZNETZ-ID:
Z-Netz-Text : %ZNETZ-TEXT:
%ENDIF:

Nur wenn in der Nachricht der Header Z-NETZ-ABS zu finden ist, werden die nachfolgenden Zeilen abgearbeitet und die anderen Header dargestellt, die hier im Beispiel alle Spezial-Header sind, die nur Nachrichten besitzen, die nicht mit ZConnect, sondern mit dem veralteten Z-Netz-Verfahren transportiert wurden. Ohne IF wurde eine Header-Datei mit diese Anordnung 4 Leerzeilen erzeugen, mit IF wird dieser Abschnitt einfach ausgeklammert.

2.4 Konstante Hilfsvariablen

TheAnswerIII kenn drei interne Variablen, die nur in Header-Dateien benutzt werden, um bestimmte Daten darstellen zu können. Sie stehen immer allein und benötigen keine Parameter:

HEUTE  Aktuelles Datum ins Header-File schreiben

%HETUE: wird bei Formatierung immer durch das aktuelle Datum ersetzt. Dabei wird die gleiche Schreibweise benutzt, als wäre der Parameter DATUM: angegeben.

JETZT  Aktuelle Uhrzeit ins Header-File schreiben

%JETZT: wird bei Formatierung immer durch das aktuelle Uhrzeit ersetzt. Dabei wird die gleiche Schreibweise benutzt, als wäre der Parameter ZEIT: angegeben.

REPLY  Antowrtenzähler formatiert darstellen

%REPLY: liefert den im Inhaltmenü links vom Betreff stehenden Antwortenzähler. Dabei wird jedoch nicht nur die Zahl dargestellt (das geht mit der Variablen ”REPLY-LEVEL”), sondern es wird noch der Text ”Reˆ ” vorangestellt. In Kombination mit dem Betreff einer Nachricht (BET), kann man so beides zusammen und lesbar darstelllen: %REPLY:%BET: ergibt bei dem Betreff ”Neues zu TheAnswer” und einem Antwortenzähler von 4: ”Reˆ 4: Neues zu TheAnswer”

UNKNOWN Unbekannte Header darstellen

%UNKNOWN: Es kann immer wieder vorkommen, daß ein Header übers Netz kommt, denn TheAnswerIII nicht kennt. Wird diese Variable in einem Headerfile gefunden werden an dieser Stelle alle Header, die hier nicht beschrieben sind mit ihrer Header-ID angezeigt.

Die möglichen Header–Informationen

3.1 ZConnect-Header

Die hier gezeigten Header-IDs gehören zum Standard-Umfang von ZConnect, und werden von jeder Software, die ZConnect-Kompatibel ist, benutzt und unterstützt.

ABS  Nur einmal Pflicht  Absenderin

Die Adresse, über die die Absenderin erreichbar ist, komplett mit Absendersystem, Domainangabe und evtl. Realname.

ANTWORT–AN: optional Alternative Antwortadresse

Eine private Antwort an die Absenderin ist nicht an die ABS–Adresse zu schicken, sondern an die hier angegebene. Dies ermöglicht Benutzerinnen mehrerer MailBoxen, alle Antworten an die “Hauptadresse“ schicken zu lassen. Auch bei automatisch generierten Nachrichten (Absenderin “Mailer–Daemon“) kann so eine Ansprechpartnerin für Rückfragen angegeben werden.

BET  Nur einmal Pflicht  Betreff
BEZ  mehrfach  optional  Bezug

Wenn diese Nachricht eine Antwort auf eine ältere Nachricht ist, gibt der Bezug die Message–ID der Originalnachricht an.

DDA Nur einmal optional Dateidatum

Gibt das Datum der letzten Änderung einer Datei an. Das Format des Datums ist unter EDA beschrieben.

DISKUSSION–IN optional Alternative Reply-Adresse

Gibt die Empfängerin an, die bei öffentlichen Antworten benutzt werden soll. Dies ist immer dann sinnvoll, wenn eine Nachricht in mehrere Bretter geschickt wird, die darauf folgende Diskussion aber auf ein Brett beschränkt werden soll. Es können aber auch reine Informationsbretter von Diskussionsbeiträgen freigehalten werden, indem die Antworten auf ein passendes Diskussions–Brett dirigiert werden.

EB mehrfach optional Empfangsbestätigung

Ist dieser Header vorhanden, verschickt das Zielsystem, sobald die Nachricht von ihm empfangen wird, eine Empfangsbestätigung an die Absenderin. Benutzt die Empfängerin einen Point und ist dieser auch mit ZCONNECT angeschlossen, wird die Empfangsbestätigung nicht beim Empfang in der MailBox ausgelöst, sondern erst vom Point. In allen anderen Fällen wird beim Einsortieren der Nachricht in die MailBox sofort die Bestätigung verschickt. Bestätigt wird der Empfang, nicht das Lesen der Nachricht (Datenschutz!).

(Fortsetzung n. Seite)

EB  (Fortsetzung)

Der EB Header kann auch eine Adresse enthalten, in diesem Fall geht die Empfangsbestätigung nicht an die Absenderin, sondern an die angegebene Adresse. Sind mehrere EB Header vorhanden, erhält jede dort aufgeführte Adresse eine Bestätigung. In der Bestätigung ist im BEZ Header die Message–ID der bestätigten Nachricht anzugeben. Weiterhin ist ein Header STAT:EB zu setzen.

EDA Nur einmal Pflicht Datum

Das Erstellungsdatum wird dabei im Format JJJJMMTThhmmss[S/W](+/– offset) angegeben, wobei S oder W für Sommer bzw. Winterzeit steht, (offset) ist die Zeitzone als Unterschied in Stunden zur GMT. Dabei wird die Zeit immer als GMT angegeben, die Zeitzone/Sommerzeit ermöglicht lediglich das Umrechnen dieser universellen Zeit auf die lokale Zeit der Absenderin. In Deutschland gelten die Zeitzonen MET und im Sommer MEST. Diese würden durch die Zusätze “W+1“ bzw. “S+2“ dargestellt Durch die Darstellung als GMT sind die JJJJMMTThhmmss Angaben auch während der Umstellung von Sommer– auf Winterzeit und umgekehrt kontinuierlich. Falls die lokale Uhrzeit nicht um ganze Stundenbeträge von GMT abweicht, wird dem Offset einen Minutenangabe zugefügt. Beispiel: “W–9:30“ für die Zentral– Australische–Zeitzone.

EMP mehrfach Pflicht Empfänger

Die Netzadresse der Empfängerin(nen). Tritt diese INFORMATION mehrfach auf, muß dieses Nachricht an JEDE dieser Empfängerinnen weitergeleitet werden. Geschieht dies nicht über ein gemeinsames Routesystem, sind Kopien der Nachricht anzufertigen. Bei diesem Kopiervorgang bekommen die einzelnen Kopien nur noch die EMP Header, an die diese Kopie weitergehen soll, alle übrigen (die über ein anderes System erreicht werden sollen) werden als Kopienempfänger (KOP Header) eingetragen. Enthält eine der EMP–Angaben keinen “@“, handelt es sich um eine öffentliche Nachricht. Eine Nachricht kann in mehrere öffentliche Bretter geschickt werden, indem für jedes Brett eine EMP–Information eingesetzt wird. Physikalisch wird natürlich nur eine Kopie der Nachricht weitergereicht. Hier wird also – im Gegensatz zu den privaten Nachrichten – niemals kopiert. Hat ein System nicht alle der in EMP Headern angegebenen Bretter bestellt, müssen dennoch alle EMP Header weitergegeben werden! Das gleiche gilt, wenn auf dem lokalen System nicht jedes Brett, das in einem EMP Header aufgeführt wird, existiert. Ein EMP Header darf auch einen Realnamen enthalten.

ERR Nur einmal optional Error

Falls dieser Header vorhanden ist, wurde die Nachricht von einem Programm automatisch zurückgeschickt – entweder weil die Nachricht fehlerhaft oder die Empfängerin unbekannt war. Der ERR Header enthält die Fehlermeldung im Klartext.

ERSETZT optional Nachricht ersetzen

Gibt die Message–ID der Nachricht an, die von dieser ersetzt wird. Damit kann dafür gesorgt werden, das von einer regelmäßig veröffentlichten Information immer nur die aktuelle in einer MailBox vorhanden ist. Anwendungsbeispiele: Serverstruktur, MailBox–Listen, ZMAPs, FAQs etc.

FILE  Nur einmal optional  Filename

Gibt den Dateinamen (ohne Directory!) der Datei an – zum Beispiel für Binärnachrichten oder Grafiken. ACHTUNG: je nach Betriebssystem des Absende–Systems, kann dieser Dateiname beliebig lang sein und evtl. Sonderzeichen, Leerzeichen sowie natürlich mehrere Punkte enthalten! Jede Software, die diesen Header auswertet, um diese Nachricht zu speichern, sollte darauf vorbereitet sein und entweder den Namen entsprechend kürzen sowie ungültige Zeichen durch Ersatzdarstellungen ersetzen oder bei ungültigen Namen einen eigenen Namen generieren.

KOM Nur einmal optional Kommentarlänge

Länge des Kommentars in Byte. Wird z.B. für Binärnachrichten, denen ein ASCII– Kommentar vorangestellt ist, gebraucht. Nach dem Header folgt der Kommentar in der angegebenen Länge, dann erst die Binärdaten. Die Binärdatenlänge ist also LEN minus KOM. Ein Kommentar kann aber auch bei allen anderen Nachrichtentypen vorangestellt werden. Für den Inhalt des Kommentars gelten IMMER die Regeln für Standard– Textnachrichten, auch wenn er einem Text mit alternativem Zeichensatz (und entsprechender TYP–Information) vorangestellt ist.

KOP merhfach optional Kopienempfängerin

Falls eine Nachricht an mehrere Personen geschickt wurde, kann diese Information die übrigen Empfängerinnen auflisten. Gibt es mehrere Kopienempfängerinnen, tritt diese Information mehrfach mit jeweils einer Empfängeradresse auf (je eine KOP–Information pro Empfängerin). ACHTUNG: diese Information dient nur der Dokumentation für die Empfängerinnen, sie wird NICHT zum Steuern der Nachrichtenweiterleitung verwendet. Falls eine KOP: Angabe gemacht wird, aber keine entsprechende EMP: Angabe vorhanden ist, wird die routende Software sich NICHT bemühen, dieser KOP– Adressatin eine Kopie zuzusenden. Die Software wird vielmehr davon ausgehen, daß diese Adressatin ihre Kopie bereits über einen anderen Routweg erhalten hat (bzw. erhalten wird).

LDA Nur einmal optional Löschdatum

Ein Datum, ab dem diese Nachricht automatisch gelöscht werden soll/kann. Kann für Veranstaltungshinweise oder andere Nachrichten mit “Verfallsdatum“ (z.B. die urgent actions von amnesty international) verwendet werden.

LEN Nur einmal Pflicht Länge

Die Länge des INHALTS (alles, was hinter dem Header noch zu dieser Nachricht gehört) in Byte. Auch die Länge 0 ist erlaubt.

MAILER Nur einmal optional  Mailer

Gibt den Namen des (von der Absenderin, bzw. vom konvertierenden Gateway) verwendeten Mailers an (pure Werbung, aber immerhin für Userinnen unsichtbar :–) Dient der Fehlererkennung im Netzwerk. Hier sollte eine eindeutige Kennung der Software incl. Versions / Releasenummer stehen.

MID Nur einmal Pflicht Message–ID

Die Message–ID muß wie eine gültige Adresse (ohne Realname) aussehen (siehe oben) und darf innerhalb von zwei Jahren weltweit nicht wiederholt werden. Dazu MÜSSEN Message–IDs eine Domain enthalten, falls dem System keine Internet– Domain zugeordnet ist, muß hier zumindest “.zer.sub.org“ eingetragen werden. POINTS werden besonders behandelt: die MailBox benutzt nur den lokalen Teil der vom Point gelieferten ID (also alles vor dem @) und hängt einen Klammeraffen ’@’ und den Pointnamen, gefolgt von einem Punkt und dem MailBox–Namen, gefolgt von der MailBox–Domain an. So ist die Eindeutigkeit von Point–Message– IDs weltweit garantiert.

(Fortsetzung n. Seite)

MID  (Fortsetzung)

Beispiel: der Point “BIONIC01“ sendet eine Nachricht mit der Message–ID “aH24.8281@BIONIC01.zer.de“. Daraus wird auf der BIONIC die Message–ID “aH24.8281@BIONIC01.BIONIC.zer.de“. Points dürfen auch nur den lokalen Teil der ID liefern (also von sich aus den @, Systemname und Domain entfallen lassen). Points können auf eine Message– ID notfalls auch völlig verzichten, in diesem Fall muß die MailBox eine eigene erzeugen. Die Message–ID dient zur eindeutigen Identifikation dieser Nachricht. Sollte innerhalb von zwei Jahren eine Nachricht mit einer gleichen Message–ID noch einmal auftreten, ist dies eine “Rekursion“, d.h. die Nachricht ist über einen Umweg noch einmal zur MailBox gelangt und kann deshalb gelöscht werden. Sie darf auf keinen Fall weitergeleitet werden. Eine praktische Implementationsmöglichkeit ist es z.B., alle Message–IDs für 90 Tage aufzubewahren und alle eingehenden Nachrichten gegen diese Datenbank zu prüfen. Eingehende Nachrichten, die älter als 90 Tage sind, können bedenkenlos entsorgt werden, ohne die Message–ID zu testen. Der Rekursionstest anhand der Message–ID (und zwar AUSSCHLIESSLICH anhand dieser) muß von jeder Software durchgeführt werden! Öffentliche Nachrichten, die als Rekursion erkannt wurden, dürfen nicht weitergeroutet werden. Persönliche Nachrichten werden nicht auf Rekursion geprüft, lediglich das Zielsystem der Nachricht darf doppelte persönliche Nachrichten ausfiltern. In Message–IDs sind die Zeichen ’ <’, ’> ’ und ’/’ verboten.

OAB Nur einmal optional  Original–Absenderin

Falls eine Nachricht manuell oder per Verteiler weitergeleitet wurde, steht hier, wer die Nachricht original verschickt hat.

OEM mehrfach optional Original–Empfängerin

Falls eine Nachricht manuell oder per Verteiler weitergeleitet wurde, steht hier die ursprünglich angegebene Empfängerin.

ORG Nur einmal optional  Organisation

Eine kurze, einzeilige Beschreibung der hinter der Absenderin stehenden Organisation, z.B. “Borland Deutschland GmbH, Starnberg, F.R.G.“. Wird eine solche Information eingesetzt und die Nachricht gibt NICHT die offizielle Meinung der Organisation wieder, wird im Nachspann (Signatur) der Nachricht meist der “Standard– Disclaimer“ eingefügt: “Meine Meinung ist NUR meine Meinung. Sie wird von meiner Arbeitgeberin weder geteilt noch bezahlt.“

PGP Nur einmal optional  Public-Key

Dieser Header beinhaltet einen Public-Key in hexadezimaler Schreibweise für PGP (Pretty-good-privacy)

POST Nur einmal optional  Post–Adresse

Wenn die Absenderin einer Nachricht auch über andere Medien, z.B. per Post, erreichbar sein möchte, kann sie in diesem Header ihre postalische Anschrift unterbringen. Die einzelnen Anschriftenzeilen werden hintereinander geschrieben und jeweils durch Semikola “;“ getrennt.

PRIO Nur einmal optional  Priorität

(ohne diesen Header gilt Priorität 0) Gibt die Dringlichkeit der Zustellung an. Zur Zeit sind folgende Dringlichkeiten definiert: 0 = normal (per Routing) 10 = direkt 20 = Eilmail (direkt mit sofortiger Auslieferung)

ROT  Nur einmal Pflicht  Routeweg

Jedes System trägt sich hier ein, wenn es die Nachricht empfängt. Z–Netz Systeme werden hier mit Domain eingetragen (“.zer.sub.org“, falls keine andere bekannt ist). Eine Nachricht (auch eine PM) darf niemals an ein System weitergereicht werden, dessen Name bereits im Routeweg steht. Falls eine PM über ein System zugestellt werden muß, das bereits im Routeweg steht, sollte diese Nachricht dem Sysop vorgelegt werden (Achtung: Datenschutz! Nur die Header, nicht der Nachrichteninhalt darf sichtbar sein!), da offenbar ein Ping–Pong–Routing besteht. Als erstes System trägt sich hier das Absender–System ein (damit auch dieses die Nachricht nicht noch einmal bekommt). Erreicht die Nachricht das nächste System, setzt dieses seinen eigenen Namen (incl. Domain) gefolgt von einem ’!’ vor den alten Inhalt dieser Information. Dazu ein Beispiel: auf der BIONIC.zer.de wird eine Nachricht erzeugt: “ROT: BIONIC.zer.de“. Nun erreicht diese Nachricht die BI–LINK.owl.de: “ROT: BI–LINK.owl.de!BIONIC.zer.de“.

SPERRFRIST Nur einmal optional  Gültig ab

Ein Datum im Format wie EDA. Vor diesem Datum wird diese Nachricht NICHT angezeigt. Damit kann z.B. eine Sperrfrist bei Pressemeldungen eingehalten werden.

STAT merhfach optional Nachrichtenstatus

Beschreibt, was die Nachricht ist: Falls dieser Header fehlt, handelt es sich um eine normale Mail. Wenn der Header vorhanden ist, gibt es folgenden Einträge: DES Nachricht ist mit DES verschlüsselt. (Data Encryption

Standard)

PGP Nachricht ist mit PGP verschlüsselt. (Pretty Good Privacy,

einer RSA Implementation)

EB Nachricht ist eine automatisch verschickte

Empfangsbestätigung.

CTL Nachricht ist eine Kontrollnachricht, die – auch wenn sie defekt

ist – nicht zurückgeschickt werden darf.

AUTO Gibt an, das es sich bei dieser Nachricht um eine regelmaessig aktualisierte Information handelt. Welche kann aus dem FILE: Header und dem EMP: Header entnommen werden, der BET: Header ist hier nicht(!) auszuwerten (weil da z.B. ”Ausgabe vom xx.xx.xx” drin stehen kann). Diese Nachricht kann von entsprechenden Hilfsprogrammen erkannt und automatisch (je nach Konfiguration) in einen FileServer, ein lokales Brett oder ein spezielles Exclude-Verzeichnis uebernommen werden.

CRYPT Die Nachricht ist dann mit dem mit diesem Absender

vereinbarten Verfahren/Passwort verschluesselt.

TELEFON Nur einmal optional Telefonnummer

Hier kann die Absenderin ihre Telefonnummer(n) unterbringen. Es wird die internationale Schreibweise verwendet, mit vorangestelltem “V“ für Voice, “F“ für Fax oder “B“ für MailBox (BBS). Bei Voice–Nummern wird ein “Q“ nachgestellt, wenn ein Anrufbeantworter vorhanden ist. Alle Nummern werden durch “;“ oder Leerzeichen getrennt. Beispiel: “V+49–521–561345Q F+49–521–561785 B+49–521–193004“. Bei kombinierten Nummern werden die Kennbuchstaben hintereinandergestellt: VF+49–521–562342Q.

TYP  Nur einmal  optional  Typ

Nähere Beschreibung des Dateityps. Definiert, um welche Art von Binärdatei es sich handelt (z.B. TIFF, GIF, PCX, ...). Alle unbekannten TYP Informationen werden als reine Binärnachricht aufgefaßt. Definiert sind die Typkennungen

BIN  allgemeine Binärnachricht
TRANSPARENT Textnachricht ohne Umlautwandlung

Beim Inhalt des TYP Headers wird nicht zwischen Groß– und Kleinschreibung unterschieden. Falls kein TYP–Header vorhanden ist, handelt es sich um eine Textnachricht.

WAB Nur einmal optional Weiterleitungsabsender

Der WAB: darf immer angegeben werden und ist gegebenenfalls mit dem ABS: identisch. Treten bei der Zustellung der Nachricht Fehler auf, wird davon der WAB informiert, nicht der ABS. Nachrichten von Mailing-Listen (Netzwerk-Verteiler) enthalten in der Regel die Adresse des Listen-Betreuers als WAB, waehrend der ABS: aus der Mail an den Verteiler uebernommen wird. Dadurch gehen Antworten an den urspruenglichen Autor, Fehlermeldungen ueber falsche Eintraege im Verteiler aber an dessen Verwalter. Dies wird in der RFC Welt als ”Envelope-Adresse” bezeichnet. (EMP: und WAB: sind die Envelope-Adressen fuer ZCONNECT).

ZNETZ–ABS Nur einmal optional Konvertierungs–Absender

Absenderangabe für die Konvertierung in das ZNETZ–Format. Hier wird der Absendername so gespeichert, daß er im Z–Netz adressierbar bleibt. In den Absender-Header (ABS) wird eine ZConnect-konforme Adresse eingetragen, die aus dieser konvertiert wurde. Diese Information kann nur einmal proHEADER auftreten. Wird eine Nachricht von ZConenct nach Z–Netz gewandelt, wird ebenfalls nach diesem Header gesucht und bei einem Treffer der Inhalt auf dem weiteren Weg als Absenderangabe benutzt

ZNETZ–TEXT mehrfach optional Konvertierungstext

Textheader bei Konvertierung in das ZNETZ–Format. Dies können die verschiedensten Inhalte sein. Wenn die Nachricht von ZConnect nach Z–Netz gewandelt wird, werden die Inhalte der Z-Netz-Text-Header bei Textnachrichten dem eigentlichen Naachrichteninhalt vorangestellt.

3.2 Weitere Headerzeilen von TheAnswer

Die hier gezeigten Header-IDs gehören nicht zum Standard-Umfang von ZConnect, und werden nur von TheAnswerIII oder wenigen anderen Pointprogrammen benutzt.

X-TA-  mehrfach  optional  TheAnswer-Kennung

Alle TheAnswerIII-spezifischen Header beginnen mit diesem Code. Dadurch soll verhindert werden, daß andere Programme, die ebenfalls eigene Header verwenden, nicht gleichlautende Header mit anderem Sinn definieren.

X-TA-ZNETZ-ID Nur einmal optional  ZNetz-Message-ID

Wird eine Nachricht im alten Z-NETZ-Format einsortiert, wird sie mit einer ZConnect-Message-ID versehen. Die alte MessageID wird mit diesem Header jedoch bei TheAnswerIII erhalten.

X-TA-ZNETZ-EMP : Nur einmal optional  ZNetz-Empfänger

Netzadressen (siehe auch EMP, ABS), jedoch keine Brettnamen werden bei der Wandlung von Z-Netz nach ZConnect verändert. In der Regel wird eine ZConnect-kompatible Domain angehängt, die ”zer.sub.org” lautet. Wird eine Nachricht im alten Z-NETZ-Format einsortiert, wird sie so gewandelt und der alte Empfängername in diesem Header gespeichert.

REPLY-LEVEL Nur einmal optional Antwortenzähler

Wie schon in der TheAnswerIII-Dokumentation erklärt, werden RE-Zeichen und andere Kürzel für ”Dies ist eine Antwort auf:” beim Einsortieren aus dem Betreff gefiltert und als Zahl neben dem Betreff im Inhaltmenü dargestellt. Dieser Zahlenwert wird bei TheAnswerIII mit dieser Header-ID in der nachricht gespeichert. Dieser Header beginnt nicht mit ”X-TA” da er offiziell auch von anderen Pointprogramm benutzt wird und dabei den gleichen Sinn und Zweck erfüllt. Beachte auch den Display-Header ”REPLY”

3.3 Lokale Headerzeilen von TheAnswer

Diese lokalen Header-IDs werden nur innerhalb von TheAnswerIII benutzt. Diese Header werden nicht ins Netz geschickt, sondern beim Erzeugen der Uploaddatei ausgefiltert oder netzgerecht umgewandelt. Um eine externe Manipulation dieser Header zu verhindern, werden Nachrichten, die von außen einsortiert werden und diese Header enthalten als illegal betrachtet.

X TA VERS  Nur einmal optional  TheAnswer-Version

Dieser Header war dazu vorgesehen, die TheAnswerIII-Version zu speichern, mit eineNachricht einsortiert oder generiert wurde. Dieser Header wird jedoch in der Version 3.00 nicht benutzt.

X TA ROBOT Nur einmal optional  Mail mit Signumverbot

Nachrichten, die diesen Header enthalten, werden mit keiner Unterschrift versehen und erhalten kein TheAnswerIII-Signum am Ende der Nachricht. Dieser Header wird von TheAnswerIII automatisch gesetzt, wenn Nachrichten an ein MAPS-Systemgehen. (Mehr Maps siehe TheAnswerIII-Dokumentation)

NEU Nur einmal optional Neuer Header

Dieser Pseudo-Header wird als Vorgabe erzeugt, wenn man im Nachrichten-Editor einenneuen Headereintrag wünscht. Er muß danach in eine gültige Header-ID verwandelt werden.

X TA CRYPT Nur einmal optional  Codierverfahren

Nachrichten mit diesem Header werden codiert, sobald sie in die Uploaddatei kopiert werden, oder in einem Netcall-Format ausgelagert bzw. gelesen werden. Im Header ist das verwendete Codierverfahren gespeichert.

X TA PW Nur einmal optional Codier-Passwort

Das Passwort, mit dem eine Nachricht beim kopieren ins Spoolbrett codiert werden soll. Der Header wird nach der Codeirung natürlich entfernt und geht nicht ins Netz.

X TA SCRIPT Nur einmal optional  Codier-Script

Wenn das verwendete Codierverfahren z.B. PMCrypt ist, muß mit einem externen Batch codiert werden. in diesem Header wird der Dos-Aufruf für das Script gespeichert, daß beim kopieren der Nachricht in die Uploaddatei ausgeführt wird, um die Nachricht wirklich zu codieren. (Wird dabei natürlich ausgebaut)

3.4 Weitere Headerzeilen

Neue Headerzeilen können jederzeit definiert werden. JEDE Software muß ihr unbekannte Zeilen UNVERÄNDERT weitergeben. Für lokale Erweiterungen wird garantiert, daß niemals eine Headerzeile mit “X–“ beginnen wird. Sie können also gefahrlos eigene Headerzeilen wie z.B. “X–Euromail–Version: 22.5“ erzeugen. Headerzeilen, die mit “U–“ beginnen, sind UUCP–Header, entsprechen also RFC822/1036 bzw. entsprechenden Nachfolgestandards. UUCP oder Internet–Gateways können auf diese Weise Informationen, für die es im ZCONNECT zur Zeit noch keine Entsprechung gibt, 1:1 durchreichen. Beispiel: “U–Date: Thu, 12 Jan 1987 PDST“ entspricht der RFC–1036 Header–Zeile “Date: Thu, 12 Jan 1987 PDST“. (Wobei in diesem Fall die Information gleichwertig mit dem EDA Header transportiert werden kann, aber es ist ja nur ein Beispiel...)

Index

ABS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 ANTWORT–AN . . . . . . . . . . . . . . . . . . . . . . . . . . 6 AUTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

BET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 BEZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 BIN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

CRYPT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 CTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

DATUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 DDA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 DES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 DISKUSSION–IN . . . . . . . . . . . . . . . . . . . . . . . . . 6 DOMAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

EB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 EB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 EDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 EMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 ENDIF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 ERR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 ERSETZT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

FILE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

HEUTE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

IF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

JETZT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

KOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 KOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

LDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 LEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

MAILER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 MID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

NAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 NEU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

OAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 OEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 ORG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

PGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
PGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
POST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
PRIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
REPLY-LEVEL. . . . . . . . . . . . . . . . . . . . . . . . . .12
REPLY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
RFC–1036 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
ROT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
SERVER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
SPERRFRIST . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
STAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
TELEFON. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
TRANSPARENT . . . . . . . . . . . . . . . . . . . . . . . . 11
TYP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
U– . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
UNKNOWN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
USER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
WAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
X– . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
X-TA-ZNETZ-EMP . . . . . . . . . . . . . . . . . . . . . . 12
X-TA-ZNETZ-ID . . . . . . . . . . . . . . . . . . . . . . . . 11
X-TA- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
X TA CRYPT . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
X TA PW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
X TA ROBOT . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
X TA SCRIPT. . . . . . . . . . . . . . . . . . . . . . . . . . .12
X TA VERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
ZEIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
ZNETZ–ABS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
ZNETZ–TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . 11