Logo of the Department Homepage · The Institute · ChemNet · Chemistry Information · Internet · Index · User Pages

CONTROL MESSAGES (RFC - CNews - INN)

Die folgende Aufstellung soll darueber informieren, was Control-Messages sind und welches Ziel eine konkrete Control-Message verfolgt. Gegenuebergestellt werden dabei die Definition im RFC 1036 und die Implementierungen in der Newssoftware (CNews bzw. INN). Der Text nimmt Bezug auf die zur Zeit aktuellen Versionen von CNews (Update der Performance-Release; 20.02.93) und INN (Version 1.4; 18.03.93).

WOZU DIENEN CONTROL-MESSAGES WEB (WWW)

Control-Messages sollen das Verhalten des Newssystems kontrollieren. Sie dienen unter anderem dazu, neue Gruppen einzurichten, alte Gruppen zu entfernen, bestimmte Artikel zu loeschen und Informationen ueber andere Newssysteme zu erhalten.

DEFINITION

Control-Messages sind definiert im RFC 1036 (Standard for Interchange of USENET Messages), Abschnitte 2.2.6 und 3. Sie sehen formal wie "normale" Newsartikel aus, sind aber zur Kommunikation zwischen den einzelnen Newsservern gedacht und loesen besondere Aktionen des News-Systems aus.

Nach RFC 1036 gibt es ein einziges gueltiges Kennzeichen einer Control-Message - die Headerline "Control: "

Allerdings wurde aus Gruenden der Abwaertskompatibilitaet im RFC 1036 fest- gelegt, dass die folgenden Headerlines ebenfalls eine Behandlung als Control- Message bewirken sollten:

"Newsgroup: *.*.ctl" (Ist keine "Control:"-Zeile vorhanden, so wird versucht, das Subject ent- sprechend auszuwerten)

"Subject: cmsg ..." (Der Rest des Subjects wird ausgewertet)

Implementierungen, die Control-Messages in der obigen Art und Weise erzeugen, erfuellen jedoch nicht den RFC-Standard!

DMPLEMENTIERUNG

RFC 1036:
Es steht den Autoren von Newssoftware frei, die durch Control-Messages ausgeloesten Aktionen automatisch ausfuehren zu lassen oder manuell. Manuelle Aktionen sollen zuegig erfolgen. [Unsere Meinung: Die Aktionen, die von Control-Messages ausgeloest werden, muessen frei vom Newsadministrator bestimmbar sein.] Wichtig: Durch Control-Messages erzeugte Fehlermeldungen sollen nicht dem Autor zugeschickt werden, sondern dem lokalen News-Account ("usenet")!

CNews:
Bei Erhalt einer Control-Message wird das zugehoerige Shellscript ausgefuehrt. Das Verhalten des Newssystems kann man nur durch Aenderung des Scripts beeinflussen. "Gefaehrliche" Control-Messages (sendsys, version) werden 24 Stunden verzoegert ausgefuehrt, um die Moeglichkeit des Cancelns dieser Messages zu ermoeglichen. Die Shellscripts findet man unter relay/ctl/* (Source) bzw. $NEWSCTL/* (installiertes System)

INN:
Das Verhalten bei Erhalt einer Control-Message (Ausfuehren, Ignorieren, Mail an den Admin, Protokollieren) kann individuell in einer Konfigura- tionsdatei bestimmt werden: Source: samples/control.ctl Installiertes System: $CTLFILE Beispiele fuer Scripts, die man in der Konfigurationsdatei zur Ausfuehrung angeben kann, finden sich im Source (samples/*).

DIE EINZELNEN CONTROL-MESSAGES WEB (WWW)

- cancel

Headerline: "Control: cancel <Message-ID>"
Auswirkung: Das Posting mit der entsprechenden Message-ID wird geloescht.
RFC 1036:   Nur der Autor sowie der lokale Newsadministrator duerfen canceln.
CNews:      Eine Ueberpruefung der Berechtigung findet nicht statt, da 
            sie zu aufwendig waere und ausserdem wenig sinnvoll, weil 
            Newsartikel sehr leicht zu faelschen sind. [2]
            Als einzige Control-Message nicht per Script implementiert, 
            sondern direkt im Code (relay/control.c).
INN:        Es kann konfiguriert werden, ob eine Ueberpruefung stattfinden 
            soll oder nicht ($VERIFY_CANCELS). 
            Default: Keine Ueberpruefung.
            Als einzige Control-Message nicht per Script implementiert, 
            sondern direkt im Code (innd/art.c)


- newgroup

Headerline: "Control: newgroup <Gruppe> [moderated]"
Auswirkung: Die neue Gruppe wird [moderiert] angelegt. 
RFC 1036:   Eine newgroup-Message ist erforderlich, bevor Artikel in der 
            betreffenden Gruppe transportiert werden koennen - daher sollte 
            sie moeglichst automatisch ausgefuehrt werden. [Anmerkung: Dieses 
            Argument galt zu Erstellungszeiten des RFC (BNews), trifft fuer 
            CNews nicht zu, ist bei INN wieder zu beruecksichtigen.]
            Im Message-Body soll eine Beschreibung der Newsgruppe anggeben 
            sein. newgroup-Messages sollen ignoriert werden, wenn der 
            Header "Approved:" fehlt.
CNews:      Alte Versionen: newgroup-Message wird defaultmaessig ausgefuehrt 
            und eine Mail an den Admin geschickt. Neueste Version: Aktion 
            kann festgelegt werden im File $NEWSCTL/newsgroupsperm. 
            Default: Die newgroup-Message wird ausgefuehrt und eine ausfuehr-
            liche Mail an den Admin geschickt.
INN:        Default: Messages von tale@*.uu.net werden ausgefuehrt, Messages 
            von bestimmten anderen Verantwortlichen werden dem Newsadmin zu-
            geschickt (Mail), der Rest wird nur protokolliert.


- rmgroup

Headerline: "Control: rmgroup <Gruppe>
Auswirkung: Die betreffende Gruppe wird geloescht.
RFC 1036:   rmgroup-Messages sind mit grosser Sorgfalt und unter Berueck-
            sichtigung der Auswirkungen auf anderen Systemen zu versenden. 
            Sie sind zu ignorieren, wenn der Header "Approved:" fehlt. 
            [Anmerkung: rmgroup-Messages sollten niemals automatisch ausge-
            fuehrt werden!]
CNews:      Die Aufforderung zur Loeschung wird an den Admin gemailt.
INN:        Analog zu "newgroup"


- sendsys

Headerline: "Control: sendsys"
Auswirkung: Die Konfigurationsdatei "sys" (CNews) bzw. "newsfeeds" (INN) 
            wird dem Absender der Message per Mail zugeschickt. [Anmerkung: 
            Diese Mail ist an die "Reply-To:"- Adresse zu senden, bei Fehlen 
            dieser Angabe an die "From:"- Adresse. Keinesfalls ist sie an die 
            "Sender:"-Adresse oder ueber den "Path:" zurueckzuschicken!]
RFC 1036:   Die im Konfigurationsfile enthaltenen Informationen ueber die Ver-
            teilung der Newsartikel werden als oeffentlich betrachtet. Wer am 
            Usenet teilnimmt, ist verpflichtet, diese Information herauszuge-
            ben - entweder automatisch oder von Hand nach Erhalt einer sendsys-
            Message. Die Datei, die als Antwort verschickt wird, soll dem 
            Format des sys-Files entsprechen.
            Eingefuehrt wurde "sendsys", um die Propagation von Newsartikeln 
            verfolgen zu koennen. [Anmerkung: Der Sinn von unbeschraenkten 
            sendsys-Messages wird heute allgemein bezweifelt.]
CNews:      Der sys-File wird mit 24-stuendiger Verzoegerung zugeschickt. 
            Eine Mail informiert den Admin.
INN:        Default: Anforderungen von *@uunet.uu.net werden ausgefuehrt. 
            Versendet wird die Datei "newsfeeds", die nicht im sys-File-Format 
            vorliegt.


- version

Headerline: "Control: version"
Auswirkung: Dem Autor wird eine Mail zugeschickt, die Angaben ueber Namen 
            und Version der lokal verwendeten Newssoftware enthaelt. 
            [Anmerkungen wie bei "sendsys"]
RFC 1036:   Keine weiteren Angaben
CNews:      Die Angaben werden mit 24-stuendiger Verspaetung zugeschickt. 
            Der Admin wird per Mail informiert.
INN:        Default: Anforderungen von *@uunet.uu.net werden ausgefuehrt, 
            ueber andere wird der Admin nur per Mail informiert.


- checkgroups

Headerline: "Control: checkgroups"
Auswirkung: Eine checkgroups-Message enthaelt eine Liste gueltiger Newsgrup-
            pen. Diese wird mit der Liste der aktiven Newsgruppen auf dem 
            lokalen System verglichen. Abweichungen werden dem Newsadmin per 
            Mail angezeigt. Die Beschreibung neuer Gruppen wird der entspre-
            chenden lokalen Informationsdatei ("newsgroups") angefuegt.
RFC 1036:   Keine weiteren Angaben
CNews:      Die Beschreibung im RFC ist so unvollstaendig, dass eine sinnvolle 
            Implementierung nicht moeglich ist. Die Mail an den Newsadministra-
            tor sollte daher einfach ignoriert werden (der Code ist bekannter-
            massen fehlerhaft, ein Fix steht noch aus [1]). Aktualisiert wird
	    die Datei "newsgroups". 
            [Anmerkung: Es gibt inzwischen diverse (Perl)-Scripts, die diese 
            Aufgabe uebernehmen koennen.]
INN:        Default: Abweichungen gemaess checkgroups-Message werden dem 
            Admin per Mail mitgeteilt.


- senduuname

Headerline: "Control: senduuname"
Auswirkung: An den Autor wird eine Mail geschickt, die den Output des Komman-
            dos "uuname" enthaelt (Liste aller ueber UUCP angeschlossenen 
            Nachbarsysteme).
RFC 1036:   Ist im RFC 1036 nicht vorgesehen.
CNews:      In der neuesten Version nicht mehr implementiert
INN:        Analog zu "version"


- ihave/sendme

Headerline: "Control: ihave <Message-ID Liste> [<Remote System>]"
            "Control: sendme <Message-ID Liste> [<Remote System>]"
Auswirkung: Die Nachrichten werden nur dann uebertragen, wenn sie auf dem 
            System noch nicht vorhanden sind. 
RFC 1036:   Das ihave/sendme-Protokoll ist optional. Es sollte nur nach sorg-
            faeltiger Abwaegung der Vor- und Nachteile eingesetzt werden.
CNews:      Die Ausfuehrungen im RFC reichen fuer eine Implementierung nicht 
            aus; die Autoren haben ein Protokoll nach von ihnen dokumentierten 
            Regeln entwickelt. Fehler im RFC:  darf nicht 
            optional sein. [3]
INN:        Default: Message wird ignoriert.

- - - - - -

[1] 
Aus dem Quellcode, Datei doc/trouble:
"There is no clear specification for the contents of such a message, and 
the C News checkgroups code is known to be buggy. This will be fixed 
eventually."

[2]
Aus dem Quellcode, Datei doc/rfcerrata:
"C News takes the position that the RFC 1036 approach to authentication is 
impossible to implement in a practical way, due to its vagueness and the 
prevalence of gratuitous and unpredictable header rewriting, and on balance 
the inability to cancel is worse than the largely-illusory security provided.  
C News therefore does not authenticate cancellations."

[3]
Aus dem Quellcode, Datei doc/rfcerrata:
"The description of the ihave/sendme protocol is so vague as to be useless 
to an implementor. See the C news documentation for an adequate description 
of the protocol. The description in RFC 1036 also contains an error: 
remotesys is not optional; given that there may be multiple message-ids pre-
ceding it, there would be no way (other than ad-hocery) to tell if the 
final argument were a message-id or a remotesys."
deutsche Version  

www@chemie.fu-berlin.de Last Modification: 2003-07-31