[Postfixbuch-users] cyrus21-admin_2.1.18-1 Debian sql und auxprob

[Patrick Ben Koetter]

* Holm Kapschitzki <holm at oleco.net>:
> Ich habe vor soviele Mechanismen wie möglich einzusetzen, wenn clineten 
> über meine Mailserver Emails abschicken. Nach vielem Lesen auch Deines / 
> Euren Buches bin ich auch zu dem Entschluß gekommen, alle Benutzer vom 
> System abzukoppeln. An dieser Stelle vielleicht noch ein Hinweis. Warum 
> greift eigentlich keiner den Cyrus- Imap in beiden Büchern so richtig 
> auf. Es liegt doch in der Hand Postfix mit Cyrus Imap zu benutzen, der 
> auch wunderbar mit virtuellen Domänen umgehen kann. Stattdessen ist den 
> "Virtual domain mailbox" so viel gewidmet. Ich selber mach mich da 
> lieber an Postfix -> Cyrus Imap -> MySQL. Wobei Cyrus und Postfix 
> dieselben Datenbanken benutzen sollen. Klar ldap ist vielleicht noch 
> wichtiger, da geht Ihr ja richtig gut drauf ein.

Erst mal Danke für's Lob. :)

Ralf und ich haben uns bewußt gegen Cyrus IMAP entschieden. Jeden der Gründe
kann man, einzeln für sich genommen, entkräften, aber in der Summe war uns das
dann nicht das passende Gegenstück zu Postfix:

a)  Cyrus IMAP ist abartig schlecht dokumentiert - zumindest war es das, als
    wir vor 3,5 Jahren begannen, das Postfix Buch zu schreiben. Uns schwebte
    von Anfang an eine möglichst umfassende Beschreibung vor.
    Wir wußten, dass Postfix selbst ein Brocken sein würde (das Manuskript
    umfaßt 550 DIN A4 Seiten) und dann auch noch die notwendige Grundmasse für
    Cyrus IMAP zu schreiben, war einfach nicht aufwandsgerecht und _viel
    wichtiger_ würde auch nicht Cyrus IMAP gerecht werden.
    Das einzige Cyrus IMAP Buch, dass damals auf dem Markt war, war das
    "Managing IMAP"-Buch von O'Reilly <http://www.oreilly.de/catalog/mimap/>
    und das war so schlecht, dass ich es nach dem (ungesehenen) Kauf ins Regal
    gestellt habe und nie wieder hervorgeholt habe.
    Würden wir also jemandem einen guten Dienst erweisen, wenn er/sie in
    unserem Postfix Buch 'gezwungen' wird, Cyrus IMAP als Gegenpart zu nutzen,
    um dann auf halber Strecke von unserem Buch in Sachen Cyrus IMAP "im Regen
    stehen gelassen zu werden"? Nein, das wollten wir nicht.
    Da freue ich mich lieber, dass Peer an einem Cyrus IMAP Buch arbeitet und
    urteile über den Cyrus IMAP Dokumentationsstand erneut, wenn ich Peer's
    Buch gelesen habe. Dieser Punkt kann also bald obsolet sein.

b)  Cyrus IMAP ist nicht so stabil wie Postfix. Das ist nicht unsere
    persönliche Erfahrung, sondern das Ergebnis einer Umfrage, die wir damals
    auf der US Postfix Mailingliste gemacht hatten. Wir haben postmaster
    gefragt, die Systeme mit 10.000 Usern aufwärts betreuen. Einhellige
    Meinung war: "Es ist eine Sammlung von Patches, bei der jeder immer nur
    gerade das hinzufügt, was er benötigt - eine saubere,
    funktionsübergreifende Integration in die Architektur von Cyrus IMAP
    findet nicht statt."
    Das kann ich weder entkräften noch bestätigen, denn meine Erfahrung mit
    Cyrus Produkten beruht ausschließlich auf Cyrus SASL. Diese Erfahrung -
    wer SASL schon mal im Alleingang bewältigen wollte, weiß bestimmt wovon
    ich spreche - hat mir allerdings gereicht. Nicht dass, Cyrus-SASL.2.x
    instabil wäre! Es ist einfach genauso bescheiden dokumentiert wie Cyrus
    IMAP es damals war (ich habe nie wieder nachgeprüft)...
    Postfix hingegen ist _besonders_ stabil; Stabilität ist eines der
    Kern-Features von Postfix. Das IMAP Produkt, dass wir nennen und einsetzen
    wollten, sollte auch in Punkto Stabilität mit Postfix "auf selber
    Augenhöhe" sein, denn wir wollten im Buch von qualitativ hochwertiger
    Software schreiben und kein "Sieh mal, was ich cooles auf freshmeat
    gefunden habe" Buch schreiben.
    Ich habe länger nichts mehr über Instabilitäten von Cyrus IMAP gehört -
    dieser Punkt kann also mittlerweile obsolet sein.

c)  Cyrus IMAP verwendet eine proprietäre Form der Mail-Ablage. Stimmt nicht
    ganz, aber auf den Cyrus-IMAP-Datastore-Zug ist AFAIK kein anderes Produkt
    aufgesprungen. Es gibt mbox und maildir als Mailbox-Formate. Die
    beherrschen die meisten Produkte, mit mehr oder weniger bewußten
    Einschränkungen. Eine Migration von einem zum anderen Produkt wäre also
    relativ einfach zu bewerkstelligen. Nicht mit Cyrus IMAP! Wir haben
    damals keine Tools gefunden. Ein wesentliches Merkmal guter Software ist,
    in unseren Augen, seine Offenheit gegenüber (Quasi-)Standards wie z.B.
    mbox oder maildir.
    Wenn ich nur an all die PHP-basierten Adressbücher denke, die ihre
    Datenfelder frei erfinden und dann daran denke, dass es seit Jahren den
    VCF-Calendar-Standard gibt, kriege ich schon die Krise. Ein Entwickler,
    der heute nicht bestehende Standards nützt oder erweitert, entwickelt ein
    Produkt, dass unnötig hohe TCO erzeugt - es ist nicht konkurrenzfähig und
    verdammt seine Nutzer zur Erstarrung, weil sie nicht wechseln können. Kult
    um Programme ist ja nett, aber wirtschaftlich betrachtet ist er, in meinen
    Augen, unverantwortlich wenn er unwirtschaftlich macht.

Bei Courier IMAP traf all das nicht zu. Courier IMAP ist

a)  hinreichend gut dokumentiert
b)  stabil
c)  nutzt bestehende Standards

Deshalb haben wir uns für Courier IMAP entschieden. Wenn sich das auch bei
Cyrus IMAP einstellt/eingestellt hat, ist er ein Kandidat als Begleiter eines
zukünftigen Postfix Buches.

p at rick

-- 
Das »Postfix«-Buch
<http://www.postfix-buch.com>
saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>