Netz - Rettung - Recht (Artikel mit Tag inn)

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

Titelbild © Weissblick - stock.adobe.com

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

letsencrypt jenseits des Webservers

nospam@example.com (Thomas Hochstein) — Tue, 30 Aug 2016 14:30:00 +0000

Vor einigen Monaten hatte ich über letsencrypt, die neue Zertifizierungsstelle für TLS-Zertifikate, berichtet und demletzt meine guten Erfahrungen damit dargestellt. Doch HTTP ist ja nicht das einzige Protokoll, das einer Absicherung bedarf. Wie sieht es mit TLS-Zertifikaten für Mail (SMTP und POP3 oder IMAP) und News (NNTP) oder noch andere Dienste aus?

Grundsätzlich ist das kein Problem: vorhandene Zertifikate mit dem (oder den) passenden Hostnamen müssen nur eingebunden werden.

In der Folge stelle ich die Vorgehensweise ausgehend von einem Debian-Jessie-System aus vor.

Erhalt des Zertifikats

Am einfachsten ist das, wenn unter jedem Hostnamen auch ein Webserver erreichbar ist; dann kann nämlich einfach das webroot-Plugin verwendet werden. Ist das nicht der Fall, kommen bspw. das manual-Plugin oder das external-Plugin in Betracht.

Installation des Zertifikats

Das bereits - für den Webserver - vorhandene oder neu erhaltene Zertifikat und der zugehörige Schlüssel ( Key), die üblicherweise im Verzeichnis /etc/letsencrypt/live/domain.example/ liegen, können nun eingebunden werden - entweder das Zertifikat und die ganze Zertifikatskette mit allen Zwischenzertifikaten zusammen in einer Datei (fullchain.pem), oder das Zertifikat (cert.pem) und die Zwischenzertifikate (chain.pem) getrennt, je nachdem, was die Applikation unterstützt.

Nicht immer ist es aber ohne weiteres möglich, unmittelbar auf die Dateien in /etc/letsencrypt/live/domain.example/ zuzugreifen, die root:root gehören und aufgrund der Verzeichnisrechte auch nur für root lesbar sind. Manche Programme (bspw. der Mailserver Exim) greifen nämlich auf die Zertifikate zu einem Zeitpunkt zu, zu dem sie bereits keine Root-Rechte mehr haben; und es erscheint wenig tunlich, sie in die Gruppe root aufzunehmen oder gar Zertifikat und Key weltweit lesbar zu machen. Andere Programme wiederum haben ausgesprochen strikte Vorstellungen darüber, welchem Benutzer und/oder welcher Gruppe die Dateien “gehören” müssen und wie die Zugriffsrechte auszusehen haben (so z.B. der Newsserver INN, der erwartet, dass der Key ausschließlich für den User news lesbar ist). In diesen Fällen wird es m.E. unausweichlich sein, Kopien der Zertifikate und des Keys mit den passenden Rechten anzulegen.

Dovecot

Der POP3- und IMAP-Server Dovecot greift als root auf die Zertifikate zu und kann - jedenfalls in seiner in Debian Jessie enthaltenen Version 2.2.13 - die Zertifikatskette (fullchain.pem) verarbeiten. Es genügt also, Zertifikat und Key einzubinden und die Serverkonfiguration neu einzulesen (service dovecot reload).

Exim

Anders sieht es mit dem SMTP-Server Exim aus. Dieser gibt seine Root-Rechte auf, bevor er auf die TLS-Zertifikate zugreift. Immerhin kommt auch er mit fullchain.pem klar.

Eine Möglichkeit ist es, Zertifikat und Key in ein passendes Verzeichnis zu kopieren und dann Eigentümer und Rechte (644!) anzupassen, bspw. so:

cd /etc/exim4
mkdir certs 
cp /etc/letsencrypt/live/domain.example/fullchain.pem /etc/exim4/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/exim4/certs/
service exim4 restart
chown Debian-exim:Debian-exim /etc/exim4/certs/
chown Debian-exim:Debian-exim /etc/exim4/certs/*
chmod 644 /etc/exim4/certs/*

Ein solches Vorgehen wird dann auch bei jeder Erneuerung der Zertifikate erforderlich (s.u.)!

Danach genügt es, die Serverkonfiguration neu zu laden (service exim4 reload) und sich dann zu Testzwecken auf Port 25 zu verbinden und nach dem EHLO ein STARTTLS abzusetzen.

INN

INN stellt - jedenfalls in der in Debian Jessie enthaltenen Version 2.5.4 - ganz besondere Ansprüche: jedenfalls der Key muss für den Benutzer news lesbar sein, und er benötigt cert.pem und chain.pem getrennt.

Umsetzen könnte man das bspw. so:

cd /etc/news
mkdir certs 
cp /etc/letsencrypt/live/domain.example/cert.pem /etc/news/certs/
cp /etc/letsencrypt/live/domain.example/chain.pem /etc/news/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/news/certs/
chown news:news /etc/news/certs/*
chmod 600 /etc/news/certs/*

Auch hier muss man dieses Vorgehen für eine Erneuerung der Zertifikate im Blick behalten (s.u.).

Ein Einlesen der inn.conf später (service inn2 restart) sollte dann alles funktionieren wie geplant.

Zertifikat-Updates

Die nunmehr im Dateisystem verstreuten Zertifikatskopien müssen nach jeder Erneuerung des Zertifikats gleichfalls erneuert werden, damit nicht ein ungültiges Zertifikat ausgeliefert wird. Sinnvollerweise geschieht das ebenso automatisiert wie die Erneuerung des Zertifikats; hilfreich dabei die Möglichkeit, letsencrypt (bzw. certbot) mittels --post-hook nach einem Zertifikatsaustausch ein Script ablaufen zu lassen.

Exim

Man könnte sich daher bspw. eine Datei /usr/local/bin/certbot-exim4-renew.sh mit folgendem Inhalt anlegen:

#!/bin/dash
cp /etc/letsencrypt/live/domain.example/fullchain.pem /etc/exim4/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/exim4/certs/
service exim4 reload

Dazu passt dann ein Cron-Eintrag der folgenden Art:

certbot certonly --quiet -n --webroot -w /var/www/domain.example -d domain.example --keep-until-expiring --post-hook /usr/local/bin/certbot-exim4-renew.sh

Damit wird versucht, das Zertifikat für diesen Hostnamen (domain.example) zu erneuern, jedoch nur, wenn es der Erneuerung bedürftig ist.

Der Aufruf sollte in der Crontab zeitlich vor dem allgemeinen Aufruf certbot renew --quiet erfolgen, damit erst das spezielle Zertifikat aktualisiert (und ggf. umkopiert) wird und danach die übrigen.

INN

Für den INN sähe diese Lösung analog mit einer Datei /usr/local/bin/certbot-inn2-renew.sh so aus:

#!/bin/dash
cp /etc/letsencrypt/live/domain.example/cert.pem /etc/news/certs
cp /etc/letsencrypt/live/domain.example/chain.pem /etc/news/certs
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/news/certs
cd /etc/news/certs
chown news:news *.pem
chmod 600 *.pem
service inn2 reload

Der Cron-Eintrag wäre dann entsprechend:

certbot certonly --quiet -n --webroot -w /var/www/domain.example -d domain.example --keep-until-expiring --post-hook /usr/local/bin/certbot-inn2-renew.sh

Auch dieser Eintrag muss zeitlich vor dem allgemeinen Aufruf certbot renew --quiet liegen.

Und ihr?

So richtig optimal erscheinen mir diese Lösungen noch nicht. Gibt es bessere Ideen? Andere Erfahrungen?

Nutzt ihr letsencrypt noch für andere Dienste als die oben genannten?

An Euren Erfahrungen und Lösungen wäre ich interessiert und freue mich daher über Kommentare, Hinweise und Ergänzungen.

Kaum macht man es richtig, schon funktioniert es!

nospam@example.com (Thomas Hochstein) — Sat, 29 Jan 2011 16:21:46 +0000

Dieser Tage stellte ich fest, daß mein Newsserver offensichtlich keine Steuernachrichten mehr ausführt. Aber warum bloß?

Die Rücknahme einiger jüngerer Änderungen - die sicherstellen sollten, daß die Steuernachrichten nicht nur ausgeführt, sondern mir auch gemailt werden (mit Dank an den Widder!) - brachte keine Lösung. Also bin ich zu systematischen Debugging übergegangen; dank fehlenden Loggings anhand des Einstreuens von Ausgabeanweisungen in eine Kopie des zuständigen Scripts (controlchan). Stunden später[tm] stellte sich dann als Ursache … ein Bedienerfehler heraus (wie immer). Wenn man Steuernachrichten für eine bestimmte Hierarchie verwerfen will, dann sollte man den Namen der Hierarchie nicht nur als Kommentar in die control.ctl eintragen, sondern für den entsprechenden Eintrag auch ein Muster wie hierarchie.* verwenden. * alleine führt nicht zum erwünschten Ergebnis (sondern zum Verwerfen aller Steuernachrichten für alle Hierarchien).

INN-Funktionsweise: Expire

nospam@example.com (Thomas Hochstein) — Tue, 26 Jan 2010 20:40:00 +0000

Wie ich vor anderthalb Wochen schrieb, fehlte meiner Beschreibung der Funktionsweise des Newsservers INN noch der Teil über Expire; namentlich deshalb, weil mir die Funktionsweise selbst nicht hinreichend klar war. Inzwischen habe ich aber, so denke ich, dank der hilfreichen Erläuterungen in de.comm.software.newsserver den notwendigen Durchblick gewonnen und die Beschreibung entsprechend ergänzt.

INN: Authentifizierung gegen MySQL-Datenbank

nospam@example.com (Thomas Hochstein) — Sat, 23 Jan 2010 16:55:00 +0000

INN bietet vielfältige Möglichkeiten der Benutzerauthentifizierung an. Wenn man einer größeren Anzahl von Benutzern einen Zugang einräumen will, bietet es sich an, die notwendigen Daten - Benutzerkennung, Paßwort, etc. - in einer Datenbank zu halten, bspw. in einer MySQL-Datenbank.

Eine denkbare Lösung dafür, die neben Benutzerkennung und Paßwort auch Namen und E-Mail-Adresse des Benutzers erfaßt sowie ein Flag für aktive/inaktive Benutzer und eine Trennung nach verschiedenen Zugriffsstufen kennt sowie den Zeitpunkt des letzten Logins festhält, möchte ich hier vorstellen. Dazu gehört über das hier vorgestellte Script für den INN hinaus natürlich noch ein passendes (Web-)Interface, mit dem Benutzer angelegt und gelöscht sowie Paßworte geändert werden können etc.

Die Datenbankstruktur sieht folgendermaßen aus:

    CREATE TABLE IF NOT EXISTS `users` (
      `userid` int(11) NOT NULL auto_increment,
      `user` varchar(16) collate latin1_bin NOT NULL default '',
      `password` varchar(16) collate latin1_bin NOT NULL default '',
      `active` tinyint(1) NOT NULL default '1',
      `username` varchar(60) collate latin1_bin default NULL,
      `usermail` varchar(60) collate latin1_bin default NULL,
      `domain` varchar(40) collate latin1_bin default '<EDITME>',
      `llo` date default NULL,
      PRIMARY KEY  (`userid`),
      UNIQUE KEY `user` (`user`)
    );

Die Felder sollten weitgehend selbsterklärend sein; "llo" steht für "last logged in".

Die Module DBI und Time::Localtime werden benötigt; außerdem müssen natürlich die Zugangsdaten für die Datenbank definiert werden:

use DBI;
use Time::localtime;
### DB Vars - EDIT ME!
$conf{'dbdriver'} = "mysql";
$conf{'dbhost'} = "localhost";
$conf{'database'} = "";
$conf{'dbuser'} = "";
$conf{'dbpw'} = "";
$conf{'dbtable'} = "";
$conf{'actcheck'} = 1;

Der eigentliche Zugriff auf die Datenbank kommt in die Subroutine "authenticate", die dann vom INN aufgerufen wird:

### DB init
my $dbs = sprintf('DBI:%s:database=%s;host=%s',$conf{'dbdriver'},$conf{'database'},$conf{'dbhost'});
my $dbhandle = DBI->connect($dbs, $conf{'dbuser'}, $conf{'dbpw'}, { PrintError => 1 });
### Query database and disconnect.
my(@result);
# quote SQL
my $sql_user = $dbhandle->quote($attributes{username});
my $sql_pass = $dbhandle->quote($attributes{password});
my $query = sprintf("SELECT domain FROM %s.%s WHERE user = %s AND password = %s",$conf{'database'},$conf{'dbtable'},$sql_user,$sql_pass);
if ($conf{'actcheck'}) {
$query .= ' AND active = 1';
};
my $dbquery = $dbhandle->prepare($query);

Wenn die Abfrage erfolgreich verlief, es also einen passenden Benutzer mit passenden Paßwort gibt, wird der Zeitpunkt des letzten Logins in der Datenbank aktualisiert:

if ($dbquery->execute()) {
@result = $dbquery->fetchrow_array;
$dbquery->finish;
if (@result) {
# log timestamp
my $tm = localtime;
my $today = sprintf('%04d-%02d-%02d', $tm->year+1900, ($tm->mon)+1, $tm->mday);
$query = sprintf("UPDATE %s.%s SET llo = '%s' WHERE user = %s",$conf{'database'},$conf{'dbtable'},$today,$sql_user);
$dbquery = $dbhandle->prepare($query);
$dbquery->execute();
$dbquery->finish;
};
};
$dbhandle->disconnect;

Danach ist nur noch entsprechend zu reagieren:

### check password and respond appropriate
if (@result) {
my $user = $attributes{username} . '@' . $result[0];
return (281, 'Authentication successful: '.$user, $user);
} else {
return (481, 'Authentication failure');
}

Das komplette Perl-Script gibt's in meinem Git-Repository.

Eingebunden wird dieses Perl-Script in die readers.conf des INN als Authentification Group:

    auth "users-mysql" {
        hosts: *
        perl_auth: "/usr/lib/news/bin/auth/passwd/perl_mysql"
    }

Es liefert dann eine Benutzerkennung der Form user@domain zurück; die domain kann dann in folgenden Access Groups referenziert werden:

    access "customers" {
        users: "*@customer.news.host.example"
        newsgroups: "*, !internal.*, !special.*"
        access: "RP"
    }

INN-Funktionsweise: Steuernachrichten und Filter

nospam@example.com (Thomas Hochstein) — Sun, 17 Jan 2010 16:06:00 +0000

Der Urlaub neigt sich endgültig seinem Ende zu, und - leider - ist die Todo-Liste, insbesondere hinsichtlich angedachter größerer Projekte, die man abends oder am Wochenende (zumindest bei meiner derzeitigen zeitlichen Belastung) nicht sinnvoll angehen kann, nicht merklich geschrumpft. Stattdessen habe ich mich (ungeplant) auf die Datensammlung zu Usenet-Hierarchien und danach dann auf den Umgang mit git konzentriert und am Ende eine ganze Reihe Dinge umgesetzt, die auf der ToDo-Liste eigentlich gar nicht vorkamen.

Nachdem Newsserver in den letzten Wochen eine so große Rolle gespielt haben ist es jetzt zum Abschluss nur recht und billig, wenn ich (nach mehrjähriger Pause) meine Seite zur Funktionsweise des INN endlich um die noch fehlenden Teile ergänze; umso mehr, als ich meine Webseiten mittlerweile in ein git-Repository eingecheckt habe und daher auch den Umgang damit üben kann, insbesondere, was fraktionierte Commits betrifft. Das ist eine sehr nette Sache: man nimmt eine Reihe unterschiedlicher Änderungen vor, die nichts miteinander zu tun haben - bspw. eine Ergänzung der INN-Beschreibung auf der einen Seite und Richtigstellungen/Tippfehlerkorrekturen, über die man zufällig stolpert, auf der anderen -, und kann diese Änderungen aber selektiv committen, bspw. zuerst nur die Ergänzungen, dann die Änderungen, dann die Rechtschreibfehler. Das macht die Commits übersichtlicher und ggf. auch leichter zu reverten, weil man nur logisch zusammengehörendes auch zusammen committet, ohne daß man beim Editieren darauf achten müßte.

Ich kann also hiermit verkünden, daß ich die Abschnitte über Steuernachrichten (control.ctl), Filter und Reader-Authentifizierung sowie eine recht umfangreiche Linksammlung ergänzt habe. Fehlen nur noch Erläuterungen zum Expire, aber das muß ich erst einmal selbst verstehen.

Update 2010-01-26: Inzwischen steht auch die Erläuterung zum Expire online. Die Seite ist damit - endlich! - fast fünf Jahre nach ihrer ersten Erstellung komplettiert. Ich hoffe, sie hilft dem einen oder anderen (vermißt wurden die fehlenden Teile allerdings offensichtlich nicht, wenn man nach dem erhaltenen Feedback über die Jahre geht …).

INN: NoCeMs verarbeiten

nospam@example.com (Thomas Hochstein) — Sat, 12 Dec 2009 21:56:00 +0000

Ergänzend zur bereits im November eingerichteten Auswertung von Cancel-Lock und -Key auf news.szaf.org habe ich heute die Auswertung von NoCeMs eingerichtet. NoCeM ("No See ‘Em") sind, grob umrissen, digital signierte Usenet-Beiträge in einem festen Format zur Löschung meist einer ganzen Reihe anderer Beiträge, also so etwas wie digital signierte Massencancel. Das mit INN ausgelieferte perl-nocem erlaubt die Auswertung dieser Nachrichten fein granuliert nach den jeweiligen Absendern. Zur Einrichtung sind folgende Anleitungen zu empfehlen:

Zur Einrichtung gehören in jedem Fall folgende Schritte:

digitale Schlüssel der Versender herunterladen (bspw. von der NoCeM Registry: NoCeM-Keyring)
konfigurieren, welche NoCeMs ausgeführt werden sollen (nocem.ctl)
entsprechenden Feed in perl-nocem einrichten
ggf. entsprechende Newsgroups, in denen NoCeMs gepostet werden, abonnieren

Der newsfeeds-Eintrag kann beispielsweise so aussehen:

nocem!\
    :!*,alt.nocem.misc,news.lists.filters,de.admin.net-abuse.announce\
    :Tc,Wf,Ap:/usr/lib/news/bin/perl-nocem

Bei den o.g. Anleitungen sind die Pfade ggf. anzupassen. Es hat sich m.E. bewährt, einfach die durch die jeweilige Distribution vorgegebene Struktur zu übernehmen.

Aktueller Cleanfeed

nospam@example.com (Thomas Hochstein) — Sun, 15 Nov 2009 15:02:00 +0000

"Cleanfeed" ist, wie der Name bereits nahelegt, ein Filter für den Newsserver INN, der auf per Feed von anderen Newsservern (Peers) empfangene Artikel wirkt, also den Feed "säubert", vor allem von Spam, böswilligen Massenpostings (als Form des "Angriffs" auf bestimmte Newsgroups) und anderen unerwünschten Erscheinungen. Nachdem die ursprünglich in den Neunzigern von Jeremy Nixon begonnene Entwicklung lange eingeschlafen erschien (und der Filter wie auch die mit ihm ausgelieferte Konfiguration zunehmend überaltert wirkten), hat sich seit 2007 nunmehr Steven Crook der Sache angenommen, einige Updates herausgebracht, die Konfiguration weiter modularisiert und eine Webseite mit entsprechender Dokumentation aufgesetzt.

Dieser "neue" Cleanfeed werkelt jetzt nach der einfachen Installation auf news.szaf.org; nur die Konfiguration bedarf sicherlich noch weiter der Verfeinerung (nachdem ich bisher wie mit dem Vorgänger in den vergangenen Jahren primär auf die Defaults setze).

INN: Cancel-Lock und Cancel-Key

nospam@example.com (Thomas Hochstein) — Sat, 14 Nov 2009 20:49:00 +0000

Im Rahmen der notwendigen Umbaumaßnahmen und der Neueinrichtung von news.szaf.org habe ich endlich auch die Unterstützung von Cancel-Lock und Cancel-Key umgesetzt.

Cancel sind Steuernachrichten zur Löschung anderer Nachrichten im Usenet, vorgesehen zur Löschung eigener Beiträge (oder ggf. noch zur Löschung von Beiträgen durch den Newsadministrator des einspeisenden Servers). Das Protokoll sieht aber keine Verifizierung dieser Nachrichten vor; grundsätzlich kann also jeder Teilnehmer Nachrichten von jedem anderen Teilnehmer löschen, was zwar unzulässig ist und auf breite Ablehnung stößt, aber dennoch in der Vergangenheit gerne vieltausendfach genutzt wurde, nicht nur für von der Netzgemeinschaft akzeptierte Spamcancel, sondern auch für Attacken gegen bestimmte Newsgroups ("leercanceln") oder Netzteilnehmer. Die als Reaktion oft erfolgte Abschaltung der Cancel-Funktionalität war aber auch nicht der Weisheit letzter Schluß.

Daher wurden bereits Ende der Neunziger Vorschläge gemacht, wie das Canceln von Beiträgen nur für Befugte ermöglicht werden kann, nämlich durch das Hinzufügen eines kryptographischen Cancel-Locks in jedem Beitrag, zu dem eine Cancelnachricht den passenden Cancel-Key enthalten muß, wenn sie ausgeführt werden soll. Cancel-Lock und -Key sind dabei zusammengesetzt aus einem geheimen Schlüssel und der Message-ID des jeweiligen (bzw. zu cancelnden) Postings. Nachdem diese Vorschläge jedenfalls auf Client-Seite nie breite Umsetzung - außerhalb einiger unixoider Newsreader - fanden (und sich das Prinzio vermutlich deshalb auch auf Serverseite nicht durchsetzte), bekamen Cancel-Lock und -Key Ende Juni 2007 durch deren verpflichtende Einführung bei dem bedeutenden deutschen Newsserver news.individual.de neuen Auftrieb. Dort hat man nämlich nicht nur die Überprüfung von Cancel-Locks aktiviert, sondern zugleich hinsichtlich der fehlenden Unterstützung im Client zumindest für die eigenen Nutzer insoweit Abhilfe geschaffen als Cancel-Locks durch den Server (!) automatisch allen Beiträgen hinzugefügt werden (und bei berechtigten Canceln wird in gleicher Weise automatisch der passende Cancel-Key eingetragen).

Bereits kurz danach wurden in de.comm.software.newsserver - namentlich durch Alexander Bartolich - erste Implementationen sowohl zum Einfügen als auch zum Prüfen von Cancel-Lock und -Key für den INN veröffentlicht:

Grundsätzlich sind für die Überprüfung von Cancel-Lock und -Key zwei Varianten denkbar: Entweder läßt man die Cancelverarbeitung in Betrieb und filtert unerwünschte Cancel (und Supersedes!) im filter_innd aus, oder man deaktiviert die Cancel-Verarbeitung komplett und führt nur erwünschte Cancel aus filter_innd heraus aus. Letzteres ermöglicht die weitere Unterscheidung, ob man Cancel ablehnen oder zwar annehmen und weiterverbreiten, aber nicht ausführen oder annehmen und ausführen möchte. Weiterhin muß man sich entscheiden, wie man mit Postings ohne Cancel-Lock umgehen will. Für diese Postings kann man weiterhin alle Cancel akzeptieren - oder keinen. (Und man muß sich eine Lösung für Spamcancel überlegen; entweder akzeptiert man signierte Cancel aus vertrauenswürdiger Quelle, oder man implementiert zugleich NoCeM als Ergänzung.)

Update: Die aktuellen Fassungen gibt es in meinem Git-Repository. Dort sind auch Anpassungen für Debian Wheezy eingepflegt.

Egal, wie man zu der Überprüfung von Cancel-Lock und -Key steht: zumindest das automatische Einfügen derselben in Postings der eigenen Benutzer (Cancel-LOck für jedes Posting, Cancel-Key für Cancel und Supersedes) ist in keinem Fall schädlich und durchaus hilfreich, eben weil es Server gibt, die Cancel nur noch mit passendem Cancel-Key ausführen. Es bietet sich an, diese Funktionalität für den INN im filter_nnrpd zu implementieren, dem Filter also, den alle, aber auch nur die lokal geposteten Beiträge durchlaufen. Eine denkbare Implementation ist die folgende für filter_nnrpd.pl, basierend auf dem Posting von Alexander Bartolich:

#
# Do any initialization steps.
#
use Digest::MD5 qw(md5_base64);
use Digest::SHA1();
use Digest::HMAC_SHA1();
use MIME::Base64();
$CANCEL_LOCK = 'hereasecretword';
#
# Filter
#
sub filter_post {
my $rval = "" ; # assume we'll accept.
$modify_headers = 1;
[...]
# Cancel-Lock / Cancel-Key
add_cancel_lock(\%hdr, $user);
if (exists( $hdr{"Control"} ) && $hdr{"Control"} =~ m/^cancel\s+(<[^>]+>)/i) {
my $key = calc_cancel_key($user, $1);
add_cancel_item(\%hdr, 'Cancel-Key', $key);
}
elsif (exists( $hdr{"Supersedes"} )) {
my $key = calc_cancel_key($user, $hdr{"Supersedes"});
add_cancel_item(\%hdr, 'Cancel-Key', $key);
}
return $rval;
}
#
# Cancel-Lock / Cancel-Key
#
sub add_cancel_item($$$) {
my ( $r_hdr, $name, $value ) = @_;
my $prefix = $r_hdr->{$name};
$prefix = defined($prefix) ? $prefix . ' sha1:' : 'sha1:';
$r_hdr->;{$name} = $prefix . $value;
}
sub calc_cancel_key($$) {
my ( $user, $message_id ) = @_;
return MIME::Base64::encode(Digest::HMAC_SHA1::hmac_sha1($message_id, $user . $CANCEL_LOCK), '');
}
sub add_cancel_lock($$) {
my ( $r_hdr, $user ) = @_;
my $key = calc_cancel_key($user, $r_hdr->{'Message-ID'});
my $lock = MIME::Base64::encode(Digest::SHA1::sha1($key), '');
add_cancel_item($r_hdr, 'Cancel-Lock', $lock);
}

Dort, wo oben [...] steht, können andere Teile des Filters eingefügt werden.

Die Überprüfung kann bspw. in cleanfeed in die cleanfood.local eingebunden werden; zunächst sind wieder die notwendigen Perl-Module einzubinden:

use MIME::Base64();
use Digest::SHA1();
use Digest::HMAC_SHA1();

Danach wird in local_filter_cancel() die Validität des Cancels geprüft und in local_filter_after_emp() die Validität von Supersedes:

#
# local_filter_cancel
#
sub local_filter_cancel {
unless($hdr{Control} =~ m/^cancel\s+(<[^>]+>)/i) {
return "Cancel with broken target ID";
}
return verify_cancel(\%hdr, $1, 'Cancel');
}
sub local_filter_after_emp {
if (exists( $hdr{'Supersedes'} )) {
#return verify_cancel(\%hdr, $hdr{'Supersedes'}, 'Supersedes');
# verify_cancel is called, but not returned, so the
# posting is unconditionally accepted
# verify_cancel calls INN:cancel() if verification suceeds
verify_cancel(\%hdr, $hdr{'Supersedes'}, 'Supersedes');
}
return undef;
}

Diese Variante setzt voraus, dass die Cancelverarbeitung in INN deaktiviert ist (innflags: -C in inn.conf setzen und INN neu starten). Sie akzeptiert nur Cancel mit passendem Cancel-Key; Supersedes werden in jedem Fall angenommen, aber nur ausgeführt, wenn sie über einen passenden Cancel-Key verfügen. Bei aktivierter Cancelverarbeitung sind die Zeilen 13 und 17 auszutauschen, d.h. die eine ist durch Entfernen des Kommentarzeichens zu aktivieren, die andere auszukommentieren.

Die eigentliche "Arbeit" erfolgt dann in den folgenden zusätzlich noch einzufügenden Funktionen:

sub verify_cancel($$$) {
my $r_hdr = shift || die;
my $target = shift;
my $descr = shift;
my $headers = INN::head($target) || return "$descr of non-existing ID $target";
my %headers;
for my $line(split(/\s*\n/, $headers)) {
if ($line =~ m/^([[:alnum:]-]+):\s+(.*)/) {
$headers{$1} = $2;
}
}
my $lock = $headers{'Cancel-Lock'};
if (defined($lock)) {
my $key = $r_hdr->{'Cancel-Key'} || return "$descr of $target without Cancel-Key";
#return verify_cancel_key($key, $lock, ' target=' . $target);
return verify_cancel_key($key, $lock, $target);
}
return undef;
}
sub verify_cancel_key($$$) {
my $cancel_key = shift;
my $cancel_lock = shift;
my $msg = shift;
$msg = '' unless(defined($msg));
# -thh
my $target = $msg;
$msg = ' target=' . $msg;
my %lock;
for my $l(split(/\s+/, $cancel_lock)) {
next unless($l =~ m/^(sha1|md5):(\S+)/);
$lock{$2} = $1;
}
for my $k(split(/\s+/, $cancel_key)) {
unless($k =~ m/^(sha1|md5):(\S+)/) {
INN::syslog('notice', "Invalid Cancel-Key syntax '$k'.$msg");
next;
}
my $key;
if ($1 eq 'sha1') {
$key = Digest::SHA1::sha1($2); }
elsif ($1 eq 'md5') {
$key = Digest::MD5::md5($2);
}
$key = MIME::Base64::encode_base64($key, '');
if (exists($lock{$key})) {
INN::syslog('notice', "Valid Cancel-Key $key found.$msg");
# -thh
# article is canceled now
INN::cancel($target) if ($target);
return undef;
}
}
INN::syslog('notice',
"No Cancel-Key[$cancel_key] matches Cancel-Lock[$cancel_lock]$msg"
);
return "No Cancel-Key matches Cancel-Lock.$msg";
}

Auch diese Funktionen sind für eine generell deaktivierte Cancelverarbeitung geschrieben; wenn die Cancelverarbeitung aktiv ist, ist die Zeile 59 wegzulassen oder auszukommentieren.

Auch der Code für cleanfeed stammt im wesentlichen von Alexander Bartolich und ansonsten von "Ray Banana".

(Die obigen Codeteile sind aus Postings zusammengetragen, getestet und für meine eigenen Zwecke angepaßt; dieser Blog-Beitrag soll eine mögliche Umsetzung von Cancel-Lock und -Key vorstellen, die ich im Rahmen der Neueinrichtung meines Newsserver vorgenommen habe. Er kann und will keine Darstellung des Für und Wider und der verschiedenen Möglichkeiten des Umgangs damit bieten.)

Umbaumaßnahmen

nospam@example.com (Thomas Hochstein) — Sat, 14 Nov 2009 19:07:00 +0000

Bereits gestern abend hatte ich bis heute in der Früh störungsbedingt die ersten Dienste (einen semi-öffentlichen bitlbee-Server, die Mailinglisten, den secondary MX für einige Domains) auf die neue Maschine umgezogen; heute war dann der Newsserver dran, der inzwischen auch provisorisch seinen Dienst aufgenommen hat. "Provisorisch" insofern, als er bislang seinen Feed von der alten Maschine bekommt und auch primär nach dort feedet, aber die ersten Peers haben erfreulich schnell auf meine Bitte per E-Mail reagiert und ihren Feed geschwenkt.

Diesmal bemühe ich mich überdies, die Konfiguration des INN direkt von Anfang an "sauber" aufzusetzen und zugleich die ersten Punkte auf (m)einer Liste der geplanten Änderungen und Verbesserungen umzusetzen. Auf dieser Liste finden sich Dinge wie

die reproduzierbar funktionsfähige Verifikation von Steuernachrichten,
ein aktueller Cleanfeed,
das automatische Setzen und das Auswerten von Cancel-Lock/Cancel-Key,
die Auswertung (ggf. auch Generierung) von NoCeMs,
das Überarbeiten des Gruppenangebots,
das Zuweisen von jeweils eigenen Hostnamen pro Feed, um diese ggf. gezielt schwenken zu können
usw. usf.

Inbesondere letzteres dürfte sich bei künftigen IP-Änderungen bewähren, weil man dann erst einmal einige Feeds auf die neue Maschine schwenken und sie dabei beobachten kann (laufen Hardware und Software stabil? ist alles richtig konfiguriert? …), und bei Bedarf auch Lastmanagement, also die Verteilung der Feeds auf verschiedenen Maschinen, ermöglichen.

Mit dem Umzug des Newsservers sollte dann die Migration von haystack, der alten Maschine, auf den Nachfolger pasture abgeschlossen sein.

INN und SSL/TLS (Debian Lenny)

nospam@example.com (Thomas Hochstein) — Mon, 27 Apr 2009 18:55:00 +0000

Das Internet ist schon lange kein friedlicher Ort mehr, an dem jeder jedem trauen kann - und deshalb wurden die ursprünglichen, unverschlüsselten Kommunikationsprotokolle schon lange durch kryptograhpisch abgesicherte Variationen ersetzt. Telnet verwendet heute wohl niemand mehr offen im Netz, stattdessen gibt es SSH; auch im Mailverkehr pflegt man - hoffentlich - zumindest das Paßwort beim Abruf über POP3 via APOP und beim Versand via SMTP über eine SMTP-Aut-Variante mit Verschlüsselung zu sichern, wenn man nicht ohnehin die ganze Kommunikation SSL-verschlüsselt, und auch diejenigen, die FTP noch nicht durch SCP/SFTP ersetzt haben, nutzen hoffentlich wenigstens SSL, um die Paßwortübertragung zu verschlüsseln.

So weit, so gut, aber schon vor einer ganzen Weile fiel mir auf, daß diese Regel für Netnews (NNTP) offenbar nicht gilt (und für UUCP oft auch nicht …); denn zu seinem oder seinen Newsserver(n) verbindet man sich oft genug noch unverschlüsselt, obwohl auch dort ein Paßwort übertragen wird. So ging es zumindest mir, und ich habe mich am vergangenen Wochenende entschlossen, dagegen etwas zu unternehmen und auch die Verbindung zumindest zu meinem eigenen Newsserver zu verschlüsseln.

Das ist - mit dem INN 2.4.5-Paket aus Debian Lenny - eigentlich ganz einfach:

Ein SSL/TLS-fähiger nnrpd ist bereits vorhanden (nnrpd-ssl). Wer nicht das vorgenannte Paket verwendet, muß den INN (oder zumindest den nnrpd) ggf. mit "configure —with-openssl" noch einmal kompilieren.
Schlüssel muß man sich erzeugen, sofern noch nicht vorhanden. Vorhandene Zertifikate bzw. Schlüssel sollte man vielleicht am einfachsten kopieren; standardmäßig werden sie in /etc/news gesucht. Das ist verhandelbar respektive konfigurierbar, aber das Zertifikat und der Schlüssel müssen dem User news gehören und die Rechte 600 aufweisen.
Die Konfigurationsdatei /etc/news/sasl.conf muß editiert (oder ggf. angelegt) werden, um die korrekten Pfade zum Zertifikat und dem privaten Schlüssel des Servers aufzunehmen. "tls_cert_file" und "tls_key_file" sind die relevanten Parameter.
Danach muß der nnrpd-ssl nur noch veranlasst werden, auf Port 563 (NNTPS) zu lauschen. Das kann man u.a. über den (x)inetd erreichen, indem man bspw. folgende Konfigurationsdatei in /etc/xinet.d/ einwirft:

    service nntps
    {
       socket_type     = stream
       protocol        = tcp
       wait            = no
       user            = news
       group           = news
       server          = /usr/lib/news/bin/nnrpd-ssl
       server_args     = -S -p 563
    }

Voraussetzung dafür ist, daß die /etc/services den Service "nntps" kennt.

Voila. Wer mag, kann auch noch eine CA daran anflanschen und bspw. Nutzer statt via Paßwort auch via Zertifikat authentifizieren, indem er die readers.conf entsprechend anpaßt, aber daran habe ich keinen Bedarf; mir genügt die Verschlüsselung der Verbindung zwischen Server und Client.

(Danke an Viktor Kafke für die entsprechenden Tips.)

INN: (History-)Cache as cache can

nospam@example.com (Thomas Hochstein) — Sun, 12 Apr 2009 18:52:00 +0000

Die sog. "History" ist beim INN die zentrale Tabelle, die Message-IDs (also die eindeutige Kennung jedes Newspostings) mit ihrem Speicherort verbindet, so daß man ein über eine Message-ID referenziertes Posting auch im Speicher-Backend wiederfinden kann; zugleich wird vor der Annahme von Postings über die History geprüft, dass das entsprechende Posting noch nicht vorhanden ist. Es sammeln sich also große Datenmengen an, auf die zudem ständig zugegriffen werden muß; ein effizientes Handling derselben ist daher Pflicht. INN unterstützt deshalb zur Verkürzung von Zugriffszeiten einen Cache für die History, der die letzten Zugriffe zwischenspeichert.

Seit Jahren betreibe ich meinen Newsserver, seit Jahren stolpere ich in den täglichen Reports des Servers darüber, daß mein Cache offenbar nicht (richtig) funktioniert, und seit Jahren plane ich, daß "bei Gelegenheit" einmal zu überprüfen. Allerdings kommt so eine "Gelegenheit" normalerweise spät oder nie …

Dieser Tage bin ich dann tatsächlich einmal dazu gekommen, das anzugehen und mich zu erkundigen, wo für das schlechte Abschneiden des Caches wohl die Ursachel liegen könne. Diese Werte erscheinen schließlich wirklich nicht berauschend:

History cache: Reason Count %Count Cache misses 190461 66.9% Do not exist 94182 33.1% Positive hits 0 0.0% Negative hits 0 0.0%

Entscheidend für das (Nicht-)Funktionieren des Caches ist, wie ich dann erfuhr, dessen Größe, die durch den Parameter hiscachesize in der inn.conf gesteuert wird. Empfohlen wurde, ihn auf mindestens 1 kB zu setzen, ggf. auch höher; bei mir stand er, wie ich dann sah, auf 0 … was einiges erklären dürfte.

Nach Erhöhung der Cachegröße auf 5 kB sieht die Sache jetzt doch deutlich besser aus:

Reason Count %Count Positive hits 183728 65.9% Negative hits 59022 21.2% Do not exist 35762 12.8% Cache misses 81 0.0%

Kleine Ursache, große Wirkung, man kennt das ja.

INN - wie funktioniert er?

nospam@example.com (Thomas Hochstein) — Wed, 27 Apr 2005 20:23:00 +0000

Nachdem "das INN-Fieber umgeht", wie Jörg so nett schrieb, habe ich mich einmal darangewagt, einen kleinen Überblick über die - anfangs nicht ganz so übersichtliche - Funktionsweise des INN zu schreiben. Die Frage nach der Einrichtung haben ja Sven und Isotopp bereits abgedeckt, die einzelnen Programmteile und Konfigurationsdateien sind im wesentlichen durch die (wirklich beispielhaft vielen!) man-Pages abgedeckt, es fehlte aber - so jedenfalls der Eindruck bei meinem Einstieg - eine Einführung in die großen Zusammenhänge, wie die einzelnen Programmteile und Konfigurationsdateien ineinander greifen, wie der INN das tut, was er tut.

INN crash recovery

nospam@example.com (Thomas Hochstein) — Wed, 13 Apr 2005 18:38:00 +0000

War der INN in Version 1.7.x wohl recht stabil und genügsam, so daß er auch nach einem unsanften Beenden - des Prozesses oder auch gleich des gesamten Systems - beim Neustart direkt auf die Füße gefallen ist, so sind neuere Versionen (wenigstens unterhalb von 2.4.x) erwiesenermaßen ziemlich mimosig. Gut, wenn man dann das passende Script mit den richtigen Maßnahmen zur Bepuschelung zur Hand hat.