Netz - Rettung - Recht

Es ist noch gar nicht so lange her … aber gestern abend war es wieder soweit:

Nov 25 23:11:17 xerxes kernel: [5810638.952272] eth1: link down
Nov 25 23:11:22 xerxes upsmon[2827]: UPS belkin-reg-pro@localhost on battery
Nov 25 23:40:12 xerxes upsmon[2827]: UPS belkin-reg-pro@localhost battery is low
Nov 25 23:40:12 xerxes upsmon[2827]: Executing automatic power-fail shutdown
Nov 25 23:40:12 xerxes upsmon[2827]: Auto logout and shutdown proceeding

Diesmal hat es allerdings genügt, die Maschine wieder anschalten zu lassen. (Und das initiale "link down" erklärt sich daraus, daß zwar der Server an einer USV hängt, der Rest der Netzwerktechnik - Switch, Router, DSL-Modem - aber nicht.)

Die Dauer des Ausfalls finde ich übrigens einigermaßen bemerkenswert; und die Laufzeit der USV auch. (Der automatische Shutdown war allerdings offenbar ein kleines wenig zu spät; die Maschine hat es nicht mehr ganz geschafft, sich herunterzufahren. Passiert ist dabei aber nichts.)

Angeregt durch den ohnehin erforderlichen Umzug des Mailinglistenservers Mailman auf eine neue Maschine habe ich jetzt endlich auch die - historisch gewachsene - Konfiguration der meisten Mailinglisten geändert und bei der Gelegenheit auch eine Vielzahl bereits seit Jahren "toter" Mailinglisten - ggf. nach Rücksprache mit dem jeweiligen Betreiber - entsorgt. Die Konfigurationsänderung besteht in erster Linie in einer Änderung des per Default genutzten Hostnamens bzw. der Domain von "list.th-h.de" (Singular, da es anfangs eine Parallelinstallation "lists.th-h.de" gab …) zu "lists.szaf.org", weil es schließlich weniger um ein nur von mir genutztes Angebot geht als vielmehr um einen Dienst, der auch anderen zur Verfügung stehen soll. Selbstverständlich bleiben die bisher genutzten Namen für die bestehenden Listen verfüg- und nutzbar.

Praktisch finde ich, daß sich Mailman so konfigurieren läßt, daß - je nach dem Hostname, unter dem das Webinterface aufgerufen wird - jeweils nur die Mailinglisten angezeigt werden, die unter der entsprechenden Domain angelegt sind. Ein Aufruf von list.th-h.de bringt also ein anderes Ergebnis als ein Aufruf von lists.szaf.org (natürlich nur soweit die Mailinglisten überhaupt öffentlich angezeigt werden).

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

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:

• Cancel-Lock in filter_nnrpd.pl setzen
• Cancel-Lock in filter_nnrpd.pl/cleanfeed.local überprüfen
  

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

"INN: Cancel-Lock und Cancel-Key" vollständig lesen

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.

Heute ist Freitag der 13.

Natürlich sind wir nicht abergläubisch, aber es ist in gewisser Weise schon passend, daß sich ausgerechnet am heutigen Morgen die Maschine, auf der u.a. der Newsserver news.szaf.org und der Mailinglistenserver laufen, weggehängt hat. Offenbar nähern sich die verbauten Platten rapide ihrem EOL; diesen Schluß läßt jedenfalls das zeitliche Zusammenfallen mit I/O-lastigen Aktivitäten wie dem Durchlauf von news.daily und dem automatisierten Backup zu, bestätigt durch den Blick auf die serielle Konsole zu, auf der sich die Maschine logmäßig gesehen entsprechend "erleichtert" hatte (man könnte auch "ausgekotzt" sagen …). Einen Reboot später war sie wieder da, aber das Raid-Array wirkte in gewisser Weise etwas unsortiert:

Personalities : [raid1]
md7 : active raid1 sdb7[1]
      65898496 blocks [2/1] [\_U]
md6 : active raid1 sda6[0]
      4891648 blocks [2/1] [U\_] 
md5 : active raid1 sda5[0] sdb5[1]
      4891648 blocks [2/2] [UU] 
md1 : active raid1 sda1[0]
      505920 blocks [2/1] [U\_]

Interessant vor allem, daß sich (je nach Partition) teilweise die eine, teilweise die andere Platte weggehängt hat. (Besser gar nicht darüber nachdenken!)

Die gute Nachricht: ein Umzug der Maschine ist schon länger geplant, und der Nachfolger ist bereits seit August gebucht (und zumindest teilweise auch schon eingerichtet). Nur der Umzug der Dienste wartete noch auf das berühmte "freie Wochenende" oder "mal eine Woche Urlaub". Insofern dürfte es sich empfehlen, die Kiste nach Möglichkeit nicht mehr als unbedingt nötig anzufassen (insbesondere I/O-lastige Aktivitäten zu unterlassen) und den Umzug zu forcieren. Jetzt ist ja zumindest mal Wochenende …

Man sagt, E-Mail sei in früheren Zeiten technisch bedingt ein eher unzuverlässiges Medium gewesen: schmale Anbindungen, schwachbrüstige oder unter Leistungsgesichtspunkten knapp kalkulierte Server, Auslieferung über viele verschiedene Zwischenstationen (Hops), teilweise über Systeme, die nicht permanent ans Internet angebunden sind (store-and-forward), teilweise auch unzuverlässige Software, zumindest bei einem hinreichend breit gefaßten Begriff von E-Mail auch viele verschiedene, zueinander inkompatible Formate (Internet-E-Mail, X.400, Mail über UUCP, private Nachrichten in Mailboxnetzen, …), die untereinander umgesetzt werden mußten, teilweise über Netzgrenzen hinweg.

Das ist heute Vergangenheit. E-Mail wird in der Regel nur noch als "Internet-E-Mail" ausgetauscht, die betreffenden Server sind per ausreichend dimensionierter Standleitung ans Netz angebunden und entsprechend leistungsmäßig - wenn sich natürlich auch jede Infrastruktur durch genügend E-Mails, meistens im Rahmen der Versendung von Spam oder Malware, in die Knie zwingen läßt -, die Protokolle sind verfeinert und erweitert und man muß nicht mehr damit rechnen, daß irgendwelche Konvertierungen zu Informationsverlusten führen oder sich zwingend auf den ASCII-Zeichensatzvorrat (ohne Umlaute o.ä. oder gar "Anhänge") beschränken.

Dieser Zugewinn an technischer Sicherheit wird m.E. aber leider oft durch administrative Maßnahmen mehr als aufgewogen: technisch mag es zwar trivial sein, E-Mail auszuliefern, aber administrativ führen Abwehrmaßnahmen gegen tatsächliche oder vermeintliche Bedrohungen (Blacklists, Filterung jenseits technisch zwingender Notwendigkeit, Greylisting, Sender-Verification-Callouts, SPF und Co., BATV, DKIM und Co., Spam-, Viren- und andere Contentfilter etc. pp.) und nicht selten auch bloße Inkompetenz derjenigen, die "mal eben" einen Mailserver aufsetzen, dazu, daß die Mailzustellung faktisch langsamer und schwieriger wird und teilweise für den Absender noch nicht einmal erkenbbar wird, daß seine E-Mail den Adressaten nicht erreicht hat). Das gilt insbesondere, wenn verschiedene Filtertechniken oder Konfigurationen auf Absender- und Empfängerseite miteinander interagieren, was zu unerwarteten Folgen führen kann.

"Zuverlässigkeit von E-Mail als Medium" vollständig lesen

Schon seit vielen Jahren verwende ich eine Subdomain zur Vergabe von personalisierten E-Mail-Adressen, die ich dann für Zwecke verwenden kann, bei denen ich meine normale E-Mail-Adresse nicht preisgeben möchte, bspw. das Abonnieren von Newslettern, an deren Seriösität ich Zweifel habe, für Webshops etc. pp. Das hat den Vorteil, daß sich über diese personalisierten E-Mail-Adressen nachvollziehen läßt, aus welcher Quelle bspw. Spammer ihre Adressen bezogen haben, und, viel wichtiger, daß sich diese Adressen rückstandslos entsorgen lassen, wenn sie missbraucht werden. Insgesamt eine gute Idee; die Frage ist immer nur, wie man sich diese Adressen erzeugt.

Meine erste Lösung war ein Catch-All, was aber den Zweck der Übung letztlich konterkarierte, weil man auf diese Weise eine unbegrenzte Anzahl valider E-Mail-Adressen erzeugt und Spam potentiell potenziert. Zwar kann man bestimmte Adressen selektiv deaktivieren, bspw. über eine Aliases-Datei, in der sie explizit geerdet werden und ein Catch-All als Fallback für nicht explizit definierte Adressen verwendet wird, aber Spammer permutieren Adressen gerne; wenn man abashop@domain.example deaktiviert, bekommt man stattdessen vielleicht Mail an abasho@domain.example und an abash@domain.example und an … So hat sich das nicht bewährt.

Also habe ich die Adressen stattdessen in einer Aliases-Datei explizit definiert (und für eine Übergangszeit doch einen Catch-All als Fallback verwendet, für den Fall, daß ich eine bereits verwendete Adresse vergessen hatte …). Das tat etliche Jahre seinen Zweck, hatte aber den Nachteil, daß ich mich für Änderungen immer erst auf dem entsprechenden Host einloggen und die Datei ändern mußte. Unbequem und, wenn man gerade unterwegs ist und nur Webzugriff hat, erst gar nicht möglich. Also habe ich reichlich oft doch meine Hauptadresse für diverse Anmeldungen verwendet; diesen Nachteil gab es bei der Verwendung des Catch-All nicht.

Die Lösung wäre - so war mir ebenfalls seit langer Zeit klar - die Verwendung eines bequemen, nach Möglichkeit webbasierten Interfaces zur Anlage neuer solcher Adressen, damit der innere Schweinehund nicht mehr dazwischenkommen kann. Und diese Lösung habe ich jetzt endlich umgesetzt. Zumindest provisorisch, aber das wird vermutlich wieder so ein langlebiges Provisorium werden …

"Personalisierte Mailadressen" vollständig lesen