Netz - Rettung - Recht (Artikel mit Tag Usenet)

Base64 ist schlecht zu lesen

nospam@example.com (Thomas Hochstein) — Tue, 05 Apr 2022 04:45:00 +0000

Bereits im vergangenen Juli hatte ich berichtet, dass ich die Moderation der Newsgroup de.alt.netdigest übernommen hatte, und auch ein wenig den von mir verwendeten Workflow vorgestellt.

Das Konversions-Script, das aus einer Einreichung per E-Mail ein Posting für die Newsgroup macht, konvertiert auch den Inhalt der Mail (des Postings) nach UTF-8 und entfernt eine ggf. vorhandene quoted-printable-Kodierung. Beim Thema “Konvertierung” musste ich schon im November letzten Jahres einmal ansetzen, um im Subject:-Header UTF-8-Zeichen “oberhalb” von 0xff korrekt zu kodieren; Anfang diesen Jahres stand ich dann aber zum ersten Mal vor einer E-Mail, deren Body - also der eigentliche Inhalt - als Base64 kodiert war. Eigentlich vorgesehen zur Kodierung binärer Inhalte ist das eine durchaus zulässige Kodierung für reinen Text - nur etwas schwer lesbar. Und da das vom Konversions-Script generierte Posting mit

Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

gepostet wird, war das etwas blöd.

Glücklicherweise war die Lösung hinreichend einfach: so, wie man quoted-printable nach 8bit umkodiert, kann man das auch mit base64 machen. Es braucht nur MIME::Base64 zusätzlich zu MIME::QuotedPrint, und zum bedarfsweisen Aufruf von decode_qp() im Fall der Fälle einen Aufruf von decode_base64().

Das war einfach, und nunmehr bin ich auch auf solche seltsamen Formate gerichtet.

[Nachträglich veröffentlicht im April 2022.]

FLOSS'n'net - Aktivitäten im Jahr 2021 (und 2020)

nospam@example.com (Thomas Hochstein) — Thu, 30 Dec 2021 06:20:00 +0000

Meine Reihe FLOSS’n’net ist in den letzten fast zwei Jahren auch mehr oder weniger der Pandemie zum Opfer gefallen; der letzte der üblicherweise jedes Quartal veröffentlichen Beiträge datiert vom April 2020 und gehört mit zu den letzten vor der “Aufholjagd” noch veröffentlichten (bzw. verfassten) Beiträgen. Entweder als Schlusspunkt oder als Neubeginn - je nachdem, wie 2022 werden wird … - möchte ich daher einen kurzen Rückblick über das vergangene Jahr (und auch das Jahr 2020) geben.

2020 endeten meine Aktivitäten - vor allem rund um Serendipity - mehr oder weniger im April. 2021 habe ich nichts an Serendipity getan, aber das eine oder andere sonst rund ums Netz. Im Einzelnen sieht das dann so aus:

Serendipity (s9y)

Das Blogsystem Serendipity werkelt auch hinter diesem Blog.

Alle Änderungen hier stammen noch aus dem April 2020.

s9y-Kern

Es ist mir endlich gelungen, einen schwer zu reproduzierenden Fehler zu finden, der mich seit Jahren wahnsinnig gemacht hat. Ich nutze für meine Blogbeiträge recht intensiv “erweiterte Eigenschaften von Artikeln”, also entryproperties, bspw. die HTML-Meta-Description und Social-Media-Bilder - und diese “verschwanden” regelmäßig in vorbereiteten Einträgen, was einerseits ärgerlich ist und andererseits oft unbemerkt bleibt. Das ging so weit, dass ich vorbereitete Einträge (Entwürfe) nicht mehr in s9y selbst gespeichert habe, sondern extern, und sie dann erst zur Veröffentlichung dort hineinkopierte. Das wurde seit 2018 im Issue #577 getrackt, aber ohne richtige Lösung (auch weil mir die Zeit zum Debugging fehlte). Am Ende hatten wir 2019 die richtige Ecke gefunden, aber das Problem nicht wirklich behoben. Das gelang aber jetzt (endlich!), und rückblickend war das eine gute Sache, hatte ich doch im Rahmen der “Aufholjagd” 2020/2021 oft mehrere Dutzend komplett postingfertige Beiträge “gebunkert”.
Scheduled entries lose all entryproperty information on publish date. mit
Fix accidental deletion of extended properties. und
[event_trackback] Draft entries should not be saved in delayed_trackbacks
Eine mit s9y 2.3.3 releaste Änderung hatte ein Designproblem im Code aufgedeckt, das zu Fehlern im Plugin History führte, einem der wenigen mit s9y gebundleten Plugins.
[plugin_history] Fix SQL error in plugin_history.

Plugins

Der Bugfix für die entryproperties erforderte auch Änderungen in den entsprechenden Plugins:
[event_metadesc] [event_social] Fix accidental deletion of extended properties.
[event_trackback] Fix draft check.
Das Plugin, das Sitemaps erstellt, sollte in diese Maps keine Übersichtsseiten für getaggte Artikel aufnehmen, die gar nicht existieren (weil das entsprechende Tag zwar vergeben wurde, aber nur für Entwürfe).
[event_sitemap] Don’t add tag pages with draft tags.

Releases

Ich habe alle geeigneten Änderungen aus der aktuellen Entwicklungsversion in den 2.3er-Zweig übernommen und dann Serendipity 2.3.5 releast sowie die Release-Notes, einen Blog- und einen Forenbeitrag verfasst.

Usenet und Co.

Zum Jahresende 2021 hin habe ich eine notwendige Änderung der Einrichtungsregeln für Newsgroups im deutschsprachigen Usenet vorgeschlagen, die Abstimmung dazu durchgeführt und sie umgesetzt.

FAQs

Ich habe 2020 und 2021 die Pflege weiterer FAQs und vergleichbarer Text übernommen und dann auch regelmäßig eine ganze Reihe Änderungen eingearbeitet:

2020

Übernahme der Newsreader-FAQ
(verfügbar in einem Git-Repository auch mit allen alten Fassungen seit 2000)
Übernahme der Newsserverliste
(verfügbar in einem Git-Repository)

2021

Übernahme der Einrichtungsregeln
(verfügbar in einem Git-Repository)

Moderation von de.alt.netdigest

Zum 01.07.2021 habe ich die Moderation der Newsgroup de.alt.netdigest übernommen.

Sonstiges

Seit April 2021 bin ich einer der Newsmaster von bawue.net.

Relaunch von Webseiten

Nicht nur für die Newsgroup de.alt.netdigest habe ich Webseiten erstellt, sondern auch die Webseiten (und die damit verbundene Hintergrunddtechnik) meines Newsservers und von szaf.org komplett überarbeitet und erneuert.

Vorherige Aktivitäten-Übersicht: I/2020

Wir werden sehen, ob und wie es 2022 weitergeht …

Titelbild © momius - stock.adobe.com

Übernahme der "Einrichtungsregeln"

nospam@example.com (Thomas Hochstein) — Mon, 13 Dec 2021 05:30:00 +0000

Vor anderthalb Jahren berichtete ich das letzte Mal hier im Blog darüber, dass ich wieder die Betreuung einer ins Usenet geposteten FAQ übernommen habe; im September war das noch einmal der Fall, wurde aber nur im Changelog meiner Webseiten dokumentiert. Seit mehr als einem Jahrzehnt ist das ein kontinuierlich wiederkehrendes Thema: immer wieder schlage ich Änderungen oder Ergänzungen für eine FAQ oder einen anderen im Usenet geposteten Text vor, und (fast) jedes Mal führt das zu der Feststellung, dass der Betreuer der FAQ entweder verschwunden (nicht mehr erreichbar) ist oder mitteilt, er sei seit Jahren nicht mehr im Usenet präsent und habe ggf. gar keinen Netzzugang mehr, so dass ich dann stattdessen die Betreuung des Textes übernehme. Dazu kommt noch die eine oder andere Bitte des bisherigen Betreuers, zu übernehmen, oder ein Todesfall … Jedenfalls zeigt eine kurze Strichliste, dass ich mindestens zwanzig regelmäßig gepostete Texte betreue (naja, manche werden gar nicht mehr gepostet), von denen aber nur zwei aus meiner Feder stammen. Alle anderen habe ich übernommen (und in einigen Fällen über die Jahre so sehr verändert, dass sie sich mittlerweile fast wie meine eigenen Texte anfühlen).

Begonnen hatte das 2010 mit dem sog. “dana-manual”, dessen Maintainer entschwunden war und dessen Betreuung ich zusammen mit Michael Ottenbruch übernommen habe. Danach kam der große Text zu den Möglichkeiten der Mitgestaltung des Usenets, und danach ging es immer weiter.

2010 war wohl auch das Jahr, in dem mir bewusst wurde, dass die (Hoch-)Zeit des Usenets mehr oder weniger vorbei ist. Natürlich waren schon vorher über die Jahre immer mehr Regulars und gewohnte Namen verschwunden, ohne dass neue “Gesichter” dazukamen; natürlich wurde es in vielen Gruppen stiller, und es gab die üblichen Diskussionen darüber. 2010 hatte ich dann aber festgestellt, dass “da draußen” nicht - wie bisher - immer neue Newsgroups und Welten warten, die man nur entdecken muss, wenn man denn die Zeit dafür findet, sondern dass diese Welten mittlerweile vergangen sind und die Infrastruktur allerorts zu bröckeln beginnt. Diese Erkenntnis begann, als ich zum Jahreswechsel 2009/2010 einmal systematisch die deutschsprachigen Regionalhierarchien zusammenstellen wollte. Das Projekt DE-Regio, geplant als spannender Abstecher in neue Welten, führte stattdessen zu der Erkenntnis, dass da draußen nichts mehr ist. Und das setzte sich dann fort: mit der Übernahme von FAQs, mit der Übernahme anderer Tätigkeiten (wie bspw. der Statistiken in - heute wieder - de.admin.news.lists oder der Übernahme von Moderationstätigkeiten) oder auch einfach der Erkenntnis, der letzte oder einer der letzten Aktiven geblieben zu sein (bei den GVV, bei der Moderation von de.newusers.questions, in der Moderation von de.admin.news.announce usw.). Einige Zeit habe ich das noch als Chance gesehen: wenn ich nur mehr Zeit hätte, wenn man nur Ressourcen bündeln würde, wenn man sich nur einigen und mal etwas ganz neues versuchen würde … Mit dem viel zu frühen Tod von Alexander Bartolich 2012 war mir dann aber klar, dass daraus wohl nichts mehr werden würde, weil damit eine (oder die ) treibende Kraft für Neuerungen im Usenet verschwunden war.

Nun gut. Genug der Rückschau.

Dieser Tage habe ich nun jedenfalls auch die Betreuung der Einrichtungsregeln (“Regeln für die Einrichtung, Änderung und Entfernung von Usenet-Gruppen in de.*”) übernommen; dabei handelt es sich nicht um eine FAQ im eigentlichen Sinne, sondern um einen quasi normativen Text. Außerdem habe ich bei dieser Gelegenheit alle vorherigen Fassungen der Regeln seit 02/1999 in mein Git-Repository aufgenommen, so dass sich zumindest für die vergangenen 23 Jahre alle Änderungen einfach per diff nachvollziehen lassen.

Hintergrund der Übernahme war - ähnlich wie 2010 bei der Übernahme des “dana-Manuals”, und damit schließt sich sozusagen der Kreis - eine Änderung des Regeltextes: mit den Posting- und Teilnehmerzahlen ist über die letzten Jahre und Jahrzehnte auch die Anzahl der Interessenten an der Administration des deutschsprachigen Usenets gefallen. Es gab schon viele Jahre lang praktisch keine Änderungsvorschläge mehr, aber wenn es sie einmal gab, wurde die in den Regeln vorgesehene Mindestanzahl an JA-Stimmen (“Mindestzustimmung”) problematisch. Dieses Jahr war es dann soweit: zwei (von mir vorgeschlagene) völlig unstrittige Änderungen erreichten nicht nur mühelos die Zwei-Drittel-Mehrheit, sondern wurden mit 45:1 bzw. 43:2 Stimmen angenommen, verfehlten aber die Mindestzustimmung von 50 Stimmen. Dieser Wert lag ganz früher einmal bei 30 Stimmen, dann lange Jahre bei 60, schließlich (seit 2011, nach mehreren Anläufen zur Absenkung) bei 50; all das zu Zeiten, wo (bei der letzten Erhöhung 1998) im Schnitt fast 180 Stimmen abgegeben wurden und später (2011) immerhin noch rund 90. Dieser Schnitt ist dann kontinuierlich gefallen.

Daher hatte ich vorgeschlagen, die Mindestzustimmung nunmehr deutlich abzusenken, mindestens auf 20 JA-Stimmen; andere Diskutanten schlugen sogar die Abschaffung der Mindestzustimmung vor. Am Ende gab es dann nicht nur überraschend viele Teilnehmer an dieser Abstimmung (nämlich mehr als 100!), sondern auch eine Absenkung der Mindestzustimmung auf 15 JA-Stimmen. Nachdem ich dieses Verfahren als Proponent in die Wege geleitet und als Votetaker die Abstimmung ausgezählt hatte, war es nun meine Aufgabe als Umsetzungsbeauftragter der Moderation von de.admin.news.announce, das Ergebnis durch Änderung des Regeltextes zum Vollzug zu bringen. Zu diesem Zweck musste ich dann zunächst dessen Betreuung übernehmen …

Und das ist dann wieder ein Beispiel dafür, wie dünn die “Personaldecke” im Usenet geworden ist, wenn der Proponent nicht nur die Abstimmung selbst leitet (in den Anfangszeiten üblich, später aber lange Jahrzehnte eine Domäne der GVV, die jetzt noch zu zweit sind; einer davon bin ich), sondern auch umsetzt und dann am Ende zudem den geänderten Regeltext betreut …

Webseiten für de.alt.netdigest

nospam@example.com (Thomas Hochstein) — Thu, 08 Jul 2021 21:30:00 +0000

Zwar ist das Usenet deutlich älter als das World Wide Web und braucht es - grundsätzlich - auch nicht; dennoch finde ich es hilfreich, Informationen nicht nur im Usenet, sondern auch im Web bereitzustellen. Das Usenet hat seine Stärken in Austausch und Diskussion; für die Bereithaltung (aktueller) Informationen zum Abruf ist es nicht die erste Wahl. Natürlich gab es immer schon FAQs und Infopostings, die regelmäßig (jede Woche, jeden Monat) veröffentlicht werden, damit sie immer in der Gruppe zur Verfügung stehen; natürlich kann man in regelmäßigen Abständen einen Status oder Updates in einer Newsgroup veröffentlichen. Bequemer - solange eine Internetverbindung besteht - und jedenfalls eine sinnvolle Ergänzung ist es aber auch, diese Informationen zusätzlich (ggf. auch in erweiterter Form) online als Webseiten anzubieten.

Daher gibt es jetzt auch eine Website für de.alt.netdigest.

Im Gegensatz zu dem Relaunch der Webseiten um Ostern diesen Jahres herum ist das wieder eine mit dem Webseitengenerator Nanoc erstellte Webpräsenz, diesmal allerdings - im Gegensatz zu meinen anderen Nanoc-basierten Webseiten - auf Grundlage von Bootstrap 5 und daher mit SASS statt LESS. Zudem liegen die Seiten auf einem Server, auf dem bisher Ruby und Nanoc noch nicht installiert waren; der Aufwand war also doch etwas größer, als ich gedacht hatte, zumal es eine ältere Version von Nanoc sein musste, weil die Ruby-Version aus Debian Stable nicht aktuell genug ist. Immerhin aber mal ein schöner Anlass, mich wieder einmal näher mit Nanoc vertraut zu machen, eine passende Rules-Datei zu erzeugen und kleine Helper zu schreiben.

Die Webseiten enthalten (eine weitere) Web-Fassung der auch in der Gruppe geposteten FAQ, einen historischen Überblick über die Geschichte der Gruppe und auf der Startseite eine kurze Einführung einschließlich des Füllzustands der Warteschlange, der bei der täglichen Neuerzeugung der Webseiten ausgelesen wird. Mir gefallen die Inhalte und das - bewusst eher schlicht gehaltene - Design; für Ergänzungen und Kritik habe ich aber natürlich ein offenes Ohr.

[Nachträglich veröffentlicht im Oktober 2021.]

de.alt.netdigest: Hinter den Kulissen

nospam@example.com (Thomas Hochstein) — Tue, 06 Jul 2021 20:15:00 +0000

de.alt.netdigest ist eine moderierte Newsgroup; das bedeutet, dass Postings nicht direkt in der Gruppe veröffentlicht werden, sondern per E-Mail an einen Moderator versandt werden, der dann - wenn nichts gegen eine Veröffentlichung spricht - aus dieser E-Mail wieder ein Posting macht und es veröffentlicht. Das geht natürlich im Grundsatz mit einem Mail- und Newsreader, wäre aber vergleichsweise aufwendig; meistens werden daher per Mail oder über ein Webinterface betriebene Moderationssysteme (oder “Bots”) verwendet.

Für de.alt.netdigest gibt es keine so komplexen Lösungen; im Prinzip müssen ja nur die per Mail eingereichten Beiträge ausgewählt, in ein bestimmtes Format gebracht und dann veröffentlicht werden. Dabei hilft eine Reihe von Scripts, die ich von meinem Vorgänger als Moderator übernommen und an meine Bedürfnisse angepasst habe - genau genommen habe ich auf der Basis der Scripts und aus Versatzstücken daraus meine eigene Lösung erstellt.

Für erste Aufgabe, das Auswählen der per Mail eingereichten Postings für eine Veröffentlichung, lässt sich bequem in einem Mailclient lösen; ich verwende wie Holger, der bisherige Moderator von de.alt.netdigest, zu diesem Zweck Thunderbird. Holger hat die ausgewählten Postings dann in einen Unterfolder verschoben, die entsprechende Datei mit einem Script zur Konvertierung bearbeitet, dass die einzelnen Mails/Postings umformatiert und in eine neue Datei schreibt, aus der sie dann mit einem weiteren Script gepostet werden können. Die eindeutigen IDs der geposteten Einreichungen werden zur Vermeidung von Duplikaten gespeichert und die fertigen Mails archiviert und später gelöscht.

Diesen Workflow habe ich im Prinzip beibehalten, aber mit einigen Abweichungen. Zum einen nutze ich keinen Thunderbird-Folder, sondern ein Verzeichnis auf dem IMAP-Server; zum anderen (und das ist vermutlich der wesentliche Unterschied) veröffentliche ich die ausgewählten Postings nicht live, sondern schiebe sie in eine Warteschlange, aus der jeden Tag eine bestimmte Anzahl veröffentlicht wird, ganz ohne mein Zutun. Das führt zu einem gleichmäßigeren Nachschub, und vor allem vermeidet es, dass Veröffentlichungen in der Gruppe unmittelbar von meinem Zeitbudget abhängig sind. Ich kann Einreichungen “schubweise” bearbeiten, wenn ich einmal am Stück Zeit habe, und mit ihnen die Warteschlange befüllen, die dann auch mal einige Tage (während des Abbaus des von Holger übernommenen Vorrats: einige Wochen) ohne Nachschub auskommt.

Auswahl

Zum Auswählen verschiebe ich mit Thunderbird die Beiträge, die veröffentlichungswürdig sind, aus dem Posteingang der Submissionsadresse in einen IMAP-Folder namens “auswahl”. Spam und ungeeignete Beiträge oder ersichtliche Duplikate kann ich löschen oder anderweitig archivieren; auch könnte ich E-Mails direkt beantworten oder in einem anderen IMAP-Folder (auch in einem anderen IMAP-Konto) verschieben.

Konvertierung

Als Quelle für die Weiterverarbeitung dient mir nicht eine Datei, in der die einzelnen Mails (bspw. im MBOX-Format) zusammengefasst sind, sondern unmittelbar der IMAP-Folder im Maildir-Format. Das Konvertierungsscript convert.pl liest die einzelnen Mails ein und schreibt sie nach Konvertierung in ein Datenverzeichnis data/auswahl/. Zuvor werden die in einzelnen, nach Jahren geordneten Dateien gespeicherten Message-IDs der bereits veröffentlichten Postings eingelesen und die IDs der neuen, zur Veröffentlichung vorgesehenen Postings mit dieser Liste abgeglichen. Wurde das Posting bereits veröffentlicht, oder enthält die Einreichung keine Message-ID, wird die entsprechende Datei nicht kopiert und eine Fehlermeldung ausgegeben; ansonsten wird die Message-ID auf STDOUT ausgegeben. Die veröffentlichungsfähigen Beiträge im Datenverzeichnis können jetzt mit einem Texteditor eingesehen und ggf. nachbearbeitet werden.

Die Dateien, die nicht ins Datenverzeichnis kopiert wurden, können im Falle von Duplikaten einfach im IMAP-Folder verbleiben; sie sollen ja nicht noch einmal veröffentlicht werden. Fehlt ihnen eine Message-ID oder bestehen andere Probleme, kann auch die Datei im IMAP-Folder entsprechend bearbeitet und bspw. die Message-ID herausgesucht und ergänzt werden. Ist das zuviel Aufwand, kann die Datei ebenfalls schlicht dort verbleiben; sie wird dann eben später nicht veröffentlicht.

Wenn nach dem ersten Durchlauf des Konvertierungsscripts Änderungen am Inhalt des IMAP-Folders vorgenommen wurden, kann man es einfach noch einmal starten; es kopiert dann wieder alle veröffentlichungsfähigen Beiträge in das Datenverzeichnis, möglicherweise diesmal auch die nachbearbeiteten.

Zur Bearbeitung gehört:

Das Verwerfen aller Mail-Header außer dem Absender (“From:” und ggf. “Reply-To:”), der den Einreicher wiedergibt.
Das Erstellen eines Betreffs (“Subject:”) aus dem Betreff des eingereichten Postings und der in eckigen Klammern vorweggestellten Newsgroup, aus der die Einreichung stammt, samt korrekter Kodierung (MIME encoded words).
Das Konvertieren des Inhalts (Body) des eingereichten Postings nach UTF-8 ohne quoted-printable-Kodierung.
Das Entfernen von Leerzeilen am Ende des eingereichten Postings.
Das Herausschreiben eines veröffentlichungsfähigen Postings, das so 1:1 eingespeist werden kann.

Das Konvertierungsscript kann auch statt aller nur eine bestimmte Mail aus dem IMAP-Folder lesen oder - statt die Mails aus dem IMAP-Folder zu lesen - die bereits ins Datenverzeichnis kopierten Beiträge neu einlesen und nochmal konvertieren; das macht zum Beispiel Sinn, wenn nach dem ersten Durchlauf noch Änderungen vorgenommen wurden (oder im Script nachgebessert werden musste ). Außerdem kann die Prüfung auf Duplikate unterdrückt werden, und es kann auch nur die Message-IDs der veröffentlichungsfähigen Beiträge ausgeben, ohne sie zu (kopieren und zu) konvertieren.

Sind die Beiträge im Datenverzeichnis veröffentlichungsreif, kann man sie in die Warteschlange - ein anderes Datenverzeichnis - verschieben. Sinnigerweise sollten dann die Message-IDs der nun zur Veröffentlichung bereitstehenden Beiträge in die Liste für den Duplikatcheck aufgenommen werden.

Veröffentlichung

Die Veröffentlichung ist vergleichsweise einfach - vor allem deshalb, weil ich dafür keinen eigenen Code geschrieben habe, sondern schlicht das Allzweckwerkzeug tinews.pl verwende, das sich auch um das Anhängen der Signatur und die GPG-Headersignatur kümmert.

Das Postingscript post.pl kann daher auch nur zwei Dinge:

Eine zufällig ausgewählte Datei aus der Warteschlange (oder eine als Parameter übergebene bestimmte Datei) vermittels tinews.pl posten.
Optional vorher Datum und Message-ID neu setzen (denn die wurden ja ursprünglich bei der Konvertierung neu erzeugt, die zu diesem Zeitpunkt Tage, im Extremfall auch Wochen zurückliegen kann).

Workflow

Aus diesen Bausteinen entsteht folgender Workflow:

Auswählen der zur Veröffentlichung vorgesehenen Einreichungen im Posteingang und Verschieben in den Auswahl-IMAP-Ordner.
Starten von convert.pl.
Ggf. Nachbearbeiten fehlerhafter Einreichungen (im IMAP-Folder) und erneuter Konvertierungslauf, bis alle Beiträge ohne Fehlermeldung kopiert werden bzw. Fehlermeldungen nur noch Duplikate betreffen.
Durchsicht aller Postings im Datenverzeichnis im Texteditor (vim auf der Shell, alternativ auch Sublime Edit oder ein anderes Tool via SCP): Stimmen Umlaute und Sonderzeichen, passt der Zeilenumbruch, sieht alles richtig aus? Wurde der Betreff richtig erzeugt?
Verschieben aller Beiträge in die Warteschlange, speichern der Message-IDs für den Duplikatcheck.

Für den letzten Schritt verwende ich ein simples Shellscript:

#!/bin/bash
~/bin/convert.pl -rm >> ~/data/mid-2021.txt
mv ~/data/auswahl/* ~/data/fertig/
mv ~/mail/.INBOX.auswahl/cur/* ~/mail/.INBOX.fertig/cur/

Der erste Befehl gibt alle Message-IDs der in den veröffentlichungsfähigen Beiträgen enthaltenen Postings aus, ohne sonst irgendeine Konvertierung vorzunehmen; diese werden an die Datei für das laufende Jahr angehängt. Die zweite Zeile verschiebt die Beiträge aus dem Auswahl-Datenverzeichnis in die Warteschlange. Die dritte Zeile kopiert die Mails aus dem IMAP-Folder “auswahl” in einen anderen für die erledigten Beiträge.

Die eigentliche Veröffentlichung erfolgt dann mehrmals täglich über einen Cronjob, der das Postingscript aufruft; solange die Warteschlamge immer nachgefüllt wird, bedarf die eigentliche Veröffentlichung dann keiner Interaktion mehr. Ist die Warteschlange zu voll, können aber natürlich auch durch einen manuellen Aufruf des Postingscripts zusätzliche Beiträge veröffentlicht werden.

[Nachträglich veröffentlicht im Oktober 2021.]

Moderation von de.alt.netdigest

nospam@example.com (Thomas Hochstein) — Thu, 01 Jul 2021 18:50:00 +0000

de.alt.netdigest ist eine Usenet-Newsgroup in der Hierarchie de.*, in der vor allem lustige, manchmal aber auch bemerkenswerte Beiträge aus den deutschsprachigen Netzen (primär den Newsgroups des deutschsprachigen Usenets, grundsätzlich aber auch aus Mailinglisten, Webforen oder dem IRC) gesammelt und veröffentlicht werden, quasi ein “Best of (Uset)net” - oder in den Worten der Kurzbeschreibung: Aktueller und klassischer Humor aus allen Netzen und IRC.

Die Newsgroup ist moderiert, d.h. Beiträge können dort nicht unmittelbar veröffentlicht werden, sondern müssen per Mail an die Moderationsadresse versandt werden (oder sie können auch in die Gruppe gepostet werden - daraus wird dann automatisch eine Mail an die Moderationsadresse erzeugt). Die Moderation trifft ggf. eine Auswahl unter den Einsendungen und sorgt ansonsten dafür, dass keine Dubletten vorkommen und die Veröffentlichungen ein einheitliches Format haben - die wesentlichen Kopfzeilen des eingereichten Postings und der (ggf. gekürzte oder kommentierte) Inhalt. In den mehr als 25 Jahren ihres Bestehens hat die Newsgroup normalerweise wie ein Uhrwerk funktioniert, mal mit regelmäßigeren Einreichungen, mal weniger regelmäßig - aber letztes Jahr war zum ersten Mal eine längere Pause. Die anschließende Diskussion führte zu dem Ergebnis, dass der (verbliebene) Moderator sich nach mehr als einem Jahrzehnt gerne zur Ruhe setzen würde; ein richtiges Ergebnis folgte aber nicht. Im Januar 2021 versiegte die Quelle dann wiederum, und diesmal habe ich mich dann im Juni bereiterklärt, ab heute die Newsgroup zu moderieren.

In den letzten zwei Wochen sind mehr als 110 Beiträge erschienen, womit ein Teil des “Rückstaus” abgebaut wurde; den restlichen Vorrat habe ich übernommen, bin also für die nächsten Tage und Wochen erst einmal mit Beiträgen versorgt.

Als erste “Amtshandlung” habe ich die bis zum Jahre 2015 regelmäßig veröffentlichte FAQ der Gruppe, die ihren Sinn und Zweck und die Vorgehensweise für Einreichungen beschreibt, wieder zum Leben erweckt und auf meine Webseiten gestellt; sie wird ab jetzt auch wieder monatlich in der Newsgroup veröffentlicht.

Ich hoffe, dass auch zukünftig weiter regelmäßig Einreichungen eintrudeln, damit die Gruppe auch in der kommenden Zeit eine abwechslungsreiche (und vor allem lustige!) Lektüre bleibt.

[Nachträglich veröffentlicht im Oktober 2021.]

"Mach's Dir doch selbst!"

nospam@example.com (Thomas Hochstein) — Wed, 14 Apr 2021 18:25:00 +0000

Ich bin seit vielen, vielen Jahren Mitglied bei bawue.net, Baden-Württembergs nichtkommerziellem Internet-Provider, einer ehemaligen Regionaldomain des ehemaligen Individual Network e.V. - also Nutzer, quasi “Kunde”, wie auch Vereinsmitglied, und all das primär, weil ich diese Vereine für gut und förderungswürdig halte. Ich glaube nicht, dass ich in all den Jahren einmal wirklich Dienste genutzt hätte …

Seit ebenfalls sehr vielen Jahren bin ich dort auch Mitglied im Admin-Team, allerdings mehr auf dem (elektronischen) Papier als faktisch, weil mir meine vielzähligen Hobbys und Aktivitäten meist keine Zeit lassen, mich dort stärker einzubringen, und wenn man in der Thematik nicht “drin” ist, dann sind auch Kleinigkeiten aufwendig.

So weit, so gut - dies zur Vorgeschichte. Ende Februar ging es auf Twitter ums Usenet und die immer weniger werdenden Server, und in diesem Zusammenhang auch um Peerings mit news.bawue.net. Dieser Tage stolperte ich nochmals über den Tweet und nahm das zum Anlass, um ein Peering mit news.szaf.org zu bitten: neue Webseiten verdienen doch sicherlich auch ein neues Peering.

Ich melde mich.
— Szlauszaf ⚫ (@Szlauszaf) April 1, 2021

Als Antwort bekam ich nur, ich könne mir den Feed ja selbst anlegen … Admin-Team, wissen schon. Es stellte sich allerdings heraus, dass mir auf der entsprechenden Maschine die Rechte fehlten. Dennoch nahm die Sache ihren nun schon zu vermutenden Gang …

Einen Tag später hatte ich mir nicht nur meinen Feed eingerichtet, sondern auch die Config mal durchgeschaut, einen Stapel tote Peers entsorgt und das Backlog weggeräumt, einige andere Peers angeschrieben … und, naja, seitdem bin ich einer der Newsmaster von news.bawue.net. (So war das eigentlich nicht geplant, aber wenn man es selbst macht, geht es oft tatsächlich am besten.)

Titelbild © magele-picture - stock.adobe.com

[Nachträglich veröffentlicht im September 2021]

Relaunch der Webseiten von news.szaf.org

nospam@example.com (Thomas Hochstein) — Tue, 30 Mar 2021 19:00:00 +0000

Seit 2005 betreibe ich einen “richtigen” Newsserver, also einen solchen, der die großen (und ein paar kleine) Hierarchien mit dem Rest der Welt peered und auch für andere Nutzer aus meinem Umkreis zur Verfügung steht: news.szaf.org.

Die zugehörigen Webseiten allerdings, die fast so alt waren, hätten schon lange ein Update vertragen können - weniger inhaltlich als vielmehr optisch und funktionell. Lange stand das auf meiner Todo-Liste, erwies sich dann aber doch als eher größeres Projekt; die Hintergründe habe ich in meinem vorherigen Blogbeitrag beschrieben. Mittlerweile ist das dort beschriebene Projekt veröffentlichungsreif. Ich präsentiere daher die neuen Webseiten für news.szaf.org.

Die aktuellen Webseiten von news.szaf.org.

Ich finde, es ist mir dabei gut gelungen, das bisherige Farbschema und generelle “look and feel” der Seite beizubehalten, aber in eine ansehnliche(re) Form zu transformieren - zum Vergleich die Fassung von 2006:

news.szaf.org früher (seit 2006).

Und natürlich erkennt man die Design-Elemente von Bootstrap; aber zumindest für mich sieht es mehr nach einem optischen Update der bisherigen Seiten als “yet another Bootstrap site” aus.

Auch die Login-Seite ist auf der einen Seite absoluter Standard, wirkt aber andererseits (wie ich finde) trotzdem optisch hübsch:

Loginseite.

Mir jedenfalls gefällt sie sehr.

So hat sich der investierte Aufwand bisher gelohnt.

[Nachträglich veröffentlicht im August 2021.]

"Sprechende" Message-IDs erzeugen mit dem INN

nospam@example.com (Thomas Hochstein) — Wed, 15 Apr 2020 06:00:00 +0000

Ich fürchte, das hier wird ein eher technisch geprägter Special-Interest-Beitrag werden, aber sei es drum: es soll darum gehen, mit Hilfe des Newsservers INN Message-IDs für Usenet-Postings zu erzeugen, die neben ihrem primären Daseinszweck - ein Posting mit einer dauerhaft und global eindeutigen ID zu versehen - auch einen menschenlesbaren Inhalt haben.

Message-IDs, ihr Aufbau und ihre Funktion

Der Message-ID-Header verleiht jedem Beitrag im Usenet (jedem Posting) und jeder E-Mail eine absolut eindeutige, nur einmal vergebene Kennung, mit der das Posting oder die E-Mail referenziert werden können.

Funktion

Die Notwendigkeit dafür ist einmal technischer Art; so können Postings und E-Mails bspw. in Logdateien eindeutig bezeichnet werden. Auch ist die Message-ID für das Threading - also die Darstellung von Postings oder E-Mails in einem “Diskussionsfaden” erforderlich; denn dazu enthält jede E-Mail die Message-ID ihres Vorgängers, also die Kennung der Nachricht, auf die sie die Antwort enthält. Bei Postings ist das ähnlich; nur werden dort die Message-IDs aller (oder bei langen Threads zumindest etlicher) Vorgänger übermittelt. So können Newsreader und Mailprogramme Bezugsverkettungen aufbauen und E-Mails (oder Postings) im Zusammenhang darstellen, ohne sich dabei auf Zufälle wie einen identischen Betreff verlassen zu müssen.

Im Usenet hat die Message-ID noch eine weitere wichtige Bedeutung: Postings werden im Gegensatz zu E-Mails nicht nur an einen oder mehrere bestimmte Empfänger übermittelt, sondern im “Floodfill”-Verfahren an alle miteinander vernetzten Newsserver verteilt. Diese Newsserver sind aber regelmäßig nicht nur einfach, sondern vielfach miteinander vernetzt und erhalten daher jeden Beitrag mehr- oder vielfach auf verschiedenen Wegen. Um Übertragungskapazität zu sparen (und Duplikate zu vermeiden) lehnen sie daher die Annahme von Beiträgen, die sie schon kennen, ab und speichern diese auch nicht, falls sie doch übertragen werden. Daraus folgt, dass ein Posting, dass eine bereits einmal verwendete Message-ID enthält, nicht verteilt wird; und schlimmer noch, dass eine Änderung der Message-ID zur mehrfachen Verteilung und Speicherung von Postings, also zu unerwünschten Duplikaten führt. Deshalb sollte man an der Message-ID von Postings, die nicht lokal erzeugt wurden, auch niemals herumfummeln und generell genau wissen, was man tut, wenn man die Message-ID manipuliert.

Unabhängig von diesen technischen Aufgaben ist die Message-ID auch der geeignetste Weg, im Usenet auf einen bestimmten anderen Beitrag zu verweisen. “Schau mal in das Posting von Hans Meier von gestern, 17.32 Uhr, da steht die Antwort auf Deine Frage” ist so aufwendig - für Schreiber und Leser - wie unprofessionell. “Schau Dir mal <d648ee74-9def-e5ca-8c12-9a347fce0dc5@host.example> an, da steht alles drin” ist hingegen schnell geschrieben (es genügt ein Kopieren der Message-ID) und ebenso schnell aufrufbar, weil Newsreader in der Regel den Aufruf von Postings anhand der Message-ID ermöglichen.

Aufbau einer Messsage-ID

Vom Aufbau her ähnelt eine Message-ID sehr einer E-Mail-Adresse: sie hat einen linken und einen rechten Teil, die durch ein @-Symbol miteinander verknüpft sind und wird von spitzen Klammern (<>) eingerahmt. Weil das sehr dem Konzept einer lokalen Adresse und einer Domain ähnelt, wird die Anforderung, dass Message-IDs global eindeutig sein müssen, am besten so umgesetzt, dass das die ID erzeugende System auf der rechten Seite seinen (weltweit eindeutigen) Hostnamen einsetzt und auf der linken Seite eine Zeichenfolge verwendet, die systemweit eindeutig ist, in der Regel also aus einem Timestamp, ggf. einer Prozess-ID oder einem Zähler besteht. Das Format wäre also <unique@hostname>.

Das funktioniert prima, solange das System einen (eindeutigen) Hostnamen hat; für den typischen (Windows-)Heimrechner ist das allerdings nicht der Fall. Dann kann man die Erzeugung der ID entweder dem Newsserver überlassen, der ja in der Regel im Netz erreichbar sein muss und daher über eine IP-Adresse und einen auch als FQDN bezeichneten domainisierten Hostnamen (news1.provider.example) verfügt. Alternativ kann man dem Newsreader einen Hostnamen (FQDN) vorgeben; das muss nicht zwingend der tatsächliche Hostname des Rechners sein, es genügt auch ein Name, der garantiert nicht anderweitig vergeben werden kann, wie ihn bspw. das Projekt My FQDN zur Verfügung stellt. Schließlich kann man, wenn alle Stricke reißen und man die Message-ID unbedingt selbst generieren will, auf die Mailadresse des Autors abstellen, für die Adresse localpart@domain dann etwa so: <unique.localpart@domain>.

Beispiele für Message-IDs

In der Praxis sieht bspw. eine durch den Newsserver INN erzeugte Message-ID so aus:

<r6d9hs$4cu$1@thangorodrim.ancalagon.de>

Auf der rechten Seite steht der Hostname des Newsservers (hier thangorodrim.ancalagon.de), auf der linken Seite finden sich (nacheinander und getrennt durch $) ein Timestamp (hier r6d9hs), die Prozess-ID des Serverprozeses (hier 4cu) und - für den Fall, dass in derselben Sekunde vom selben Prozess mehrere Beiträge entgegengenommen werden - ein Zähler (hier 1). Timestamp und Prozess-ID werden dabei in einem Zahlensystem auf der Basis 32 kodiert; dezimal lautet der Timestamp also 912696892 und die Prozess-ID 4510. Und tatsächlich: wie das Logfile des Newsservers zeigt, wurde der Beitrag von dem Prozess Nummer 4510 angenommen:

thangorodrim nnrpd[4510]: thangorodrim.ancalagon.de (127.0.0.1) connect - port 119

Beim Timestamp muss man nun noch wissen, dass der INN vom tatsächlichen Unix-Timestamp (also der Anzahl der Sekunden seit der Epoche, d.h. seit 01.01.1970 00:00:00) wahllos 673416000 abzieht, um eine kürzere Message-ID zu erhalten. Zählt man also zu dem Timestamp von 912696892 noch 673416000 hinzu, erhält man 1586112892 - und das ist umgerechnet der 05.04.2020, 18:54:52 Uhr: passt!

Der Newsreader slrn arbeitet ähnlich:

<slrn94p19c.ns.thomas@thangorodrim.ancalagon.de>

Die Message-ID besteht aus dem Namen des Newsreaders (slrn), einem verkürzten Zeitstempel im 32er-Zahlensystem (94p19c), der Prozess-ID (ns) und der Mailadresse des Nutzers (bzw. seinem Usernamen und dem Hostnamen).

Vorteile einer selbst erzeugten Message-ID

Am einfachsten wäre es natürlich, die Erzeugung von Message-IDs dem Newsserver zu überlassen; andererseits hat die Erzeugung eigener Message-IDs durchaus Vorteile. Manche Newsreader benötigen das schon deshalb, weil sie eigene Postings auch ablegen und speichern wollen. Ganz allgemein hat eine selbst erzeugte Message-ID aber den Vorteil, dass man (nur) an ihr sehr einfach eigene Beiträge erkennen kann, auch dann, wenn man vielleicht wechselnde E-Mail-Adressen verwendet, und dass man nur so auch Antworten auf eigene Beiträge erkennt (weil diese eine Message-ID mit dem eigenen FQDN im References-Header tragen). So kann ein geeigneter Newsreader bspw. Antworten auf eigene Postings hervorheben, oder man kann sich mit einem Tool wie fupcheck per Mail über Antworten benachrichtigen lassen.

“Sprechende” Message-IDs

Noch schöner finde ich es persönlich, wenn die Message-ID meiner Postings nicht nur global eindeutig ist, sondern auch für den menschlichen Leser verwertbare Informationen enthält. So ist es ja theoretisch nett, dass ich aus der Message-ID <r6d9hs$4cu$1@thangorodrim.ancalagon.de> herauslesen kann, dass es sich um ein Posting vom Abend des 05.04.2020 handelt - aber natürlich wird kaum je ein Mensch r6d9hs in eine Dezimalzahl umwandeln, 673416000 hinzuzählen und das Ergebnis dann von einem UNIX-Timestamp in ein Datum konvertieren. Viel praktischer wäre es doch, wenn man einer Message-ID direkt ansehen könnte, von wann sie ist, und am besten vielleicht auch von wo, d.h. aus welcher Newsgroup. Dann muss man sich nicht wundern, wenn mal wieder jemand erst nach Monaten oder Jahren auf einen alten Beitrag antwortet, und man kann auch an einer zitierten Message-ID ungefähr ablesen, wo sie herkommt.

Ich erzeuge daher seit vielen, vielen Jahren unter Hinzunahme meines Hamsters “sprechende” Message-IDs, die aus den Initialen der (ersten) Newsgroup, in der der Beitrag erschienen ist, einem lesbaren Zeitstempel und einem Zähler bestehen. Der Beitrag mit der Message-ID

<dcsn.1908202159.235@meneldor.ancalagon.de>

ist mithin am 20.08.2019 um 21.59 Uhr von meinem Laptop meneldor aus in der Newsgroup d.c.s.n erschienen; letzteres kann man mit etwas Erfahrung als de.comm.software.newsreader (oder auch de.comm.software.newsserver - natürlich sind Initialen nicht eindeutig!) übersetzen. Außerdem handelte es sich um den 235. Beitrag im Jahr 2019; das ermöglicht mir zudem durch einen schlichten Blick in die Datei, in der der Zähler gespeichert wird, die Gesamtzahl meiner Beiträge im jeweiligen Jahr zu erfassen.

Klar, das ist eine Spielerei, aber eine für mich hilfreiche - und liebgewonnene - Spielerei.

“Sprechende” Message-IDs mit dem INN erzeugen

Nun habe ich in letzter Zeit öfters mal von verschiedenen Rechnern aus mit verschiedenen Newsreadern (nicht nur zu Testzwecken) auf meinem “hauseigenen” INN gepostet. Und da hätte ich dann gerne - auch ohne Hamster - meine sprechenden Message-IDs, die der INN für mich setzen müsste.

Der richtige Ansatzpunkt für solche Manipulationen ist der Filter filter_nnrpd.pl (bei Debian in /etc/news/filter/), der nur auf dem Server über den NNRP-Daemon (nnrpd) gepostete Beiträge bearbeitet, nicht aber etwa ein- und durchgeleitete Beiträge wie der filter_innd.pl - denn an Message-IDs schon geposteter Beiträge herumzufummeln ist ein absolutes No-Go!

Insbesondere wenn man den Server nicht alleine nutzt, möchte man die Veränderungen an der Message-ID auf eigene Postings beschränken; das kann man zum Beispiel durch einen Filter auf den Domain-Part (also die rechte Seite der Message-ID) lösen oder indem man nur Postings bearbeitet, die einen entsprechenden Zusatzheader (wie bspw. X-Fix-MID: yes) gesetzt haben.

Im filter_nnrpd.pl gibt es die Funktion filter_post; dort sind wir richtig. Am Anfang sollte man auf jeden Fall den Rückgabewert der Funktion auf einen leeren String setzen, denn ansonsten werden Postings mit einer Fehlermeldung abgewiesen. Außerdem muss man das Verändern von Headern freischalten:

my $rval = ""; # assume we'll accept.
$modify_headers = 1;
# [...]
return $rval;

So weit, so gut. An der mit “[…]” markierten Stelle prüfen wir jetzt, ob das Posting modifiziert werden soll oder nicht; wenn ja, rufen wir eine - noch zu schreibende - Funktion dafür auf:

# Fix Message-ID
if (exists($hdr{'X-Fix-MID'})) {
    # remove trigger header
    delete $hdr{'X-Fix-MID'};
    # fix MID
    $hdr{'Message-ID'} = fix_mid($hdr{'Newsgroups'}, $hdr{'Message-ID'});
}

Ist die Headerzeile X-Fix-MID auf irgendeinen Wert gesetzt, entfernen wir sie und setzen dann die Message-ID auf den Rückgabewert der Funktion fix_mid. Und die sieht wie folgt aus:

#
# Message-ID
#
sub fix_mid($$) {
    my ($newsgroups, $mid) = @_;
    my ($fqdn, $element, $initial)= '';
    # get FQDN
    if (defined($mid) && $mid ne '') {
       ($fqdn) = $mid =~ /<.+\@(.+)>$/;
    } else {
       $fqdn = $inn::fromhost;
    }
    # get timestamp
    my $datetime = strftime("%Y%m%d%H%M%S",localtime());
    # get initials of first newsgroup
    my($newsgroup,undef) = split /,/, $newsgroups;
    my @newsgroup = split /\./, $newsgroup;
    foreach $element (@newsgroup) {
       $initial .= substr($element,0,1);
    };
    # get, increment and save counter
    open CTR, '+</var/lib/news/mid-counter';
    flock(CTR, 2);
    my $counter = <CTR>;
    $counter++;
    seek(CTR,0,0);
    print CTR $counter;
    close CTR;
    # return Message-ID
    return sprintf('<%s.%s.%s@%s>', $initial, $datetime, $counter, $fqdn);
}

Wir übernehmen also den Domain-Part der bestehenden Message-ID; nur wenn es bisher keine Message-ID gibt, nehmen wir den Hostnamen des Newsservers. Dann generieren wir den Zeitstempel, die Initialen der (ersten) Newsgroup und laden und schreiben den Zähler; letzteres ist natürlich mit Plattenzugriffen verbunden. Am Schluss werden die Einzelteile zu einer Message-ID zusammengesetzt.

Voila!

Nachtrag vom 10.01.2021: Die meisten Newsreader nutzen natürlich mehrere parallele Threads zum Lesen und Posten. Das geht dann schief, wenn deshalb verschiedene nnrpd-Prozesse gleichzeitig auf die Datei /var/lib/news/mid-counter zugreifen. Daher bedarf es eines exklusiven Locks auf die Datei, schon beim Lesen, damit nicht mehrere Prozesse denselben Zahlenwert erhalten; und weil beim Schließen eines Dateihandles auch die Locks aufgegeben werden, muss die Datei zum Lesen und Schreiben geöffnet werden. Und wenn man das wiederum tut, muss man nach dem Lesen zurück an den Anfang der Datei springen, um den alten Inhalt mit der neuen Zahl zu überschreiben. Den Beispielcode oben habe ich entsprechend angepasst.

(Und wenn man das testen will, sollte man bedenken, dass filter_nnrpd.pl immer dann, aber auch nur dann neu geladen wird, wenn ein neuer nnrpd-Prozess startet - dementsprechend also nicht, wenn der Newsreader die Verbindung erst einmal offen hält und weitere Testposts dann über die noch bestehende Verbindung abgesetzt werden.)

Übernahme der Newsreader-FAQ

nospam@example.com (Thomas Hochstein) — Wed, 11 Mar 2020 06:50:00 +0000

Ich betreue mittlerweile eine ganze Reihe an regelmäßig ins Usenet geposteten FAQs, an denen sich allerdings meistens nicht mehr viel ändert; die letzten größeren Updates gab es vor fast zwei Jahren, Mitte 2018. Vor gut zwei Jahren hatte ich auch das letzte Mal neue FAQs übernommen, weil die ursprünglichen Autoren oder Betreuer sie nicht mehr pflegen konnten oder wollten bzw. nicht mehr erreichbar waren oder nicht mehr am Usenet teilnahmen.

Zum Jahreswechsel wurde ich dann auch gefragt, ob ich nicht die sog. Newsreader-FAQ übernehmen wolle, die Michael Meier einmal anno 2000 ins Leben gerufen hatte; bis Ende 2003 wurde sie von Christoph Garbers betreut und seitdem bis jetzt von Thomas Hühn, der aber ebenfalls das Usenet (weitgehend?) verlassen hat und daher vorschlug, ich könne ja vielleicht … Und freilich, ich kann - wenn es mir auch natürlich lieber wäre, wenn das Usenet mit allem Drumherum weniger zentralisiert wäre. Aber lieber ein SPOF für sehr viele FAQs als dass diese schon jetzt nicht mehr weitergepflegt werden können.

Ich habe die Betreuung des Textes also übernommen und bin ihn einmal grob durchgegangen, vor allem im Hinblick auf tote Links und eine Anpassung der Formatierung, die mir mehr entsprach. Das hat zunächst einmal wenig an den Inhalten geändert, aber da halte ich es weiterhin mit dem bisherigen Geist der FAQ: zu den jeweiligen Newsreadern soll sich bitte jemand äußern, der sie kennt. Ich betreue die FAQ, ich schreibe sie nicht allein, und ganz sicher teste ich nicht haufenweise Newsreader.

FAQ-Updates

nospam@example.com (Thomas Hochstein) — Fri, 27 Jul 2018 21:40:00 +0000

Heute standen wieder einmal Updates vieler - fast aller - meiner ins Usenet geposteten FAQs an. Die Löschung einer Newsgroup war der konkrete Anlass für einige Änderungen, und es lohnte sich dann, auch bei den anderen FAQs die in den letzten Monaten - teilweise in mehreren Jahren - akkumulierten Änderungen einmal in die gepostete Fassung zu übernehmen. Der Release-Prozess für meine FAQs ist dankenswerterweise ja mittlerweile recht einfach. Folgende FAQs wurden aktualisiert:

die Erläuterungen zur Einrichtung neuer Gruppen in de.* (dana-Manual),
Wichtige Begriffe in de.admin.news.* (dan-Glossar),
Wie kann ich das Usenet aktiv mitgestalten?,
Die Newsgruppen der de-Hierarchie und
die Einführung in die Rechtsgruppen des deutschsprachigen Usenets.

Auch die älteren Texte

Informationstexte-Verzeichnis für Usenet-Einsteiger,
Häufig gestellte Fragen in der Gruppe de.newusers.questions (dnq-FAQ) und
Welche Gruppe wofür?

wurden zumindest ein wenig aktualisiert.

[Dieser Eintrag wurde nachträglich im August 2018 veröffentlicht.]

FAQ-Updates

nospam@example.com (Thomas Hochstein) — Fri, 26 Jan 2018 07:30:00 +0000

Im Januar 2018 habe ich die Betreuung dreier weiterer FAQs übernommen und zwei FAQs (davon eine der neu übernommenen) auf meinen Webseiten in HTML-Form online gestellt:

Informationen über de.alt.test.moderated ist die Einführung zu der moderierten Testgruppe de.alt.test.moderated, die ich seit 2010 betreue und nunmehr in Markdown überführt habe, so dass ergänzend zur reinen Textfassung auch eine HTML-Fassung abfällt.
Von Boris ‘pi’ Piwinger habe ich mit seinem Einverständnis die Pflege der Einführung in die Rechtsgruppen des deutschsprachigen Usenets übernommen. Der Text wird jetzt wieder regelmäßig gepostet und steht auch online; pi’s Webseiten leiten auf den neuen Ablageort des Textes weiter.
Der bisherige Maintainer des Textes “Die Newsgruppen der de-Hierarchie” war nicht mehr erreichbar. Ich habe daher diesen Text in Absprache mit dem Moderator von de.newusers.infos ebenso übernommen (und aktualisiert) wie das “Informationstexte-Verzeichnis für Usenet-Einsteiger”.

Für diese Texte gilt - wie für alle anderen -: “Betreuung” einer FAQ muss und soll nicht gleichbedeutend sein mit “einziger Autor”. Ergänzungen, Korrekturen, Kommentare nehme ich gerne entgegen.

Der Injection-Date:-Header

nospam@example.com (Thomas Hochstein) — Fri, 06 Oct 2017 06:05:00 +0000

Das Usenet ist zunehmend in die Bedeutungslosigkeit zurückgefallen - ironischerweise sind die zugrundeliegenden Formate und Protokolle heutzutage aber klarer spezifiziert als das zu seinen Hochzeiten der Fall war. NNTP, das Übermittlungsprotokoll mit der größten Verbreitung, war recht gut definiert, erst in RFC 977 von 1986 und dann zwanzig Jahre später in RFC 3977; außerdem kann man den INN wohl als eine Referenzimplementation betrachten.

Mit dem Nachrichtenformat war es da schon schwieriger: Auf RFC 850 von 1983 folgte RFC 1036 von 1987, der während der Blütezeit des Usenets niemals aktualisiert wurde, obschon es bereits 1993 einen Entwurf für einen Nachfolger gab, den sog. “Son-of-1036” (der erst 2010 als historisches Dokument in Form von RFC 1849 veröffentlicht wurde). Der De-Facto-Standard war dann letztlich “Son-of-1036” mit weitgehend ungeschriebenen Modifikationen aus der Implementierungspraxis, während die USEFOR working group der IETF sich unendlich lange vergeblich mit der Erstellung einer Spezifikation abmühte. Als Ende 2009 dann endlich RFC 5536 “Netnews Article Format” veröffentlicht wurde (der zusammen mit RFC 5537 “Netnews Architecture and Protocols” ein umfassendes Kompendium zur Implementation von Newsservern, -readern und allen möglichen anderen Tools rund um das Usenet bzw. Netnews darstellt), waren die großen Zeiten des Usenets bereits Vergangenheit.

Implementation von RFC 5536

Es dauerte dementsprechend auch seine Zeit, bis die Theorie der RFCs allmählich in die Praxis einzusickern begann. Die ersten Neuerungen fanden sich schon in INN 2.5.0 (von 2009), aber neue Header wie Injection-Info oder Injection-Date wurden erst ab INN 2.5.3 (2012) tatsächlich beachtet und erst ab INN 2.6.0 (2015!) erzeugt.

Damit wurden dann die bisherigen, nie offiziell standardisierten Header NNTP-Posting-Host, NNTP-Posting-Date und X-Trace durch eine klarere Definition des Path-Headers und die neuen Header Injection-Info und Injection-Date ersetzt. Dabei ersetzt Injection-Date das NNTP-Posting-Date (also den Zeitstempel der Einspeisung ins Netz per POST), wohingegen im Header Injection-Info alle Daten über das einspeisende System enthalten sind; dieser Header ersetzt also neben NNTP-Posting-Host vor allem X-Trace.

Wer als Newsserver-Betreiber diese Tracking-Header zu Zwecken der Anonymisierung oder Pseudonymisierung seiner Nutzer bisher entfernt oder modifiziert hat, muss beim Update auf INN 2.6.0 (und damit beim Update auf Debian Stretch) entsprechend aufpassen und nacharbeiten. Dasselbe gilt auch für denjenigen, der Postings aus seinem INN heraus per suck erneut ins Netz einspeist: auch der Header Injection-Info muss vor dem Repost entfernt werden.

Injection-Date als Ersatz für NNTP-Posting-Date?

So weit, so gut - eines sollte man aber dabei nicht aus den Augen verlieren: Injection-Date ist nicht dasselbe wie NNTP-Posting-Date, obschon das eine der Ersatz des anderen sein soll (RFC 5536, 3.2.7):

This header field is intended to replace the currently used but
undocumented "NNTP-Posting-Date" header field, whose use is now
deprecated.

NNTP-Posting-Date wurde nämlich - wenn konfiguriert - immer gesetzt, um den Zeitpunkt der tatsächlichen Einspeisungs ins Netz anzugeben, der durchaus Stunden oder Tage nach der Erstellung des Artikels liegen kann. Injection-Date hat zwar denselben Zweck - um aber zu vermeiden, dass ansonsten identische Artikel mit verschiedenen Injection-Date-Headern verbreitet werden, darf Injection-Date nicht gesetzt werden, wenn der eingelieferte Artikel bereits sowohl einen Date:- als auch einen Message-ID:-Header hat:

                                     If the proto-article had
both a Message-ID header field and a Date header field, an
Injection-Date header field MUST NOT be added, since the proto-
article may have been multiply injected by a posting agent that
predates this standard.  Otherwise, the injecting agent MUST add
an Injection-Date header field containing the current date and
time.

Sinnigerweise findet man das nicht in RFC 5536, sondern in RFC 5537 (3.6, Ziffer 11). Der Hintergrund für diese Regelung ist etwas komplex: Die Verbreitung von Duplikaten bereits vorhandener Artikel wird verhindert, indem jeder Newsserver nur solche Artikel annimmt, deren Message-ID er noch nicht kennt. Um nun diese Liste bekannter Message-IDs (die sog. History) nicht ins Unendliche wachsen zu lassen, speichert jeder Newsserver die ihm bekannte Message-IDs nur für einen begrenzten Zeitraum (bspw. 14 Tage) und nimmt ältere Artikel schlicht nicht an. Für die Bestimmung des Alters eines Artikels soll aber auf den Injection-Date-Header abgestellt werden, nicht auf “Date”; schließlich mag ein Artikel vor seiner Einspeisung länger auf Halde gelegen haben. Wenn nun aber ein Artikel (mit Date und Message-ID) einmal heute und dann nochmals drei Wochen später eingespeist würde und beide Male ein aktuelles Injection-Date bekäme, dann würde ein Newsserver, der seine History nur 14 Tage hält, den zweiten Artikel annehmen (lt. Injection-Date ist er ja ganz frisch) und duplizieren (weil er nicht mehr weiß, dass derselbe Artikel vor drei Wochen schonmal vorbeikam).

Nun ist es alles andere als ungewöhnlich, dass ein einzuspeisender Artikel bereits über Date und Message-ID verfügt; das Datum wird ohnehin regelmäßig gesetzt, und die Message-ID setzten viele (die meisten?) Newsreader auch. Das bedeutet dann aber im Umkehrschluss, dass Injection-Date in sehr vielen Situationen eben kein Ersatz für NNTP-Posting-Date ist.

Mir fiel das auf, als ich mal wieder einen Stapel noch auf meinem Laptop herumliegender Artikel mit ungefähr einer Woche Verspätung gepostet hatte: nach dem Update meines lokalen Newsservers auf Debian Stretch war nicht mehr erkennbar, dass diese Postings verspätet eingespeist worden waren, weil es keinen Injection-Date-Header gab. Die Ursache dieses scheinbaren Fehlers musste ich mir dann erst von Russ Allbery persönlich erklären lassen …

X-NNTP-Posting-Date

Ich habe mir dann kurzerhand einen Ersatz geschaffen und setze nunmehr über den Perl-Filter (filter_nnrpd.pl) einen X-NNTP-Posting-Date-Header:

# Add X-NNTP-Posting-Date header
$hdr{'X-NNTP-Posting-Date'} = strftime("%a, %d %b %Y %H:%M:%S %z", localtime);

votetakers.de - Release 0.13

nospam@example.com (Thomas Hochstein) — Mon, 28 Aug 2017 17:10:00 +0000

Vor rund zweieinhalb Jahren habe ich das letzte Mal über ein Update für votetakers.de berichtet. Diesmal kann ich dann direkt zwei Updates vermelden.

Bei den Releases 0.12 im Januar 2016 und 0.13 im August 2017 wurden einige Fehler behoben (darunter auch Schreibfehler), Whitespace bei verlinkten Message-IDs ausgefiltert und alle URLs auf HTTPS umgestellt. Außerdem sind die Seiten auf einen neuen Server umgezogen und wurden nach UTF-8 konvertiert.

FAQ-Updates

nospam@example.com (Thomas Hochstein) — Thu, 03 Aug 2017 06:05:00 +0000

In den letzten Tagen habe ich mal wieder einige meiner FAQs aktualisiert:

die Erläuterungen zur Einrichtung neuer Gruppen in de.* (dana-Manual),
Wie kann ich das Usenet aktiv mitgestalten? und
Wichtige Begriffe in de.admin.news.* (dan-Glossar)

Dabei habe ich insbesondere Links geprüft und aktualisiert - einmal betraf das die Änderungen an meiner Website nach dem Relaunch im Mai, zum anderen aber sind in den letzten Monaten und Jahren wieder einmal viele Seiten (und ganze Domains) aus dem Netz verschwunden.

Gefühlt geht immer mehr Wissen aus der frühen (und der gar nicht ganz so frühen) Zeit des Netzes in den Neunziger Jahren und nach dem Jahrtausendwechsel verloren …