Netz - Rettung - Recht

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