NNTP Header (2/3)

Im Network news transfer protocol (NNTP) sind eine Reihe von Headern definiert, die die Verbreitung und Darstellung von Nachrichten steuern. Einige dieser Header sind zwingend erforderlich, andere optional oder benutzerdefiniert (d.h. nicht im engeren Sinne in NNTP definiert).
Dieser Artikel listet alle erforderlichen und die üblichen optionalen bzw. benutzerdefinierten Header auf. Ein Dokument über die Struktur des NNTP ist ebenfalls verfügbar.

Header folgen der Form "Variable: [Wert] [[ggf. Wert2]] [...]" und stehen vor der eigentlichen Nachricht (dem "Body") und jeweils in einer eigenen Zeile. Sollte sich ein Header über mehrere Zeilen erstrecken, so müssen alle ab der zweiten mit einem Leerzeichen beginnen; ein ggf. folgender Header muss dann wieder in einer neuen Zeile stehen.
Das folgende Beispiel zeigt die Header Message-ID,X-Auth und References:

Message-ID: <aoohd1$1c8$1@xyz.ruebezahl.de>
X-Auth: PGPMoose V1.1 PGP comp.lang.c++.moderated
 iQBVAwUAPbFUkEHMCo9UcraBAQHVuwH+MT3PTdzB2LScVxlIkOW2jyXuRntSi570
 mc9fgyG/uR5IQO9CaQl9yxQWya+H1iyRJJLSqV8F6zkkw9Ix59IgFw==
 =yr5O
References: <hjm4$dk631@mamenchi.zrz.TU-Berlin.DE>

Inhalt

• Erforderliche Header, im einzelnen
  From, Date, Newsgroups, Subject, Message-ID und Path
• Optionale Header, im einzelnen
  Sender, Reply-To, Followup-To, References, Expires, Organization, Distribution, Keywords, Summary, Approved, Lines, Xref und Control
• Einige benutzerdefinierte Header, im einzelnen
  X-No-Archive, X-Priority, X-Newsreader, X-Mailer, User-Agent, X-Auth, X-Complaints-To, X-Problems-To, X-Face und NNTP-Posting-Host

Erforderliche Header

• From Der From-Header enthält die E-Mail-Adresse des Autors der Nachricht. Sie wird normalerweise nicht geprüft und kann daher gefälscht sein (siehe auch Sender-Header). Der Name des Autors wird in diesem Header meist mit angegeben: Dann muss entweder der Name nachgestellt in runden Klammern stehen, oder der Name steht vor der E-Mail-Adresse, die dann in spitzen Klammer steht. Einige Clients nutzen zuweilen leicht abweichende Formate (siehe Beispiel-Nachricht), so dass Entwickler von News-Servern oder -Clients "nachsichtig" programmieren sollten. Beispiele für gültige From-Header:

  From: jd@web.de
  From: jd@web.de (Jonathan Dillmann)
  From: Jonathan Dillmann <jd@web.de>

• Date Im Date-Header wird der Zeitpunkt des Absendens der Nachricht vom Autor angegeben. Diese Angabe wird vom Client erzeugt und hängt damit i.d.R. von der System-Uhr des Clients ab; Server sollten diese Angabe ungeprüft übernehmen. Die gütigen Formate dieses Headers sind vielfältig (näheres siehe RFC 822). Beispiele:

  Date: Fri, 18 Oct 2002 10:45:11 +0200
  Date: Fri Oct 18 08:45:11 2002

• Newsgroups In welchen der hierarchisch geordneten Gruppen eine Nachricht veröffentlicht werden soll, wird im Newsgroups-Header bezeichnet. Normalerweise wird nur eine Gruppe benannt, da cross postings (kurz: xpost), also das Veröffentlichen ein und derselben Nachricht in mehreren News-Gruppen, meist nicht den Gepflogenheiten entspricht. Mehrere Gruppen können jedoch angegeben werden, indem sie durch Kommata (und ggf. Leerzeichen) getrennt werden. Die Angabe einer übergeordneten Hierarchie, um alle Gruppen unterhalb dieser Ebene zu erreichen, ist nicht zulässig, etwa de.comp.datenbanken für die (möglicherweise verfügbaren) Gruppen de.comp.datenbanken.misc, de.comp.datenbanken.ms-access und de.comp.datenbanken.mysql. Siehe auch: Followup-To-Header. Beispiele für gütige Angaben:

  Newsgroups: de.soc.recht.misc
  Newsgroups: uni-schwerte.intern, de.soc.staedte.schwerte

  Sind mehrere Gruppen angegeben, so sollte jeder Server diesen Header unberührt lassen, auch wenn er nicht alle Gruppen führt oder kennt, da vielleicht einige Server, die die Nachricht nach ihm erhalten, dies tun.

• Subject Im Subject-Header wird der Betreff der Nachricht angegeben, der so aussagekräftig sein sollte, dass der Benutzer entscheiden kann, ob dieser Artikel für ihn von Interesse ist. Sollte sich ein Artikel auf einen anderen beziehen (siehe References-Header), so sollte der Client der Betreff-Zeile ein "Re: " voranstellen, wenn das nicht bereits dort steht.
• Message-ID Der erste Server – also der, der die Nachricht vom Client des Autors erhält – gibt der Nachricht eine eindeutige Kennzeichnung in der Form <intern eindeutige ID@vollständiger Name des Servers>. Die "intern eindeutige ID" kann z.B. eine laufende Nummer sein, die der Server frei generieren kann. Zusammen mit "vollständiger Name des Servers" ergibt sich eine eindeutige Bezeichnung der Nachricht. Alle anderen News-Server dürfen diese Kennung nicht verändern, und der vergebene Server sollte sicherstellen, dass er diese ID aus Gründen der späteren Nachrichtenverfolgung frühestens zwei Jahre nach Ablauf der Nachricht erneut vergibt. Die ID dient sowohl den Servern als auch den Clients, zu erkennen, welche Nachrichten sie bereits haben; dem Client in Verbindung zum References-Header zusätzlich, zu welchem Diskussionsfaden die jeweilige Mitteilung gehört, falls er diese Abhängigkeiten darstellen will.
• Path Im Path-Header steht, welchen Weg die Nachricht (bisher) genommen hat. Der erste Server – also der, der die Nachricht vom Client des Autors erhält –, erzeugt diesen Header und trägt seinen Namen ein. Jeder weitere Server ergänzt diese Angabe, indem er seinen eigenen Namen plus ein Trennzeichen voranstellt. Von hinten nach vorn gelesen ergibt der Header also den Pfad, den die Nachricht gegangen ist. Als Trennzeichen kommen die Zeichen "," (Komma), "!" (Ausrufezeichen), "?" (Fragezeichen) und ";" (Semikolon) in Frage. Der Path-Header ist i.Ggs. zu allen anderen Headern (ggf. ausser Xref) aufgrund der Art seiner Erzeugung und Erweiterung bei jedem Server unterschiedlich. Beispiel:

  Path: news.siberius.com!news-mue1.dfn.de!xyz.ruebezahl.de

Optionale Header

• Sender Der Sender-Header hat das gleiche Format wie der From-Header und enthält die Angabe des Besitzers des Zugangs (des posting host). Diese Angabe macht nur Sinn, wenn jemand anderes als der Besitzer des Zugangs (etwa jemand auf Besuch) eine Nachricht veröffentlicht. Der Sender-Header sollte vom Server, der die Nachricht vom Client erhält, geprüft werden. Siehe auch: Reply-To-Header. Beispiel für: Peter benutzt Susis Zugang:

  From: ppanther@homoeopathie-und-nietzsche.de (Peter Panther)
  Sender: SusiSuessholz@theologie.uni-schwerte.de (Susi Suessholz)

• Reply-To Der Reply-To-Header hat das gleiche Format wie der From-Header und enthält eine E-Mail-Adresse, an die (private) Antworten an den Autor gesandt werden sollen. Die Angabe macht nur Sinn, wenn der Autor zwischen seiner herkömmlichen und speziell für diese Nachricht geltende E-Mail-Adresse unterscheiden will.
• Followup-To Der Followup-To-Header hat das gleiche Format wie der Newsgroups-Header und stellt die Anforderung dar, eine Diskussion in eine (oder ggf. mehrere) andere Gruppen umzuleiten. Diese Umleitung kann sinnvoll sein, wenn sich im Laufe der Diskussion das Thema derart verändert hat, dass eine andere Gruppe für die weitere Unterhaltung besser geeignet ist.

  Eine Nachricht mit einem Followup-To-Header wird sowohl in den ursprüglichen als auch den "neuen" Gruppen veröffentlich (x-post, siehe Newsgroups-Header). Daher sollte der Benutzer, der das follow up to (kurz: f'up2) setzt, in seiner Nachricht soviel von der bisherigen Debatte zitieren, dass die Teilnehmer der neuen Gruppe die diskutierte Thematik nachvollziehen können und dazu nicht in der ursprünglichen Gruppe nachlesen müssen. Alle Teilnehmer der Diskussion können nun das f'up2 beachten, also Folgebeiträge in die neuen Gruppen senden, oder ablehnen und die Debatte in den bisherigen Gruppen fortsetzen.

• References Diskussionen im usenet sind, zumindest potentiell, hierarchisch geordnet: Auf einen Beitrag wird geantwortet, auf diese Antwort wird dann wieder geantwortet usf. Diese Hierarchie wird durch den References-Header abgebildet, der alle Message-IDs der Nachrichten enthält, auf die der aktuelle Beitrag eine mittel- oder unmittelbare Antwort darstellt. Aus technischen Gründen wäre es lediglich erforderlich, im Reference-Header nur den unmittelbar beantworteten Beitrag zu bennenen; die Abbildung der vollständigen Diskussionskette kann einigen Clients jedoch die Darstellung der Hierachie vereinfachen. Falls die Hierarche zu tief wird, kann der Reference-Header gekürzt werden und nur den letzten Teil der Diskussionskette, etwa die letzten acht Ebenen, darstellen.

  Die Message-IDs, werden in der Reihenfolge dargestellt, die dem Diskussionsverlauf entspricht. Die IDs werden, wie im Message-ID-Header, in <spitze Klammern gefasst> und, falls mehrere aufgeführt sind, durch Leerzeichen getrennt. Im folgenden Beispiel bezieht sich der Beitrag auf eine Nachricht mit der ID <123@news.ruebezahl.de>, die sich zuvor wiederum auf einen anderen Beitrag mit der Kennung <hjm4$dk631@mamenchi.zrz.TU-Berlin.DE> bezogen hat:

  References: <hjm4$dk631@mamenchi.zrz.TU-Berlin.DE> <123@news.ruebezahl.de>

  Clients sollten beim Erstellen von Antworten (follow up, kurz f'up) den Rerefence-Header erzeugen bzw. einen bestehenden entsprechend erweitern. Ausserdem sollten sie den Betreff der beantworteten Nachricht übernehmen und ihm, falls das dort nicht bereits steht, ein "Re: " (für "Reply", Antwort) voranstellen.

• Expires Der Expires-Header hat das gleiche Format wie der Date-Header und gibt den Zeitpunkt an, bis zu dem die Nachricht gültig sein soll. Normalerweise bestimmen die News-Server selbst, wie lange sie einen Beitrag zu Verfügung stellen wollen, da eine permante Speicherung zu immer höher werdendem Speicherbedarf führen würde; diese Frist entspricht i.d.R. um die 30 Tage. In einzelnen Fällen kann jedoch die Angabe eines davon abweichenden Zeitpunkts sinnvoll sein, z.B., wenn es um eine Termin-Ankündigung geht, die in wenigen Tagen nicht mehr von Interesse sein wird. Viele Server ignorieren diesen Header jedoch, insbesondere wenn es sich um Zeitpunkte handelt, die nach den regelmässigen Löschfristen liegen.
• Organization Ähnlich wie der From-Header dient der Organization-Header der Identifikation des Autors der Nachricht und benennt die Organisation (Firma, Hochschule, Verein etc.), der der Autor angehöhrt. Und genauso wie der From-Header wird diese Angabe nicht geprüft und kann daher gefälscht sein. Beispiel:

  Organization: Star Trek Fleet Command

• Distribution Wie das world wide web ist auch das usenet weltweit ausgelegt. Um die Verbreitung von Nachrichten trotzdem einzuschränken, gibt es mehrere Möglichkeiten: Bestimmte Newsgroups können, bestimmt durch ihren Namen oder ihre Charta, rein lokal beschränkt sein (wie z.B. nrw.ruhrgebiet.allgemein), oder von News-Servern nur an wenige, bestimmte andere Server weitergegeben werden. Ein weitere Variante wird durch den Distribution-Header realisiert, mit dem angegeben werden kann, für welche Gebiete, Städte etc. die Nachricht bestimmt ist. Der Distribution-Header ähnelt dem Newsgroups-Header: Ein Client erhält die Nachricht nur, wenn er die entsprechende Newsgroup und einen unter Distribution angegebenen Eintrag abonniert. Ein Beispiel, wo das Sinn machen kann:

  Newsgroups: de.rec.tiere.entlaufen
  Distribution: München, Bayern

• Keywords Der Keywords-Header kann einige (wenige) Stichwörter enthalten, die über den Inhalt der Nachricht Aufschluss geben. Ähnlich wie der Betreff der Nachricht und der Summary-Header kann diese Angabe dem Benutzer die Entscheidung erleichtern, ob er sich für den Beitrag interessiert.
• Summary Der Summary-Header kann eine kurze Zusammenfassung enthalten, die über den Inhalt der Nachricht Aufschluss gibt. Ähnlich wie der Betreff der Nachricht und der Keywords-Header kann diese Angabe dem Benutzer die Entscheidung erleichtern, ob er sich für den Beitrag interessiert. Der Summary-Header sollte bei Antworten (f'up) auf Beiträge mit angegeben werden, damit sich auch Leser, denen nur diese Antwort zur Verfügung steht, über die diskutierte Thematik kurz informieren können.
• Approved Wenn eine Nachricht in einer moderierten Newsgroup veröffentlicht wird oder es sich um eine (bestimmte) Kontrollnachricht handelt, so muss der Approved-Header vorhanden sein und die E-Mail-Adresse des Moderators der Gruppe bzw. eines Administrators enthalten. Näheres zur Behandlung von moderierten Newsgroups siehe X-Auth-Header, zu Kontrollnachrichten siehe NNTP: Kontrollnachrichten. Obwohl laut RFC 1036 nur die Angabe einer E-Mail-Adresse statthaft ist, kommt es nicht selten vor, dass auch mehrere, getrennt durch Kommata, aufgeführt sind.
• Lines Der Lines-Header entält die Anzahl der Zeilen, aus denen der Body besteht (ohne die Leerzeile, die nach allen Headern folgt und den Beginn des Bodies markiert, siehe: Aufbau von NNTP-Nachrichten). Zur Prüfung, ob ein Server oder Client die Nachricht vollständig übertragen hat, ist diese Angabe i. Ggs. zum halbwegs vergleichbaren HTTP-Header content-length weniger geeignet, da nichts über die Länge der einzelnen Zeile ausgesagt wird. Derartige Prüfungen sollten über das unter NNTP liegende Protokoll (z.B. TCP/IP) abgewickelt werden.
• Xref Der Xref-Header enthält, ähnlich wie der Message-ID-Header, eine Kennung der Nachricht. Diese Kennung ist allerdings nicht serverübergreifend eindeutig, sondern gilt nur für den Server, von dem der Client (oder ein anderer Server) die Nachricht bezieht. Aus diesem Grunde muss der Server den Xref-Header selbst erstellen bzw. einen bestehenden (wenn er die Nachricht von einem anderen Server bezieht) durch eigene Angaben überschreiben. Ist die Nachricht in mehreren Gruppen veröffentlicht, so gibt es im Xref-Header ggf. auch mehrere Einträge; jedoch nur dann, wenn der Server auch mehr als eine der angegebenen Gruppen verwaltet.

  I.Ggs. Message-ID-Header kann man den Xref-Header als datenbankorientierten Identifikator, als Index betrachten. Er ist für die eindeutige Identifizierung einer Nachricht nicht erforderlich, wird jedoch von vielen Servern und Clients wegen einer effizienteren Verwaltung genutzt. Beispielsweise kann ein Server einem anderen eine Nachricht übertragen, die eine Message-ID trägt, die bereits vergeben ist. Dies kann der empfangende Server zwar feststellen, indem er seinen eigenen Datenbestand nach dieser ID durchsucht; dieser Vorgang ist bei grossen Datenbeständen und hohem Nachrichtenaustausch jedoch aufwändig. Wird stattdessen eine eigene ID vergeben, so ist die Nachricht – zuminest technisch und auf diesem Server – eindeutig, und zwar für jede vom Server verwaltete Newsgroup.

  Der Xref-Header folgt der Form "[Host] [Newsgroup:Nummer] [[Newsgroup:Nummer]] [...]". Der "Host" ist der Name des Servers, der die Nachricht speichert, und zwar ohne die Angabe der Domain (wie z.B. t-oline.de), da diese Angabe eh nicht domänenübergreifend ist. Der Hostname muss jedoch der entsprechenden Angabe des ersten Eintrags des Path-Header entsprechen, andernfalls sollten empfangende Systeme den Xref-Header als ungültig bzw. als nicht vorhanden betrachten. Die aufgeführten Newsgroups müssen zudem den unter dem Newsgroups-Header genannten Gruppen entsprechen bzw. zumindest eine Teilmenge dessen darstellen, wenn der Server nicht alle dieser Gruppen führt. Die "Nummer" schliesslich stellt eine ab 1 beginnende laufende natürliche Zahl dar, die den Beitrag innerhalb der Newsgroup identifiziert. Beispiel:

  Xref: zx7 de.alt.test:79995 alt.test:1356642

• Control Nachrichten im usenet können nicht nur für Menschen gedachte Beiträge darstellen, sondern auch die technisch notwendige Kommunikation zwischen News-Servern abwickeln. Eine solche Kontrollnachricht ist gegeben, wenn die Nachricht den Control-Header enthält. Aus Gründen der Kompatibilität sollten auch solche Nachrichten als "control messages" interpretiert werden, deren Subject-Header mit "cmsg" beginnt oder deren Newsgroups-Header "all.all.ctl" lautet. Es gibt, insbesondere bei populärer News-Server-Software, inzwischen effizientere Verfahren, um die Kommunikation zwischen Servern abzuwickeln.

  Ausführliches dazu siehe: NNTP: Kontrollnachrichten.

Benutzerdefinierte Header

• X-No-Archive Obwohl Artikel i.d.R. nach einiger Zeit aus den Datenbanken der News-Server gelöscht werden (siehe Publikation von NNTP-Nachrichten), gibt es Archive, die Nachrichten auch nach Ablauf dieser Zeit speichern. Eines der grössten öffentlichen Archive, dejanews, das inzwischen in Google groups aufgegangen ist, hat den X-No-Archive-Header eingeführt, der die Aufnahme eines Artikels in ein Archiv unterbinden soll. Ein Rücksichtnahme auf diesen Header ist natürlich nicht zwingend. Google groups beachtet diesen Header, und zwar auch, wenn er allein in der ersten Zeile des Body der Nachricht steht, da nicht alle Clients diesen Header kennen oder den Benutzer keine neuen definieren lassen. Der X-No-Archive-Header kann die Werte "yes" (= Archivierung verhinden) oder "no" (= Archivierung erlauben) annehmen. Die letzte Variante ist mit dem Fehlen des Headers gleichzusetzen. Siehe auch Google groups Posting FAQ. Beispiel:

  X-No-Archive: yes

• X-Priority Die Wichtigkeit einer Nachricht kann mit Hilfe dieses Headers angegeben werden. Es gibt keine eindeutige Regel, welcher Wert welche Dringlichkeit kennzeichnen soll, so dass Server oder Clients keine Aktivitäten (z.B. automatisches Herunterladen und Aufblenden der Nachricht) von diesem Header abhängig machen sollten. Häufig werden Angaben von 1-3 gemacht, die jedoch unterschiedlich interpretiert werden.
• X-Newsreader, X-Mailer, User-Agent Ähnlich wie mit dem HTTP-Header User-Agent für Web-Browser kann der Client seinen Namen, häufig zusammen mit der Versionsnummer, in einem dieser Header verewigen. Serverbetreiber und Newsreader-Hersteller können so die Verbreitung eines Clients feststellen. Auch hier hat sich leider keine eindeutige Bezeichnung durchgesetzt. Beispiele:

  X-Mailer: Mozilla 4.7 [de] (WinNT; I)
  User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722
  User-Agent: tin/1.5.10-20011117 ("Darkcell") (UNIX) (SunOS/5.7 (sun4u))
  X-Mailer: Mozilla 4.7 [de] (WinNT; I)
  User-Agent: Xnews/5.04.25
  X-Newsreader: Microsoft Outlook Express 5.50.4807.1700

• X-Auth Mit Hilfe des X-Auth-Headers kann man die Authentizität des Autors oder einer anderen Rolle, z.B. eines Newsgroup-Moderators, prüfen. Dies ist etwa in moderierten Newsgroups erforderlich, also in Gruppen, in denen nur nach Erlaubnis eines Moderators Nachrichten veröffenlicht werden dürfen. Ein häufig eingesetztes Verfahren ist hier pgpmoose, das auf News-Servern eingesetzt wird und alle Nachrichten löscht, die im X-Auth-Header keine PGP-Signatur enthalten, die zum im Approved-Header benannten Moderator passen. Beispiel für eine solche Signatur:

  X-Auth: PGPMoose V1.1 PGP comp.lang.c++.moderated
   iQBVAwUAPbFUkEHMCo9UcraBAQHVuwH+MT3PTdzB2LScVxlIkOW2jyXuRntSi570
   mc9fgyG/uR5IQO9CaQl9yxQWya+H1iyRJJLSqV8F6zkkw9Ix59IgFw==
   =yr5O

  Siehe auch: freshmeat.net: Project details for pgpmoose.

• X-Complaints-To, X-Problems-To Der X-Complaints-To- oder X-Problems-To-Header soll, sofern vorhanden, eine Kontaktadresse enthalten, an die Beschwerden über die betreffende Nachricht bzw. deren Autor gesendet werden können, z.B. die E-Mail-Adresse des Administrators des Servers, zu dem der Client die Nachricht gesendet hat. Diese Header sollten das gleiche Format wie der From-Header haben.

  Wie bei allen Headern kann auch diese Angabe gefälscht sein. Einige Server sind (per Dafault) leider so konfiguriert, dass sie beliebige "X-"-Header, die ihnen der Client übermittelt, ungeprüft übernehmen. Besser gewartete Server geben ihren eigenen X-Complaints-To- bzw. X-Problems-To-Header an und weisen neue Nachrichten zurück, die eine solche Angabe bereits enthalten.

• X-Face Obwohl das usenet rein textbasiert ist, kann man als kleine Ausnahme eine 48x48 Pixel grosse schwarz-weisse Bilddatei angegeben. Diese Grafik ist dazu gedacht, das Gesicht des Autors darstellen und zusammen mit der Nachricht im usenet-Client angezeigt zu werden. Natürlich kann man jedes beliebige Icon angegeben, das untere Beispiel zeigt z.B. den Hund Gromit:

  X-Face: "r6;_Y:euflWQIf$5%P0Fc%TyS(t/+D6fCCS2W;0Rk)BBVCt|z#ERoPCI%0QA
   `vmEi&(y';5Th{Li4G1HXItb0_)&PWr

  Bei X-Face handelt es sich um ein spezielles Format, dass z.B. mit dem Unix-Programm "compface" oder dem Online X-Face Converter von Jeff Dairiki erzeugt werden kann.

• NNTP-Posting-Host Der NNTP-Posting-Host-Header darf nur vom ersten Server – also dem, der die Nachricht vom Client erhält – erzeugt werden. Er enthält entweder die IP oder den per DNS afgelösten Namen des Systems, von dem der Server die Nachricht erhalten hat. Diese Protokollierung erweitert bei Bedarf die Möglichkeiten, den Absender einer Nachricht aufzuspüren. Sollte der Client diesen Header übermitteln, so muss ihn der Server löschen (und ggf. durch einen eigenen ersetzen). Siehe auch From-Header, Sender-Header.

Literatur:

• World Wide Web Consortium (W3C): RFC 1036. Standard for Interchange of USENET Messages.
• World Wide Web Consortium (W3C): RFC 850. Standard for Interchange of USENET Messages. Veraltet!
• World Wide Web Consortium (W3C): RFC 977. Network News Transfer Protocol.
• Spencer, Henry: Son of RFC1036. News Article Format and Transmission. Internet draft.