Aus dem Rechenzentrum

Wer Zugangsdaten zum Abruf von Mails hat, kann damit üblicherweise auch Mails versenden. Das ist bei uns genauso wie bei praktisch allen anderen Providern auch.

Nun wissen wir natürlich nicht, was für ein Client das ist, der sich da via SMTP AUTH an einem unserer Mailserver anmeldet. In diesem Fall ist es kein Desktop-Mailclient, sondern ein Postfix-Mailserver, den der Kunde lokal bei sich betreibt. Sein Desktop-Mailclient verschickt also Mails über Postfix, und Postfix macht dann SMTP AUTH bei uns. Kein Problem, geht.

Schlecht wird es, wenn es um Spam geht. In diesem Fall ist beim Kunden nämlich offenbar ein User-Passwort geknackt worden und dann fleißig Spam über seinen Postfix-Server geschickt worden – der dies dann wiederum brav via SMTP AUTH über uns weitergeleitet hat. Gut, dass in solchen Fällen dann schnell unser Monitoring anspringt, das in diesem Fall feststellte, dass dieser User ungewöhnlich viele Mails verschickt, die dann als zumindest temporär nicht zustellbar in der Mailqueue verblieben. Minuten später war der betreffende Account zum Relaying gesperrt – ein nettes Feature von vpopmail, weil der Abruf von Mails weiterhin problemlos möglich bleibt, nur eben kein Relaying mehr. Die betreffenden Mails haben wir aus der Mailqueue in die Quarantäne verschoben, damit der reguläre Mailbetrieb erstmal weitergehen konnte.

Wir haben für diesen Fall mittlerweile ein vorgefertigtes Schreiben, das wir mit ein paar Log-Auszügen schmücken und das den Kunden sinngemäß zu folgenden drei Punkten auffordert:

1. Teilen Sie uns mit, was genau die Ursache für den Spamversand war
2. Teilen Sie uns mit, was genau Sie unternommen haben, um vergleichbare Vorfälle in Zukunft zu verhindern
3. Bestätigen Sie uns bitte ausdrücklich, dass Sie ihre lokale Mailqueue geleert haben

Ziel ist, sicherzustellen, dass der Kunde wirklich verstanden hat, was das Problem war. Insbesondere Leute, die sich mit Mailserver-Administration auskennen, werden die Hände über dem Kopf zusammenschlagen, wenn sie wüssten, wie häufig wir auf Frage 2 die Antwort „Ich habe einen Spamfilter auf meinem PC installiert“ lesen müssen, was nun eben gerade überhaupt nichts damit zu tun hat, dass man ein Open-Relay-Problem hat. Es liegt uns zwar allgemein fern, Kunden „erziehen“ zu wollen. In diesem Bereich tun wir es trotzdem – freundlich, hilfreich, aber auch konsequent. Spamming ist ein AGB-Verstoß, egal ob der Kunde Urheber des Spamversands ist (sowas resultiert dann auch gleich in einer fristlosen Kündigung) oder Spam „nur“ durchgeleitet hat, oftmals durch Unwissenheit. In diesem Bereich geben wir dann auch durchaus eine zweite Chance, wenn klar ist, dass der Kunde den Vorfall zum Anlass genommen hat, sein System entsprechend abzusichern.

Ursprünglich enthielt das Schreiben nur die ersten beiden Punkte. Den dritten haben wir ergänzt, nachdem es wiederholt vorkam, dass Kunden zwar tatsächlich das ursprüngliche Problem begriffen und auch nachprüfbar behoben hatte – aber noch ein paar tausend bereits entgegengenommene Mails in seiner Mailqueue hatte, die sein Mailserver nach Wiederfreischaltung dann erst nochmal zu verschicken versucht hat.

Es hat also auch durchaus seinen Grund, dass wir die drei simplen Fragen durchnummerieren. Es scheint wirklich schwierig zu sein: Selbst wenn man eindringlich darauf hinweist, dass gegen die AGB verstoßen wurde; dass man andere User mit Spam belästigt hat (und man selbst will ja auch nicht von Spam belästigt werden) – all diese Formulierungen führen regelmäßig trotzdem nicht dazu, dass sich ein Kunde die Zeit nimmt, unsere wirklich nicht übermäßig lange Mail vollständig zu lesen und zu beantworten. Das Durchnummerieren der Fragen hat schon mal dazu geführt, dass ein etwas größerer Anteil von Kunden darauf kommt, dass wir auf drei Fragen vermutlich auch drei Antworten erwarten, aber für etwa ein Viertel alle derart Angeschriebenen liegt das offenbar immer noch nicht auf der Hand – mit der Folge, dass wir Nachfragen müssen, was für den Kunden, der relaytechnisch nun gerade „auf dem Trockenen“ sitzt, auch nicht wirklich so super ist.

Insbesondere nicht für den Kunden von heute. Es entwickelte sich ein längerer Mailaustausch, den ich in anonymisierter und in Umfang und Formulierungen etwas reduzierter Form gerne wiedergeben möchte – ein kleiner Einblick, womit wir uns auch herumschlagen müssen.

Ich: (sende dem Kunden die Hinweismail in puncto Sperrung)

Kunde: „Ich habe den Account meiner Tochter gelöscht und hoffe, dass die Spammails nicht mehr von meinem Account ausgehen. Bitte um Entsperrung, damit wir wieder am normalen Leben teilnehmen können.“

Ich: „Bestätigen Sie mir doch bitte noch, dass Sie auch die Mailqueue Ihres Mailservers gelöscht haben“ (mit nachvollziehbarer Erklärung, warum wir auf dieser Bestätigung bestehen)

Kunde: „Ich bin bei Ihnen, weil ich keine Zeit habe, mich permanent um mein System zu kümmern. Dass jemand Daten hackt, soll vorkommen. Ich habe den Account gelöscht. Was tot ist, kann keine Daten mehr versenden.“

Ich: (… detaillierte Erläuterung, wieso das Löschen eines Accounts etwas ganz anderes ist als das Löschen der Mailqueue … bildlicher Vergleich, dass wenn man den Typen, der die Briefe in den Briefkasten wirft, vom Briefkasten wegschubst, damit ja immer noch die bereits eingeworfenen Briefe bleiben …) – „Ich bitte daher erneut darum, uns ausdrücklich zu bestätigen, dass Sie die Mailqueue Ihres lokalen Mailservers geleert haben.“

Kunde: „Ich habe alles gelöscht. Ich habe alle Postausgangsordner kontrolliert und dort hängt nichts mehr zum Versenden.“

Ich hatte schon so ein ungutes Gefühl. Wäre es um einen Exchange-Server gegangen, hätte ich ja angenommen, das „Postausgang“ eine krude Übersetzung für „Queue“ wäre, aber bei Postfix … aber ich wollte mal nicht so pingelig sein und habe sicherheitshalber die Verarbeitung der Queue des betreffenden Relayhosts bei uns kurz mal gestoppt und erst dann das Relaying wieder freigeschaltet.

Sekunden später prasselten hunderte von Spammails auf uns ein. Gut, dass ich die Mailqueue vorher gestoppt hatte. Also – Account direkt wieder sperren; die frisch eingelieferten Spammails direkt auch wieder in die Quarantäne verschieben, Verarbeitung wieder starten.

So langsam frage ich mich, ob der Kunde überhaupt weiß, dass er einen Mailserver betreibt – und wenn ja, wie das sein kann, dass er selbst aus der überdeutlichen Formulierung „die Mailqueue Ihres lokalen Postfix-Mailservers“ immer wieder lediglich auf den Postausgangsordner seines MUAs kommt. Ich habe nun erstmal ganz konstruktiv vorgeschlagen, dass er doch einfach unsere Infrastruktur für die Ablage seiner Mailboxen nutzen könnte, was ihn ja nicht mal etwas extra kostet und gerade, wenn er im Grunde sowieso keine Zeit für die Administration hat, vermutlich auch die beste Lösung für ihn wäre, um nicht unbeabsichtigt das restliche Internet mit Spam zu belästigen. Erfahrungsgemäß fühlen sich leider oftmals gerade die Kunden, die schon mehr oder weniger objektiv durch ihr Handeln belegt haben, wie wenig sie sich auskennen, ganz besonders auf den Schlips getreten, statt einfach mal zu sagen: Alles klar, ich habe einen Fehler gemacht; was raten Sie mir? Warten wir mal ab, was da kommt.

Nicht, dass ich im Moment nichts Besseres zu tun hätte als zu bloggen. Tatsächlich hätte ich durchaus Besseres zu tun – ich müsste nämlich eigentlich weiter an der clientseitigen Implementierung einer API arbeiten, deren Realisierung sich nun schon seit längerem zieht wie Kaugummi, und die für mich ein – erneutes – Lehrstück ist, dessen Ergebnis @fhemberger so treffend mit Only use SOAP to wash your hands zusammenfasst, wofür ich herzlich danke.

Softwareentwicklung ist nicht unser Kerngeschäft, und von größeren Aufträgen in dem Bereich lassen wir auch typischerweise die Finger – da haben andere ihren Fokus. Häufig geht es aber um vergleichsweise kleine Projekte; oftmals von Agenturen, die das im Prinzip auch selbst könnten, aber aus verschiedenen Gründen (und sei es die wie immer knappe Zeit) an uns auslagern. Da sagen wir dann durchaus nicht nein, vor allem, wenn wir den Kunden und womit er so arbeitet bereits gut kennen.

Woran ich gerade arbeite, ist eine Sache, die sich auf dem Papier im Grunde überschaubar liest – was schließlich auch die Voraussetzung dafür ist, so etwas wie ein verlässliches Angebot abgeben zu können. Gleichzeitig ist es ein gutes Beispiel dafür, warum wir hier künftig wohl verstärkt auf einer Abrechnung auf Stundenbasis pochen werden, denn was uns hier bei einer vergleichsweise einfachen API vorgesetzt wurde, geht auf keine Kuhhaut. Insofern will ich hier auch gar nicht groß über SOAP selbst ranten – schon deshalb nicht, weil es aussichtslos wäre, sich mit dem grandiosen Rant The S stands for Simple messen zu wollen (ja, das ist als Lesebefehl aufzufassen). Nein, hier soll es um die konkrete SOAP-API gehen, mit der ich gerade zu arbeiten gezwungen bin und deren Bezeichnung und Hersteller ich lieber in den Mantel des Schweigens hülle.

Es geht um ein Projekt aus dem touristischen Bereich. Unser Kunde hat eine Datenbank mit Unterkünften (Hotels, Ferienwohnungen, etc.), und eine Unterkunft kann einen oder mehrere Raumtypen haben (z.B. Einzelzimmer, Doppelzimmer, etc.). Mit diesen Daten soll ein Portal gefüttert werden, an das sich unser Kunde gerne angebunden wissen möchte. Die API bietet eine Insert-, eine Update- und eine Delete-Funktion für die Unterkünfte, wobei hier jeweils Raumtypen als Unterelemente übergeben werden können. So weit, so gut – simples CRUD, wobei das R schickerweise weggelassen wurde. Aber damit kann man unter der gegebenen Aufgabenstellung klarkommen.

„Die Schnittstelle ist als SOAP über HTTP realisiert.“

Diesen Satz in der Einleitung zu lesen, ließ mich bereits erschaudern. SOAP ist für mich so ziemlich der Inbegriff von höllischer Bloatware und totaler Überkomplexität. Wer im 21. Jahrhundert normalerweise REST-APIs implementiert und dabei Datenstrukturen in schlanken Formaten wie JSON oder YAML verwendet, der fragt sich bei der Lektüre der SOAP-Spezifikation, was genau die Leute geraucht haben müssen, die sich freiwillig aufhalsen, ihre Datenstrukturen in XML abzubilden, dabei munter Namespaces einzuführen, XML-Schemas zu definieren, diese jetzt schon um etliche Faktoren aufgeblähte Struktur dann noch in einem SOAP-Body zu verpacken und diesen gemeinsam mit einem SOAP-Header in einen SOAP-Envelope zu stecken, der dann unter Zuhilfenahme des zusätzlichen HTTP-Headers „SOAPAction“ (von dem niemand so genau sagen kann, was der soll) an einen HTTP-Server zu schicken, der diesen ganzen Rotz (sorry …) dann erstmal validieren und dann in seine eigene Datenstruktur parsen muss, nur um bei der Antwort den umgekehrten Weg zu gehen.

Von Hand möchte man so etwas in keinem Fall implementieren. Es ist extrem aufwendig und auch fehlerträchtig, weshalb man sich für SOAP noch etwas Besonderes ausgedacht hat: Dienstbeschreibungen in Form von WSDL-Dateien, die vereinfacht gesagt maschinenlesbar dokumentieren, unter welcher URL eine API zu finden ist, welche Funktionen diese API beherrscht und wo man das XML-Schema finden kann, das die Datentypen beschreibt, die man übermittelt und zurückbekommt. Gedacht ist das so, dass man als Entwickler jene WSDL-Datei dem SOAP-Toolkit seiner Wahl zum Fraß vorwirft und jenes damit dann irgendetwas Sinnvolles macht, also z.B. dynamisch oder statisch irgendwelche Klassen generiert, die man dann in der Programmiersprache seiner Wahl mehr oder weniger „nativ“ benutzen kann, ohne sich um den riesigen Bloat hintendran kümmern zu müssen. Soweit die Theorie.

Was ich nun also in der Spezifikation lese, ist „SOAP“. Was ich nicht lese, ist „WSDL“. Ich beginne also schweren Herzens, die entsprechenden SOAP-Aufrufe manuell zu implementieren. Überraschung: Es funktioniert nicht – ich bekomme via SOAP eine sauber formatierte Fehlermeldung, dass es die (dokumentierte) API-Funktion auf dem Server nicht gäbe. Ich stelle eine Supportanfrage an den API-Provider. Ich warte von Dienstag bis zum darauffolgenden Montag auf Antwort und bekomme dann den überraschenden Hinweis: Die URL zur API würde nicht stimmen; ich müsste da noch ein ?wsdl anhängen.

Das ist nun schon mal obskur, denn unter dieser URL kann ich mitnichten die API ansprechen, wie der Mitarbeiter mir mitteilte, sondern erhalte – Überraschung – eine WSDL-Datei zum Download. Klasse, freue ich mich; wenigstens etwas, auch wenn das heißt, dass ich meine bisherige Handarbeit und vor allem die endlosen völlig fruchtlosen Tests umsonst gemacht habe. Ich werfe nun also den Klassengenerator an, der mir anstandslos binnen einer Sekunde ein dickes Bündel fertiger Klassen generiert, mit denen ich die SOAP-API nun bequem ansprechen kann.

Angeblich.

Alles, was ich von der API zurückbekomme, ist eine HTML-(!)-Seite mit dem Hostnamen als Inhalt. Das ist wahrlich keine valide SOAP-Nachricht, und mein Client schmiert entsprechend ab. Ich dokumentiere den kompletten HTTP-Request und die HTTP-Antwort und frage, was hier falsch sein soll; immerhin spreche ich hier die API exakt so an, wie die WSDL-Datei es vorgibt. Es ist immer noch Montag.

Ich warte auf Antwort bis zum darauffolgenden Mittwoch. Also dem Mittwoch eine Woche später. Mir wird mitgeteilt, dass man die Abläufe intern ein wenig umstrukturiert habe und ich nun einen neuen Ansprechpartner für die Schnittstelle hätte. (Ich kann an dieser Stelle schon mal ein wenig in die Zukunft greifen: Immer, wenn ich den neuen Ansprechpartner anschreibe, scheint dieser meine Anfragen intern weiterzuleiten und ich bekomme Antwort vom bisherigen Ansprechpartner. Aber schön, dass wir mal drüber geredet haben.)

Eine weitere Woche vergeht. Dann bekomme ich die überraschende Antwort des neuen Ansprechpartners, ich würde die falsche URL ansprechen. Huh..? entfährt es mir da beim Lesen, denn diese URL habe ich schließlich selbst nirgendwo angegeben – sie entstammt vielmehr direkt der WSDL-Datei des Anbieters. Ich weise freundlich auf diesen Umstand hin und bitte darum, dann doch bitte die WSDL-Datei zu korrigieren. Derweil mache ich das in Handarbeit und ersetze in den automatisch generierten Klassen anschließend manuell die Ziel-URL. Schön ist anders.

Nach einer Woche habe ich immer noch nichts gehört. Ich erlaube mir, vorsichtig nachzufragen, wann ich denn mit der aktualisierten WSDL-Datei rechnen könne. Und ich sende noch ein weiteres Bündel Fragen mit. Dazu gehört beispielsweise, warum Umlaute, die ich korrekt UTF8-kodiert (wie vorgeschrieben) an das Portal übermittle, in jenem Portal falsch dargestellt werden (Unicode! Rocket Science!!). Außerdem erschließt sich mir die Möglichkeit der Übertragung von Textinhalten nicht. Hier gibt die API ein Listenelement vor, mit dem ich mehrere Texte in verschiedenen Sprachen übergeben kann, jeweils klassifiziert durch eine Eigenschaft „language“. Dokumentation und XML-Schema sagen, das sei ein String. Ob ich da nun „Deutsch“, „German“, „de“, „de_DE“ oder was auch immer reinschreiben muss, und analog, was für die englischsprachige Variante dort hin muss. Und ich stelle fest: Von allen übermittelten Textblöcken erscheint immer nur der letzte im Portal – das dann aber unabhängig davon, welche Sprache er hat. Last but not least frage ich zum zweiten Mal nach einem Beispielrequest für das Anlegen einer Unterkunft, der dann vielleicht auch gewisse Anhaltspunkte gibt, was man in diesem oder jenem Element so übermitteln müsste. Die Dokumentation ist da nämlich ziemlich, äh, mau.

Eine weitere Woche geht ins Land. Das mit den Umlauten habe man behoben, teilt man mir mit. Zur WSDL-Datei weiß man überraschend zu sagen, dass „eine Aktualisierung zur Zeit nicht geplant sei“. Ähm – sie ist falsch, aber eine Aktualisierung ist nicht geplant? Na vielen Dank auch. In Sachen Textfeld weiß ich nun, dass hier „de“ erwartet wird – erfahre aber auch gleich, dass die Übermittlung von Texten in mehreren Sprachen derzeit nur in Planung ist, ergo gar nicht funktioniert. Und Beispiele gebe man „eigentlich“ nicht raus, „da die relevanten Informationen in der Dokumentation beschrieben sind und die Umsetzungen in der Praxis sehr unterschiedlich ausfallen können“. Ich staune und interpretiere das als Bitte, mich dann eben bei jeder weiteren Kleinigkeit, bei der ich nicht unbedingt einfach nur raten will, was denn die API erwartet (weil die Dokumentation dazu eben so gut wie nichts enthält), dann eben den Support zu nerven. Zudem frage ich mich, was dieses „eigentlich“ zu bedeuten hat. Hinter einem „eigentlich“ erwarte ich eigentlich (haha) so etwas wie „… aber für Sie mache ich mal eine Ausnahme“. Macht man aber nicht. Das Beispiel bleibt aus.

In puncto „Angabe der Sprache“ gab man mir nebenbei recht – man habe die Dokumentation entsprechend überarbeitet, und mir wurde eine „aktualisierte Version“ zugeschickt. Die aktualisierte Version enthält nun tatsächlich einen entsprechenden Hinweis – während die auf dem Titel genannte Versionsnummer aber identisch zur vorherigen ist, ebenso hat sich die Datumsangabe nicht verändert, und die Dokumenthistorie, die ein separates Kapitel darstellt, weiß auch nichts von diesem überraschenden neuen Release der Dokumentation.

Der nächste Tag bricht an.

Ich arbeite weiter und führe mir die API-Funktion zu Gemüte, mit der ich mir die Eigenschaften von Unterkünften und Zimmertypen abrufen kann. Diese Eigenschaften können nämlich im Sinne einer ordentlichen Kategorisierung nicht als Freitext, sondern nur als numerische Felder übergeben werden – okay, kann ich verstehen. Worüber ich mich nur wundere: Alle Umlaute sind kaputt. Ja, was zum … nun, nachdem ich zur Sicherheit einen tcpdump des HTTP-Datenstroms gemacht habe, ist definitiv klar: Das ist nicht meine Schuld. Die API selbst liefert die Umlaute als vier Bytes – klarer Fall von „doppelt kodiert“. Unicode! Rocket Science!! Aber das ist noch nicht alles. Die Funktion, die mir die Eigenschaften zurückliefert, schmeißt nämlich munter am Ende immer noch ein leeres Eigenschafts-Element mit raus (was laut XML-Schema nicht leer sein darf, weil alle Child-Elemente mandatory sind) und verpasst diesem und dem vorletzten Element noch XML-Attribute, die im XML-Schema überhaupt nicht vorkommen. Soll heißen: Was mir die API zurückliefert, validiert nicht gegen das eigene XML-Schema des Anbieters. Ich baue also einen Filter ein, der ungültige Eigenschaften und leere Elemente rausfiltert, und baue ein zusätzliches decode_utf8 mit ein, um der doppelten Umlautkodierung Herr zu werden. Und, natürlich, ich frage den Support.

Unabhängig von der API eröffnet sich hier das nächste Problemfeld. Auch in der lokalen Datenbank gibt es nämlich Eigenschaften von Unterkünften und Zimmern, und auch hier werden diese durch Mappings zwischen ID und Beschreibung hergestellt. Für die letztlich benötigte Zuordnung von ID zu ID muss ich also anhand der Beschreibung matchen – und schon ein schneller Blick verrät: Was hier ein „Aufzug“ ist, ist dort ein „Lift“. Was hier „Haustiere“ sind, heißt dort „haustierfreundlich“. Bei einigen hundert möglichen Eigenschaften zeichnet sich jetzt schon ab, dass nicht unerhebliche Zeit nicht nur fürs Programmieren, sondern auch für das manuelle Mappen inhaltsgleicher Eigenschaften draufgehen wird. Ich freu mich. Ein Mitarbeiter meines Kunden schreibt flugs ein kleines Webinterface und übernimmt dankenswerterweise das Begriffs-Mapping. Aber das nur am Rande, während ich auf Antwort auf meine Frage warte, wie ich mit der nicht gegen das eigene Schema validierenden XML-Antwort verfahren soll.

Ich warte über zwei Wochen auf die Rückmeldung, die überzähligen XML-Elemente und -Attribute solle ich doch bitte einfach ignorieren. Warum man unter diesen Maßgaben sich dann überhaupt die Mühe macht, ein XML-Schema zu schreiben, ist mir schleierhaft. Auf meinen Hinweis, dass die API die Eigenschaften entgegen der Dokumentation nicht in UTF-8 liefert, sondern in fälschlicherweise doppelter Kodierung, wird nicht eingegangen. Das Problem ist auch heute – Wochen später – nicht behoben.

Beim Mapping der Eigenschaften stellt sich heraus, dass einige wichtige Eigenschaften fehlen, und mein Kunde bittet den Anbieter, diese in seiner Eigenschaftsliste nachzupflegen. Wieso, heißt es da – die sind doch da. „Ich hab’s grad probiert“. Ich teste selbst erneut. Die Eigenschaften sind nicht da. Ins Blaue hinein starte ich diese Read-Only-Abfrage auf dem Produktivsystem und stelle überrascht fest: Hossa! Das Produktivsystem des Anbieters kennt viel mehr Eigenschaften als das Entwicklungssystem … darunter auch die benötigte. Ich baue in mein Tool eine Funktion ein, die das Lesen der Eigenschaftslisten auf dem Produktivsystem macht, das Hinzufügen, Ändern und Löschen von Unterkünften aber auf dem Testsystem, denn davon, die API produktiv zu nutzen, sind wir noch weit entfernt.

Nachdem ich die Eigenschaftsliste vom Produktivsystem abgefragt habe, aktualisiere ich meine Mappings und starte einen erneuten Durchlauf. Was zum..?! Nun sind im Portal wieder Umlaute kaputt, aber nur bei den Eigenschaften, nicht bei den sonstigen Daten einer Unterkunft. Und sie sind anders kaputt – statt doppelt kodiert sind sie nun sozusagen „halb kodiert“. Ich stelle entsetzt fest, dass das Produktivsystem die Umlaute korrekt zurückliefert – ganz im Gegensatz zum Testsystem, für das ich extra das zusätzliche decode_utf8 eingebunden hatte. Also baue ich das wieder aus, denn die Eigenschaftsliste werde ich ja sowieso nie wieder vom Testsystem abrufen, weil die ja unvollständig ist. Als ich mir testweise den HTTP-Trace vom Produktivsystem anschaue, stelle ich fest, dass der Unterkunftstyp „Hütte“ gleich doppelt vorhanden ist, mit zwei verschiedenen IDs. Mit einem fixen SQL-Statement finde ich auch gleich noch weitere Redundanzen. Das kann ja heiter werden.

Derweil beschäftige ich mich mit der Funktion der Zimmertypen. So, wie ich eine komplette Unterkunft mit Hilfe der Update-Funktion anhand der ID, die ich beim Insert zurückbekommen habe, aktualisieren kann, so kann ich auch die Zimmertypen einer Unterkunft aktualisieren. Ich kann aber auch nur das. Das Entfernen von Zimmertypen ist schlicht nicht vorgesehen. Ich kann zwar Zimmertypen hinzufügen; das geht wohl – dabei erfahre ich aber nicht die vom API-System vergebene ID für jenen Zimmertyp. Den gibt’s laut Spezifikation nämlich nur beim Insert einer Unterkunft; da werden dann die IDs der mit übermittelten Zimmertypen gleich mitgeliefert. Mache ich später jedoch ein Update auf eine Unterkunft, ist das nicht der Fall. Soll heißen: Ich bekomme einen zusätzlichen Zimmertypen zwar ins System. Ich kann ihn dann anschließend aber nie wieder ändern – weil ich ja seine ID nie erfahre. Löschen geht genausowenig. Weder mit noch ohne ID. Die Zimmertypenliste ist append only. Wer bitte denkt sich sowas aus?

Die einzige Möglichkeit, die Liste der Zimmertypen nachträglich zu verändern (also nicht die Eigenschaften der Zimmertypen, sondern eben das Hinzufügen oder Entfernen von Zimmertypen) ist insofern, die komplette Unterkunft zu löschen und neu anzulegen. Klar, das geht. Aber …

So eine Unterkunft kann auch Bilder haben. Für diese Bilder übermittele ich entsprechende URLs. Diese werden dann aber nicht etwa im Portal einfach „as is“ eingebunden, sondern das Portal ruft die Bild-URLs ab und speichert diese lokal auf dem Portal-Webserver. Synchron. Synchron heißt: Wenn ein Hotel es nun wirklich gut meint und fünf Außenansichten, fünf Innenansichten und für jeden der vier Zimmertypen noch fünf Innenansichten von Zimmern bereitstellt, dann haben wir 30 Bilder – und mein API-Aufruf mit dem Insert oder dem Update muss warten, bis der Portal-Webserver alle diese Bilder heruntergeladen hat. Na, die werden sich freuen, wenn wir erstmalig die ersten paar hundert Unterkünfte, alle jeweils mit Fotos, in deren System einpflegen … hoffentlich haben die dann Traffic flat.

Kann man die Verarbeitung von Bildern in einer API noch ineffizienter gestalten? Aber sicher, da geht noch was. Sobald die Bilder nämlich abgerufen sind, vergisst die API die Original-URLs. Wenn ich also zu einem späteren Zeitpunkt eine Unterkunft erneut übermittle, zum Beispiel, weil sich die Telefonnummer geändert hat, dann werden alle verknüpften Bilder erneut vom Quellsystem abgerufen. Wenigstens ein „If-Modified-Since“ hätte es doch vielleicht sein dürfen, aber … Fehlanzeige.

Durch Trial and Error finde ich heraus, dass man beim Aktualisieren der Unterkunft offenbar nicht alle Elemente mitschicken muss und das Weglassen eines Elements im Fall der Bilder dafür sorgt, dass die bestehende Bilderliste unverändert bleibt – also die Bilder auch nicht erneut abgerufen werden müssen. Das ist ja schon mal etwas. Im Gegensatz zur Liste der Zimmertypen ist die Liste der Bilder aber nicht append only – übermittle ich hier ein neues Bild, ersetzt das komplett die bisherige Bilderliste. Möchte ich also 30 Bilder um ein Bild Nr. 31 ergänzen, muss ich folglich dann doch wieder alle 31 Bilder übermitteln – die dann auch alle 31 erneut abgerufen werden. Das Übermitteln einer leeren Bilderliste (wo also das XML-Element nicht weggelassen wird, sondern schlicht ohne Child-Elemente übermittelt wird), führt dann überraschenderweise aber nicht zum Löschen aller bestehenden Bilder. Es gilt also: Eine Unterkunft, die einmal Bilder hatte, kann nie wieder gar keine Bilder mehr haben. Mindestens eins muss es dann schon bleiben. Gerade im Hinblick darauf, wie sich die API in Bezug auf die Zimmertypen verhält, fehlt mir hier jegliche Berechenbarkeit. Unnötig anzumerken, dass die Dokumentation mit keiner Silbe Bezug auf die unterschiedliche Handhabung dieser beiden Listen nimmt.

Nun versuche ich heute abend, mit einem dicken Bündel Workarounds und jeder Menge Klimmzüge weiterzuarbeiten. Ich starte damit, nach dem heutigen Support-Mailverkehr zunächst die Kategorieliste zu aktualisieren und wundere mich darüber, dass genau null Kategorien gefunden wurden. In einer zweiten Konsole habe ich den tcpdump-Aufruf für den HTTP-Trace noch griffbereit. Überraschung: Während das Testsystem weiterhin eine unvollständige Liste von Eigenschaften mit fehlerhaften Umlauten liefert, liefert das Produktivsystem nun gar keine Liste von Eigenschaften mehr. Der API-Key wird akzeptiert (ein bewusst falsch gesetzter API-Key provoziert korrekt einen SOAP-Fault), aber das Listenelement in der Antwort ist leer.

Die ursprüngliche Implementierung hatte ich gegenüber dem Kunden mit ca. 6-8 Stunden Umsetzungsdauer angegeben. Inzwischen zieht sich das Projekt seit Wochen hin, was nicht zuletzt dem Umstand geschuldet ist, dass der Support des API-Anbieters wiederholt extrem lange braucht, selbst sauberst mit HTTP-Traces dokumentierte Probleme auf dem Niveau von „Also, bei mir geht’s …“ zu beanworten und offensichtliche Fehler, die auch nichts mit fehlerhafter Bedienung oder schlechter Dokumentation zu tun haben, einfach überhaupt nicht zu fixen. Möglicherweise um den anderen API-Nutzern, die hierfür schon jeweils eigene Workarounds gebaut haben, nicht ihre Systeme kaputtzumachen.

6-8 Stunden also. Veranschlagt. Die realen Stunden belaufen sich entsprechend meiner Arbeitsprotokolle mittlerweile auf 15 – das Verfassen dieses Blogposts selbstverständlich nicht mit eingerechnet. Den gibt’s gratis obendrauf.

Mein persönlicher Rat? Wenn der Begriff „SOAP“ fällt – lauft. Lauft, so weit ihr könnt. Nicht nur, weil das Protokoll den krudesten API-Standard darstellt, der mir in den letzten Jahren untergekommen ist (wobei, nein, da muss ich mich korrigieren – dieser Preis gebührt wohl UCP, mit dem ich für einen anderen Kunden den Versand von SMS implementieren durfte), sondern auch, weil der Einsatz von SOAP nach meiner Erfahrung schon fast als Garant dafür anzusehen ist, dass man es auf der gegenüberliegenden Seite mit Leuten zu tun hat, die sich der Tragweite der Protokollwahl nicht im Geringsten bewusst sind.

Manchmal begegnen einem auch im Alltag lustige Softwarefehler in fremden Geräten – so wie mir neulich bei den Fahrkartenautomaten der Mainzer Verkehrsgesellschaft (MVG): Die Automaten verrechnen sich, ganz profan, und zwar immer dann, wenn man mit ec-Karte bezahlt.

Dabei traue ich mich kaum, das als „Angriff“ zu bezeichnen, denn die Sache war so trivial, dass sie mir schlicht und einfach versehentlich passiert ist: Die MVG-Automaten bieten, wie viele andere auch, die Möglichkeit, über einen Button „Weitere Fahrkarten“ mehrere Tickets in eine Art Warenkorb zu legen und diesen dann gesammelt zu bezahlen. Der Haken war: Sobald man ec-Karten-Zahlung wählte, wurde nur der Preis der ersten Fahrkarte an das ec-Terminal übertragen. Ich kaufte also Sammeltickets (5 Tickets auf einmal zum vergünstigten Preis), und weil ich die öfter nutze, gleich 2 x 5. Als das ec-Terminal nur den Preis für 5 Tickets zeigte, war ich schon leicht genervt, weil ich davon ausging, jede Abbuchung einzeln bestätigen zu müssen. Aber weit gefehlt: Nach Buchung des Betrags für 5 Sammeltickets spuckte der Automat direkt 10 Tickets aus und wünschte mir noch einen schönen Tag. Was zum..? Ich hab’s gleich noch einige Male versucht, diesmal aber entsprechend ohne die Buchung durchzuführen; ich wollte nur sehen, welchen Betrag das ec-Terminal anzeigte. Reproduzierbar handelte es sich nur um den Preis für die jeweils erste Fahrkarte, egal wie viele ich buchen wollte.

Ich teile hierbei nicht die Meinung von @amokleben, dass sowas (unmittelbar) publik gemacht gehört, sondern halte es mit @fabianonline, dass eine Publikation erst dann erfolgen sollte, wenn der Bug behoben wurde oder das Verkehrsunternehmen nicht reagiert – ganz im Sinne von Responsible disclosure. Jedenfalls würden wir uns dieses Vorgehen in Bezug auf potentielle Probleme bei uns genauso wünschen – zumal durch verfrühte Veröffentlichung dem Verkehrsunternehmen potentiell finanzieller Schaden entstanden wäre, für den ich durchaus nicht hätte geradestehen wollen. Praktischerweise sichert die MVG im Rahmen ihrer Kundengarantien zu, jegliche Anfragen innerhalb von spätestens 10 Werktagen zu beantworten, womit dann auch direkt der Rahmen gesteckt war, den ich abzuwarten bereit war. Nun denn, so verfasste ich mal einen etwas ungewöhnlichen Bugreport, ganz ohne Ticketsystem, aber wie sich das gehört mit Dokumentation und entsprechenden Belegen.

Heute kann ich erfreut vermelden, dass die MVG einen guten Job gemacht hat. Erstens wurde der Vorgang vernünftig eskaliert, und ich bekam – weil anzunehmen war, dass die Fehlerbehebung noch etwas Analyse der entsprechenden Fachabteilung bräuchte – eine Zwischenmeldung mit dem Bearbeitungsstand. Vor wenigen Tagen erhielt ich dann schließlich die Rückmeldung: Die von mir bereitgestellten Daten bezüglich der Buchung und der Seriennummern der Fahrkarten seien eine große Hilfe bei der Analyse gewesen; der Fehler habe nun behoben werden können – und ein Check meinerseits an zwei verschiedenen Automaten konnte dies auch bestätigen. Prima!

Die zweite Charge Sammeltickets, für die ich ja nun nichts bezahlt hatte, wurde mir denn auch als kleines Dankeschön direkt geschenkt – eine nette Geste, über die ich mich sehr gefreut habe und die, wie ich finde, auch dazu motiviert, im Zweifelsfall lieber einmal konstruktiv einzugreifen, statt sich monatelang heimlich mit erschlichenen Tickets auszustatten.

Da ich zum Teil immer wieder darauf stoße und gelegentlich danach gefragt werde, hier mal mein gesammeltes Wissen über Swap unter Linux. Wie immer bei sowas gilt: YMMV.

Was ist der Sinn?

Hin und wieder begegnen mir Mißverständnisse darüber was Swap eigentlich ist: es ist zusätzlicher Arbeitsspeicher, man spricht auch von Virtuellem Speicher (wobei der Begriff eigentlich nicht korrekt ist), in Windows-Sprech würde man es Auslagerungsdatei nennen.

Für Swap gibt es zwei Anwendungsfälle:

1. ) Wenn dem Kernel mal akut der freie RAM zur Neige geht weil zu viele Prozesse laufen, dann müßte er normalerweise irgendwann anfangen Prozesse abzuschießen. Das ist dann für den Prozess und vor allem die von ihm verwalteten Daten mit hoher Wahrscheinlichkeit unangenehm. Hat der Kernel aber Swap zur Verfügung, kann er erstmal dorthin Pages aus dem RAM auslagern. Der Nachteil ist, daß das System ab diesem Moment langsam wird, denn die Zugriffszeiten selbst schneller Festplatten können nicht mit denen von echtem RAM konkurrieren. Der Server der also ohnehin schon in den Seilen hängt, beginnt dann in die Knie zu gehen, aber immerhin ist er noch nicht K.O. Man erreicht also, daß der Kernel noch ein paar Minuten länger durchhält bevor er Prozesse abschießen muß, damit man z.B. als Admin vielleicht noch eine Chance hat sich einzuloggen, nachzuschauen was los ist und die Ursache zu bekämpfen.

2.) Selbst bei gut geschriebenen Programmen ist es kaum zu vermeiden, daß sie mehr Speicher belegen als pro Benutzung eigentlich gebraucht wird (außer vielleicht bei Programmen die nur einzelne Kleinstaufgaben erledigen). Das hängt auch oft davon ab, welches Nutzerverhalten auftritt: wer etwa ein Videoschnittprogramm benutzt um nur eine Tonspur zu schneiden, braucht die Videoroutinen nicht, wer Evolution offen hat und nur IMAP nutzt, braucht die POP3-Routinen nicht, wer LibreOffce nutzt um Briefe zu schreiben, braucht keine Tabellenkalkulations-Routinen usw., wer Linux ohne X11 auf einem Server betreibt, braucht die ganzen Routinen für die graphische Benutzeroberfläche nicht und wer ein Virtuelles System laufen läßt, braucht in diesem nicht in der inittab sechs Konsolen mit mingetty aufzumachen, weil durch die Virtualisierung eh nur eine einzelne angesprochen wird. Nun kann der Kernel anhand der Speicherzugriffe eines Programmes erkennen welche Teile des ihm zugewiesenen Speichers ein Programm nicht braucht und diese dann in den Swap bewegen. Zu einem gewissen Grad kann der Kernel das manchmal sogar antizipieren. Bei Programmen die lange inaktiv sind, kann der Kernel sie auch komplett für die Dauer ihrer Inaktivität in den Swap bewegen, wenn er sie von dort zurück holt ist das immer noch schneller als wenn das Programm neu gestartet würde, da es im Swap ja bereit so vorliegt daß es 1:1 in den RAM kopiert werden kann (davon profitieren am stärksten Programme in Skriptsprachen, die nicht nochmal durch den Interpreter oder Just-in-time-compiler müssen — außer bei Java, das diesen Mechanismus anscheinend aushebelt).

Linux-Distributionen bevorzugen (anders als Windows und MacOS X) beim Swap (wie die meisten unixoiden Betriebssysteme) die Verwendung von Partitionen statt von Dateien. Wobei dies mittlerweile eher aus Tradition geschieht denn aus technischer Notwendigkeit. Man kann durchaus auch Swapfiles benutzen (siehe unten). In jedem Fall wird die Größe des Swap unter Linux vorher festgelegt, Linux kann nicht (wie z.B. Windows oder MacOS X) dynamisch weitere leere Bereiche auf der Festplatte als Swap appropriieren, wenn auch der Swap zur Neige geht. (Das ist eine gute Sache, sonst hat man irgendwann das Problem, daß nicht nur der Swap voll ist, sondern auch das Dateisystem und dann geht’s wirklich bergab.)

Größe

Es ist erstaunlich wie lange sich alte Faustregeln wie „der Swap sollte vier mal so groß sein wie der RAM“ halten, sie sind einfach nicht tot zu kriegen. Zunächst einmal: Ein System mit i386er Architektur kann nicht mehr als 4 GiB Speicher adressieren, egal ob es sich um RAM oder Swap handelt. Einem i386er-System mit 2 GiB RAM ganze 8 GiB Swap zu verpassen, ist weitgehend nutzlos.

Bei Systemen mit x86_64er Architektur stellt sich die Sache deutlich anders da, hier könnte man komplette Festplatten als Swap verwenden. Adressierbar sind mit den meisten Speicherkontrollern 256 TiB (Tebibyte, entsprechend einem 48 Bit Adressraum), da der Speicherkontroller mit dem Swap jedoch nichts zu tun hat, könnten dank 64-Bit-Adressraum der Architektur theoretisch sogar 16 EiB (Exibyte) genutzt werden — also weit mehr als selbst große Festplatten oder RAID-Systeme heutzutage bieten (wobei soweit ich weiß noch kein gängiges Betriebssystem wirklich bereit ist die vollen 64 Bit zu nutzen). Das alles ist jedoch eine rein theoretische Geschichte, denn niemand will, daß sein System Gibibyte-weise Swap rausschreibt. Auch hier sind 4 GiB mehr als genug, meiner Erfahrung nach genügen meist sogar 2 GiB, wenn mehr als 4 GiB RAM vorhanden sind.

Partition oder Datei?

Ja Gretchen, wie halten Sie es denn mit dem Swap? Es ist letztlich eine Glaubensfrage. Viele altgediente Linux-User bestehen auf Swap-Partitionen und lehnen Swapfiles kategorisch ab. Früher ging der Linux-Kernel mit mit Swapfiles deutlich ineffizienter um als mit Partitionen, dies ist aber schon lange nicht mehr der Fall.

Das verbleibende Hauptargument für eine Swap-Partition ist, daß sie kontinuierlich ist und somit nicht fragmentieren kann. Nun ist Fragmentierung bei Linux nicht so schlimm und große Dateien sind in Dateisystemen die in Extends strukturiert sind immer ein bißchen fragmentiert. Starke Fragmentierung kann aber auch unter Linux negative Auswirkungen auf die Performance haben, wovon jeder MySQL-Admin der InnoDB einsetzt ein Liedchen singen kann. (Dateien zu defragmentieren ist bei Linux übrigens ziemlich knifflig, da etwa für ext2, ext3, ext4 und ReiserFS kaum Defragmentierungs-Tools existieren und einem in Foren und auf Mailinglisten auch eher ein wenig hilfreiches, kategorisches „Linux braucht nicht zu defragmentieren“ entgegenschallt — auch wenn das natürlich nicht immer stimmt.)

Geringe Fragmentierung eines Swapfiles wäre also wie gesagt nicht schlimm und das gute an einem Swapfile mit seiner fixen Größe ist, daß er nicht nachträglich fragmentieren kann, denn er wird ja nicht größer. Hier muß man jedoch aufpassen: Bei Dateisystemen die Copy-on-Write verwenden (BtrFS, ZFS, kurz: die Zukunft) können Swapfiles wieder fragmentieren. Bei diesen Dateisystemen kommen außerdem noch Checksummen zum Einsatz, um Silent Data Corruption (etwa durch ein umgefallenes Bit auf einer Festplatte) zu erkennen und zu behandeln. Auf so einem Dateisystem sind Swapfiles nicht sinnvoll.

Also wer ein Dateisystem ohne Copy-on-Write und extensives Checksumming verwendet, kann sich die Mühe beim Partitionieren sparen:

# dd if=/dev/zero of=/swapfile0 bs=1k count=2097152
# mkswap /swapfile0
# swapon /swapfile0
# echo "/swapfile0 swap swap defaults 0 0" >> /etc/fstab

Die Zahl die man bei dd hinter count= eintragen muß richtet sich danach, wie groß die Datei sein soll. Hier wurde 2048 * 1024 (1k) gerechnet, also 2 GiB.

Swappiness

In den meisten Fällen swappt Linux nicht so rasch wie einige andere Betriebssysteme. MacOS X z.B. swappt meist schon beim Booten, allerdings weniger aus Mangel an RAM, sondern vielmehr weil XNU (der MacOS X Kernel) versucht präemptiv zu swappen, also allozierten Speicher der mit hoher Wahrscheinlichkeit nicht oder nur selten genutzt werden wird frühzeitig in den Swap zu bewegen und so den RAM länger frei zu halten. Linux kann das auch, ist da aber deutlich zurückhaltender.

Linux hat allerdings eine Neigung seinen RAM schnell zu füllen und das liegt daran, daß Linux bestimmte Daten die es immer wieder braucht oder von denen es erwartet sie zu brauchen schonmal im RAM zwischenspeichert. In der Ausgabe von free taucht dies dann als +/- buffers/cache auf. Bevor Linux anfängt zu swappen wird es oft diesen Speicher erstmal wieder frei schaufeln (sofern dies sinnvoll ist).

Wie Swap-freudig Linux ist läßt sich justieren und das ist sogar recht wichtig, wenn man Linux auf Servern einsetzen will. Die meisten Linux-Distributionen sind nämlich für den Desktop-Einsatz optimiert und das heißt, daß die Swap-Freudigkeit (swappiness) des Kernels dort relativ hoch ist. An einem Desktop sitzt ja auch ein Benutzer der bemerkt wenn der Rechner langsamer wird und sich dann denken könnte, daß er vielleicht zu viele Programme offen hat und dann anfangen könnte, welche zu beenden. An einem Server sitzt aber meist niemand, also kann es sinnvoll sein hier die Swappiness runter zu drehen.

Typische Default-Werte für die Swappiness sind heutzutage 60 oder 70. Die Skala reicht von 0 (swappe nur wenn es nicht anders geht) bis 100 (swappe beim geringsten Anlaß). Was man hier bevorzugt, muß man selbst entscheiden. Es kann durchaus eine gute Idee sein, hier mit hohen Werten zu arbeiten, um im Normalbetrieb ungenutze Speicherseiten großer Programme aus dem RAM zu bekommen. Auf einem Server kann Swap nützlich sein, oder gänzlich unnütz. Je nachdem kann man den Wert hoch oder niedrig einstellen. Ich persönlich bevorzuge auf Laptops (dort nehme ich immer langsame, stromsparende Festplatten) und Servern Werte von 30 bis 0 (auf Servern schalte ich immer alles ab was nicht gebraucht wird, das spart oft schon genug RAM). Es kann aber auch auf Servern sinnvoll sein hohe Werte zu verwenden, wenn man viele schlafende Prozesse hat, die die meiste Zeit nur RAM belegen.

Um die Swappiness einzustellen muß man bei den meisten Distributionen die /etc/sysctl.conf editieren und dort z.B. folgendes eintragen:

# Use swap only if it is absolutely neccessary
vm.swappiness = 0

Die Änderungen werden nach einem Neustart wirksam, alternativ kann man auch die sysctl.conf neu einlesen lassen oder den Wert selbst einmalig in /proc/sys/vm/swappiness schreiben.

RAID?

Man kann natürlich auch auf RAID-Devices swappen, aber es ist nicht sinnvoll. Die Ausfallsicherheit oder gar Redundanz die man etwa bei einem RAID-1, RAID-5, RAID-6 oder RAID-10 gewinnt, bringen einem bei Swap überhaupt nichts, denn die Informationen in einem Swap braucht man nicht wiederherstellen, sie sind flüchtig. Ein RAID-1 würde allenfalls beim Lesen aus dem Swap etwas Tempo bringen, aber beim Schreiben bringt es keinen Gewinn, ähnliches gilt für RAID-10. Bei einem RAID-5 und RAID-6 muß zusätzlich die Berechnung der Paritätsinformation erfolgen, was das ganze weiter verlangsamt.

Und um gleich noch mit diesem Mythos aufzuräumen: RAID schützt nicht davor, daß auf der Festplatte Bits umkippen, die meisten RAID-Systeme können so etwas zwar erkennen, aber sie können es leider nicht behandeln (ein RAID-1 mit zwei Platten z.B. kann nicht erkennen, welcher der zwei Blöcke der richtige oder falsche ist). Wenn in benutzem Swap ein Bit umkippt, dann hat das die gleichen Konsequenzen, als wenn das im RAM passiert: das Programm oder sogar das Betriebssystem stürzt ab. Kein RAID-Level kann das zuverlässig verhindern, man kann sich mit Swap keinen Pseudo-ECC-RAM bauen. Da Daten aber selten lange im Swap liegen, ist die Wahrscheinlichkeit eines Bitflips äußerst gering, da sowas meist eher in Bereichen auftritt in denen sehr lange nicht auf die Platte geschrieben wurde.

Das einzige was bei Swap etwas bringen würde wäre ein RAID-0, bei dem man ein bißchen Performance gewinnt. Hier muß man sich aber nicht die Mühe machen, einen RAID-0 zu konfigurieren (der auch RAM belegt), das kann das Swap-Subsystem selbst und viel effizienter, indem man einfach zwei Swaps auf zwei Festplatten anlegt und sie mit gleicher Priorität einbindet (was zur Folge hat, daß beide gleichmäßig genutzt werden), z.B.:

/dev/sda3 swap swap defaults,pri=1 0 0
/dev/sdb3 swap swap defaults,pri=1 0 0

SSD?

Oh du liebe Zeit, nein!

Nein.

SSDs sind zwar gehörig schneller als Festplatten mit drehenden Scheiben, aber sie verkraften nur eine begrenzte Anzahl von Schreibzyklen. Auf eine SSD zu swappen ist ein sicherer Weg die teuren Dinger schnell abzunutzen. Wenn SSDs irgendwann mal billig sind (oder Geld kein Problem darstellt), dann kann man sicherlich darüber nachdenken, aber im Moment wäre es echt noch schade drum. (Derzeit kostet das Gigabyte Festplattenspeicher um die 3 Cent, das Gigabyte SSD-Speicher zwischen 1 und zwei Euro.)

Das Hauptproblem ist aber ein anderes: Wohl kaum jemand wird eine SSD erwerben und sie ausschließlich aus Swap verwenden. Das wäre aber das einzig sinnvolle. Man kann auf SSDs durchaus swappen, aber wenn man es tut, dann sollte der Rechner die SSD auch abnutzen dürfen. Den meisten dürfte es aber nicht schmecken, wenn durch die Abnutzung von 4 GiB Swap auf einer wesentlich größeren SSD auch der restliche Speicher auf dieser SSD kaputt gemacht wird, was aber leider der Fall wäre. Also wenn man auf eine SSD swappt, dann sollte man vielleicht doch lieber eine kleine nehmen, die dann nur für den Swap da ist und sich nicht seine 3.000 Euro teure 1T B SSD mitsamt allen anderen schönen Daten drauf ruinieren.

Vor kurzem rauschte eine Meldung durch den Online-Blätterwald: Sicherheitslücke beim Online-Speicher Dropbox lauteten beispielsweise die reißerischen Titel.

Ich komme da nicht ganz mit. Unter einer Sicherheitslücke verstehe ich klassischerweise einen Umstand, der es Leuten ermöglicht, ohne Authentifizierung Dinge zu tun, für die sie sich normalerweise anmelden müssten. Genau das ist hier aber nicht der Fall – vielmehr geht es um etwas viel Einfacheres: Es geht um die Erschleichung eines Zugriffs durch den Klau von Authentifizierungsdaten. Das ist, um’s mal vorsichtig zu sagen, ein alter Hut und auch kein Dropbox-spezifisches Problem. Jeder, der auf seinem Rechner irgendwo Passwörter gespeichert hat, sei es im Browser, sei es in einem FTP-Client, unterliegt einer völlig vergleichbaren „Sicherheitslücke“: Wer in jenen Rechner einbricht und diese Daten kopiert, hat damit Zugriff auf die Accounts des betreffenden Users. Gleiches gilt beispielsweise auch für Cookies: Wer einen Cookie stehlen kann, stiehlt damit implizit auch den Zugang, der hypothetisch hinter diesem Cookie steht. Viele Cookies dienen ja dazu, jemanden im Lauf einer Session wiederzuerkennen, ohne dass er sich für jeden Seitenaufruf erneut identifizieren muss – der Cookie ersetzt also die Authentifizierung mit Username und Passwort. Insofern halte ich das für hanebüchen, die „Entdeckung“ als „Sicherheitslücke“ zu bezeichnen.

Im Grunde passen Cookies sogar als noch besserer Vergleich zu Dropbox als abgespeicherte Passwörter. Die Authentifizierung bei Dropbox funktioniert nämlich so, dass man bei Einrichtung des Clients auf einem Rechner seine Dropbox-Zugangsdaten angibt, der Client authentifiziert sich damit und besorgt sich eine sogenannte Host-ID. Diese wird dann abgespeichert und dient dann künftig – anstelle der Zugangsdaten – als Authentifizierung. Der „Angriff“ basiert darauf, die Datei zu klauen, in der die Host-ID steht. Insofern entspricht das Verfahren exakt dem Vorgang, sich an einer Website mit Username und Passwort anzumelden, die eine Option „[X] angemeldet bleiben“ bietet und daraufhin einen Cookie setzt, der eine lange Gültigkeit hat oder sogar nie verfällt: Die ursprünglichen Zugangsdaten werden ersetzt durch einen anderen Authentifizierungsmechanismus, der unabhängig von den Zugangsdaten besteht. Den Cookie kann ein Trojaner stehlen – und damit die Identität des Bestohlenen.

Und auch in einem weiteren Punkt gleicht die Dropbox-Authentifizierung Cookies: Der Sicherheitsexperte, der die „Lücke“ aufdeckte, verweist nämlich darauf, dass nicht einmal das Ändern des Passworts helfen würde, denn: Das wirkt sich nicht auf die Host-ID aus, die völlig eigenständig als Authentifizierung dient. Man könnte also sogar formulieren: Man braucht die Anmeldung mit Benutzername und Passwort nicht zur Nutzung der Dropbox, sondern lediglich zur Generierung der Host-ID; am Webinterface analog dazu zur Generierung des Cookies.

Benutzern muss doch klar sein, dass, wenn sie ihren Rechner rebooten, ihr Smartphone aus- und wieder einschalten … dass, wenn dann trotzdem der Zugriff auf die Dropbox auf „magische“ Weise immer noch ohne Eingabe irgendwelcher Zugangsdaten funktioniert, irgendeine Art von Authentifizierung hinterlegt sein muss. Dass das nicht übermäßig sicher ist, kann da doch ernsthaft keine Überraschung sein; dafür hat’s doch wohl bitte keinen Experten gebraucht, der das „aufdeckt“, sondern nur etwas gesunden Menschenverstand.

In der Sicherheitstechnik kennt man im Grunde drei Möglichkeiten der Authentifizierung: Geheimes Wissen (z. B. ein Passwort), Besitz (z. B. ein Haustürschlüssel) und Biometrie (körperliche Merkmale, die in der Regel nur schwer kopierbar oder fälschbar sind). Die Übergänge sind hier fließend: Melde ich mich an einem Dienst mit einem Passwort an, stellt jenes geheimes Wissen dar, das man mir nicht stehlen kann, sondern mich höchstens zur Preisgabe zwingen kann. Speichere ich das Passwort aber ab, z.B. im Browser oder sonstwo, mutiert es zu Besitz – man muss mich nicht mehr foltern; man muss mir nur noch die Datei klauen, in der das Passwort steht.

Es sollte keine Überraschung sein, dass jedes dieser Verfahren für sich genommen schwach ist. Menschen kompromittieren geheimes Wissen, in dem sie sich Trivialpasswörter ausdenken, überall das gleiche Passwort nehmen oder es gleich durch Aufschreiben oder Abspeichern in Besitz konvertieren. Besitz kann man stehlen; Besitz von klassischen Gegenständen setzt zumindest schon mal einen Einbruch voraus, Besitz von Dateien schon nur noch einen Trojaner auf dem Rechner, und wenn ich mir anschaue, wieviele Leute nicht mal ihr Betriebssystem aktuell halten und bei wievielen Freunden ich schon Malware von der Platte kratzen durfte, halte ich „Besitz“ schon fast für die fahrlässigste Möglichkeit der Authentifizierung. Biometrie allein bringt’s auch nicht – die Geschichten, wo Computer Menschen eben gerade nicht zuverlässig erkennen bzw. umgekehrt zuviele Menschen als zu einem biometrischen Merkmal passend erkennen, gibt es mehr als genug. Wir selbst waren eine Zeitlang in einem Rechenzentrum mit Fingerabdruckscanner und haben in drei Vierteln der Fälle in der Sicherheitsschleuse festgehangen, weil der Scanner uns nicht korrekt erkannte. Umgekehrt dürfte der Fingerabdruck des früheren Innenministers Schäuble spätestens seit der Veröffentlichung praktischer Fingerabdruck-Klone in der Datenschleuder, der Zeitschrift des CCC, eins der am häufigsten kopierten biometrischen Merkmale sein.

Was man also braucht, um Sicherheit zu erhöhen, sind Kombinationen von Verfahren. Das ist auch gar nicht weiter kompliziert: Jeder, der schon mal einen Geldautomaten benutzt hat, hat damit beispielsweise bereits die Kombination aus Besitz (ec-Karte) und geheimem Wissen (PIN) angewendet – keins davon hätte ihm alleine schon Bargeld verschafft. Selbst Kombinationen aus zwei identischen Verfahren sind sicherer als eins allein – um im Bankenumfeld zu bleiben: Mit einer PIN komme ich zwar ins Onlinebanking rein; um auch Überweisungen zu tätigen, brauche ich aber auch eine TAN. Mit einer TAN ohne PIN komme ich umgekehrt aber nicht mal ins System. Mit dem zunehmenden Umbau der Systeme auf TANs, die aufs Handy geschickt werden oder die man mit einem optischen Leser generiert, der wiederum die eingesteckte ec-Karte voraussetzt, wird hier verstärkt geheimes Wissen mit Besitz (Handy, oder TAN-Generator mit eingesteckter ec-Karte) gekoppelt.

Auch am Rechner gibt es schon lange Beispiele für Kombinationsverfahren: Browser, in denen man Passwörter abspeichern kann (womit die Datei, in der sie gespeichert werden, das Passwort zu Besitz mutieren lässt), können diese Datei auch verschlüsseln. Rufe ich nun den Browser auf und möchte eins der gespeicherten Passwörter nutzen, muss ich zunächst das Passwort eingeben, um die Passwortdatei zu entschlüsseln – Besitz und Wissen. Wer mit SSH-Keys arbeitet, wird diese typischerweise ebenfalls verschlüsselt haben und einen SSH-Agent starten, der zunächst die Passphrase zur Entschlüsselung des Keys abfragt und dann so den als Datei hinterlegten Key nutzbar macht – Besitz und Wissen.

Ich sehe also nicht, wo bei Dropbox da jetzt die Sicherheitslücke liegen soll. Es mag vielleicht irritierend sein, weil für den User nicht transparent ist, dass die Anmeldung faktisch via Besitz (Datei mit Host-ID) und nicht via Wissen passiert, weil sie nicht wissen, wie genau das alles im Hintergrund funktioniert. Aber auch wenn der Dropbox-Client einfach nur die Zugangsdaten in einer Datei abgespeichert hätte, wäre Wissen zu Besitz geworden, nur mit dem Unterschied, dass dann das Ändern des Passworts des Dropbox-Accounts Wirkung zeigen würde. Aus technischer Sicht finde ich den Unterschied allerdings zugegebenermaßen marginal. Wer häufiges Ändern von Passwörtern ernsthaft als „Sicherheitsmethode“ ansieht, dem ist vermutlich egal oder nicht bewusst, dass bis zur Passwortänderung schon längst alle möglichen Daten abgeschnorchelt oder gar unbemerkt verändert worden sein können. Die Sicherheit ist schließlich mit dem Einbruch kompromittiert – eine spätere Passwortänderung kann das nicht mehr ungeschehen machen.

Dropbox trägt also eigentlich nur an einem Schuld: Dass sie kein Kombinationsverfahren für die Authentifizierung forcieren. Dabei wäre es doch nun ein Leichtes, die Datei mit der Host-ID zu verschlüsseln und als Basis für eine Entschlüsselung ein vom User eingegebenes Passwort zu nehmen oder meinetwegen auch nur ein paar mit dem Finger aufs Smartphone geschmierte Linien – wobei eben wichtig ist, dass das nicht einfach dergestalt realisiert wird, dass die Software die Datei mit der Host-ID „freigibt“, sondern schon tatsächlich so, dass die Datei mit der Host-ID damit so verschlüsselt ist, dass der Besitz der Datei alleine tatsächlich nicht ausreicht, auch wenn man diese „hintenrum“ kopiert.

Aber vermutlich wäre das den meisten schon zu kompliziert. Man lobt Dropbox ja nun vor allem wegen seiner Einfachheit. Dem Sicherheitsexperten gehört insofern Dank, als dass er vielleicht ein wenig Sensibilität dafür weckt, wie Authentifizierung tatsächlich funktioniert. Das ändert aber nichts daran, dass die Mehrheit der User, wenn sie nicht gezwungen wird, vermutlich immer die bequemste Authentifizierung wählen wird, nämlich „merk dir meine Daten für immer und lass mich dann in Frieden“. Hieraus dann speziell Dropbox einen Vorwurf zu machen, halte ich für unredlich und an der Sache vorbei.

Eine lange Angelegenheit findet in einem einzeiligen Schreiben der Staatsanwaltschaft Koblenz ihren Abschluss:

Das vorbezeichnete Ermittlungsverfahren wurde gemäß § 170 Abs. 2 der Strafprozessordnung eingestellt.

Damit ist nun also offenbar auch dort angekommen, dass der Vermieter eines Servers, der dann von einem Webhoster verwaltet wird, der dort eine Website eines Küchenhändlers betreibt (nun mehr: betrieb), der dort einen Onlineshop betreibt und dann seine Kunden nicht mit der bestellten Ware beliefert … nun, also, dass wir daran keine Schuld tragen.

Das Schreiben bezieht sich übrigens auf einen Vorgang, über den ich bereits vor zehn Monaten unter dem Titel Schlampig ermittelt gebloggt habe – und schon damals zog sich der Fall bereits ein halbes Jahr lang hin. Auch mein Rechtsbeistand freut sich über die späte Einsicht und kommentiert:

Es wundert nur, dass Ermittlungsorgane dafür so lange brauchen.

Dass ich der zuständigen Polizeidienststelle – was aktenkundig ist – in Kooperation mit meinem Kunden angeboten hatte, entsprechende Protokollauszüge von FTP- oder E-Mail-Logins zu sichern, um sie im Fall einer richterlichen Verfügung bereitstellen zu können: Das hat offenbar niemanden interessiert. Bis heute wurde nichts dergleichen abgefragt. Dass ich weiterhin mitteilte, dass unser Kunde genauere Informationen über den Küchenhändler bereitstellen könnte: Egal. In der Ermittlungsakte fand sich nicht einmal ein Versuch einer Kontaktaufnahme mit meinem Kunden (er hätte gerne geantwortet, wie auch schon in gleicher Angelegenheit drei anderen Polizeidienststellen davor).

Zwischenzeitlich wurde mir übrigens großzügig angeboten, das Verfahren einzustellen, wenn ich denn – aufgemerkt! – einfach nur den entstandenen Schaden begleichen würde. Mein Rechtsbeistand und ich haben herzlich gelacht, und ich habe dann mein Kreuz im Feld „Ich bin NICHT einverstanden“ gemacht.

Nun hat die Geschichte also ein Ende gefunden – jedenfalls für mich; denn dass die Vorwürfe gegen mich zurückgezogen wurden, könnte ja auch bedeuten, dass man den tatsächlich Schuldigen dingfest machen konnte.

Vor allem den Geschädigten wäre dies mehr als alles andere zu wünschen. Vor allem nach so langer Zeit.

Anfang der Woche erhielten wir eine knappe Mail eines Herrn Etzler von WebOptimizer24 (jaja, nofollow gesetzt, keine Sorge), der uns zu unserer vor kurzer Zeit gestarteten Hosting-Plattform Uberspace.de mit einem herzlichen „Respekt!“ bedachte und – vermutlich rhethorisch – fragte, warum er bisher noch nichts von uns gehört habe. In Feierabendlaune nannte ich eine Reihe von Gründen, darunter ein offensichtliches „uns gibt es erst seit Anfang des Jahres“, aber auch ein etwas augenzwinkerndes „Wir lassen die Finger von SEO“. Hätte ich doch nur geahnt, dass Herr Etzler dies offenbar als Aufforderung angesehen hat …

Ganz kurz für diejenigen, die mit dem Begriff „SEO“ nichts anfangen können: Er steht für „Search Engine Optimization“, also kurz gesagt für alle Techniken, die dafür sorgen, in Suchmaschinen weiter oben zu stehen. Suchmaschinen arbeiten schließlich mit komplexen Algorithmen, die versuchen, durch Inhaltsanalyse, vor allem aber auch durch Querverlinkungen herauszufinden, welche Inhalte eine gute Bewertung wert sind und welche nicht. Es liegt nahe, dass einige Unternehmen das sportlich sehen und wahlweise versuchen, diese Algorithmen auszureizen – oder auch auszutricksen. Insofern gibt es fließende Grenzen zwischen, nennen wir es mal, „gutem SEO“ und „bösem SEO„. Einer unserer Kunden, der – durchaus sehr erfolgreich – in diesem Bereich arbeitet, bringt „gutes SEO“ auf den erfrischend einfachen Punkt:

Das beste und meiner Meinung nach einzige SEO ist und bleibt: Schaffe guten Content oder wertige Inhalte, der Rest kommt von alleine.

Bis hierhin habe ich nichts einzuwenden: Wer das Netz mit interessanten Inhalten bereichert, hat es durchaus verdient, höher gerankt zu werden – wobei das eben weniger eine Geheimwissenschaft ist als vielmehr sehr viel Arbeit. Arbeit, die wir jedoch gerne auf uns nehmen.

Überrascht war ich nun, als ich zufällig auf ein Review über Uberspace.de bei Qype stieß, das ich leider nicht mehr verlinken kann, weil es nach dieser ganzen Aktion gelöscht worden ist – aber einen Screenshot habe ich noch rechtzeitig angefertigt. Ein Qype-User mit dem wohlklingend-generischen Namen „giuliaalpha“ lobte Uberspace.de in den Himmel und beschrieb unter anderem:

In meinem Fall ist es so, dass drei sog. Langzeitarbeitslose aus unserem Unterstützungsverein eine Geschäftsidee für das Internet hatten. Zu scheitern drohte die wirklich gute Idee an den Kosten für das Webhosting und die Programmierung der Webseite.
Dank uberspace konnte das Projekt trotz der sehr bescheidenen finanziellen Mittel online gehen. Inzwischen werden schon gute Umsätze erzielt und – so funktioniert das Konzept – jeden Monat natürlich mehr als der Mindest-Euro überwiesen.

Man könnte meinen, das wäre aus unserer Konzeption abgeschrieben, so perfekt passt es zu unserem „Zahl, soviel du für angemessen hältst“-Konzept. Der Haken ist: Uberspace.de ist erst ab dem 01.04.2011 kostenpflichtig – zum Zeitpunkt dieses Blogposts wäre das … morgen. Es ist also völliger Blödsinn, wenn „giuliaalpha“ schreibt, es würde „jeden Monat natürlich mehr als der Mindest-Euro überwiesen“ – und auch sonst enthielt das Review noch einige andere Merkwürdigkeiten. Wer sich für die Details interessiert, kann das komplette Review wie gesagt im Screenshot noch einsehen.

Und noch etwas ist in dem Review interessant:

Die Webseite wurde Pro Bono von Herrn Etzler von der Firma WebOptimizer24.de in München erstellt. Bitte sehen Sie sich auch meine Bewertung dafür an.

Ach. Jener Herr Etzler, der dem Arbeitslosenprojekt in seiner Herzensgüte die Website kostenlos erstellt? Dem Projekt, das angeblich schon seit Monaten bei Uberspace.de läuft, während Herr Etzler erst vor wenigen Tagen von Uberspace.de erfahren hat? Sorry, aber wer hier an einen Zufall glaubt, der glaubt vermutlich auch noch an den Weihnachtsmann. Vor allem, weil „giuliaalpha“ ein brandneuer Account ist, ohne öffentliches Profil, der genau zwei Reviews verfasst hat: Eins über uns, und eins über WebOptimizer24. D’Oh.

Wie man im Screenshot ebenfalls gut sehen kann, haben wir eine öffentliche Replik dazu geschrieben, mit dem Tenor: „Wir freuen uns natürlich über positive Reviews, aber echt sollten sie bitte schon sein – und dieses hier ist es eben nicht. Probiert uns doch bitte selbst aus und bildet euch ein eigenes Urteil.“ Wir haben uns vorher mit einigen Usern und auch im Team beraten und hielten das für die bessere Reaktion, als bei Qype dafür zu sorgen, das Fake-Review einfach verschwinden zu lassen.

Man möchte einwenden, dass es uns doch egal sein könnte, beziehungsweise dass wir uns doch einfach freuen könnten, wenn uns jemand mit einem positiven Review bedenkt – Stichwort „Weiß doch keiner, dass das nicht echt ist“. Stimmt aber nicht. Wir wissen es. Wir arbeiten hart dafür, uns echte Reputation zu verdienen: Wer für schnellen Support gelobt werden will, muss eben erstmal schnellen Support leisten; wer für seine saubere Serverkonfiguration Lob ernten will, muss eben seine Server sauber konfigurieren. Wir bezahlen niemanden für positive Äußerungen über Uberspace.de – und in diesem Punkt sind wir pingelig: Wenn Dritte falsch-positive Reviews über uns verfassen, wirft das ein schlechtes Licht auf uns, weil es den Eindruck erweckt (oder zumindest erwecken könnte), dass wir uns unsere Reputation nicht zu verdienen, sondern zu erkaufen versuchen. Davon distanzieren wir uns klar.

Nun, wenig überraschend war unsere öffentliche Replik kurz darauf verschwunden. Dafür erhielt ich von „giuliaalpha“ eine Direktnachricht via Qype, die ich nun eben leider nicht zitieren kann, ohne dabei die Vertraulichkeit zu brechen. Insofern müssen wir darauf vertrauen, dass uns der folgende Teil schlicht geglaubt wird – keine Sorge, es kommt gleich noch ein unterhaltsames Ende, das hier bei einer Einschätzung helfen könnte.

Natürlich war das alles ein großes Missverständnis, das „Giulia“ außerordentlich bedauert. Sie hat meine öffentliche Richtigstellung auch gleich zum Anlass genommen, ihr Review durch eine entsprechende Ergänzung zu korrigieren, von der ich ebenfalls einen Screenshot angefertigt habe, da die Korrektur zusammen mit dem Review mittlerweile natürlich auch gelöscht wurde. Um mal den relevanten Teil direkt zu zitieren:

Das Lob, das ich hier für uberspace.de ausgesprochen habe, hat den Praxistest noch nicht bestanden. Ich habe die Infos über diesen Webhoster per Mail erhalten, damit wir in ZUKUNFT diesen Anbieter nutzen bzw, unseren Mitgliedern empfehlen können. […] Richtig ist, dass die o.g. Projekte bei einem anderen Webhoster untergebracht wurden zu speziell ausgehandelten Sonderkonditionen […]“

Aha. Soso. Naja, klar: Einen Anbieter, mit dem man Sonderkonditionen aushandelt, und einen Anbieter, der bisher noch überhaupt gar kein Geld genommen hat – da kann man schon mal was verwechseln. Vor allem, wenn man so detailliert unser Konzept des frei wählbaren Preises in seiner praktischen Anwendung dokumentiert, während man tatsächlich überhaupt nicht bei uns hostet.

Der eigentliche Klopper kam dann aber in der Mail, und es erscheint mir ausnahmsweise angemessen, für einen einzigen Satz meine ansonsten eiserne Regel zu brechen, nicht ungefragt aus an mich persönlichen gerichteten Mails zu zitieren. Aber bitte, Giulia, verklag mich doch:

Und noch ein Mißverständnis muss ich ausräumen: Unser Projekt für Menschen, die es wirklich nicht einfach haben, hat gar keinen Webauftritt.

Do legst di nieder..! Es ist also nicht nur das Review zu Uberspace.de frei erfunden; auch die Korrektur von wegen „in Wirklichkeit hosten wir bei einem anderen Anbieter“ hat’s nicht so mit der Wahrheit. Und weil’s so schön ist, ist damit auch gleich die Information, dass WebOptimizer24 generös die Website des Arbeitslosenprojekts kostenlos gestaltet hat, mit weggewischt. Das hat sie natürlich nicht öffentlich geschrieben.

Entsprechend deutliche Worte habe ich in meiner Antwortmail an Giulia gefunden:

Das ist doch nicht dein Ernst, dass das ein „Missverständnis“ war. Zwischen „Unser Projekt hat gar keinen Webauftritt“ und „Das Projekt konnte bei Uberspace.de online gehen und der Telefonsupport war super und wir bezahlen jeden Monat Geld“ liegt kein „Missverständnis“, sondern das eine macht das andere zu einer fetten Lüge.

Zugegeben: Nicht sehr freundlich, aber Hand aufs Herz: Auf den Punkt. Ist doch wahr. Und weil es mir stinkt, wenn Leute glauben, mich für dumm verkaufen zu können, ergänzte ich noch kühl:

Wenn du nicht an deinen öffentlichen Äußerungen gemessen werden willst, äußere dich nicht öffentlich.

Besondere Aggressionen rief bei mir hervor, dass „Giulia“ sich darüber beklagte, ich hätte mit meiner öffentlichen Replik WebOptimizer24 in ein schlechtes Licht gerückt (Ach!), und das, obwohl die doch wirklich nichts für ihren Fehler könnten. Um hier nochmal aus ihrer eigenen (öffentlichen) Korrektur zu zitieren:

Für diesen Irrtum kann ich mich nur entschuldigen. Ich bin halt keine Internet-Fachfrau und habe mich wohl in den Begriffen Webspace, uberspace, Webhoster und Webprovider verheddert. Hinzu kam die Begeisterung, dass Unternehmen tatkräftig Langzeitarbeitlose unterstützen und aus dem Hartz IV Kreislauf heraushelfen.

Herrje, gleich muss ich weinen. Vor Begeistung Begriffe verwechselt. Klar, „Webspace, uberspace, Webhoster und Webprovider“, bei sovielen AdWords kann man schon mal den Überblick verlieren. Und was mich besonders aufregt: Dieser ständige Hinweis auf das ach so tolle Projekt. Völlig unbenommen, ob dieses Projekt für Langzeitarbeitslose nun existiert (wünschenswert wär’s ja) oder nur kreativ von einem SEO-Spammer, der gerne die Tränendrüse bedient, aus den Fingern gesaugt wurde: Selbst noch soviel Engagement „für die gute Sache“ rechtfertigt keine öffentliche Lüge, schon gar nicht, wenn diese völlig unnötig ist.

Inzwischen klingelte mein Telefon – Qype meldete sich. Das ist erstmal ein ganz normaler Vorgang: Da ich mich gestern zwecks „offizieller“ Reaktion zu dem Review als „Das ist mein Geschäft“-User bei Qype angemeldet habe, erfolgt kurz darauf eine telefonische Verifikation. Ist ja auch gut so.

Der Qype-Mitarbeiter am anderen Ende der Leitung war ausgesprochen launig drauf. Er hatte erfreulicherweise das Review sowie meine Replik bereits gelesen und äußerte sich regelrecht amüsiert zu dem Vorgang – und fand, ich habe mit der offenen Reaktion auch die beste Möglichkeit einer Replik gewählt. Gerade für ein Unternehmen wie Qype, das ja auch schnell ein Glaubwürdigkeitsproblem bekommt, wenn sich dort SEO-Spammer-Kommentare zwischen die echten Reviews mogeln, ist es ja in besonderer Weise wichtig, das eigene System sauberzuhalten. Gut, er war zugegebenermaßen nicht ganz glücklich darüber, dass ich in meiner Replik zufällig mitlesende Ubernauten gebeten habe, wenn dann doch bitte in ihren eigenen Blogs über Uberspace.de zu berichten und dann auch öffentlich mit dem eigenen Namen dafür einzustehen. Aber konnte nicht verhehlen, dass er auch ein gewisses Verständnis für meine Äußerung hatte, gerade angesichts des Vorfalls.

Nun ist das Review also plötzlich wieder weg. Ich weiß nicht, ob Qype es entfernt hat, was auch durchaus nachvollziehbar wäre; nicht nur, weil es einerseits nachweislich erfunden war, sondern auch, weil es andererseits nach der „Korrektur“ nun auch wirklich keine Silbe mehr mit Uberspace.de zu tun hatte. Aber ich tippe darauf, dass „Giulia“ es selbst gelöscht hat. Es kam nämlich noch eine Antwortmail von ihr. Und weil ich mit sowas gerechnet habe, ließ ich meine Nachricht an sie mit den Worten enden:

Ich weise sicherheitshalber darauf hin, dass ich mir vorbehalte, Auszüge aus weiteren Antworten von dir, die du an mich direkt sendest, ebenfalls öffentlich zu machen. Wenn du damit nicht einverstanden bist, sende mir bitte keine weiteren Nachrichten.

Insofern kann ich jetzt nur kalt lächelnd mit einem „she deserved it“ schließen und wünsche viel Vernügen:

Werter Jonas,

schade, dass Ihr Projekt wohl noch sehr im Anfangsstadium ist, denn Sie haben offensichtlich zu viel Zeit, viel zu viel Zeit. Jede Zeile einer Mail bzw. Posting akribisch zu analysieren, zeugt entweder von extremer Langeweile oder schlimmeren Eigenschaften

Wenn ich mir Ihre Kommenatre ansehe, haben Sie entweder meine Zeilen nicht richtig gelesen, nicht richtig erfasst oder haben andere Absichten. Ich tippe auf letzteres.

Die Frage ist auch, ob Sie tatsächlich zu überspace gehören, denn Ihr Profilbild ist ja nichts weiter als ein pixeliges Irgendwas-Firmenlogo und sicher keine Originaldatei. Das könnte natürlich auch das Werk eines unterbeschäftigten Mitbewerbers sein. Ich kann mir nicht vorstellen, dass ein Unternehmer sein eigenes Firmenlogo so verunstaltet.

Wie dem auch sei: Nachdem Sie mich als Lügnerin bezeichnen, ich meine Zeit lieber besser nutze, als für Ihre kindlichen Clownerien und auch keine Brieffreundschaft suche, ist dieser Zeilenwechsel von meiner Seite aus beendet.

Aufrichtig gute Besserung wünscht
Giulia

Der geneigte Leser möge sich nun sein Urteil selbst bilden.

Wer übrigens noch ein bisschen über WebOptimizer24 erfahren möchte, der kann sich ja diesen launigen Beitrag im Blog von seo-united.de (ja, auch hier nofollow, klar) zu Gemüte führen: H. E. ist neuer SEO Weltmeister! – aber bitte nicht den Kommentar Nr. 3 überlesen, auch wenn man es sonst in puncto Blog-Kommentaren vielleicht eher wie Stephen Fry hält. Es lohnt.

Seit ein paar Jahren ist Green IT in aller Munde und in diesem Zusammenhang hatte ich mich auch vor einer Weile schonmal mit der Frage beschäftigt, woher eigentlich der Strom für das Rechenzentrum kommt, in dem unsere Server stehen. Die Antwort war in etwa, dass zwar Atomstrom im Energiemix drin ist, aber Ökostrom auch gerne genommen wird und dessen Anteil seit Jahren steigt. Ich habe nicht genauer nachgehakt, denn damals interessierten mich an der ganzen Sache noch andere Details. Zu der Zeit wurde noch viel darüber diskutiert, ob Atomstrom denn nicht doch auch irgendwie „green“ wäre (die Anspielung auf das berühmte — und fiktive — grüne Atom-Glühen in populären Medien war sicherlich unbeabsichtigt), außerdem könne man ja eh nur den Marktanteil von Ökostrom hochtreiben, aber die geladenen Elektronen aus der Steckdose kommen ggf. trotzdem vom nahe gelegenen AKW, auch wenn man formal Ökostrom kauft usw. … Insgesamt eine komplexe Materie und mich persönlich interessierten bei Green IT mehr die Giftstoffe in den Geräten und stromsparende Architekturen (ich freue mich schon darauf, in ein paar Jahren meinen Heimserver, der eh meist nur rum-idle-t, durch etwas mit ARM-Prozessor ersetzen zu können).

Aber da Ökostrom durch den auslegungsüberschreitenden Störfall (vulgo: Super-GAU, auch wenn das die Spindoctors der Atom-Lobby nicht gerne hören) in Fukushima-1 wieder ein heißes Thema wurde, dachte ich mir, ich recherchiere mal den aktuellen Stand der Dinge. Wer weiß, vielleicht kommt ja auch bald eine Kundenanfrage, ob man auf seine Homepage „läuft mit Ökostrom“ raufschreiben kann. Jonas hatte den gleichen Gedanken und kam mir mit der Anfrage bei unserem Rechenzentrumsbetreiber zuvor. (Um die Zusammenhänge zu klären: Das Rechenzentrum ist die Databurg in Frankfurt am Main und dort wiederum hat unser ISP Plus.line Räume gemietet, in welchen wir wiederum ein paar Racks gemietet haben.)

Die kurze Antwort:

Unser Rechenzentrum und damit auch unsere Server beziehen nach wie vor leider unter anderem auch Strom aus Kernenergie. Und zwar nicht nur technisch, weil halt Atomstrom ins Netz eingespeist wird, sondern auch vom Energiemix her. Immerhin ist es aber weniger Atomstrom als im landesweiten Schnitt und es wird lieber Ökostrom als Kernenergie in den Mix eingekauft.

Die lange Antwort:

Rechenzentren verbrauchen viel Strom, selbst wenn es stromsparende Rechenzentren sind (so ein Rechenzentrum kann auch im wesentlichen nur auf energieeffiziente Klimaanlagen setzen, der Rest vom Gros des Stromverbrauchs kommt eh von den Servern der Kunden). Häufig zahlen Rechenzentrumsbetreiber mehr Stromkosten als Gewerbesteuer, von daher richtet sich die Standortwahl für Rechenzentren zum Teil auch nach den lokalen Strompreisen (vor allem aber nach den Möglichkeiten, dicke und möglichst mehrere Anschlussleitungen und Strom aus verschiedenen Netzen bekommen zu können). Von daher sind die meisten Rechenzentren auch durchaus an stromsparenden Klimaanlagen interessiert, das Problem ist halt nur: selbst stromsparende Klimaanlagen fressen immer noch eine Menge Strom.

Nun sind Strompreise in Deutschland für die Endabnehmer ohnehin nicht so richtig lokal, erstens werden die Preise an der Strombörse gemacht, zweitens reichen die Stromanbieter diese Preise nicht in Reinform an die Verbraucher durch. (Etwa wenn gerade so viel Strom verfügbar ist, dass die Preise zeitweilig sogar negativ werden, davon bekommen die Endverbraucher — sehr zu ihrem Leidwesen — natürlich nichts mit.) Als Großabnehmer wird man bei den Stromanbietern natürlich besser behandelt denn als Privatmensch und man bekommt auch andere Tarife, aber natürlich wird man trotzdem gehörig zur Ader gelassen. (Wir haben ja in Deutschland bei ständig wachsendem Energieangebot seit vielen Jahren stetig steigende Endverbraucherpreise und die Energiekonzerne machen Traumgewinne — die Freuden eines Oligopols.) Hinzu kommt noch, dass die meisten Ökostromtarife sich an Privatverbraucher richten, im Segment für Großabnehmer ist die Auswahl deutlich kleiner.

Ein zentrales Problem ist hierbei aber auch die Ausfallsicherheit: Ein Rechenzentrum braucht nicht nur viel Strom, es braucht ihn permanent in ausreichender Menge, Ökostrom fällt nicht immer in gleicher Menge an. Gute Rechenzentren haben mehr als eine Anschlussleitung die den Strom über unterschiedliche Trassen von unterschiedlichen Hauptverteilern anliefern (damit kein lustiger Bagger beim Straßenbau mal eben beide Leitungen rausreißt oder ein einzelner, defekter Hauptverteiler allen den Spaß verdirbt). Das Zauberwort hier ist der „Singe Point of Failure“, also der neuralgische Punkt, an dem alles scheitern kann, den man unbedingt vermeiden möchte. In diesem Punkt bringt Ökostrom übrigens einen direkten Vorteil: durch die dezentrale Erzeugung ist es bei Ökostrom viel einfacher, ihn über mehrere Leitungstrassen heranzuführen.

Zusätzlich zu den häufig redundanten Stromzuführungen haben die Rechenzentren oft noch Notstromaggregate in unterschiedlicher Anzahl (je mehr, desto teurer wird das Housing). Gute Notstromaggregate sind so gebaut, dass der Diesel dafür obendrein räumlich über den Aggregaten gelagert ist, so dass bei Pumpenausfall der Kraftstoff auch durch die Schwerkraft dahin kommt wo er gebraucht wird. Außerdem verfügen Rechenzentren fast immer über große Mengen Batterien (häufig Autobatterien), vor allem um die Zeit zwischen Stromausfall und vollem Anlaufen der Notstromaggregate zu überbrücken. Bei den Notstromaggregaten ist das Problem, dass sie anders als Dieselgeneratoren in Kraftwerken nicht 24/7 von Fachkräften gewartet werden, sondern eben lange untätig rumstehen und dann aber auch wirklich anspringen müssen, d.h. sie sind mehr auf Ausfallsicherheit denn auf Energieeffizienz optimiert. Es ist für Rechenzentrumsbetreiber also keine Option, auf Solardächer und Windräder zu vertrauen und bei Flaute und Wolken dann den Diesel zuzuschalten, weil der einfach zu teuer ist. Obendrein läuft ein Dieselgenerator nur in bestimmten Leistungsstufen wirklich effizient, kommt also nicht in Frage, um mal eben noch das eine oder andere KW dazu zu erzeugen, das gerade nicht vom Himmel scheint. Rechenzentren werden also immer darauf angewiesen sein, zur Not den Strom über ein weites Netz auch aus größerer Ferne beziehen zu können, wenn bei dezentraler Erzeugung von Ökostrom gerade nicht genug anfällt, und sie werden zumindest nach dem derzeitigen Stand der Technik immer auf fossile Notreserven angewiesen sein. Ein Rechenzentrum nur mit Ökostrom zu betreiben ist, wenn man keine Talsperre zur Hand hat (besser zwei, wegen Redundanz) sehr schwierig, deswegen gibt es so wenig davon, jedenfalls in Deutschland. In Norwegen und Island sieht die Situation anders aus, weil man in Island nur den Finger in den Boden stecken muss, um Erdwärme nutzen zu können, und Norwegen dermaßen viele kleine Wasserkraftwerke hat, dass sie oft gar nicht wissen wohin mit dem vielen Strom.

Es gibt ein paar Projekte, bei denen versucht wird, Öko-Rechenzentren zu bauen, die unter anderem auch die riesigen Mengen Abwärme der Server zur Energiegewinnung nutzen. Das sind aber Mammut-Projekte, also etwas, das für ein kleines, mittelständisches Unternehmen wie uns noch sehr, sehr weit in der Zukunft liegt.

Worauf das letztlich hinausläuft: Unser Rechenzentrum bezieht einen Strommix, der sich an den Kosten orientieren muss, um konkurrenzfähig zu bleiben. Wenn gerade viel Ökostrom anfällt (also der Wind kräftig weht, es über den Talsperren regnet, die Solaranlagen gleißende Sonne bekommen), dann ist dieser billig und wird ohnehin per Gesetz bevorzugt ins Netz eingespeist. Zu solchen Zeiten ist im Energiemix unseres Rechenzentrums viel Ökostrom mit drin. Wenn gerade wenig Strom anfällt, wird Ökostrom noch bevorzugt, aber es kommt eben auch mehr konventionelle Energie und Atomenergie in den Mix. Insgesamt liegt der Anteil Ökostrom den das Rechenzentrum bezieht so schonmal über dem deutschlandweiten Schnitt und der Anteil ist größer als der vom Atomstrom:

Das ist ein lobenswerter Anfang.

In den nächsten Wochen wird der Atomstromanteil wohl weiter fallen, da die Kanzlerin ja in einem Anfall von vorwahlsonntäglicher Aktivitätssimulation kurzerhand die Abschaltung wenigstens der ältesten Meiler angekündigt hat und dies wohl auch geschieht. (So richtig beruhigend ist das auch nicht, wenn man dann liest, dass sie beim fachgerechten Runterfahren von ISAR-1 gleich mal einen kleinen (nicht auslegungsüberschreitenden) Störfall hatten.) Hier bleibt abzuwarten, ob diese Abschaltung vorübergehend bleibt oder bei der Neubewertung der Sicherheitsfrage herauskommt, dass man es doch lieber sein läßt mit den alten Hütten. Falls wir Pech haben, fällt den Regierenden wieder ein dicker Koffer Schwarzgeld oder ein Haufen Aufsichtsratsposten auf, die die Atomlobby zufällig rumliegen hat. Wenn wir uns alle ins Zeug legen und politischen Druck machen, bleiben diese Reaktoren aber vielleicht auch einfach aus politischen Gründen aus.

Aber was kann man denn nun tun, damit Green IT eben auch Ökostrom heißt? Die Sache ist ja immerhin seit ein paar Jahren in der Diskussion, aber Rechenzentren mit Ökostrom sind immer noch eher rar und man sieht „läuft mit Ökostrom“-Siegel auf Webseiten eher selten. Wir hängen da als Anbieter so ein bisschen in der Luft. Einerseits haben wir keine direkte Kontrolle darüber, woher unser Rechenzentrum den Strom bezieht, andererseits könnten uns ja auch Kunden fragen, wie’s denn bei uns aussieht und wir sind allesamt selbst keine Kernkraftbefürworter und nähmen auch lieber Ökostrom als irgendwas anderes. Gleichzeitig sind wir mit der Databurg sehr zufrieden. In der Vergangenheit waren wir in anderen Rechenzentren, und die Erfahrungen haben gezeigt: Solange wir keinen Grund haben, mit der Databurg unzufrieden zu sein, gehen wir da nicht freiwillig weg. Davon abgesehen ist ein Umzug von einem Rechenzentrum in ein anderes ein enormer Aufwand, den man nicht ohne triftige Gründe auf sich nimmt. Die Databurg wird auch nicht auf einmal ankündigen, komplett auf Ökostrom umzusteigen, denn das wäre auf einen Schlag viel zu teuer und würde einige Kunden verjagen. Uns bleibt hier also nur die Möglichkeit, mehr Ökostrom zu fordern, damit es über die Jahre weiterhin immer mehr wird. Wir werden bei Plus.line in Zukunft öfter mal nach dem Energiemix fragen und die werden dann sicherlich öfter mal bei der Databurg und die bei ihren Stromanbietern nachfragen, besonders wenn nicht nur wir sondern auch andere Kunden nachhaken. (Die Nachfrage nach Ökostrom ist ja ganz aktuell schon um 10% gestiegen. Ohne zynisch sein zu wollen nehme ich mal an, dass dieser Anstieg sich fortsetzen wird, je länger Fukushima-1 Radioaktivität freisetzt.) Gleichzeitig gilt nach wie vor für uns alle: Immer mal wieder bei allen möglichen Anbietern und Herstellern anfragen, woher sie ihren Strom beziehen, damit die mitkriegen, dass ihren Kunden das wichtig ist.

Die Kehrseite der Medaille ist natürlich, dass der Ökostrom (noch) teurer ist. Nun haben wir (und unsere Kunden) uns schon länger damit abgefunden, dass die Strompreise sich offenbar nur in eine Richtung verändern, und bisher war das auch immer noch zu ertragen. Es bleibt zu hoffen, dass der Ökostrom ab einer bestimmten kritischen Masse den Strompreis auch mal drücken wird (wie gesagt entstehen an der Strombörse ja bereits gelegentlich solche Effekte). Letztlich soll es aber nicht am Geld scheitern. Wenn ich die Wahl habe, entweder mehr für Ökostrom zu bezahlen oder in 20 Jahren die Server vor dem steigenden Meeresspiegel in Sicherheit bringen zu müssen, dann ziehe ich den Ökostrom vor (und das obwohl ich als Berliner nichts gegen ein Strandbad Oranienburg einzuwenden hätte).

Denn was wir bei der ganzen Sache auch nicht vergessen dürfen: die 58% Strom aus fossilen Energieträgern. Wir wissen alle, was das mit unserem Klima anstellt und wir wissen alle, dass wir, unsere Kinder, unsere Enkel und weitere Generationen dafür langfristig auf die eine oder andere Art und Weise bezahlen müssen. Ich persönlich bin aber auch davon überzeugt, dass wir und unsere Nachfahren für die Kernkraft noch viel, viel bitterer bezahlen werden. Selbst wenn es nicht mehr zu Störfällen kommen sollte (glaube ich nicht, aber angeblich sind wir ja jetzt mit Windscale, Three Mile Island, Tschernobyl und Fukushima für die nächsten 80.000 Jahre statistisch bedient), dann werden die Endlager (wenn es sie denn mal gibt) für die nächsten 10.000 bis 100.000 Jahre Kosten für die Bewachung und Überwachung verursachen. Vermutlich häufiger als uns lieb ist, wird auch mal ein Lager ausgeräumt werden müssen wie jetzt die Asse.

Ein Detail am Rande: Dass wir keine Kernkraft-Fans sind kommt nicht von ungefähr, Jonas lebt in Mainz, Andreas in Frankfurt am Main, Matthias in Griesheim bei Darmstadt, die Databurg steht in Frankfurt am Main: von dort aus sind es 49 km Luftlinie bis zu den Meilern bei Biblis. Die vorherrschende Luftströmung von Biblis führt Richtung Darmstadt, Mainz und schließlich Frankfurt. Weniger als 200 km entfernt stehen noch die Meiler bei Cattenom, Philippsburg, Neckarwestheim und Grafenrheinfeld. Das Kraftwerk Biblis steht im Rheingraben, einem der wenigen ernstzunehmenden Erdbebengebiete in Deutschland und ist für Erdbeben bis Stärke 4,5 ausgelegt. In der Gegend hat es in der Vergangenheit durchaus schonmal erheblich stärker gewackelt, das wird auch heiß diskutiert. Ich selbst wohne zwar in Berlin und damit 224 km entfernt vom nächsten Meiler (dem Pannenreaktor bei Krümmel), sitze aber natürlich mit im Boot, und wenn man bedenkt, dass Tschernobyl deutlich weiter weg ist als 200 km, sind mir die 224 km bis Krümmel auch kein großer Trost.

Auch von der rein technischen Seite her habe ich Einwände gegen die Kernkraft: Es erscheint mir einfach wahnwitzig, Uran und Plutonium vereinfacht gesagt als Heizstäbe für eine überdimensionierte Dampfmaschine zu verwenden. Gesellschaftlich gesehen halte ich es für vollkommen unakzeptabel, den Menschen, die hier in den nächsten 100.000 Jahren leben, den Giftmüll aufzubürden. Mein größter Einwand ist aber ein politischer: Ich halte die Menschen als politische Wesen schlicht für ungeeignet, um mit so etwas Gefährlichem wie Kernkraft verantwortungsvoll umgehen zu können. In autokratischen Regimen kann man nicht davon ausgehen, dass hinreichend für das Wohl der allgemeinen Bevölkerung vorgesorgt wird, allenfalls wird man dafür sorgen, dass die Luxusvillen und -wohnungen der Parteikader/höheren Offiziere der Militärregierung/Großfamilie des Diktators weit genug von den Meilern entfernt stehen, wie man an unzähligen Beispielen mit Kernkraft, vor allem aber auch mit chemischen Gefahrenstoffen sehr gut sehen kann. In demokratischen Staaten ist die Sorgfalt der politischen Aufsicht über so eine Technik immer gefangen im Spannungsfeld zwischen dem Lobbyismus der Kernkraftwerksbetreiber einerseits und dem öffentlichen Druck auf die Politiker (bzw. deren Angst vor der nächsten Wahl) andererseits. Wie man momentan anhand diverser Enthüllungen sehr schön sehen kann, erreicht die Sorgfalt der Aufsicht und die Höhe der Sicherheitsstandard in den Jahren unmittelbar nach einem schweren Unfall bei der Kernkraft ein Maximum und sinkt dann bis zum nächsten Unglück auf ein Minimum herab, weil die öffentliche Aufmerksamkeit fehlt. Auch in Deutschland wurde bis vor kurzem diskutiert ob man die Sicherheitsanforderungen nicht etwas lockern sollte — und das, obwohl bei uns der Widerstand gegen die Kernenergie im internationalen Vergleich extrem ausgeprägt ist.

Vor diesem Hintergrund: Liebe Databurg, liebe Leute bei Plus.line, bitte macht weiter mit dem schrittweisen Wechsel von Kernkraft auf Ökostrom, und bitte macht danach gleich weiter mit dem Ausstieg aus fossilen Energieträgern. Für uns alle gilt, dass wir dieses Thema Herstellern und Dienstleistern gegenüber verstärkt ansprechen müssen und dass wir uns politisch engagieren müssen, damit dieses Land aus der Kernkraft so schnell wie technisch vertretbar aussteigt, andere Länder zum Ausstieg ermutigt, die weitere Verbreitung der Kernkraft bekämpft, und selbstverständlich auch nicht nachläßt das Ziel zu verfolgen von fossilen Brennstoffen wegzukommen.

Update:Da stichele ich oben noch mit dem Begriff des Super-GAUs und bekomme (mangels Fernseher) gar nicht mit, dass im Fernsehen derzeit diverse Simpsons-Episoden nicht ausgestrahlt werden, bei denen die Kernkraft in einem schlechten Licht dargestellt wird. — Angeblich aus Gründen der Pietät, vielleicht aber auch um Kernkraftgegner nicht mit noch mehr verbaler Munition in Form von Memen zu versorgen. Das ist natürlich eine Aufforderung, sich diese Folgen nun erst recht anzusehen und so bin ich auf dieses schöne Zitat von Mr. Burns gestoßen: „Oh, ‘meltdown.’ It’s one of those annoying ‘buzzwords.’ We prefer to call it an unrequested fission surplus.”.

Das Schlimme ist: Wenn man erstmal angefangen hat, sich – mehr oder weniger aus Verzweiflung – mit einer ganz bestimmten Sache intensiver zu beschäftigen, kommt es nicht selten vor, dass sich eine dumpfe Traurigkeit über einen legt. Traurigkeit, dass Multi-Millionen-Dollar-Unternehmen nicht zu schade sind, mit mächtigen Zahlen anzugeben …

Going strong for well over 3 years now, we’re proud that SNDS is now used by over 20,000 organizations to provide transparency over 200 million IPs!

… und dann gleichzeitig für jene zwanzigtausend Organisationen diese schicke Menüleiste hier zu gestalten:

Wo denn da die Menüleiste ist..? Na, markieren wir doch mal mit Strg+A den Inhalt der Seite. Ah, jetzt, ja:

Kann das wahr sein? Sowas muss doch bei der Qualitätskontrolle aufgefallen sein!

Aber bleiben wir mal nicht an der Oberfläche. Für denjenigen, der sich dafür interessiert, kann ich ja nebenbei auch gerne mal zeigen, in welcher Detailgenauigkeit Hotmail Daten erfasst. So stellt sich das – anonymisiert – dar:

Das ist aber noch nicht alles: Ist eine Complaint Rate anklickbar, lassen sich vollständige Mails mit Headern und Inhalten abrufen, in nicht anonymisierter Form. Ich muss also mein voriges Posting in einer Hinsicht korrigieren: Die Information, dass man bei Hotmail absolut keine Details zu den Sperrungsgründen einsehen kann, revidiere ich gerne – man kann erschreckend viele Details einsehen.

Warum ich mich nun nicht übermäßig über diese tollen Debuggingmöglichkeiten freue, sondern das erschreckend finde? Das liegt daran, dass der Zugriff auf das SNDS-Interface wie ebenfalls im vorigen Posting bereits geschildert nicht weniger als den Inhabern von zwanzig E-Mail-Adressen offensteht, die Microsoft aus irgendeinem Grund für autorisiert hält, auf diese Informationen zuzugreifen. Dazu gehören nicht nur einige E-Mail-Adressen unses Uplink-Providers, sondern auch die jeweils allgemeinen Kontaktadressen (info@...) eines bundesweiten Ökolandbaubetriebs, eines Kabelnetzbetreibers, eines Herstellers von Papierservietten, einer Landmetzgerei im Westerwald, eines Rechenzentrums aus Düsseldorf, einer Kunststoffverarbeitung und eines Unternehmens für Kreditkartensicherheit. Alle diese könnten, wenn sie denn wollten, Einsicht in die statistischen Werte der Mailzustellungen aus unserem Netz an Hotmail nehmen und dabei auch unbearbeitete, sprich: in keinster Weise anonymisierte E-Mails einsehen. Selbst AOL, von denen ich in puncto Mail nun auch nicht sonderlich viel halte, schafft es, zumindest E-Mail-Adressen und andere Daten, die irgendwie personenbezogen aussehen, aus den Spam-Complaints herauszuredigieren. Hotmail nicht.

Und während wir hierzulande politisch um die Vorratsdatenspeicherung ringen, sei nur kurz angemerkt, dass man im SNDS-Kalender die letzten vier Monate zurück klicken und die dafür bei Hotmail abgelegten Daten einsehen kann. Und zwar, wie gesagt, auch die Mailinhalte. Das verlangt hierzulande nicht mal die Vorratsdatenspeicherung.

Der heutige Freitag bot eine lustige Überraschung: Plötzlich konnten von keinem unserer Hosts aus mehr Mails an Adressen unter der Domain hotmail.com zugestellt werden. Gestern ging’s noch. Heute nicht mehr.

Ich empfehle jedem Kunden, der für eingehenden Mailverkehr gerne eine Blacklist einsetzen möchte, ausschließlich welche zu verwenden, die auch nachvollziehbar machen, warum jemand gelistet wird: Sprich, wo man eine Message-ID, eine Beispiel-Mail oder auch nur wenigstens einen Timestamp erfahren kann, nach dem man im Logfile suchen kann. Bei Hotmail gibt es so etwas nicht. Also, so überhaupt nicht. Man kann nichts nachschlagen; man bekommt nur einen Link auf eine Seite, die die Statuscodes erklärt und die einem „hilfreich“ mitteilt:

Die E-Mail wurde von Windows Live Hotmail wegen Verletzung der Richtlinien zurückgewiesen. Ursache für die Zurückweisung können Spam-verdächtige Inhalte oder die Zuverlässigkeit der IP-Adresse/Domäne sein. Wenn Sie kein E-Mail-/Netzwerkadministrator sind, wenden Sie sich an Ihren E-Mail-/Netzwerk-Dienstanbieter, um Unterstützung zu erhalten.

Darin war Microsoft ja immer schon groß: Jeden, der irgendwelche Probleme hat, an den Administrator zu verweisen – aber jenem dann nicht einen Deut Hilfestellung zu geben, was für Probleme man mit einem hat, denn als Administratoren der Mailserver sehen wir in unseren Logs keinen Deut mehr als das, was auch die Enduser in ihren Bouncemails sehen. Pickel bekomme ich auch immer dann, wenn ich als Grundlage für ein Blacklisting Phrasen wie „…könnte…“ oder ganz besonders „…oder…“ lese. Ja Himmel nochmal, die Sperrung ist doch nicht vom Himmel gefallen; die wird doch einen konkreten Grund haben – wieso nennt ihr dann nicht einfach den konkreten Grund, statt mit verschiedenen theoretischen Möglichkeiten absolut überhaupt nicht hilfreich zu sein?

Ich möchte kurz einwerfen, dass wir selbstverständlich eine strikte Anti-Spam-Politik fahren. Wir filtern selbst Spam aus, so gut es geht; wir betreiben natürlich keine offenen Relays; wir stopfen Sicherheitslücken in Webapplikationen, die einen Spamversand ermöglichen; wir verpflichten unsere Kunden, Mailings nur mit confirmed Opt-In zu betreiben; und sollte wirklich mal ein Kunde als Spammer auffallen, wird ihm auch tatsächlich gekündigt. Nicht ohne Grund findet man praktisch nie auch nur einen unserer Server auf irgendwelchen Blacklists, außer vielleicht mal temporär zwischen Feststellen und Behebens eines Problems. Insofern ist es schon verwunderlich, wenn Hotmail plötzlich Mails von Hosts abweist, die in den Augen der gesamten restlichen Welt absolut „sauber“ sind – immerhin gibt es genug Massen-RBL-Checker, bei denen wir problemlos verifizieren können, dass Hosts, von denen Hotmail nichts annehmen will, definitiv auf keiner Blacklist stehen.

Kommen wir also zum „was tun“, und da redirected Hotmail einen auf dieses hübsche Formular, das man bei Zustellungsproblemen bitte ausfüllen möge:

https://support.msn.com/eform.aspx?productKey=edfsmsbl&ct=eformts&st=1&wfxredirect=1

Da geht’s dann los:

• Primärer Kontaktname für das Unternehmen
• Primäre E-Mail-Adresse für das Unternehmen
• Aus welcher Domäne heraus senden Sie?
• Wie würden Sie Ihre Firma oder sich selbst beschreiben?

Gut, soweit noch nachvollziehbar und auch kein Problem – vor allem, da man sich beim letzten Punkt durchaus als „Internetdienstanbieter (ISP)“ oder „E-Mail-Dienstanbieter (ESP)“ klassifizieren kann. Das hat nur keinen Einfluss auf den Rest des Formulars, der wie folgt aussieht:

• Wie lauten die IP-Adressen Ihrer ausgehenden E-Mail-Server (aus der Perspektive des empfangenden Mailservers)?
• Handelt es sich bei Ihrem Server um einen dedizierten oder einen freigegebenen Server?
• Geben Sie bitte zur schnellen Lösung des Problems möglichst viele Details an, einschließlich des Datums und der Uhrzeit, zu denen das Problem auftrat, einer Beschreibung des Vorgangs, den Sie ausführen wollten, der genauen Schritte, durch die das Problem verursacht wurde, sowie detaillierter Informationen über möglicherweise zurückgegebene Fehlermeldungen.
• Kopieren Sie alle Fehlermeldungen, und fügen Sie sie ein:
• Welchen Internetdienstanbieter verwenden Sie?
• Welches Betriebssystem verwenden Sie?
• Nennen Sie Ihre E-Mail-Übertragungssoftware.
• Nennen Sie Ihre E-Mail-Listen-Verwaltungssoftware.
• Wie werden zurückgesendete Nachrichten (Unzustellbarkeitshinweise) von Ihrem System bearbeitet?
• Wie häufig senden Sie E-Mail?
• Welchen Umfang weisen diese E-Mail-Sendungen auf?
• Nennen Sie einige der Konten innerhalb der Systeme von Microsoft, an die Sie zu senden versucht haben.
• Werden in Ihren SMTP-Protokollen fehlerhafte Transaktionen angezeigt, wenn Sie versuchen, E-Mails an Adressen bei MSN, Windows Live Hotmail oder andere MSN-Dienste zu senden? Wenn ja, fügen Sie diese Einträge hier ein.
• Können Sie von Ihren E-Mail-Servern eine Verbindung via Telnet mit Port 25 von „mx1.hotmail.com“ herstellen?
• Können Sie die Route zu 216.32.183.201 von Ihren E-Mail-Servern rückverfolgen?
• Geben Sie Beispiele einiger von Ihnen gesendeten Nachrichten einschließlich der Kopfzeilen an (aus der Perspektive der Empfänger). Kopieren Sie den Text und fügen Sie ihn hier ein.
• Auf welche Art werden Empfänger Ihren E-Mail-Listen hinzugefügt?
• Geben Sie die URL Ihrer Website an.
• Geben Sie die URL Ihrer Datenschutzrichtlinie an.
• Geben Sie die URL an, unter der sich Benutzer für den Empfang Ihrer E-Mails entscheiden können.
• Geben Sie die URL an, unter der sich Benutzer dauerhaft von Ihrer E-Mail-Liste streichen lassen können.
• Sind Sie derzeit Kunde von Return Path?
• Nehmen Sie am Sender Score Certified-Programm teil?
• Veröffentlichen Sie SPF (Sender Policy Framework)-/Sender-ID-Datensätze für Ihr IP?
• Verwenden Sie gesonderte IPs für Transaktionskommunikation im Gegensatz zu Werbe-/Abonnement-Marketingkommunikation?
• Nehmen Sie am Junk-Mail-Meldeprogramm (Junk Mail Reporting Partner Program, JMRPP) teil?
• Setzen Sie Smart Network Data Services ein?

Alle diese Fragen sind verpflichtend zu beantworten – dabei sind drei Viertel davon für uns als ISP überhaupt nicht sinnvoll beantwortbar: Welches Betriebssystem verwenden Sie? – Ja soll ich da alle Betriebssysteme aller Server aufführen?! Nennen Sie Ihre E-Mail-Übertragungssoftware – Äh, „verschiedene“?! Wie häufig senden Sie E-Mail? – Nun ja, hm, „sehr häufig, denn wir hosten ein paar tausend Domains“?! Geben Sie die URL an, unter der sich Benutzer für den Empfang Ihrer E-Mails entscheiden können – Nun, sagten wir bereits, dass wir ISP sind? Nicht wir verschicken diese Mails!

Besonders großartig finde ich persönlich die Aufforderung, einige Mails mit Headern und Inhalt in das Formular zu kopieren. Ist Microsoft sich im Klaren darüber, dass wir als ISP nach geltendem Datenschutzrecht überhaupt nicht berechtigt sind, die Kommunikation unserer Kunden einzusehen?

Der Witz schlechthin ist schließlich: Es ist auch nicht möglich, postmaster@hotmail.com oder abuse@hotmail.com zu erreichen – die SMTP-Verbindung wird nämlich bereits nach dem MAIL FROM: abgewiesen, nicht erst nach dem RCPT TO:. Ich bin mir nicht sicher, ob das noch als RFC-konform angesehen werden kann, denn eigentlich handelt es sich hierbei um Adressen, die verpflichtend bestehen und verpflichtend von administrativem Personal gelesen werden sollten.

Tja, was nun? Wir haben nun zunächst Hotmail über einen extern stehenden Relayserver mit der Bitte um Unterstützung angeschrieben. Aber im Grunde sind wir wütend: Besonders, weil Hotmail nun gerade einer der Mailprovider ist, die sich jahrelang einen feuchten Dreck um Spam-Prävention gekümmert haben und nun heute – ähnlich wie zum Beispiel auch AOL – weitestgehend nach Gutsherrenart und nicht nachvollziehbaren Kriterien Hosts blockieren und es selbst versierten und verantwortungsbewussten Postmastern extrem schwer machen, für Abhilfe zu sorgen.

Ganz ehrlich? Ginge es hier nur um mich persönlich und nicht um noch einen Haufen Kunden, würde ich angesichts dieses Verhaltens schlicht sagen: Wenn Hotmail keine Mails mehr von mir will, dann ist das eben so. Das sagt letzten Endes mehr über Hotmail als über mich.

So werde ich aber nun mal gleich wieder meinen Kollegen in seinem Bestreben nach Klärung und ggf. temporären Workarounds unterstützen … und hoffen, dass dieses Trauerspiel ein schnelles Ende findet.

Update

Wir routen alle Mails an Hotmail jetzt erstmal über einen unserer Server, der in einem externen Rechenzentrum in einem ganz anderen IP-Netz steht. Als Workaround tut das erstmal, bis Hotmail sich zu einer Stellungnahme bequemt.

Update 2

Ui, fantastisch: Wenn man sich bei Microsoft ein bisschen umschaut, kann man unter Umständen tatsächlich den in einer riesigen Textwüste versteckten Link „To learn more about the Sender and ISP Services, go here“ finden (kleiner Tipp an Microsoft: Vielleicht mal die Einführung zu Links bei SELFHTML nachlesen, die anschaulich erklärt, warum man Links nicht mit Wörtern wie „hier“ beschriften sollte). Die Zielseite des Links verweist dann schließlich auf die Smart Network Data Services von Microsoft, wo man die Reputation „seiner“ IP-Adressen einsehen kann – nachdem man sich als für die betreffenden Netzbereiche zuständig registriert hat.

Das funktioniert so, dass man dort einen Netzbereich eingibt und SNDS dann schaut, ob die Reverse Lookups der IPs aus diesem Netzbereich alle in der gleichen Domain liegen, dann sind postmaster@ und abuse@ unter dieser Domain autorisiert; zusätzlich wird das Whois abgegrast. SNDS erklärt auch den Algorithmus:

The WHOIS approach queries global, regional, and national IP registrars, such as ARIN and APNIC, using the first IP in the range to find the most specific allocation record covering it. It then looks to make sure the range being requested isn’t larger than the record covers. If so, it authorizes any email addresses contained in the record.

Das ist natürlich prima, denn in unseren Netzbereichen stehe ich natürlich mitsamt E-Mail-Adresse drin. Also flugs den Vorgang gestartet – daraufhin findest SNDS sage und schreibe zwanzig E-Mail-Adressen, die sich als für diesen Netzbereich zuständig erklären können, darunter einige Adressen von Plus.line, unserem Uplink-Provider (was ja völlig okay ist) sowie eine ganze Reihe weiterer E-Mail-Adressen von Domains, die definitiv nicht uns gehören, die nicht auf IPs in unserem Netzbereich verweisen und die sowieso schon mal überhaupt nicht in den Whois-Einträgen unserer Netzbereiche stehen. Nur eine E-Mail-Adresse fehlt in der Liste: Meine. Also, nur damit hier keine Missverständnisse entstehen:

$ whois 82.98.87.192
[Querying whois.ripe.net]
[...]
inetnum:        82.98.87.192 - 82.98.87.255
netname:        JONASPASCHE-FFM-003
descr:          Jonas Pasche
descr:          Albert-Schweitzer-Strasse 2d, Mainz
country:        DE
admin-c:        JP55128-RIPE
tech-c:         PLN
status:         ASSIGNED PA
mnt-by:         PLUSLINE-MNT
source:         RIPE # Filtered
[...]
person:       Jonas Pasche
address:      Albert Schweizer Str. 2d
address:      55128 Mainz
phone:        +49 6131 90667 27
fax-no:       +49 6131 90667 28
e-mail:       mail@jonaspasche.de
nic-hdl:      JP55128-RIPE
mnt-by:       HGC-MNT
source:       RIPE # Filtered
[...]

Tja, soviel zur Auskunft, der Algorithmus „authorizes any email addresses contained in the record“ – schön wär’s. Netterweise bietet Microsoft die Möglichkeit, Probleme mit dem Algorithmus zu melden, aber nicht, ohne gleich anzumerken, dass er natürlich intensiv getestet wurde und dass das SNDS-Team auch so oder so keine manuellen Autorisierungen vornehmen kann:

Although this algorithm has undergone extensive testing, please report any issues, remembering of course to follow the feedback guidelines. Be aware that the SNDS team cannot manually adjust authorizations and will be unable to process any such requests.

Tja. Also hab ich dann mal ein Problem mit dem Algorithmus gemeldet. Und warte dann mal darauf, dass der Algorithmus in Ordnung gebracht wird, denn manuell wird ja nicht autorisiert. Damit ich dann, wenn ich mich möglicherweise irgendwann tatsächlich als für diesen Netzbereich zuständig autorisieren kann, zumindest einmal einsehen kann, was Hotmail möglicherweise gegen uns hat. Aber klar, mit einer Möglichkeit der Aufhebung der Sperrung ist das auch wiederum nicht verbunden, selbst wenn sich hierbei ein Problem zeigen sollte, das tatsächlich bei uns besteht und tatsächlich von uns behoben werden könnte. Insofern – warum mache ich mir die Mühe eigentlich …

Die Registrierung der Zuständigkeit für einzelne IP-Adressen aus unserem Netz ist übrigens kein Problem, sofern das Reverse Lookup irgendwie auf uns verweist, denn die postmaster– und abuse-Adressen betreuen wir bei unseren eigenen Domains ja durchaus selbst. Also habe ich mal zumindest einzelne IP-Adressen hinzugefügt. Ist es nicht beruhigend, dass SNDS freimütig zu allen manuell hinterlegten E-Mail-Adressen nur dieses hier zu sagen hat:

All of the specified IPs have normal status.

Nur ändert das leider nichts daran, dass weiterhin SMTP-Verbindungen auch von den IP-Adressen, von denen SNDS behauptet, sie hätten einen normalen Status, abgewiesen werden:

550 SC-001 Unfortunately, messages from $IP weren’t sent. Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.

Ein wenig fühlt es sich an, als wäre ich in der Twilight Zone. Hoffentlich hat das bald ein Ende. Wir bleiben dran.

Update 3

Ein Facepalm jagt den nächsten. Über unseren Umleitungs-Workaround haben wir es tatsächlich geschafft, eine Mail an abuse@hotmail.com abzusetzen. Prompt trudelt ein Autoresponder ein, der sich mit den Worten

We wanted to thank you and let you know that your report has been received.

freundlich bedankt und darauf hinweist:

Please don’t reply to this message, because it is from an unmonitored email address.

Die fragliche Mail kommt … auch von abuse@hotmail.com. Unmonitored, was?

Update 4

07.03.2011, 12:30 Uhr

Okay, bei postmaster@hotmail.com sieht’s noch schlimmer aus. Hier kommt dann postwendend ein Autoresponder mit der freundlichen Nachricht:

postmaster@hotmail.com is an unmonitored account. If you need assistance, please consult our help pages or visit http://postmaster.live.com.

Hierzu kann ich nur RFC 2821 zitieren:

   Any system that includes an SMTP server supporting mail relaying or
   delivery MUST support the reserved mailbox "postmaster" as a case-
   insensitive local name. [...]
   SMTP systems are expected to make every reasonable effort to accept
   mail directed to Postmaster from any other system on the Internet.
   In extreme cases --such as to contain a denial of service attack or
   other breach of security-- an SMTP server may block mail directed to
   Postmaster.  However, such arrangements SHOULD be narrowly tailored
   so as to avoid blocking messages which are not part of such attacks.

Interessant ist in diesem Zusammenhang auch die Listing-Policy für postmaster.rfc-ignorant.org, die es ausdrücklich als Grund für ein Blacklisting ansieht, wenn Mails an den Postmaster mit einem Autoresponder beantwortet werden, der zum Ausdruck bringt, dass die Mail nicht von einem Menschen gelesen wird:

Further, if a postmaster address contains a „redirecting auto-acknowledgement“, such that it is obvious that the message will not be received by a human (as specified in the RFCs), that shall also be considered a listable offense.

Ah, sehr schön: Sie nehmen das auch ernst und führen hotmail.com tatsächlich auf ihrer Blacklist.

Unnötig zu sagen, dass es bisher weder auf unsere Anfrage an abuse@hotmail.com von Freitag Nachmittag eine Antwort gab, noch auf unsere Anfrage, wieso der SNDS-Algorithmus zwar völlig Fremden erlaubt, Details zum Mailverkehr unserer Netze einzusehen, aber nicht uns, obwohl wir als admin-c eingetragen sind. Und ebenso unnötig zu sagen, dass für die IP-Adressen, die wir manuell autorisiert haben, auch weiterhin „All of the specified IPs have normal status“ angegeben wird. Die fragliche Seite trägt zwar den Hinweis „This data is updated once a day, not real-time so it may not reflect the current state of the system“, aber nachdem das Blacklisting nun schon stolze drei Tage andauert, kann man auch das nicht mehr als Ausrede gelten lassen.

Also, nur um das nochmal festzuhalten: Wir kriegen alle unsere Netze komplett gesperrt, ohne je auch nur eine Abuse-Message erhalten zu haben; wir können SNDS aufgrund eines Fehlers im Algorithmus nicht für unsere Netze nutzen; für einzelne IP-Adressen gibt SNDS faktisch falsche Auskünfte und disqualifiziert sich damit im Grunde; Hotmail erwartet, dass wir zum Debugging Datenschutzverletzungen mit Kundenmails begehen; es gibt keine RFC-konforme Postmaster-Adresse; Mails an abuse@hotmail.com werden nicht beantwortet; Mails an msn-snds@microsoft.com werden nicht beantwortet.

Well done, Microsoft.

Update 5

09.03.2011, 11:38 Uhr

Es ist ja nicht so, dass wir nicht zumindest versucht hätten, das absurd lange Beschwerdeformular nach bestem Wissen und Gewissen auszufüllen und alle Fragen höflichst zu beantworten; im schlechtesten Fall zumindest mit „Wir sind selbst ISP; Frage trifft nicht zu“. Nach dem Absenden haben wir eine Ticketnummer erhalten sowie den Hinweis:

Um sicherzustellen, dass Sie die Antwort von Microsoft erhalten, fügen Sie Ihrer „Sicherungsliste“ für E-Mails die Domäne „microsoft.com“ hinzu. Geht in Ihrem „Posteingang“ innerhalb von 24 Stunden keine Antwort ein, überprüfen Sie die Ordner „Massensendungen“ oder „Junk-E-Mail“.

Zunächst einmal: Ich habe zwar schon etliche Mailserver administriert, sendmail, qmail, postfix, exim … und habe aber dennoch keine Vorstellung, was Hotmail mit einer „Sicherungsliste“ meinen könnte. Offenbar eine Art Whitelist. Aber davon abgesehen:

Hände rauf, wer überrascht ist – die 24 Stunden sind mittlerweile lange um, und natürlich gab es keinerlei Reaktion von Hotmail. Das wirft dann nebenbei auch die Frage auf: Was bitte soll ich mit der Ticketnummer? Es gibt ja keine einzige andere Kontaktmöglichkeit – keine Postmaster-Adresse, keine allgemeine Support-Adresse, auch keine telefonische Hotline; man kann sich auf den Kopf stellen: Alles wird letztlich auf irgendwelche Formulare umgeleitet.

Ist das nicht der Witz schlechthin – mit einem der größten E-Mail-Provider weltweit … kann man nicht per E-Mail kommunizieren.

Sollte tatsächlich irgendwann mal doch noch eine Antwort auf unsere Beschwerde kommen, gehe ich jede Wette ein, dass der Absender vermutlich donotreply@hotmail.com heißen wird und sich in der Mail ein Hinweis finden wird, dass man nicht antworten kann, sondern bitte das Formular unter der folgenden URL ausfüllen möge … (Anekdote am Rande: Bei Ryanair ist das noch viel schlimmer. Dort gibt’s für Beschwerden nicht mal ein Online-Formular. Man muss sich per Fax beschweren, an eine Faxnummer in Irland. Und dabei … eine E-Mail-Adresse angeben. Die Antwort von Ryanair folgt dann per E-Mail – von einer Adresse aus, an die man nicht antworten kann, und mit dem Hinweis, dass, wenn man noch etwas antworten möchte, die E-Mail bitte ausdrucken und zusammen mit seiner Antwort wieder nach Irland faxen möge.)

Wir haben nun erstmal das Beschwerdeformular ein weiteres Mal ausgefüllt, ebenso gewissenhaft, diesmal auf Englisch (das Formular ist auf Deutsch, deshalb hatten wir es beim ersten Versuch auch auf Deutsch ausgefüllt). Und haben dabei auch mal die Ticketnummer erwähnt, die wir bereits erhalten haben. Die Hoffnung stirbt ja bekanntlich zuletzt.

Update 6

10.03.2011, 14:40 Uhr

Holy crap! Wir sind noch zurückhaltend mit Luftsprüngen, aber nachdem wir es jetzt von einigen Hosts aus getestet haben, macht es ganz den Eindruck, als sei die Sperrung aufgehoben. Zurückhaltend sind wir vor allem deshalb, weil wir auch weiterhin (auch über 24 Stunden nach dem zweiten Ausfüllen des Formulars) keinerlei Rückmeldung erhalten haben, also auch nicht unter der von uns extra dafür angelegten Hotmail-Adresse. Wir wissen also nicht nur nicht, warum wir eigentlich gesperrt worden sind; wir wissen auch nicht, warum es jetzt wieder geht – ob da jemand tatsächlich unsere Anfrage gelesen und bearbeitet hat oder ob das alles nur ein bedauerliches Missverständnis war, oder ob schlicht die Sperrung automatisiert nach einer definierten Zeit zurückgenommen wurde und jederzeit wieder erfolgen kann.

Was auch weiterhin nicht funktioniert, ist eine Authentifizierung für unsere IP-Netze bei SNDS (und wer nicht das ganze Blog liest, sondern nur dieses eine Posting hier, möchte vielleicht einen kurzen Blick auf SNDS werfen). Da werden wir gegenüber Hotmail noch dranbleiben müssen.

Für heute können wir uns jetzt aber erstmal einen Moment zurücklehnen und uns den Schweiß von der Stirn wischen … waren ja nur sechs Tage, die Hotmail begründungslos den Mailverkehr aller unserer Kunden abgeklemmt hat.