CONTROL-MESSAGES (RFC - CNews - INN)

WOZU DIENEN CONTROL-MESSAGES WEB (WWW)

DEFINITION

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."