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äßt.
Diese Schlüsselwörter begannen ihre Karriere als spätnä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 mußten. Englisch auf der anderen Seite, mit seiner 50-prozentigen Redundanz, sah damals nach einem sehr unzulänglichen Modell aus.
Das ist aber nicht mein Grund, aus dem ich englisch-ähnliche Syntaxen normalerweise vermeide -- ich erwähne es hier nur, um ihn zu demolieren. 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, daß sie eine bedeutende Quelle für Bugs und Verwirrung unter den Anwendern wird. Ein weiter ist der, daß eine englisch-ähnliche Syntax von ihrem gesprochenen "Englisch" oft verlangt, daß es in eine groteske Form gepreßt 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 sogenannten "Fourth Generation"- und kommerziellen Datenbankabfragesprachen beobachten kann).
Die Steuerungssyntax von fetchmail scheint diese Probleme zu umgehen, da die Sprache extrem eingeschränkt ist. Sie kommt einer General Purpose-Sprache nicht einmal in die Nähe, 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, daß Paßwörter in der rc-Datei verschlüsselt werden, so daß 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 Paßwort 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-Paßwörter 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.