Enterprise Software
Proprietäre Wege fordern ihren Zoll von den Benutzern

Enterprise Software

Der grundlegende Unterschied zwischen Software-Entwicklungen aus dem kommerziellen und dem Open-Source-Bereich liegt darin, dass die kommerziellen Kodierer einen finanziellen Anreiz haben, proprietäre Systeme zu liefern und die Verwendung von völlig offenen Standards entweder zu begrenzen oder zu vermeiden.

Vielleicht weisen sie deshalb die tollsten Sachen zurück, einfach nur, weil sie von jemand anderem entwickelt wurden (und dem anderen Geld bringen). In anderen Lebensbereichen bezeichnen wir ein solches Verhalten als verrückt oder unsozial.

Da gäbe es bereits ein vollkommen perfektes Verfahren, manche Dinge zu realisieren, wie das Simple Mail Transport Protocol (SMTP) für E-Mail oder das Domain Name System (DNS) zur Übersetzung der numerischen IP-Adressen in überschaubarere Domain-Namen. Aber die Software-Anbieter haben wirtschaftliche Vorteile, wenn sie es anders anpacken – und so spielte Microsoft, als sie den Exchange Server bauten, SMTP einfach herunter und wählte proprietäre Alternativen.

Eine Folge davon ist, dass Microsoft Outlook heute Bugs hat, die Microsoft auch zugibt und die noch zu beheben sind. Die Fehler verhindern, dass es SMTP-Mails mit Authentifizierung und SSL-Verschlüsselung senden kann.

Dies ist eine ernste Angelegenheit, denn Authentifizierung und Verschlüsselung gehen Hand in Hand. Nur wenige Leute würden ihren Benutzernahmen oder das Passwort ins Internet schicken, wenn die Daten nicht verschlüsselt sind.

Microsoft behauptet, dass der Bug nur diejenigen Systeme betrifft, die keinen standardmäßigen IP-Port für SMTP verwenden, doch das ist nur die halbe Wahrheit. Die andere Hälfte ist, dass es keinen standardmäßigen IP-Port für verschlüsselte SMTP gibt.

Die Internet Engineering Task Force (IETF) zieht einen solchen Standard zurzeit in Betracht – ein Entwurf befindet sich unter dem Link am Ende des Artikels. Der Entwurf erlischt gegen Ende des Monats und sein Arbeitstitel – draft-hutzler-spamops-00.txt – deutet auf die Wichtigkeit des Dokuments hin. Wenn jeder gezwungen wäre, sich erst bei einem Mail-Server zu authentifizieren, bevor er ihn verwendet, würden weder Endnutzer noch Server-Administratoren von Spam geplagt. Ohne ein Standardverfahren für verschlüsselte Authentifizierung kann ich mir nicht vorstellen, wie jeder gezwungen werden soll, sich zu authentifizieren.

In der Zwischenzeit, ohne einen Standard verfügbar zu haben, bleibt den Firmen nur, ihr Bestes zu tun. Microsoft setzt trotzdem noch auf Exchange. Anti-Spam-Anbieter tun Ähnliches. Der Rest von uns liest die Krümel auf.

Einige Firmen fahren SMTP mit Authentifizierung und Verschlüsselung auf dem üblichen SMTP-Port 25, aber das wird kniffelig, wenn man einen Proxy-Server verwendet, der den Spam vom Front-End des Mailsystems herausfiltert. Ironischerweise liegt der Hauptgrund für viele Unternehmen, ihre Mailserver zu sichern, nicht in der Angst vor Spam, sondern in der Einhaltung von verschiedenen Vorschriften wie “corporate gpovernance” (die neue EU-Regelung für Unternehmensorganisation) und Datenschutz.

Diejenigen, die erkannt haben, wie wichtig es ist, dass die Anwender sich authentifizieren, bevor der Zugang zu den Ressourcen gestattet wird, werden sich zweifellos auf das stürzen was die IETF schließlich zur Verfügung stellt und es schnellstmöglich integrieren. Andere wiederum werden dem Verlangen nicht widerstehen können, ihre eigene inkompatible Lösung zu erfinden.