Aufbau des "Network news transport protocol" (NNTP) (1/3)

Das Network news transfer protocol (NNTP) dient im Internet der Verbreitung von Nachrichten, die i. Ggs. zu E-Mails nicht an einen speziellen Empfänger, sondern innerhalb von hierarchisch geordneten Gruppen im sog. usenet an die Allgemeinheit gerichtet sind

Dieser Artikel führt kurz in den technischen Aufbau des usenet ein und gibt Ihnen einen kompakten Überblick über den Aufbau von Nachrichten und die Kommunikation zwischen Newsservern und -clients. Dokumente über die üblichen NNTP-Header und NNTP-Befehle und Response-Codes stehen ebenfalls zur Verfügung. Informationen über die Benutzung des usenet finden Sie z.B. unter Erste Schritte im Usenet von Hubert Partl.

Inhalt

• Aufbau von NNTP-Nachrichten
• Publikation von NTTP-Nachrichten
• Kontrollnachrichten (Befehle), im einzelnen
  Cancel, Ihave und SendMe, Newgroup, Rmgroup, Sendsys, Version und Checkgroups.

Aufbau von NNTP-Nachrichten

Ähnlich wie beim E-Mail-Protokoll SMTP ist NNTP rein texbasiert: Das Verarbeiten von etwa binären Formaten bedarf also besonderen Vorgehensweisen wie etwa uu- oder base64-Kodierungen. Ebenfalls wie bei SMTP dienen die meisten Header der Zustellung und Weiterleitung der Nachrichten.

Während etwa die HTTP-Kommunikation dreiteilig ist (Requestbefehl bzw. Status-Code, Header, Body), so bestehen Mitteilungen innerhalb von NNTP nur aus zwei Teilen: Den Headern, die immer in einer eigenen Zeile stehen und der Form Header-Name: Wert folgen, und dem Body mit dem (eigentlichen) Inhalt. Einzelne Header können sich auch über mehrere Zeilen erstrecken, wenn die Folgezeilen mit einem oder mehreren Leerzeichen beginnen (ein Beispiel für einen mehrzeiligen Header finden bei der Erläuterung des X-Auth-Header). Für den Austausch von Nachrichten zwischen Servern oder zwischen Client und Server reicht diese Struktur aus; besondere Mitteilungen, wie z.B. die Aufforderung zum Löschen einer Nachricht, sind durch Kontrollnachrichten implementiert.

News-Artikel beginnen immer mit einer Reihe von Headern, von denen einige zwingend erwartet, andere nach Belieben vergeben werden können. Es können auch benutzerdefinierte Header erzeugt werden, die – der Übersichtlichkeit halber – mit "X-" beginnen sollten, z.B. X-No-Archive. Nach den Headern folgt eine Leerzeile (in veralteten Varianten von NNTP auch anders gelöst, siehe Literatur), und darauf hin der Body, also die eigentliche Nachricht. Ein Beispiel:

  Path: news.siberius.com!news-mue1.dfn.de!xyz.ruebezahl.de
  From: "Jonathan Dillmann" <jd@web.de>
  Newsgroups: de.soc.recht.misc
  Subject: Re: Diebstahl eines Rades
  Date: Fri, 18 Oct 2002 10:45:11 +0200
  Organization: XYZ GmbH, Germany
  Lines: 8
  Message-ID: <aoohd1$1c8$1@xyz.ruebezahl.de>
  References: <hjm4$dk631@mamenchi.zrz.TU-Berlin.DE>
  NNTP-Posting-Host: xyz.ruebezahl.de
  X-Priority: 3
  X-MSMail-Priority: Normal
  X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
  X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

  Hallo,

  > gibt es eigentlich eine zentrale Datenbank für gestohlene
  > Fahrräder? Ist eine präventive Frage.

  Siehe mal http://www.bikefinder.de

  Gruss Jonathan

Publikation von NNTP-Nachrichten

Nachrichten im usenet werden dezentral und redundant gespeichert. Ein News-Server, der eine Nachricht von einem Client erhält, speichert sie in seiner Datenbank und sendet sie an alle anderen News-Server, die er kennt und von denen er weiss, dass sie Nachrichten der entsprechenden News-Gruppe(n) verwalten. Diese speichern sie ebenfalls und senden sie wiederum an alle ihnen bekannten Server, falls diese die Nachricht noch nicht haben, usf. Da auf diese Weise der Speicherbedarf stetig steigen würde, löschen die Server die Nachrichten aus ihren Datenbanken nach Ablauf einer bestimmten Zeit (meist um die 30 Tage).

Von besonderer Bedeutung ist die eindeutige ID einer Nachricht, die durch den Header Message-ID gekennzeichnet ist. Diese ID liegt im Format <laufende Nummer@News-Server> vor; die laufende Nummer kann der erste News-Server, der die Nachricht erhält, nach freiem Belieben vergeben, so dass sich zusammen mit dem Namen des Servers immer eine eindeutige Bezeichnung der Nachricht ergibt. 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, zu erkennen, welche Nachrichten sie bereits haben, als auch dem News-Client in Verbindung zum References-Header, zu welchem Diskussionsfaden die jeweilige Mitteilung gehört.

Für die effiziente Verbreitung der Nachrichten ist auch der Path-Header von Bedeutung, an den sich jeder Server anfügt, der die Nachricht bekommt. Ein System kann so erkennen, dass ein Weiterleiten an ein ihm bekannten Server unnötig ist, falls er im Path-Header erwähnt ist. Die links stehende Grafik stellt beispielhaft den Weg einer Nachricht dar:

Das vorliegende Beispiel ist stark vereinfacht. Zum einen kann die Nachricht bei dieser Konstellation auch anders verteilt werden: H2 könnte die Nachricht auch über den Pfad H3 » H4 » H5 » H2 bekommen; der kürzeste Weg ist nicht immer der schnellste. Zum anderen sind die Verbindungen zwischen Servern fast immer bidirektional, so dass, wenn H5 den Server H3 kennt, dies auch umgekehrt gilt, und somit H5 die Nachricht von H3 bekommen hätte und der Weg über H4 nicht erforderlich gewesen wäre. Datenstrukturell handelt es sich bei einem Netzwerk aus News-Servern um einen ungerichteten Graphen, wobei die Knoten die Server und die Kanten die Beziehungen dazwischen darstellen. An den Kanten wird zusätzlich die Information gespeichert, welche Newsgruppen die einzelnen Server pflegen, so dass auch nur die Nachrichten an einen Server geleitet werden, an denen er auch interessiert ist.

Kontrollnachrichten (Befehle)

Kontrollnachrichten dienen der Verbreitung von Befehlen oder Anfragen von Clients oder Servern an (andere) Server. Der Vorteil, diese Kommunikation genauso zu behandeln wie die Verbreitung von Nachrichten, liegt hauptsächlich darin, dass sich diese Anfragen genauso verbreiten wie "Inhalte" und damit ein spezielle Behandlung entfällt. Allerdings ist diese Methode in vielen Fällen, etwa zur Synchronisation vieler Nachrichten unter verschiedenen Servern, nicht sehr effizient. Daher haben einige, weit verbreitete News-Server-Programme eigene Verfahren entwickelt, die diese Aufgaben sinnvoller erledigen. Falls sie mit einem Server kommunizieren, der diesen Standard nicht unterstützt, können sie immer noch auf das in RFC 1036 definierte Verfahren zurück greifen, das im folgenden beschrieben wird

Kontrollnachrichten unterscheiden sich von herkömmlichen Nachrichten durch den Control-Header. Aus Gründen der Kopatibilität sollten auch solche Nachrichten als "control messages" interpretiert werden, deren Subject-Header mit "cmsg" beginnt oder deren Newsgroups-Header "all.all.ctl" lautet. Alle Werte des Control-Headers und/oder alle Eintragungen im Body der Nachricht werden als Parameter der jeweiligen Anfrage bzw. Anforderung betrachtet. Beispiel für das Anlegen einer neuen Newsgroup (siehe Newgroup):

  Path: xyz.ruebezahl.de
  From: "News Administrator" <news-admin@ruebezahl.de>
  Message-ID: <ab_cdef123_g@xyz.ruebezahl.de>
  Approved: news-admin@ruebezahl.de
  Control: Newgroup de.alt.fan.football unmoderated
  Subject: cmsg Newgroup de.alt.fan.football unmoderated
  X-No-Archive: yes
  X-Auth: PGPMoose V1.1 PGP system.newgroup
   PPlv,3ImsThqbHJMNaNiMraBAQHVuwH+MT3PTdzB2LScVxlIkOW2jyXuRntSi885
   zuqaGbbhuR5IQO9CaQl9yxQWya+H1iyRJJsfrw5F6zkkw9Ix59khjqln
   88pjk
  X-Info: http://www.ruebezahl.de/usenet/admin/readme.txt

• Cancel: Eine Nachricht löschen
  Syntax: cancel [Message-ID]

  Der Cancel-Befehl zum Löschen einer Nachricht wird vom Client an einen Server und von diesem Server, wie bei einer herkömlichen Nachricht auch, an alle ihm bekannten Server propagiert. Der Parameter "[Message-ID]" enthält die Message-ID der zu löschenden Nachricht.

  Grundsätzlich zum Löschen berechtigt (im Sinne von RFC 1036) sind nur der Autor der Nachricht oder der Administrator eines betroffenen Servers. Alle anderen Löschanfragen sind abzulehnen. Allerdings kann der Absender der Anfrage nicht immer zweifelfrei bestimmt werden (siehe auch From-Header und Sender-Header), so dass teilweise auch Nachrichten ohne Berechtigung gelöscht werden.

  Für Server ist es empfehlenswert, die Löschanfrage auf die gleiche Art zu verteilen wie die zu löschende Nachricht selbst, weil sich so die Chance erhöht, alle betroffenen Server zu erwischen. Falls ein Server eine Löschanfrage mit einer Message-ID bekommt, zu der er (bei sich) keine Nachricht findet, so sollte er die Anforderung zumindest kurz im "Hinterkopf" behalten, da er die Nachricht vielleicht noch bekommt und sie von der Löschanfrage überholt wurde.

• Ihave und SendMe: Nachrichten zwischen Servern austauschen
  Syntax: ihave [Message-ID list]
          sendme [Message-ID list] [[remotesys]]

  Mit den Befehlen Ihave und SendMe tauschen benachbarte Server Ihre Nachrichten aus. Angenommen, Server A hat die Nachricht mit der Message-ID <abc@xyz.ruebezahl.de> so sendet er an an dem ihm bekannten Server B die Nachricht "Ihave <abc@xyz.ruebezahl.de>". Falls B an der Nachricht interessiert ist (also sie noch nicht hat), so antwortet er entsprechend mit "SendMe <abc@xyz.ruebezahl.de>".

  Diese Art der Nachrichtenverteilung ist recht ineffizient. Zum einen können, insbesondere bei kurzen Nachrichten, diese Kontrollnachrichten mehr Aufwand und Datenverkehr verursachen, als wenn die Server ihre Nachrichten einfach blind an ihre Nachbarn sendeten. Zum anderen ist dieses Protokoll sehr langatmig, wenn es um eine Sammelübertragung von vielen Nachrichten auf einmal geht. Daher wird diese Kommunikation meist mit Hilfe anderer Standards erledigt (siehe oben).

  Statt eine oder mehrere Message-IDs im Control-Header hinter Ihave bzw. SendMe anzugeben, kann man sie auch in den Body schreiben. Diese Vorgehensweise empfiehlt sich zumindest, wenn man viele Message-IDs übermitteln will.

• Newgroup: Eine neue Newsgroup erzeugen
  Syntax: newgroup [groupname] ["moderated|unmoderated"]

  Der newgroup-Befehl fordert einen Server auf, eine neue Gruppe anzulegen. Wie auch die Verteilung von Nachrichten wird so eine neue Gruppe um die Welt getragen. Ebenso wie das Löschen von Gruppen sind solche Aufforderungen besonders gründlich zu prüfen, da man mit dem Anlegen und Entfernen von Gruppen sorgsam umgehen sollte. Da dies i.d.R. nicht 20 mal am Tag passiert, werden diese Befehle meist auch nicht automatisch ausgeführt, sondern dem jeweiligen Administrator zur Einzelentscheidung "auf den Schreibtisch gelegt". Als zweiter Parameter kann "moderated" für moderierte bzw. "unmoderated" für unmoderierte Newsgroups angegeben werden. Zudem kann im Body eine Beschreibung angegeben werden, die Server an den Client übertragen können, um den Benutzern Hinweise zum Inhalt der Gruppe zu geben. Beispiel: siehe oben.

• Rmgroup: Eine Newsgroup löschen
  Syntax: Rmgroup [groupname]

  Der Rmgroup-Befehl fordert einen Server auf, eine bestehende Gruppe zu löschen, also aus der Liste der verwalteten Gruppen zu entfernen und möglicherweise eintreffende Nachrichten für diese Gruppe nicht zu verarbeiten. Wie auch die Verteilung von Nachrichten wird so eine Löschanfrage um die Welt getragen. Ebenso wie das Anlegen von Gruppen sind solche Aufforderungen besonders gründlich zu prüfen, da man mit dem Anlegen und Entfernen von Gruppen sorgsam umgehen sollte. Da dies i.d.R. nicht 20 mal am Tag passiert, werden diese Befehle meist auch nicht automatisch ausgeführt, sondern dem jeweiligen Administrator zur Einzelentscheidung "auf den Schreibtisch gelegt".

• Sendsys: Liste der einem Server bekannten anderen Server anfordern
  Syntax: cancel [Message-ID]

  Der Sendsys-Befehl fordert vom Server eine Liste der Server an, die er "kennt", d.h., mit denen er Nachrichten austauscht. Ein Abgleich derartiger Informationen kann zu einer effizienteren Verteilung von Nachrichten eingesetzt werden.

• Version: Server nach eingesetzter Software fragen
  Syntax: version

  Der Version-Befehl fordert den News-Server auf, die genutzte Sofware (inkl. Versionskennung) an den Absender dieser Aufforderung per E-Mail zu schicken, und zwar an die unter Reply-To oder – falls nicht vorhanden – an die unter From angegeben Adresse.

• Checkgroups: Liste aller verfügbaren Newsgroups anfordern
  Syntax: checkgroups

  Der checkgroups-Befehl fordert eine Liste aller auf dem Server verfügbaren Newsgruppen an.

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.