Funktionsbeschreibung

Dieser Text befindet sich inhaltlich auf dem Stand des Jahres 2002 und wird nicht mehr gepflegt oder aktualisiert. Er ist in jeder Hinsicht veraltet und steht nur noch zu Dokumentationszwecken online.

Der Ablauf in der Übersicht

Wenn der Article Checker gestartet wird, verbindet er sich mit dem in der Konfigurationsdatei eingestellten Newsserver und authentifiziert sich ggf. mit Benutzername und Passwort. Danach holt er sich den aktuellen Zählerstand der ersten in der Konfigurationsdatei genannten Newsgroup, vergleicht diesen mit dem gespeicherten letzten Stand und liest - wenn neue Postings vorliegen - jedes Posting der Reihe nach ein.

Wenn entweder

• das Schlüsselwort (Default: check) im Subject [nicht mehr in der ersten Zeile des Bodies!] vorkommt oder

• für diese Gruppe "Autocheck" in der .ini-Datei definiert ist und keines der "Verbots"-Schlüsselwörter (Default: ignore, no reply, no replies) in Subject oder der ersten Zeile des Bodies vorkommt und das Killfile nicht greift,

wird das Posting auf formale Fehler geprüft und ggf. eine Antwort generiert. Diese erscheint als Followup auf das geprüfte Posting, aber nur in der Testgruppe, nicht als Crosspost. Die Antwort kann auf einem anderen Server als dem, von dem der Bot liest, gepostet werden. Dabei gilt: check (oder das entsprechende Schlüsselwort lt. .ini-Datei) führt immer zu einer Prüfung, auch wenn ignore etc. (oder das entsprechende Schlüsselwort lt. .ini-Datei) dabeisteht. Eine Antwort kann aber immer (auch trotz check) dadurch unterdrückt werden, dass ignore etc. (oder das entsprechende Schlüsselwort lt. .ini-Datei) in den Header Keywords: eingetragen wird.

Soweit direkt hinter dem Schlüsselwort verbose steht, fügt der Bot einen Auszug aus dem Logfile (bzw. von seiner Ausgabe auf STDOUT) an.

Wenn die erste Newsgroup komplett geprüft ist, schreibt das Programm den neuen Stand des jeweiligen Artikelzählers in die .ini-Datei und setzt die Prozedur mit der nächsten Gruppe fort. Danach beendet es sich.

Der Start kann durch das Anlegen einer Sperrdatei verhindert werden, so dass für kurzzeitige Pausen keine Änderungen an Cronjobs oder Taskplanern vorgenommen werden müssen.

Alternativ kann der Bot ab V 1.2.02 BETA auch von einem INN direkt befeedet werden. Bisher wird dabei allerdings nur traditional spool unterstützt. (Bislang experimentiell.)

Was überprüft der Checkbot?

• Doppelte Header.

• From:-Header: Dieser muss in der Form mail@do.main, mail@do.main (Realname) oder Realname <mail@do.main> angegeben werden, wobei sowohl Realname wie auch mail@do.main nur die im RFC s-o-1036 zugelassenen Zeichen enthalten dürfen. Insbesondere sind Punkte am Ende von mail oder Punkte und Sonderzeichen innerhalb von Realname, wenn dieser nicht in Anführungszeichen steht, unzulässig.

  Die Top-Level-Domain der Mailadresse muss existieren und do.main muss den restriktiven Vorgaben für Domainnamen entsprechen, d.h. darf nichts außer alphanumerischen Zeichen, - und . enthalten. Wenn Realname fehlt oder nicht aus mindestens zwei getrennten Wörtern von mindestens zwei Buchstaben Länge besteht, wird dies ebenso wie die Verwendung von Role-Accounts bei Aufforderung via check (oder bei Vorliegen eines anderen Problems) moniert.

• Reply-To: Sollte nicht mit From: übereinstimmen. Ansonsten gleiche Prüfungen wie bei From:, der Realname wird allerdings nicht verlangt.

• Date: Muss syntaktisch gültig sein und nach 1970 liegen.

• Message-ID: Muss syntaktisch gültig sein, d.h. aus <localpart@fqdn> bestehen. Der FQDN muss eine gültige Top-Level-Domain haben; er darf nicht aus einer IP-Nummer bestehen und darf keine ungültigen Zeichen enthalten, d.h. ist auf alphanumerische Zeichen, - und . beschränkt. Sollte der Newsreader ein Mozilla sein und der localpart der MID dem üblichen Mozilla-Muster entsprechen und die Domain der Mailadresse auch für die Message-ID verwendet werden, wird - soweit check angefordert wurde oder bereits ein anderes Problem aufgetreten ist - ebenfalls eine Warnung ausgegeben. Die in draft-ietf- usefor-msg-id-alt-00 vorgeschlagene Fassung <unique%address@do.main> wird erkannt und einstweilen nicht moniert.

• 8bit-Zeichen im Header werden moniert.

• 8bit-Zeichen im Body erfordern (irgendein) definiertes Charset und (irgendein) definiertes Content-Transfer-Encoding. Der Sinngehalt dieser Angaben wird noch nicht geprüft.

• Base64 als Kodierung für den Body wird bei Aufforderung via check (oder bei Vorliegen eines anderen Problems) moniert.

• MIME-Multipart-Postings produzieren bei Aufforderung via check (oder bei Vorliegen eines anderen Problems) einen Hinweis. Eine sinnvolle Auswertung der einzelnen MIME-Parts kann leider noch nicht geleistet werden, da der Bot (noch) nicht in der Lage ist, das Posting in einzelne MIME-Parts zu zerlegen.

• Postings mit VCard werden bei Aufforderung via check (oder bei Vorliegen eines anderen Problems) moniert; allerdings wird bisher wohl nur die Netscape-Variante erkannt, OE-VCards noch nicht (?).

• HTML-Postings werden bei Aufforderung via check (oder bei Vorliegen eines anderen Problems) moniert; falls beides (text/plain und text/html) als multipart/alternative verschickt wurde, erkennt der Bot das noch nicht; dann erfolgt nur der allgemeine Hinweis auf Multipart-Postings.

• Die Zeilenlänge im Body muss weniger als 76 Zeichen betragen; in der Signatur sind maximal 80 erlaubt. Dies wird bei Aufforderung via check (oder bei Vorliegen eines anderen Problems) moniert.

• Der Signaturtrenner muss, soweit vorhanden, -- sein. Die Länge der Signatur darf maximal 4 Zeilen à 80 Zeichen betragen. Dies wird bei Aufforderung via check (oder bei Vorliegen eines anderen Problems) moniert.

Der Checkbot kann auch in einem pedantic-Modus gestartet werden, in dem er alle genannten Probleme immer, also auch ohne Aufforderung via check, moniert. Genauso können einzelne Überprüfungen abgeschaltet werden.

Konfigurationsdateien

Der Checkbot benötigt zwei Konfigurationsdateien: die .ini-Datei und die .rc-Datei. Erstere enthält Konfigurationseinstellungen, letztere die Textbausteine, aus der die Antwortpostings zusammengesetzt werden. Außerdem können noch zwei weitere Dateien angelegt werden: die Sperrdatei .disabled und das Killfile .kill.

.ini-Datei

Die einzelnen Parameter stehen jeweils in einer eigenen Zeile. Der Aufbau ist folgender:

Parametername = Parameterwert
[...weitere Name-Wert.Paare...]
checkgroups:
news.gruppe y/n
[...weitere Gruppen...]

Gültige Parameter sind:

1. reader: Der Newsserver, von dem die zu checkenden Postings geladen werden, ggf. gefolgt von einem Komma und dem anzusprechenden Port. Dieser Eintrag (zumindest der Servername) ist zwingend.

2. reader_user: Der dafür ggf. erforderliche Benutzername. Fehlt dieser Eintrag, wird keine Authentifikation vorgenommen.

3. reader_pass: Das Passwort zu dem Benutzernamen.

4. post_server: Der Newsserver, auf dem die Antworten des Bots gepostet werden sollen, ggf. gefolgt von einem Komma und dem anzusprechenden Port. Fehlt dieser Eintrag, wird der unter reader angegebene Server verwendet.

5. poster_user: Wie oben.

6. poster_pass: Wie oben.

7. trigger_check: Der Begriff oder die Begriffe, der/die den Checkbot zum Checken bewegen soll(en), wenn er ihn (oder einen von ihnen) im Subject: oder der ersten Zeile des Bodies findet - als Regular Expression. Standardmäßig (wenn dieser Eintrag fehlt) ist das check - egal, ob alleine stehend oder Teil eines Wortes.

8. trigger_ignore: Der Begriff oder die Begriffe, der/die den Checkbot im Autocheck-Modus vom Checken abhalten soll(en), wenn er ihn (oder einen von ihnen) im Subject: oder der ersten Zeile des Bodies findet - als Regular Expression. Standardmäßig (wenn dieser Eintrag fehlt) sind das ignore, no reply (mit und ohne Leerzeichen), noreplies (mit und ohne Leerzeichen) sowie nocheck (in einem Wort).

9. rcfile: Der Dateiname der .rc-Datei. Falls der Eintrag fehlt, wird der Name der .ini-Datei angenommen.

10. killfile: Der Dateiname der .kill-Datei. Falls der Eintrag fehlt, wird der Name der .ini-Datei angenommen.

Parametername und -wert werden durch ein = getrennt. Zwischen den Parametern dürfen Kommentarzeilen stehen; diese dürfen aber kein = enthalten! Auf die Parameter muss das Schlüsselwort checkgroups: (mit dem Doppelpunkt) auf einer eigenen Zeile folgen.

Alle weiteren Zeilen enthalten jeweils den Namen einer zu checkenden Newsgroup, ein (!) Leerzeichen, y oder n, um den Autocheck-Modus für diese Gruppe ein- (y) oder auszuschalten (n), ein (!) Leerzeichen und danach den aktuellen Stand des Artikelzählers für die betreffenden Gruppe, den der Checkbot selbständig aktualisiert. Bei der Ergänzung neuer Gruppen kann man den Zähler sowohl eintragen (wenn man einen passenden Wert kennt) wie auch weglassen. Kommentare o.ä. sind nach dem Schlüsselwort checkgroups: nicht mehr zulässig.

Auch im Feeding-Modus werden nur Postings in die Gruppen geprüft, die hier genannt werden; auch die Einstellungen für den Autocheck-Modus werden übernommen. Bei Crossposts in mehrere zu checkende Gruppen gilt die niedrigste Einstellung, im Zweifelsfall also ein abgeschalteter Autocheck-Modus.

.rc-Datei

In dieser Datei sind die Textbausteine enthalten, derer sich der Checknot bei der Generierung einer Antwort bedient, einschließlich der Headerzeilen. Sie lassen sich den eigenen Bedürfnissen anpassen.

Die einzelnen Textbausteine sind folgendermaßen aufgebaut:

[name]
;
Textbausteintext
;

Zu achten ist auf einen korrekten Zeilenumbruch im Textbausteintext. Das Löschen eines Textbausteins führt dazu, dass die entsprechenden Checkroutinen nicht mehr durchgeführt werden (d.h., genau genommen: sie werden durchgeführt, ein eventuell positives Ergebnis aber vor dem Posten der Antwort verworfen). Nicht gelöscht werden dürfen die Abschnitte [head], [header], [header-auto], [footer], [intro], [allok] und [nr].

Es können seit Build 00061301 BETA auch spezielle newsreaderspezifische Textbausteine definiert werden. Diese bestehen dann aus dem Namen des Textbausteins, einem Bindestrich und der Newsreaderkennung, bspw.

[sigdel-oe]
;
Textbausteintext
;

Diese werden dann direkt nach dem allgemeinen Textbaustein ausgegeben. Für nähere Hinweise bzgl. der erkannten Newsreader und der zugehörigen Kürzel vgl. die .readme-Datei sowie sample.ini.

Es können seit Build 00080901 BETA auch Variablen verwendet werden. Diese werden dann automatisch mit dem entsprechenden Wert ersetzt. Zur Verfügung stehen alle Headerzeilen des gecheckten Postings als $header{'headername'} und nach Dekodierung von quoted/printable und Base64 als $header_decoded{'headername'} sowie ab Build 00082501 BETA der Localpart ($frlocpart/$rplocpart) und der Domainpart der Adresse im From: ($frdompart) sowie im Reply-To: ($rpdomain) und der (zuletzt) erkannte falsche Signaturtrenner ($wrongsig) zur Verfügung. Vgl. dazu auch die beigefügte sample.rc.

.disabled-Datei

Wenn eine solche Datei existiert, wird das Programm sofort ohne weitere Ausgabe beendet. Vorgesehen ist dieser Mechanismus, um den Checkbot (oder eine Inkarnation desselben) ohne die Notwendigkeit von Änderungen an Cronjobs oder Taskplaner-Einträgen kurzzeitig zu dekativieren.

Eine Datei namens artchk.pl.disabled deaktiviert den Bot ganz, mit dem Namen <inidatei>.disabled nur den Lauf unter Aufruf der entsprechenden .ini-Datei unterbunden.

.kill-Datei

In dieser Datei finden sich Einträge, um bestimmte Postings von der automatischen Prüfung auszunehmen.

Die einzelnen Einträge sind folgendermaßen aufgebaut:

headername = regular expression # Kommentar
# noch ein Kommentar

Dabei bedeutet headername den Namen einer Headerzeile (einer Kopfzeile), deren Inhalt mit der als regular expression angegeben Regular Expression verglichen wird. Wenn der reguläre Ausdruck bei einem Posting auf den Inhalt der entsprechenden Headerzeile passt, wird das betreffende Posting nicht automatisch geprüft. Kommentare können als eigene Zeilen oder auch in einer anderen Zeile, aber immer mit # beginnend, eingefügt werden. Text zwischen # und dem Zeilenende wird ignoriert.

Das Killfile hat keine Wirkung bei einer durch check im Subject (Betreff) ausgelösten Prüfung.

Parameter beim Aufruf

Die Aufrufsyntax für den Checkbot ist artchk.pl -v(vvv) -ppath -nname -lname --log.

-v mit einem bis vier v spezifiziert den Debug-Level für die Ausgabe. Je höher die Anzahl der v, desto umfangreicher die Ausgabe. Die Option kann weggelassen werden; Voreinstellung ist "0".

-p path muss eine gültige (am besten absolute) Pfadangabe sein. Dieser Pfad wird den Dateinamen (-n) der Konfigurationsdateien vorangestellt. Die Option kann weggelassen werden; Voreinstellung ist ein leerer Pfad.

-n name muss der Dateiname der Konfigurationsdateien sein. Er wird um den Pfad (-p) ergänzt. Die Option kann weggelassen werden; Voreinstellung ist der Name des Checkbots einschließlich Extension, also im allgemeinen artchk.pl.

-l name muss der Dateiname eines Logfiles sein. Er wird um den Pfad (-p) ergänzt. Die Option kann weggelassen werden; Voreinstellung ist die Angabe bei -n mit angehängtem .log.

--log startet das Logging und schreibt wichtige Meldungen sowie das Ergebnis der Prüfroutinen (check verbose - Debug-Level 4) für jedes Posting mit der jeweiligen Message-ID in das Logfile, auch wenn die Prüfung nicht zu einem Antwortposting (Followup) führt.

--feedmode startet den Checkbot im Feeding-Modus. In dieser Betriebsart erwartet er auf STDIN die Übergabe des Pfades zum jeweils zu checkenden Posting; alle Bildschirmausgaben sind unterdrückt, das Aktivieren des Loggings ist empfohlen. Das Script bleibt in einer Schleife, bis die Eingabe auf STDIN beendet wird. Dieser Modus ist vorgesehen, um den Checkbot direkt aus einem INN heraus zu befeeden; vgl. dazu die Erläuterungen auf der Installationsseite.

--pedantic sorgt dafür, dass auch im Autocheck-Modus alle Probleme gemeldet werden.

Debug-Level

Mit der Einstellung des Debug-Levels kann die Ausgabe des Checkbots auf der Standardausgabe (STDOUT) beeinflusst werden. Je höher die Zahl, desto umfangreicher die Ausgabe.

Bei der Anforderung von check verbose wird das Äquivalent von Debug-Level 4 an das Antwortposting angehängt.

Dieser Text befindet sich inhaltlich auf dem Stand des Jahres 2002 und wird nicht mehr gepflegt oder aktualisiert. Er ist in jeder Hinsicht veraltet und steht nur noch zu Dokumentationszwecken online.