Das Kreuz mit den Kommentaren

Neulich hatte ich mit einer "StrongSwan"- - einer IPSec-Implementierung für Linux - Konfiguration zu tun als auch mit einer für OpenLDAP.
In der OpenLDAP-Konfig habe ich mal den Fehler begangen, nicht benötigte ACL-Zeilen einfach aus zu kommentieren. Das Problem war, dass in den ACLs Zeilenenden einfach überlesen werden, folgerichtig die aus Kommentierung nicht den beabsichtigten Effekt hatte, insbesondere mehr als beabsichtigt aus kommentiert hat.

Die StrongSwan-Konfiguration ist in dieser Hinsicht fast noch schlimmer. Sie ist in Sektionen eingeteilt. Eine Section hat eine Selektor mit einem folgenden Namen, die direkt am Zeilenanfang stehen müssen. Der Inhalt der Sektion ist alles, was eingerückt ist. Will man Teile einer Sektion unwirksam machen, indem man sie aus kommentiert, so muss das eingerückt passieren, mithin dürfen die Kommentarzeichen ("#") nicht am Zeilenanfang stehen, weil sie sonst eine neue (in aller Regel in dieser Form invalide) Sektion auf machen und insbesondere die restlichen Teile von der eigentlich zugehörigen Sektion "abschneiden".

Eine Bitte an Programmierer (unter Unix): Haltet euch an die Regel, das von einem Hash ("#") an bis zum nächsten Zeilen Wechsel  (newline) alles Kommentar ist, selbst wenn man ansonsten newlines einfach überliest! Und ignoriert Zeilen vollständig, wenn am Zeilenanfang aus kommentiert wird!

Ist E-Mail tatsächlich tot?

Pointiert geschrieben proklamiert +Carsten Koch in seinem Tweet - mit einem Verweis auf einen entsprechenden Artikel in der Welt - das Ende der E-Mail in Unternehmen...

Eigentlich müsste man Ihm und der "Welt" die Bewertung "Thema verfehlt" ausstellen.

Die Lackschäden am neuen Auto - oder - Warum akzeptieren wir so viel Mißt im Internet?

Nicht alles was hinkt, ist ein Vergleich... Wohl wahr.

Vergleicht man "Internet-Angebote" - read: solche, die über das Internet in irgend einer Form anfassbar sind -  mit einem Auto, so könnte man Unsinnigkeiten in diesen Angeboten mit Lackschäden an einem Auto vergleichen und Unsinnigkeiten in zugrunde liegenden Infrastrukturen mit Schäden "unter der Haube".


Zum Beispiel bastelt ein großes deutschsprachiges Business orientiertes social network munter an seiner Oberfläche herum,

• ist aber inzwischen öfters nicht erreichbar,
• nicht in der Lage ein Fehler-Artefakt aus einer regelmäßig versandten e-Mail zu entfernen,
• verwendet ungültige nicht verifizierbare X.509-Zertifikate bei der optionalen Absicherung einer Mailserver-Verbindung - read: "STARTTLS" im SMTP-Dialog (Tat das zumindest bis vor wenigen Monaten) -,
• stellt Kalender-Feeds für die abonnierten Events, die man direkt in seinen Desktop- oder Smartphone-Kalender einbinden kann, per HTTP- statt HTTPS-Link zur Verfügung, sodass jeder Admin eines Proxys, über den die Anfrage läuft, auf den Event-Kalender zugreifen kann - im Gegensatz zu HTTPS und
• lässt die Events (augenscheinlich) Minuten nach deren Endtermin aus dem Kalender verschwinden, sodass man kaum eine Chance hat, sie sich gegebenenfalls noch händisch oder durch Kopieren in einen eigenen Kalender zu konservieren/archivieren.

Zum Beispiel versendet eine große Buchhandlungskette

• Rechnungen mit Euro-Zeichen aber deklarierter ISO-8859-1-Zeichenkodierung (der im Gegensatz zur ISO-8859-15-Zeichenkodierung das EURO-Zeichen gar nicht enthält) und
• Versandtbestätigungen gleich ganz ohne Content-Type- und Charset-Informationen.

Diverse Newsletter-Versender verwenden zwar willkommener weise in ihren Mails einen List-Id-Header - welcher zum zuverlässigen Sortieren von Newsletter- und Mailinglisten-Mails in user spezifische folder dienen soll -, bekommen dafür sogar eine Zertifizierung, verwenden ihn aber vollkommen falsch, sodass der Header seinen Zweck überhaupt gar nicht erfüllen kann (Beispielsweise "List-Id: <batchid>.<campaignid>.lists.customer.tld", also in keiner Weise permanent, wie es der entsprechende RFC sinnvollerweise fordert).

Wenn überhaupt, so werden diese und weitere Fehler erst nach Monaten gefixt.

Wie geschrieben: Das ist alles nichts dramatisches aber macht einiges, selbst für einen erfahrenen Internet-Hasen, schwieriger, noch dazu unnötigerweise und vieles für den typischen Internet-User unmöglich, obwohl es einfach möglich wäre.

Wenn mir jemand die Frage in der Überschrift schlüssig erklären kann; immer her damit :-).

Prozesse und die Realität - offensichtlich schwer zu vereinbaren

"Prozesse" (in einer Firma) dienen der Modellierung der Realität. Ziel ist es, standardisierte Abläufe zu schaffen, die zum einen unter Anlegen von Metriken das Messen von Effizienz erlauben, zum anderen das Einarbeiten neuer Mitarbeiter erleichtern.
Die entwickelten (Geschäfts-) Prozesse sollten alle üblichen aber auch weniger üblichen Aspekte einer Aufgabe abbilden, mithin sollte der "Prozessarchitekt" qua Tätigkeit in den entsprechenden Bereichen und/oder adäquater Analyse der Vorgänge in diesen entsprechendes Wissen besitzen.

So weit so gut. Aber was passiert, wenn dem nicht so ist!? :-) (so breit, wie der Smiley grinsen müßte, bekomme ich ihn auf diese Weise gar nicht :-))

Gute Intention - schlechte Umsetzung

Newsletter sind keine Mailinglisten. Dennoch sind diverse Mail-Header, die für Mailinglisten sinnvoll sind, durchaus auch für Newsletter nicht nur geeignet sondern ebenfalls sinnvoll. Beispiele sind die Header "List-Id" und "List-Unsubscribe".

Warum soll ausgerechnet De-Mail staatlich sanktioniert werden?

Die Pressemitteilung des BITKOM.

Die Notwendigkeit einer staatlichen Sanktion von De-Mail und insbesondere die Notwendigkeit einer besonderen Domain erschließt sich mir nicht; nicht mal nach ein paar Stunden Gedanken zu diesem Thema.

Die Ende-zu-Ende-Verschlüsselung bekommt man mit - zum Beispiel per X.509-Zertifikaten und umgangssprachlich gesprochen - Verschlüsselung mit Zertifikaten hin. Die Authentifizierung des Senders und des Empfängers ebenfalls und die Authentifizierung der Mailhops per SMTP-STARTTLS ebenfalls.

Verwaltung von OIDs für Deutschland - Lizenz zum Geld drucken

Für meinen Arbeitgeber beschaffe ich derzeit einen OID-Arc.

Nicht unüblich ist, einen entsprechenden Prefix kostenfrei (!) unter {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1)} anzulegen (Siehe IANA's Private Enterprise Number (PEN) Request Template)

Nun gibt es aber noch den Bereich {joint-iso-itu-t(2) country(16) de(276)}, der für ein solches Anliegen sehr viel besser geeignet erscheint. Noch dazu ist die Registrierung laut mündlicher Auskunft auch für Privatpersonen praktikabel,  unter bestimmten Umständen für bestimmte Gruppen sogar kostenfrei. Seit kurzem (Stand Januar 2011) steht dort aber ein Verweis auf den Knoten {iso(1) member-body(2) de(276)}.

Systematischer Handel mit Millionen EC-Daten?

"@zdf_wiso" hat auf Twitter am 14. Oktober 2010 um etwa 10:45 gefragt, "

  Was denkt Ihr über den neuen Datenskandal? http://fb.me/BRidLv7a"

Wenn wir - die Gesellschaft - weiter versuchen, alle diese Verfehlungen mit Gesetzen zu regeln, werden wir uns zu Tode regeln und eine Menge mehr Verwaltung generieren.

Unix-Systeme partitionieren

Ich bin Informatiker im Unix-/Linux-/Netzwerk-Bereich.

Neulich war ich bei einem "Kunden", der einen Unix-Server mit diversen Daemons betreibt. Darunter ein Squid. Die Partitionierung war offensichtlich beim Default der entsprechenden Distribution belassen: Eine Root- und eine "/daten"-Partition.