Netz - Rettung - Recht

Nein, nicht "igitt"! Git. (iGit wäre vermutlich die Apple-Variante.)

Nachdem gestern Russ Albery auf meine Frage, in welchem Format denn Änderungen für das control.ctl (siehe dazu auch meinen vorigen Beitrag) am besten eingereicht werden sollten, mit

Anyone who’s really inspired can send me Git patches against the repository at git://git.eyrie.org/usenet/control.git, of course.

geantwortet hatte, war mein Ehrgeiz geweckt; schließlich plane ich nach Abschluss meiner "Forschungen" über die deutschsprachigen Regionalhierarchien eine Zusammenstellung der dann vermutlich eher umfangreichen Änderungen einzureichen, und warum sollte ich das dann nicht direkt richtig professionell versuchen? Außerdem wollte ich mich seit Jahren immer schon mal wieder mit Versionsverwaltungssystemen beschäftigen, bin aber bisher nie über die eher theoretischen Konzepte - konkret von SVN - herausgekommen. Warum also nicht jetzt einen neuen Versuch wagen?

Daher habe ich etwas gegoogelt, mir git heruntergeladen (naja, genauer gesagt das passende Debian-Paket git-core installiert), das Repository ausgecheckt und festgestellt, daß das eigentlich eine recht einfache Sache zu sein scheint. Mal gucken, wie ich dann auch tatsächlich damit zurechtkomme. Bevor es soweit ist, dürften ja auch noch einige Recherchen anstehen (und der Versuch, die Ergebnisse praktikabel zusammenzustellen und zu präsentieren; meine erste Idee, eine statische HTML-Seite zu bauen, hat sich jedenfalls eindeutig nicht bewährt).

Wenn’s mal wieder etwas länger dauert …

Im Zusammenhang mit den geplanten Auffrischungsarbeiten an meinem Newsserver wollte ich auch mal die dort geführten Hierarchien abgleichen und vielleicht auch etwas erweitern; dabei stolperte ich dann ja, wie bereits geschildert, über die "List of Usenet public managed hierarchies", und nachdem dort Lücken bezüglich einiger deutschsprachiger Hierarchien auftauchten, brachte mich das auf den Gedanken, "mal eben" die notwendigen Ergänzungen vorzunehmen. Das sollte ja schnell gemacht sein - schließlich stammen die ganzen deutschsprachigen kleinen und regionalen Hierarchien aus den Anfangszeiten des deutschen Usenets, meistens aus einem universitären oder Vereins-Umfeld, und sind daher vermutlich gut gepflegt, mit kanonischen Listen der existierenden Newsgroups ("checkgroups"), dazugehörigen Webseiten usw. usf., wie ich das beispielsweise von der Karlsruher Regionalhierarchie "ka.*" kannte.

To make a long story short: mitnichten.

Ich sitze jetzt bereits seit letztem Jahr (und damit bald eine gute Woche) daran, mir einen Überblick zu verschaffen, und weiß inzwischen, daß einerseits leider nur noch die wenigsten "kleinen" Hierarchien überhaupt noch aktiv sind, und daß andererseits so Dinge wie Gruppenlisten, Einrichtungsregeln, digital signierte Steuernachrichten etc. pp. in der guten alten Zeit offenbar keine besondere Rolle gespielt haben. Oft genug sind bspw. die Webseiten der früher zum "Individual Network" gehörenden Vereine nicht mehr existent, oder das Angebot - und die Domain - wurde an einen Nachfolger abgegeben, der zwar noch im Internetzugangsgeschäft tätig ist, aber mit Usenet nichts mehr am Hut hat, oder sie wurde "vor kurzem" (bspw. 1998 oder so) aktualisiert. Dementsprechend ist das Web in den meisten Fällen eine sehr schlechte Informationsquelle, aber auch das Usenet und die Newsgroups der jeweiligen Hierarchien erweisen sich nicht direkt als Goldgruben, denn auch dort ist von geposteten Gruppenlisten oder ähnlichen administrativen Dokumenten wenig zu sehen, oder man liest nur davon, daß vor Jahren bereits der bisherige Verantwortliche sein Amt aufgegeben hat und ein Nachfolger nicht in Sicht ist. Der Gruppenbestand variiert teilweise von Server zu Server, und manche Hierarchien scheinen ein "Geisterdasein" zu führen, da die Gruppen zwar auf vielen Servern eingerichtet sind (oft wohl als Folge von Kristian Köhntopps "Regio"-Paket aus der Zeit, als er selbst einen Newsserver betrieb und vielen Neueinsteigern als erster Peer unter die Arme griff), aber die eigentlichen, ursprünglichen "Kernserver" gar nicht mehr existent sind (oder die Gruppen jedenfalls nicht mehr mit ihnen gepeert werden).

Inzwischen habe ich aber sozusagen Blut geleckt und finde es umso wichtiger, für diejenigen, die daran interessiert sind, diese regionale Vielfalt - und sei es nur als wehmütige Erinnerung an die Anfangszeiten des deutschen Netzes - zu erhalten und die wenigen nicht aktiven Hierarchien zu verteilen und zu fördern, die notwendigen Informationen zur Verfügung zu stellen. Ich werde also weiter sammeln und auch aktiv nachforschen und dann das Ergebnis meiner Nachforschungen in geeigneter Weise zusammenstellen. Stay tuned!

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.

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