RackBlogger

In vielen anderen Blogs wurde auch schon darauf hingewiesen: es gibt eine Online-Petition gegen die Zensur und Sperrung von Internetseiten.

Das Verfahren der DNS-Sperre ist technisch betrachtet ziemlich lächerlich - der Wegfall der Unschuldsvermutung und das geplante Loggen der Zugriffe auf die Stopp-Seiten sind aber alles andere als lustig. Man muss sich das mal vorstellen: auf einer geheimen (!) Liste stehen Namen von Servern, bei deren Aufruf (egal ob “aktiv” oder als ungewollte Weiterleitung von einer böswilligen Webseite aus) man protokolliert und als “verdächtig” eingestuft wird…

Nach Meinung vieler Experten ist diese Art der Internetzensur kaum geeignet, um aktiv gegen Kinderpornographie vorzugehen, wird aber mit erheblichen Einschnitten in die Grundrechte bezahlt.

Der Hostblogger hat eine interessante Liste an Links zusammengestellt, die ich hier einfach nochmal aufführe und erweitert habe. Der Artikel der c’t (erster Link) fasst die aktuelle Lage schön zusammen:

• Argumente für Kinderporno-Sperren laufen ins Leere (c’t - Magazin für Computertechnik)
• Die dreizehn Lügen der Zensursula (Lutz Donnerhacke / netzpolitik.org)
• Ein Mäntelchen für’s reine Gewissen (ZEIT Online)
• Phoenix und die Kinderporno-Expertin (Stefan Niggemeier, Medienjournalist)
• Die Grenzen des Stopp-Servers (FAZ)
• Nationale Abschottung durch Sperrverfügungen gegen illegale Inhalte im Internet (Gutachten des Max-Planck-Instituts)
• “Seiten zu sperren, hilft nicht” (Berliner Zeitung)

Also: Petition unterzeichnen, und “Zensursula” eine Absage erteilen.

So sieht ein typischer Samstag aus:

• gemütlich Ausschlafen bis 06:00 (Katze meldet sich zum Frühstück zurück…).
• Katze angeboten, noch ‘ne Runde mit im Bett liegen zu bleiben. Katze akzeptiert schnurrend. Verlängerung bis 09:00.
• 10:00: Katze ist gefüttert. Milchkaffee, Croissant mit Nutella und c’t auf der Terasse.
• 11:00: kurze Fahrt zum Bauhof - altes Geschirr für Polterabend suchen. Leider fast nichts mehr da.
• 12:30: Nudelsalat für den Abend gemacht (Ricotta, Knoblauch, Olivenöl, frischer Basilikum, Salz, Pfeffer, Tomaten und natürlich Nudeln. Leeeecker.)
• 14:00: Fahrt ins Büro. Muss noch ein bisserl wichtigen Papierkram erledigen und brauche Unterlagen dazu, die nur “offline” existieren. Herrliches Wetter - Fenster geöffnet, Kaffee und Schokolade am Schreibtisch.
• gegen 17:30: Polterabend von Freunden - Grill, Bier, Spaß.

Das nächste Wochenende verspricht aber auch schon toll zu werden.

Schon bizzar… Sun hat MySQL gekauft, nun kauft Oracle Sun. Somit wird die MySQL AB dann wohl ein Tochterunternehmen von Oracle.

Ein Kunde hat uns seine Umfirmierung mitgeteilt. Die Daten wurden aktualisiert; der Kunde hat kurz darauf nachgefragt, ob die geänderten Daten dann bei uns “fix” sind. Ich habe (sinngemäß) geantwortet mit

Ja, die Daten sind mindestens bis zur nächsten Umfirmierung so fixiert.

Daraufhin der Kunde:

Die nächste Umfirmierung ist voraussichtlich am 17.06.2478 (falls ihr das schon mal dem Server mitteilen wollt)

Wer selbständig ist[EDIT],[/EDIT] kennt das: alle paar Tage hat man irgendjemanden am Telefon, der zuerst nach der Geschäftsleitung verlangt, und dann tolle Angebote hat: kostenlose Krankenkassen-Vergleiche, Zeitschriften-Abonements zu “Spezialkonditionen”, und so weiter…

Eben hat schon wieder so jemand angerufen. Für solche Fälle habe ich mir nun ein neues Vorgehens-Schema ausgedacht:

• wenn mit unterdrückter Nummer angerufen wird, sage ich nur: “Leider unterdrücken Sie Ihre Rufnummer. Ich will natürlich nur seriöse Gesprächspartner - bitte rufen Sie ggf. nochmal ohne Nummernunterdrückung an” (und dann auflegen bevor der Anrufer darauf antworten kann)
• Wer mit Rufnummer anruft: ich notiere mir die Rufnummer, und lasse mir nochmal den genauen Namen geben (gerade bei den kleinen PKV-Vergleichern oder Aboanbietern ist das manchmal lustig, wenn ich nach der korrekten Firmierung frage und die regelrecht herumdrucksen…)
• Dann lasse ich den Anrufer ca. 2-3 Sätze lang erzahlen um was es geht. Danach drehe ich den Spieß um: zuerst frage ich “Haben Sie auch eine Internetseite”? Häufigste Antwort: “nein, wir beraten telefonisch […]”. Das ist meine Chance Ich frage: “Oh, prima - da kann ich Ihnen gleich ein Angebot machen. Wir bieten nämlich zufällig Domains und Webhosting an. Können Sie mir bitte kurz Ihre Kontaktdaten durchgeben, damit ich Ihnen ein Angebot zuschicken kann?”

Sollte ich jemals so einem Anrufer erfolgreich ein Hosting-Paket andrehen können, werde ich das hier bloggen.

Ein leider häufigeres Problem ist der gefühlte Verlust von E-Mails. Das bedeutet, Kunden glauben, dass E-Mails an sie nicht ankommen, sondern von einem ominösen Spamfilter oder was-auch-immer abgewiesen werden.

Leider liegt die Ursache aber fast immer beim Absender. Wenn wir eine E-Mail nicht annehmen sollten, dann hat das seinen Grund (z.B. Virus enthalten, Server auf Blacklist, etc.). Aber in diesem Fall lehnen wir die E-Mail schon während der SMTP-Verbindung ab, d.h. der Absender sollte von seinem Mailserver eine aussagekräftige Fehlermeldung bekommen. Der Betrieb des Mailclusters ist somit zwar etwas aufwendiger, weil wir während der SMTP-Session auf Viren und Spam filtern statt alles in Ruhe in einer Queue abzuarbeiten. Aber nur so können wir zuverlässige Fehlermeldungen erzeugen statt die E-Mail-Welt mit Bounces an gefälschte Absenderadressen zuzumüllen.

In den wenigen Fällen, in denen der Fehler nicht beim Absender liegt, liegt er dann meist bei unserem Kunden. Der Klassiker: irgendein Rechner im Kundennetzwerk ruft parallel auch die E-Mails ab, und löscht diese anschließend auf dem Server…

Würde der Absender einfach nur die Fehlermeldung lesen, wäre eigentlich klar, warum seine Mail nicht bei unserem Kunden angekommen ist. Aber durch die Desensibilisierung mit “Postmaster”-Mails schaut sich das wohl kaum noch jemand an, sondern vermutet irgend ein technisches Problem.

Aus Kulanz führen wir gerne E-Mail-Recherchen durch und belegen den Kunden anhand der Logfiles, was mit bestimmten Mails passiert ist. Die häufigsten Probleme sind:

• “Inhouse-Mailserver” in Form von schlecht konfigurierten Exchange-Servern, die über eine dynamische DSL-IP-Adresse direkt Mails versenden wollen (und dann natürlich regelmäßig auf Blacklists stehen)
• unfähige Provider, die in der Domain als MX eine IP-Adresse statt einem Hostnamen eintragen
• Spam-Schleudern (”ich habe Ihnen doch nur eine Word-Datei schicken wollen” -> wegen Virus abgelehnt…
• zwischengeschaltete Spam-Appliances, die etwas zu großzügig filtern, oder abgestützte lokale Virenscanner

Eben wurde eine Domain von uns zu einem anderen Provider umgezogen. Aus Neugier habe ich mir nach dem KK-ACK den neuen WhoIs-Eintrag mal angesehen.

Manche Mitbewerber haben den Zweck von “Tech-C” und “Zone-C” wohl nicht richtig verstanden, und tragen dort auch den Domaininhaber ein (als Mailadresse aber “info@[provider]”). Obwohl der in sicherlich 99,9% der Fällen nicht die DNS-Server konfiguriert und betreibt…

Das ich kein großer Freund von PHP bin ist wahrscheinlich nicht neu. Inzwischen fällt es mir aber schwer, PHP überhaupt als Programmiersprache ernst zu nehmen.

Wer mir zuerst sagen kann, welches Ergebnis man denn nach Schritt 5 erwartet (und welches man tatsächlich bekommt), gewinnt einen Kugelschreiber.

$betrag = ‘34.04148′; # Betrag in CHF
echo “Input: $betrag\n”;

# Schritt 1: *20
$betrag = $betrag * 20;
echo “Schritt 1: $betrag\n”;

# Schritt 2: Rundung
$betrag = round($betrag);
echo “Schritt 2: $betrag\n”;

# Schritt 3: / 20
$betrag = $betrag / 20;
echo “Schritt 3: $betrag\n”;

# Schritt 4: * 100
$betrag = $betrag * 100;
echo “Schritt 4: $betrag\n”;
var_dump($betrag);

# Schritt 5: intval
$betrag = intval($betrag);
echo “Schritt 5: $betrag\n”;