Netz - Rettung - Recht

Meine Webseiten wurden zuletzt Anfang 2005 komplett neu gestaltet und haben an verschiedenen Stellen dringlichen Überholungsbedarf … zu der es bisher nie so recht gereicht hat. Das wird zumindest im alten Jahr auch nicht mehr anders werden; dennoch habe ich die Gelegenheit genutzt, wenigstens an einigen Stellen ordnend, organisierend und aktualisierend einzugreifen. Unter anderem habe ich einen kompletten Linkcheck über die Seiten laufen lassen und nach Möglichkeit alle toten Links entfernt. (Und das waren nicht wenige!) Außerdem hat das CSS sich ein wenig geändert; bspw. habe ich den Zeilenabstand erhöht, was das Lesen, wie ich finde, direkt deutlich angenehmer macht.

Nachdem ich mich derzeit gerade um meinen im November neu eingerichteten Newsserver bemühe und dabei bin, die Liste der geführten Newsgroups einmal zu konsolidieren, bin ich dabei auf die "List of Usenet public managed hierarchies" auf usenet.trigofacile.com gestoßen, der vom derzeitigen Mit-/Hauptentwickler des INN betriebenen Webseite. Dort findet sich ein komfortables Webinterface für den Zugriff auf die durch konventionell anderweitig verfügbaren Daten zur Konfiguration von Usenet-Hierarchien, also sowohl deren Gruppenbestand und dessen Änderungen als auch die notwendige Konfiguration des Newsservers, um Steuernachrichten für Änderungen des Gruppenbestands automatisiert durchzuführen. Die entsprechenden Rohdaten finden sich auf dem FTP-Server des ISC, wie bspw. das Steuernachrichten-Archiv, das generische Active- und Newsgroups-File und das generische control.ctl etc. pp.

Gepflegt werden sie von Russ Alberry, der auch die zugehörigen Scripts und Daten ("control-archive") pflegt.

Nach dieser Erkenntnis habe ich direkt einmal Updates bzw. Ergänzungen für ka.* und szaf.* dort eingeworfen und news.admin.hierarchies abonniert.

Es ist Weihnachten, und damit hat auch mein Weihnachtsurlaub begonnen, für den ich mir (mal wieder) sehr viel vorgenommen habe; allerlei Sachen, die ich "immer schonmal" machen wollte, zu denen man aber im Alltag nicht die notwendige Zeit und Muße findet. Unter anderen will ich auch einige etwas umfangreichere Projekte rund um meine Rechner und Webseiten umzusetzen versuchen.

Nachdem ich eine - schon jetzt endlose - Liste vieler kleiner und auch etlicher großer Aufgaben zusammengestellt habe, die zudem ständig weiter wächst, kann ich nunmehr auch schon die ersten Erledigungen vermelden: dieses Blog (und auch alle weiteren *Serendipity*-Installationen, und alle anderen Softwarepakete, die "von Hand" installiert wurden und daher nicht über das Paketmanagement der jeweiligen Distribution aktualisiert werden) ist/sind jetzt wieder auf dem aktuellen Stand!

Es geschehen noch Zeichen und Wunder! Auf meine Anfang November an den Support gestellte Frage bzw. den Hinweis auf Probleme beim Mailversand durch Ebay bzw. der Zustellung solcher E-Mails kam - nach einem Zwischenbescheid - nunmehr eine Antwort in der Sache:

Sehr geehrter Herr Hochstein,

Sie hatten sich an eBay gewandt, da Ihre Nutzer nicht alle E-Mail von uns erhalten haben.

Durch Sie und andere E-Mail-Provider sind wir auf eine Änderung in der Kopfzeile unserer Benachrichtigungen hingewiesen worden. Dies könnte der Auslöser für das geschilderte Problem gewesen sein. Um diese  Fehlerquelle auszuschliessen, haben diese Änderung jetzt korrigiert.

Herr Hochstein, bitte informieren Sie uns, ob Ihre Nutzer ab dem 16.12.2009 noch Benachrichtigungen vermissen.

Ich danke Ihnen für Ihre Mühe und wünsche Ihnen eine angenehme Woche.

Und die Überprüfung hat tatsächlich eine Behebung des Problems ergeben: die im Envelope-From bzw. Return-Path (dem "technischen" Absender der E-Mail) verwendeten Adressen existieren jetzt wieder bzw. nehmen E-Mail entgegen.

Erfreulich, daß man sich bei Ebay solcher Probleme tatsächlich annimmt und sie behebt. Das motiviert dazu, auch in anderen Fällen entsprechend tätig zu werden.

Nachdem ich im letzten Monat meine Verwaltung personalisierter E-Mail-Adressen auf eine bequeme Weboberfläche umgestellt hatte, habe ich dieses Konzept nun auch auf meine abonnierten Mailinglisten erweitert.

Bislang habe ich alle Mailinglisten mit derselben E-Mail-Adresse abonniert, die ich dann per UUCP abgerufen habe. Das hatte den protokollbedingten Vorteil, daß die E-Mails komprimiert wurden, aber den Nachteil, daß ich keine Kontrolle über die Konfiguration des MX hatte, also auch keine Spamfilterung implementieren konnte, und daß bei einem Wechsel des Providers auch diese E-Mail-Adresse verlorengeht, dann also plötzlich alle bezogenen Mailinglisten unter anderer Adresse neu abonniert werden müssen. Und schließlich kamen über diese Adresse geradezu ungeheure Mengen an Spam an, geschuldet den Webarchiven der meisten Mailinglisten. Also habe ich mich nun entschieden, auch für den Bezug von Mailinglisten jeweils individualisierte Mailadressen unter einer (anderen) Subdomain einzusetzen; das erleichtert es überdies, bei Problemen mit der Abbestellung einer Liste einfach die entsprechende Bezugsadresse stillzulegen.

Das Hauptproblem bei einer solchen Umstellung ist es, die bisherige Bezugsadresse aus jeder einzelnen Liste aus- und die neue Bezugsadresse dann wiederum in jede Liste neu einzutragen (von der Reihenfolge her natürlich andersherum, damit keine Mailverluste auftreten). Und man glaubt gar nicht, wie schnell man dabei Low-Traffic-Listen (Ankündigungen o.ä.) vergißt …

Schon seit langer Zeit (tatsächlich wiederum Jahren) habe ich daher Scripts laufen, die versuchen, aus den über die Zustellung an meine Mailnglistenadresse geschriebenen Logs möglichst alle betroffenen Mailinglisten zu isolieren. Und ausgerüstet mit diesen Listen, einer Liste der Mailinglisten, an deren Bezug ich mich bewußt erinnere und einer Liste meiner Mail2News-Gateways habe ich nunmehr die Herkules-Aufgabe begonnen, alle Mailinglisten umzustellen (und manche dabei direkt abzubestellen). Ich bin gespannt, welche Listen ich vergessen werde …

Dazu waren ergänzende Umstellungen "drumherum" erforderlich: bspw. bei der lokalen Auslieferung der Mailinglistenmails, die Filter und Mail2News-Gateways berücksichtigen muß, oder auch bei der Konfiguration der richtigen Absenderadresse für jede Mailingliste in Mailclient oder Newsreader, damit eventuelle Antworten auf die Listen dann auch auf diesen landen und nicht abgewiesen werden, weil sie von einer Adresse kommen, die dem Mailinglistensystem unbekannt ist. Und das Logging wollte angepaßt werden, und … und … und …

Ich bin gespannt, wie sich diese Umstellung bewähren wird.

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:

• INN-Dokumentation zu perl-nocem
• Somewhat of an copy&paste tutorial for NoCeM

Zur Einrichtung gehören in jedem Fall folgende Schritte:

1. digitale Schlüssel der Versender herunterladen (bspw. von der NoCeM Registry: NoCeM-Keyring)
2. konfigurieren, welche NoCeMs ausgeführt werden sollen (nocem.ctl)
3. entsprechenden Feed in perl-nocem einrichten
4. 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.