8 Was wir von fetchmail sonst noch lernen können

Bevor wir zu den allgemeinen Belangen der Software-Entwicklung zurückkehren, wollen wir noch einige spezifische Lektionen der fetchmail-Erfahrung untersuchen.

Die rc-Syntax beinhaltet die optionalen noise-Schlüsselwörter, die vom  Parser einfach ignoriert werden. Sie gestatten eine an Englisch angelehnte Syntax und sind bei weitem lesbarer als die traditionell knappen Schlüssel/Wert-Paare, die man erhält, wenn man diese überflüssigen Schlüsselwörter auslässt.

Diese Schlüsselwörter begannen ihre Karriere als spät nächtliche Experimente, als ich bemerkte, wie sehr die rc-Deklarationen bereits einer imperativen Mini-Programmiersprache ähnelten. (Aus diesem Grund änderte ich auch das ursprüngliche popclient-Schlüsselwort server zu poll).

Mir schien es, als würde eine Anpassung dieser imperativen Mini-Programmiersprache an gewöhnliches Englisch die Benutzung vereinfachen. Obwohl ich ein überzeugter Partisan für die Mach eine Sprache daraus-Schule des Designs bin (Beispiele dafür sind Emacs, HTML und viele Datenbankmaschinen), zweifle ich normalerweise an Englisch-ähnlichen Syntaxen.

Traditionellerweise haben Programmierer eine Tendenz, Steuerungssyntaxen zu bevorzugen, die sehr präzise und kompakt sind und keine Redundanzen beinhalten. Das ist ein kulturelles Erbe aus jener Zeit, als Computerressourcen teuer waren und die einzelnen Phasen des Parsing so einfach und billig wie möglich sein mussten. Englisch auf der anderen Seite, mit seiner 50-prozentigen Redundanz, sah damals nach einem sehr unzulänglichen Modell aus.

Das ist jedoch nicht der Grund, aus dem ich eine der englischen Sprache nahe Syntax normalerweise vermeide. Ich erwähne dieses Argument hier nur, um es zu entkräften. Mit den heutigen billigen CPU-Zyklen und Speicherbits sollte Kompaktheit kein Selbstzweck sein. Heute ist es für eine Programmiersprache wichtiger, für die Menschen bequem in der Handhabung zu sein, als billig für den Computer.

Es bleiben aber andere gute Gründe, um vorsichtig damit zu sein. Einer davon sind die Kosten für die Komplexität des  Parsers -- man will die Komplexität ja nicht so weit aufblähen, dass sie eine bedeutende Quelle für Bugs und Verwirrung unter den Anwendern wird. Ein weiterer ist der, dass eine englisch-ähnliche Syntax von ihrem gesprochenen Englisch oft verlangt, dass es in eine groteske Form gepresst wird, die dann mit einer ethnischen Sprache nur mehr oberflächlich zu tun hat und so verwirrend ist wie eine traditionelle Syntax einer Programmiersprache (was man oft bei so genannten Fourth Generation Languages und kommerziellen Datenbankabfragesprachen beobachten kann).

Die Steuerungssyntax von fetchmail scheint diese Probleme zu umgehen, da die Sprache extrem eingeschränkt ist. Sie kommt nicht einmal in die Nähe einer  Allzweck-Sprache, und die Dinge, die sich damit ausdrücken lassen, sind nicht sehr kompliziert. Das Potential für Verwirrung bei der Unterscheidung zwischen einer kleinen Teilmenge von Englisch und der eigentlichen Steuerungssprache ist daher gering. Ich glaube, es gibt hier eine breiter anwendbare Lektion zu lernen:

16. Wenn Ihre Programmiersprache in keinster Weise  Turing-vollständig ist, können Sie sich mit syntaktischer Glasur anfreunden.

Eine weitere Lehre betrifft Sicherheit durch Unsichtbarkeit (security by obscurity). Einige fetchmail-Anwender baten mich, die Software so zu ändern, dass Passworte in der rc-Datei verschlüsselt werden, so dass Spione sie nicht so leicht entdecken könnten.

Ich folgte dieser Bitte nicht, denn es führt keineswegs zu einem Schutz. Jeder, der das entsprechende Privileg erhalten hat, Ihre rc-Datei zu lesen, wird fetchmail genau wie Sie aufrufen und verwenden können -- und wenn es Ihr Passwort ist, hinter dem er her ist, wird er in der Lage sein, den Dekoder aus dem fetchmail-Quellcode selbst herauszulesen.

Alles, was verschlüsselte .fetchmailrc-Passworte für Sie tun könnten, ist, Ihnen ein trügerisches Gefühl der Sicherheit zu vermitteln, wenn Sie nicht sehr angestrengt darüber nachdenken. Die allgemeine Regel hier ist:

17. Ein Sicherheitssystem ist nur so sicher wie seine Geheimnisse. Hüten Sie sich vor Pseudo-Geheimnissen.