Alexander (HH): Mailserver unter Linux - Rat erwünscht

Beitrag lesen

Moin Moin!

... Zumindest nicht nach meinem Anspruch an Dokumentation: Doku muss vom eigentlichen Produkt losgelöst verfügbar sein,
Dann dürftest Du mit so ziemlich jeder kommerziellen Software ernsthafte Probleme haben.

mit so mancher, ja. Wobei mein häufigster Kritikpunkt der ist, dass dem Programm ein geheimnisvoller Installer beiliegt, der vollautomatisch und möglicherweise korrekt "irgendwas" tut, und man weiß nicht, was dieses "irgendwas" ist. Eine Anleitung, wie die Software alternativ manuell zu installieren wäre, vermisse ich tatsächlich oft.

Das haben Microsoft und die Installer-Hersteller Anwendern und Entwicklern in den letzten 20 Jahren gründlich abgewöhnt. Unter Windows ist eine Installation von Software, die intensiv MS-Technik benutzt, ohnehin mit massiven Eingriffen in die große Müllhalde alias Registry verbunden, da ist ein guter Installer zumindest der stabilere Weg für den Normalanwender.

Ich fand die Installation unter klassischem MacOS schon immer elegant: Disk Image bzw. Archiv öffnen, Programm auf die Platte kopieren, fertig.

Das geht mit Windows-Software auch, kommt aber eben bei Registry-Geschichten (ActiveX-Controls, ...) schnell an seine Grenzen.

Einige Software gibt es in beiden Varianten: Als Archiv mit Executables und Doku, und als Installer (EXE oder MSI). Beispiele: PuTTY, Startup Control Panel, TightVNC

Die großen, bekannten Projekte sind gut dokumentiert [...]

Aber gerade Consumer-Ware erfreut sich teilweise eines nahezu völligen Fehlens jeglicher Doku, etwa die Mozilla-Produkte. Gäbe es da nicht Millionen von Anwendern, die immer mal wieder irgendwas herausfinden, oder Programmierer, die sich wirklich die Mühe machen, die Sources zu analysieren, um herauszufinden, was da wirklich abläuft ...

Mozilla kenne ich nicht von innen, aber ich denke, dass da noch jede Menge Altlasten aus Netscape-Zeiten mitgeschleppt werden. Vielleicht nicht unbedingt im Code, aber in der Art und Weise, wie die Projekte die entwickelt werden. Mozilla, und dort vor allem Firefox und Thunderbird, hat natürlich ein riesiges Problem, das andere Projekte nicht dermaßen stark haben: Es gibt reichlich Konkurrenz und sehr viele "Kunden", die schnell zu einem Konkurrenzprodukt wechseln, wenn es nicht regelmäßig sichtbare Updates gibt und in vielen Punkten nicht mindestens das Niveau der Konkurrenz erreicht wird.

Lernresistenz habe ich nur dann, wenn ich keinen Sinn in dem erkenne, was ich da lernen soll.
Das ist ein riesiges Problem mit binc und der djb-Software. Du mußt ein völlig neues Konzept lernen, wie Programme miteinander interagieren, nämlich die Geschichte, Kommandozeilenparameter nur teilweise auszuwerten und den Rest stumpf an exec() weiterzureichen. Erst dann kannst Du diese Software wirklich voll nutzen.

Okay, das habe ich so zur Kenntnis genommen und sage: Danke, aber es gibt andere Methoden, die offenbar das gleiche erreichen, und die mir bereits vertrauter sind. Ich sehe nicht ein, wieder etwas anderes zu lernen, ohne dessen Vorzug klar sehen zu können.

Fang an, mit Maschinen unter Last zu arbeiten und Du wirst den Vorteil dieser Methode sehen. Das muß nicht zwangsläufig "Big Iron" sein, auch auf kleinen Embedded-Systemen kann man so sehr viel erreichen, ohne 100W Grundlast aus der Steckdose zu saugen.

Und wie steht es mit der Sicherheit?

Wenn man der Beschreibung glauben darf, ziemlich gut. Aber das ist auch für mich ein nebensächliches Thema - ich bin alleiniger Nutzer des Systems und muss mich nicht vor mir selbst schützen. Wichtig ist mir Stabilität (also störungsfreier Betrieb), leichte Administrierbarkeit und kompaktes Design. Die Tatsache, dass ich als Linux-Greenhorn das Teil in knapp drei Stunden fix und fertig zum Laufen gebracht habe, spricht für sich, finde ich. DAS sind Dinge, die mir wichtig sind, nicht ein Award für elegantes und ästhetisches Softwaredesign.

Dir ist bewußt, dass Du Daten aus dem Netz verarbeitest? Werden die validiert, bevor sie in Dovecot hineinlaufen? Wohl kaum. Und genau deswegen ist es auch auf Single-User-Systemen hinter NAT-Routern wichtig, dass die Software sicher ist.

Aber Dovecot läßt permanent etwas Code mit Root-Rechten laufen, dieser Prozess ist u.a. auch für das Logging zuständig.

Ja. Na und?

Ein Loch an der Stelle und ein Angreifer ist root. Loggt man mit nobody-Rechten, ist ein Angreifer erstmal nur nobody und muß noch ein zweites Loch finden, um root zu werden.

Ich spreche hier noch nicht einmal von gezielten Angriffen, das normale "Grundrauschen" durch Botnetze und Scriptkiddies ist schon schlimm genug.

Zum Mail Process Design liest mal nur FIXME.

Hehe, das habe ich auch noch nicht gesehen.

Eine der ersten Seiten, auf die ich beim willkürlichen Klicken gestoßen bin. Das vermiest den Eindruck eines Projektes schonmal merklich.

Natürlich gibt es zwei Wikis, wäre ja auch langweilig mit nur einem.

Zwei? Ich habe nur ein gefunden.

http://wiki2.dovecot.org/ -- ganz oben im ersten Wiki verlinkt. "Wer lesen kann, ist klar im Vorteil" pflegte mein Ex-Kollege in solchen Fällen zu sagen.

Ja, mag sein. Aber diese Informationen sind eben auch zugänglich, ohne dass man das Source-Archiv bereits in der Hand hat. So wie ich das erwarte und voraussetze.

busybox macht das, binc leider nicht. Blöd, insbesondere weil das wirklich wenig Mühe machen würde.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".