Netz - Rettung - Recht (Artikel mit Tag perl)

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

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

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);

Fußnoten von MultiMarkDown zu Wordpress konvertieren (und zurück)

nospam@example.com (Thomas Hochstein) — Sun, 28 Sep 2014 10:15:00 +0000

Wir Juristen lieben Fußnoten … oder verwenden sie jedenfalls mit Vorliebe und in großer Zahl und Länge - eine juristische Arbeit ist nur echt, wenn mindestens ein Drittel, besser die Hälfte der jeweiligen Seite oder mehr von einem Fußnotenapparat in Anspruch genommen wird.

Dieses Feeling will man natürlich auch beim Web-Publishing nicht vermissen; hier kommt Wordpress zu Hilfe, gibt es doch verschiedene Plugins für eine Fußnotenverwaltung, von denen mir bisher footnotes am besten gefällt. Man kann seine Fußnoten einfach im Fließtext an der passenden Stelle ergänzen, entweder in eckigen Klammern: ((...)) oder in Tags wie <fn>...</fn> oder ganz anders. Am einfachsten erscheint mir dabei die erstgenannte Möglichkeit, und da das Plugin umfangreiche Anpassungen auch des CSS direkt in der Konfiguration erlaubt, funktioniert das auch recht gut.

Nun schreibe ich meine Blogbeiträge in der Regel in Markdown, und auch das kann Wordpress natürlich verarbeiten. Was liegt also näher, als Blogbeiträge erst in einem Markdown-Editor vorzubereiten und dann am Ende in Wordpress (oder Serenidpity, natürlich) einzufügen? Umso mehr, als auch Scrivener als ein mögliches Ausgabeformat MultiMarkdown kennt?

Das Problem dabei ist allersings, dass Fußnoten zwar in MultiMarkdown (wenn auch nicht in “purem” Markdown) unterstützt werden, das Format da aber anders aussieht; dort ist nämlich an der Stelle, wo das Fußnotenzeichen im Text stehen soll, nicht etwa - wie bei den Wordpress-Plugins - der gesamte Fußnotentext einzufügen, sondern nur ein Platzhalter in der Form [^x], wobei x für eine beliebige Zeichenfolge steht. Die Fußnoten werden dann - wie im Ausgabeformat ja auch - am Ende des Textes in der Form [^x]: ... eingefügt. Das hat zwar den Nachteil, dass man einen Zähler hochzählen muss und Schwierigkeiten bekommt, wenn man eine Fußnoten “zwischendrin” einfügen will, ist aber besser lesbar - und für die Einfügerei hat man ja Tools wie Scrivener, die das bei der Ausgabe automatisch richtig machen.

Nur: wie bekommt man die Fußnoten im MultiMarkdown-Format dann in Wordpress, oder einen Text aus Wordpress wieder in einem verständlichen Format in den Markdown-Editor? Die ersten beiden Male habe ich das von Hand gemacht … Das geht. Aber es dauert. Und dauert. Und spaßig ist auch anders. Und: wozu gibt es Computer?

Also habe ich nach ein paar Versuchen - und einigen Blicken ins Perl-Kochbuch, das passenderweise ausgerechnet ein Dickhorn-Schaf auf dem Cover hat! - ein kurzes Script zusammengehackt, das erst die vergleichsweise einfache Aufgabe der Konvertierung des Wordpress-Formats ins MultiMarkdown-Format übernommen hat und dann um die Konvertierung in umgekehrter Richtung erweitert wurde, die eigentlich auch gar nicht so richtig komplex ist. Das funktioniert unter Linux wie auch - mit Activestate-Perl - unter Windows und tut seinen Zweck, auch wenn man das Problem sicherlich noch eleganter lösen könnte und es an jeder Fehlerbehandlung (und an Dokumentation bisher auch …) fehlt.

Wer auch vor diesem Konvertierungsproblem steht und wen der noch rohe Zustand des Scripts nicht abschreckt, der kann sich gerne im Git-Repository bedienen.

Markdown: HTML aus Text erzeugen

nospam@example.com (Thomas Hochstein) — Sat, 24 May 2014 15:19:00 +0000

Der erste längere (Erläuterungs-)Text, den ich zur Veröffentlichung im Netz verfasst habe, war im September 1998 die Header-FAQ, deren erster Entwurf am 18.09.1998 in der Newsgroup de.admin.net-abuse.mail veröffentlicht wurde und die dann seit dem 15.10.1998 unter dem Titel “E-Mail-Header lesen und verstehen” dort über viele Jahre lang monatlich erschien.

Text- und HTML-Version

Natürlich sollte es zu der monatlich geposteten FAQ auch eine Web-Version geben, die bereits im Oktober entstanden war und deren URL im November 1998 das erste Mal in der FAQ genannt wurde. Und natürlich sollte diese Version auch mit allem Annehmlichkeiten, die HTML für Optik und Funktion bietet, also namentlich Formatierungen und Verlinkungen, ausgestattet sein. Das bedeutete dann umgekehrt aber auch, dass zwei völlig getrennte Versionen desselben Textes zu pflegen waren; insbesondere bei größeren Änderungen und Ergänzung keine wirklich gute Idee. Es musste also eine andere Lösung her: die eine Fassung sollte aus der anderen Fassung generiert werden, oder ggf. beide Fassungen aus demselben Rohtext.

HTML-Dokumente aus Textdokumenten erzeugen

Da mir das Usenet als Publikationsmedium (damals) deutlich näher lag, hatte ich zuerst den Gedanken, die Webseite - also das HTML-Dokument - zumindest im wesentlichen aus dem Textdokument der geposteten FAQ zu erzeugen. Bei entsprechenden Recherchen stieß ich dann auch auf das Tool AscToHTM, das genau diesem Zweck diente und sich auch insbesondere an FAQ-Autoren richtete. Eine Zeit lang habe ich damit auch gearbeitet (und das erzeuge HTML-Dokument dann quasi mit Header und Footer versehen, um es optisch und organisatorisch - Navigation! - in meine damalige Webseitenstruktur einzubinden), aber so wirklich überzeugend war das nicht. Es bedurfte einiger Kompromisse im Layout des geposteten Textes, um die HTML-Generierung überzeugend hinzubekommen, und der Aufwand war doch vergleichsweise groß.

Textdokumente aus HTML-Dokumenten erzeugen

Daher habe ich mich - theoretisch im übrigen völlig richtig - in der Folge davon überzeugen lassen, dass die Vorgehensweise, aus (letztlich) unstrukturiertem Text strukturierten Text (mit Markup) zu erzeugen, bereits gedanklich verfehlt ist und keinen dauerhaften Erfolg haben könne: HTML enthält gegenüber text/plain zusätzlichen Informationsgehalt, Struktur, Markup eben, und aus der Gestaltung des Rohtextes das Markup zu “erraten”, ist keine brauchbare Lösung. Daher bin ich danach dann eben den umgekehrten Weg gegangen und habe beschlossen, dass nunmehr die Webversion der FAQ das “Master-Dokument” (oder die Quelle) sein sollte und ich den geposteten Text daraus erzeuge. Information und optische Gestaltung zu kürzen sollte ja vergleichsweise trivial sein. — Ganz so war es dann erwartungsgemäß doch nicht, denn auch der gepostete “reine” Text sollte ja einigermaßen apart formatiert sein, mit dem was, man an “Formatierungen” in E-Mail und Usenet so gewohnt ist: Zitate eingeleitet mit “|” am Zeilenfang, Hervorhebungen und Betonungen durch *Sternchen* o.ä. und dieser Dinge mehr. Für den Anfang half dazu html2text, damals in C++ geschrieben, mittlerweile durch den verstorbenen Aaron Swartz auch in PYthon reimplementiert, aber ganz zufrieden war ich mit dem Output noch nicht.

Einiges Experimentieren führte dann zu dem folgenden Workflow:

wget http://th-h.de/faq/$1 -O output.html
html2text -nobs -width 70 -rcfile html2text.rc output.html > output.txt
./wrap.pl < output.txt > wrapped.txt

Und wrap.pl, das (daher der Name) vor allem für den Umbruch auf 70 Zeichen pro Zeile unter Beachtung von (nicht zu umbrechenden Zitaten) zuständig war, sah folgendermaßen aus:

#!/usr/bin/perl
use Text::Wrap qw(&wrap $columns);
$columns = 70;
while (<>) {
chomp;
if (/[-\/]$/) {
($zeile, $rest) = /(.+\s)(\S+)$/;
print “$zeile\n”;
JOINLOOP: while (<>) {
$rest .= $_;
last JOINLOOP if (/^$/);
}
$rest =~ s/\n/ /g;
$_ = wrap(”, ”, $rest).”\n”;
};
print $_;
if (/^[|>:]/) {
QUOTELOOP: while (<>) {
chomp;
if (/^$/) {
print “\n”;
last QUOTELOOP;
} elsif (/^[|>:]/) {
print “\n$”;
} else {
print $;
}
};
};
print “\n”;
};

Das ließ sich jetzt durchaus automatisieren; andererseits gefiel es mir nicht wirklich, dass die Quelle des Textes nun ein HTML-Dokument war und ich erst längere Konversionsprozesse laufen lassen musste, um zu überprüfen, ob auch die (aus meiner Sicht immer noch primäre) Textfassung ordentlich aussah. Und HTML schreiben ist auch deutlich aufwendiger als “Klartext”, selbst wenn man sich durch geeignete Editoren beim Einfügen der passenden Tags (und deren Schließen!) unterstützen lässt.

Die Lösung?

Am Ende habe ich, glaube ich, einfach wieder beide Texte getrennt gepflegt oder, wahrscheinlicher, die FAQ (erst einige Zeit nicht mehr richtig aktualisiert und dann) gar nicht mehr gepostet; sowohl das Spam-Problem (jedenfalls der Wunsch, Spam nachzuverfolgen und zu melden) als auch das Usenet waren dabei, in die Bedeutungslosigkeit abzurutschen.

What would I today do?

(Ja, das ist kein Englisch. Nein, das ist Absicht. Ja, das spielt auf WWJD an.)

Inzwischen sind bald 16 Jahre ins Land gegangen, und es gibt damit natürlich ganz andere technische Möglichkeiten, dieses Problem zu lösen. Über manche habe ich zwischendurch nachgedacht, bspw. über Docbook und die zugehörige Toolchain, wenn ich mich recht erinnere, sogar einmal kurz damit gebastelt, aber mich nie ernsthaft damit beschäftigt. Richtig lange, umfangreiche Texte würde ich heute vermutlich in AsciiDoc zu schreiben versuchen. Beides sind Varianten der Technik “mehrere Formate aus einem Quelltext erzeugen”.

Markdown

Insbesondere für kürzere Texte und als generische Lösung bietet sich aber mittlerweile sozusagen ein Königsweg an, der auch entsprechende Verbreitung gefunden hat: Markdown. Die Idee setzt wieder dort an, wo auch ich damals - ganz instinktiv - angefangen hatte, nämlich bei der Erzeugung eines HTML-Dokuments aus einem entsprechend formatierten Textdokument, wobei aber eben durchaus “optische” Formatierungen eingebaut werden, die sich erkennen, parsen und in strukturiertes Markup umsetzen lassen. Wir kennen das - mittlerweile - auch aus Wikis. Das schöne an Markdown ist dabei, dass sich die Formatierungen dem E-Mail- und Usenet-Nutzer zumeist unmittelbar erschließen und die Syntax leicht erlernbar ist, die Texte selbst weitgehend lesbar bleiben und keiner großen Nachbearbeitung mehr bedürfen und auch (insbesondere bei der Verwendung von Erweiterungen wie Markdown Extra oder MultiMarkdown) nahezu alle Formatierungen, die man sich im generierten HTML nur wünschen kann, machbar sind. Wenn man die Möglichkeiten dazunimmt, die modernes CSS bei der optischen Gestaltung von Webseiten bietet, bleiben kaum mehr Wünsche offen.

Ein Beispiel

Für längere oder komplexere Texte wird man sich möglicherweise ergänzende Gedanken machen müssen, aber zumindest kurze Postings lassen sich so ohne großen Aufwand elegant ins Web stellen. So sieht bspw. der gepostete und leicht lesbare Text Willkommen in de.etc.notfallrettung! auch in der Webversion entsprechend aus, und diese Webversion kann jederzeit automatisiert erzeugt werden. Ich plane durchaus, auch meine längeren FAQs - die bisher auch im Web nur als Textversionen abrufbar sind - zukünftig auf diese Weise formatiert verfügbar zu machen, nehme aber an, dass insoweit noch einige Nacharbeiten erforderlich sein werden.

Weitere Vorteile

Insbesondere in Verbindung mit Versionsverwaltungssystemen wie Git zahlt es sich m.E. darüber hinaus aus, wenn der Quelltext möglichst gut lesbar ist und nicht mit Formatierungen oder HTTML-Tags überladen ist; aus einem Markdown-Dokument kann ich überdies bei jeder Änderung automatisch den zu postenden Text und die Webversion ohne zusätzlichen Aufwand aus dem Git-Repository erzeugen, kann mich also auf das Schreiben der Texte konzentrieren, ohne mich mit Routineaufgaben belasten zu müssen. (So jedenfalls die Theorie; ich strebe zukünftig auch eine entsprechende Automatisierung an. )

Noch ein Vorteil ist, dass Markdown (wie auch Wiki-Syntax) vergleichsweise leicht zu erlernen ist und ggf. (wie in Wikis) mit entsprechenden Editoren gekoppelt werden kann, in denen Buttons entsprechendes “Markup” erzeugen. Die Barriere für das Verfassen von Web-Texten wird damit abgesenkt.

Schlusswort

Insgesamt kann ich jedem nur raten: probiert Markdown einmal aus!

Die Texte schreiben sich darin sehr flüssig, und für die meisten CMS und Blogsysteme gibt es entsprechende Plugins. Nicht umsonst setzt bspw. auch Github sehr intensiv auf Markdown.

(Wie ich gerade bemerke, hatte ich darüber übrigens vor vier Jahren schon einmal geschrieben. Manchmal dauert eben alles etwas länger …)

newsstats 0.01 released

nospam@example.com (Thomas Hochstein) — Mon, 02 Sep 2013 11:32:00 +0000

Unter usenet.dex.de stellt Cornell Binder Graphen über die Nutzung der verschiedenen Newsgroup der deutschsprachigen Usenethierachie de.* seit 1992 bereit. Ende 2009 versiegte aber offenbar der Rohdatenstrom, den bis dahin die FU Berlin - wohl über den dort betriebenen Dienst DFNNetNews - angeliefert hatte. Daher bin ich damals kurzfristig in die Bresche gesprungen und habe mit dem von mir betriebenen Newsserver news.szaf.org die Anlieferung der Daten übernommen.

Das dazu begonnene Projekt destat habe ich knapp ein Jahr später unter dem Namen newsstats weitergeführt. Die Entwicklung stagnierte - nach einigen Verbesserungen, namentlich der zuverlässigen Erfassung von Crossposts - allerdings schnell und wurde erst im Mai 2012 (nach einem weitgehenden Rewrite) fortgesetzt. Seitdem (und ab Januar 2012 zurückgehend) veröffentliche ich monatliche Postingstatistiken in der Newsgroup de.admin.news.misc, die aus dem vermittels newsstats erzeugten Datenbestand stammen, und versorge auch usenet.dex.de regelmäßig mit aktuellen Daten.

Erst jetzt, anderthalb Jahre später und rund drei Jahre nach den ersten Ansätzen, komme ich aber dazu, erstmals eine Fassung von newsstats als Version 0.01 zu veröffentlichen. Das Paket steht auf meiner Downloadseite zur Verfügung und kann auch aus dem Git-Repository heruntergeladen werden.

newsstats speichert statistische (Roh-)Daten live aus einem INN-Feed, die dann (monatlich) ausgewertet werden können, und kann daraus Statistiken - bspw. (und derzeit ausschließlich) über die Anzahl von Postings pro Newsgroup - erzeugen. Weitere Statistiken - einspeisende Server, Newsreader, … - soll(t)en (ursprünglich) später einmal hinzukommen.

[Dieser Eintrag wurde nachträglich im Mai 2014 veröffentlicht.]

checkmail 0.5 released

nospam@example.com (Thomas Hochstein) — Sat, 23 Jul 2011 22:32:00 +0000

Nach einem guten Jahr habe ich mal wieder Zeit zu einer kleinen Änderung in checkmail gefunden, die ich dann sogleich als Version 0.5 released habe.

checkmail überprüft die ihm übergebenen E-Mail-Adressen nun zunächst auf syntaktische Richtigkeit (wobei allerdings auf der Domain-Seite keine in eckigen Klammern stehenden IP-Adressen akzeptiert werden), bevor er weitere Tests damit durchführt.

Die Dokumentation wurde entsprechend aktualisiert.

Die aktuelle Version steht jeweils auf meiner Downloadseite zur Verfügung.

yapfaq 0.9.1 (Bugfix-Release)

nospam@example.com (Thomas Hochstein) — Mon, 01 Nov 2010 15:41:00 +0000

Ich habe heute die Version 0.9.1 von yapfaq released, die einen Fehler der bisherigen Version 0.9 behebt:

Im Test-Modus (-t) wurde teilweise fälschlich eine leere Headerzeile "X-Supersedes:" hinzugefügt.

Die aktuelle Version steht jeweils auf meiner Downloadseite zur Verfügung.

yapfaq 0.9 released

nospam@example.com (Thomas Hochstein) — Sun, 15 Aug 2010 16:55:00 +0000

Ich habe heute die bereits seit Juni im Prinzip fertige neue Version 0.9 von yapfaq released, die im Vergleich zur bisherigen Version 0.8.2 nur wenige Änderungen aufweist:

Packaging geändert

Neue Versionen von yapfaq können jetzt einfach durch Kopieren des Tarballs über die vorherige Version installiert werden, ohne die Konfiguration zu überschreiben; Beispiel-Konfigurationsdateien sind entsprechend umbenannt.

Kleine Änderungen an den Headern der erzeugten Postings

Das Standard-Format für die Message-ID hat sich geändert; nunmehr wird das internationale Datumsformat verwendet.

Wenn im Subject:-Header ein Platzhalter für die letzte Änderung der FAQ vorgesehen ist, wird dieser ersatzlos entfernt, falls das Änderungsdatum nicht extrahiert werden kann, bleibt also nicht mehr einfach stehen.

Und schließlich werden Test-Postings jetzt als solche gekennzeichnet, sie enthalten keinen Supersedes:-Header mehr, sondern nur noch eine entschärfte Version, und ihre Message-ID enthält nunmehr zwingend einen Timestamp, um mehrfache Tests - am selben Tag - zu ermöglichen.

Die Dokumentation wurde entsprechend aktualisiert.

Die aktuelle Version steht jeweils auf meiner Downloadseite zur Verfügung.

checkmail 0.4 released

nospam@example.com (Thomas Hochstein) — Sat, 19 Jun 2010 11:58:00 +0000

Nach dem gestrigen Release der praktisch komplett neu geschriebenen Version 0.3 von checkmail kann ich heute die Version 0.4 von checkmail ankündigen, die die eigentlich geplanten Änderungen enthält.

checkmail erkennt temporäre Fehler - bspw. auch beim Greylisting - jetzt als solche, statt diese E-Mail-Adressen als nicht zustellbar zu definieren; außerdem werden in jedem Fall die Antworten des Mailservers standardmäßig ausgegeben.

Überdies kann checkmail jetzt selbst eine tatsächlich zufällige - und damit mit hoher Sicherheit nicht zustellbare - E-Mail-Adresse erzeugen, wenn geprüft werden soll, ob der betreffende Mailserver überhaupt schon im SMTP-Dialog die Zustellbarkeit überprüft (ansonsten sind positive Antworten keine Garantie für die Existenz der geprüften Adresse). Die übrigen Konfigurationsangaben (der zu verwendende Absender und die Angaben für HELO/EHLO) können nun nicht nur im Script definiert, sondern auch auf der Kommandozeile übergeben werden.

Die Dokumentation wurde entsprechend aktualisiert.

Die aktuelle Version steht jeweils auf meiner Downloadseite zur Verfügung.

checkmail 0.3 released

nospam@example.com (Thomas Hochstein) — Fri, 18 Jun 2010 21:23:00 +0000

Nach rund 5 Jahren Pause habe ich nunmehr eine neue Version 0.3 von checkmail released, einem Kommandozeilen-Tool zur Überprüfung der Zustellbarkeit von E-Mail-Adressen.

Im Prinzip wurde das Script komplett neu geschrieben, modularisiert, neu strukturiert und in den Kommentaren vereinheitlicht. Außerdem habe ich die Ausgaben neu gefaßt und ausführlicher gemacht; MXe werden jetzt zuverlässig in der nach dem DNS vorgegebenen Reihenfolge ausprobiert, Multi-Line-Antworten ordnungsgemäß protokolliert und der Exit-Status bei der Batch-Verarbeitung von Adressen sinnvoll gesetzt (womit zugleich eine Veränderung der Bedeutung des Exit-Status verbunden war).

Außerdem wurde die Dokumentation im POD-Format in das Script integriert und ins Englische übersetzt und ein Changelog hinzugefügt.

Die aktuelle Version steht jeweils auf meiner Downloadseite zur Verfügung.

yapfaq 0.8 released

nospam@example.com (Thomas Hochstein) — Thu, 13 May 2010 21:37:00 +0000

Soeben habe ich eine neue Version 0.8.1 von yapfaq released, die im Vergleich zur bisherigen Version 0.7 nur noch vergleichsweise kleine Änderungen aufweist:

PGP-/GPG-Support entfernt

Die Unterstützung für das Signieren von Postings ist ersatzlos entfallen. Es bestehen ausreichende Möglichkeiten, dies extern zu lösen, bspw. über tinews.pl; daher gibt es keinen Anlaß, den dort enthaltenen Code in yapfaq zu duplizieren. Seit der letzten Version ist der Aufruf - bspw. - von tinews.pl direkt aus yapfaq heraus möglich.

Konfiguration

Die in der Konfigurationsdatei yapfaq.cfg mögliche Definition des Schemas für die Erzeugung der Message-ID kann jetzt auch einen Platzhalter für einen Unix-Timestamp enthalten.

Außerdem kann die in der letzten Version hinzugefügte Möglichkeit, zum Posten ein externes Programm zu verwenden, nunmehr auch in der Konfigurationsdatei .yapfaqrc definiert werden, nicht nur über den Kommandozeilenparameter "-s".

Kleinere Änderungen und Fehlerbehebung

In der Konfigurationsdatei yapfaq.cfg wurden optionale Einstellungen als solche gekennzeichnet und auskommentiert, außerdem die Optionen mit einheitlichen Erläuterungen als Kommentar versehen.

Die Dokumentation wurde um bisher fehlende Optionen und die Erläuterung der voranstehenden ergänzt. Außerdem enthält sie jetzt Links zum Git-Repository und zum Bugtracker.

Die aktuelle Version steht jeweils auf meiner Downloadseite zur Verfügung.

Update: Nachdem Version 0.8 nicht lauffähig war, ist dieser Fehler in Version 0.8.1 behoben.

yapfaq 0.7 released

nospam@example.com (Thomas Hochstein) — Thu, 15 Apr 2010 05:00:00 +0000

Gestern habe ich eine neue Version 0.7 von yapfaq released. Im Vergleich zur Version 0.6.2 ergeben sich folgende wesentlichen Änderungen und Neuerungen:

Konfiguration über .rc-Datei

Es sind keine Einstellungen in yapfaq.pl selbst mehr erforderlich; alle Konfigurationsparameter - zu nutzender Newsserver, Benutzername und Paßwort für diesen, etc. pp. - können jetzt in der Datei .yapfaqrc eingestellt und geändert werden.

Außerdem kann über den neuen Kommandozeilenparamter "-c" eine andere .rc-Datei übergeben werden; auf diese Weise lassen sich bspw. durch Angabe unterschiedlicher .cfg-Dateien in verschiedenen .rc-Dateien auch verschiedene FAQ-Sammlungen durch yapfaq bearbeiten.

Posten über externes Programm

Statt die FAQs durch yapfaq selbst posten zu lassen können diese nunmehr auch per Pipe an ein externes Programm weitergegeben werden, das durch den neuen Kommandozeilenparamter "-s" definiert wird, bspw. inews aus dem INN-Paket oder den mächtigeren Ersatz tinews.pl, den man von ftp.tin.org herunterladen kann. Selbstverständlich kann dieses externe Programm auch cat, mail o.ä. sein - je nachdem, was man erreichen möchte.

Kleinere Änderungen und Fehlerbehebung

Der Kommandozeilenparamter "-h" gibt jetzt nicht mehr nur Version und Kommandozeilenparameter aus, sondern stattdessen die komplette man-Page; Version und Copyright erhält man über den neuen Kommandozeilenparamter "-V" ausgegeben.

Die Statusinformationen - letztes Posting der FAQ und dessen Message-ID - werden jetzt nur noch nach erfolgreichem Posten (bzw. wenn das mit "-s" aufgerufene Programm den Exitcode "0" zurückgibt) gespeichert.

Ein Anmeldeversuch am Newsserver erfolgt nur noch, wenn ein Benutzername gesetzt ist.

Und schließlich ist die Angabe des Formats für die Message-ID jetzt optional; für den Default wird der Hostname des Systems als FQDN herangezogen. Bei ungültigen Angaben für Expires und Message-ID-Format wird jetzt korrekt der Default eingesetzt; außerdem finden beim Laden der Konfigurationsdatei (standardmäßig yapfaq.cfg) nunmehr weitere Überprüfungen statt.

Die aktuelle Version steht jeweils auf meiner Downloadseite zur Verfügung.

yapfaq 0.6.2 released

nospam@example.com (Thomas Hochstein) — Fri, 26 Feb 2010 19:59:00 +0000

Wie am Wochenende schon angekündigt, habe ich yapfaq in den letzten Tagen etwas weiterbearbeitet. Version 0.6 (bzw., aufgrund einiger kleiner Fehler im ersten Release, Version 0.6.2) enthält neben einigen kleineren Änderungen vor allem folgende Erweiterungen:

Variabler Expires:-Header

Die bisherige Version hat einen Expires:-Header von drei Monaten gesetzt; dieser Wert ist nunmehr konfigurierbar.

Kommandozeilen-Parameter

yapfaq nimmt jetzt einige Kommandozeilen-Parameter entgegen. So können mittels "-v" Informationen über den Programmablauf ausgegeben werden; mit dem Parameter "-f" kann die Abarbeitung auf die genannte FAQ beschränkt werden, yapfaq arbeitet dann also nicht alle FAQs ab. Außerdem kann mit "-p" das Posten aller - oder einer - FAQ(s) erzwungen werden, auch wenn diese eigentlich noch nicht fällig ist; am sinnvollsten ist das im Zusammenhang mit "-f". Die Parameter "-d" und "-t" ermöglichen Tests: "-d" führt zu einem reinen Simulationslauf, bei dem nichts gepostet wird, so daß bspw. getestet werden kann, welche FAQs zum Posten anstehen würden. "-t" ermöglicht es, die FAQ nicht in die eigentlich vorgesehene(n) Gruppe(n) zu posten, sondern stattdessen in eine Testgruppe oder auf die Konsole auszugeben, um zu prüfen, wie ein Posting aussehen würde.

Die aktuelle Version steht jeweils auf meiner Downloadseite zur Verfügung.

POD - plain old documentation

nospam@example.com (Thomas Hochstein) — Thu, 25 Feb 2010 20:56:00 +0000

Perl bietet eine recht interessante und bequeme Art, die Dokumentation zu einem Script oder Modul in den Programmcode einzubetten: POD, "plain old documentation".

Dieses Format ermöglicht es, die Dokumentation jeweils beim Code einzubetten oder doch zumindest am Ende des Programmcodes in derselben Datei zu speichern. Diese Dokumentation kann dann mittels perldoc angezeigt oder mit Hilfe von entsprechenden Tools in andere Formate - Klartext, HTML, man pages etc. - konvertiert werden, so daß die Dokumentation aus dem Sourcecode selbst erzeugt werden kann.

Mehr Informationen dazu:

perlpod man page
perldoc man page
podlators (translators from POD to text and nroff from Russ Allbery)
pod2text man page
pod2html man page