7 Fetchmail wird erwachsen

Da war ich also mit einem eleganten und innovativen Design, einem Code, von dem ich wusste, dass er gut funktionierte, da ich ihn jeden Tag verwendete, und einer lebhaft wachsenden Liste von Betatestern. Nach und nach dämmerte mir, dass ich nicht mehr mit einem trivialen persönlichen Hack befasst war, der einigen Leuten nützlich sein konnte. Ich hatte meine Finger in einem Programm, dass jeder Hacker mit einer Unix-Maschine und einer SLIP/PPP-Mailverbindung wirklich braucht.

Durch das Leistungsmerkmal des SMTP-Forwarding zog fetchmail der Konkurrenz soweit davon, dass es realistisch wurde, in ihm einen baldigen Kategorienkiller zu sehen, eines jener klassischen Programme, die eine Nische so kompetent ausfüllen, dass Alternativen nicht einfach nur weggeworfen, sondern fast vergessen werden.

Ich denke, man kann ein solches Ergebnis nicht wirklich planen oder anstreben. Man muss von Designideen hineingezogen werden, die so mächtig sind, dass sie im Rückblick wie offensichtlich, natürlich oder sogar gottgewollt wirken. Die einzige Möglichkeit, so eine Idee zu finden, ist, eine Menge solcher Ideen zu haben -- oder das technische Urteilsvermögen, um die guten Ideen anderer Leute jenseits deren Vorstellungen weiterzuentwickeln.

 Andy Tanenbaum hatte die ursprüngliche Idee, ein einfaches  Unix für den IBM PC zu schaffen, der eigentlich ein Lehrbehelf war. Linus Torvalds hievte das Minix-Konzept weiter als Andrew es wahrscheinlich für möglich gehalten hätte -- und es wurde etwas ganz Wunderbares daraus. In der selben Weise (nur in kleinerem Maßstab) übernahm ich einige Ideen von Carl Harris und Harry Hochheiser und hetzte sie zu Höchstleistungen. Keiner von uns war originell in dem romantischen Sinne, in dem sich die Leute ein Genie vorstellen. Es ist aber so, dass die Wissenschaften, Ingenieurskünste und Softwareentwicklungen nicht von Genies weitergebracht werden, was immer anderes die Hackermythologie auch behauptet.

Die Resultate konnten sich trotzdem sehen lassen -- tatsächlich war es genau die Sorte Erfolg, für die jeder Hacker lebt! Und das bedeutete, dass ich meine Latte noch höher legen musste, um fetchmail so gut zu machen, wie ich nun sah, dass es werden konnte. Ich musste nicht nur für den eigenen Bedarf schreiben, sondern auch Leistungsmerkmale unterstützen, die für Menschen außerhalb meines Orbits wichtig wären. Und simpel und robust sollte mein Programm auch noch sein.

Das erste und mit Abstand wichtigste Leistungsmerkmal, das ich nach dieser Erkenntnis schrieb, war Multidrop-Unterstützung -- die Fähigkeit, Mail aus Mailboxes zu holen, die alle Mail für eine ganze Gruppe von Benutzern angesammelt hatte, und dann jede einzelne davon an die jeweiligen Empfänger zuzustellen.

Ich entschied mich für den Einbau von Multidrop-Unterstützung zum Teil deswegen, weil Benutzer es sehr nachdrücklich forderten, aber der Hauptgrund dafür war meine Überlegung, dass es einige Bugs aus dem Single Drop-Code herausrütteln würde, da es mich zwang, Adressierung in allgemeinster Form zu behandeln. Und genau so war es auch. Das  Parsing RFC 822 konform zu bekommen kostete mich erstaunlich viel Zeit, die aber nicht für ein individuelles, besonders kniffliges Stück Code draufging, sondern weil es eine Menge Details gab, die alle voneinander abhängig waren und peinlich genaue Implementation erforderten.

Die Verbesserung lohnte sich aber; die Multidrop-Adressierung stellte sich als eine exzellente Design-Entscheidung heraus. Ich wusste danach auch, warum:

14. Jedes Tool sollte in der erwarteten Weise nützlich sein, aber wirklich großartige Tools bieten darüber hinaus unerwarteten Nutzen.

Der unerwartete Nutzen von fetchmail mit Multidrop ist der, dass man damit eine Mailingliste mit Alias-Expansion betreiben kann -- und das von der Klientenseite der SLIP/PPP-Verbindung aus. Das bedeutet, dass jemand mit einem ISP-Konto eine Mailingliste ohne Zugriff auf die Alias-Dateien des ISP (Anmerkung: Internet Service Provider) unterhalten kann.

Eine weitere bedeutende Änderung, die von Betatestern gefordert wurde, war die Unterstützung von 8 bit  MIME-Betrieb. Das war relativ einfach, da ich mir Mühe gegeben hatte, den Code 8-bit-clean zu halten. Nicht dass ich die Nachfrage für dieses Feature vorhergesehen hätte, aber ich befolgte einfach eine andere Regel:

15. Beim Entwickeln von Gateway-Software jeglicher Art ist jeder Aufwand gerechtfertigt, um den Datenstrom so wenig wie möglich zu beeinflussen -- und man darf Information niemals wegwerfen, außer der Empfänger verlangt es so!

Wenn ich diese Regel nicht befolgt hätte, wäre 8-bit MIME-Unterstützung schwierig und voller Fehler geworden. So aber war alles, was ich zu tun hatte, die  RFC 1652 zu lesen und ein triviales Schnipsel von Header-generierender Logik einzubauen.

Einige europäische Benutzer nervten mich solange, bis ich eine Option einbaute, die die Anzahl der Nachrichten pro Verbindung begrenzte (so dass sie die Kosten für ihre teuren Telefonleitungen steuern konnten). Ich zierte mich lange Zeit und bin noch immer nicht ganz glücklich damit, aber wenn man für die ganze Welt Software schreibt, muss man auf seine Kunden hören -- das ändert sich auch dann nicht, wenn sie einem dafür nichts bezahlen.