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 pro�HEADER 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.