.

Für Mail-User gibt es jede Menge Gründe, um POP zugunsten von IMAP abzuschwören. Der Admin des Mailservers jedoch muss sich im Gegenzug mit einer erhöhten Ressourcenbelastung abfinden und den Tiefen des Protokolls herumschlagen. Das Linux-Magazin hilft allen Beteiligten.

Marc Crispin, der Erfinder des Protokolls, nannte IMAP das “bestgehütete Geheimnis im elektronischen Nachrichtenverkehr”. Damals hatte er Recht, weil IMAP ein Exot war. Ironischerweise stimmt seine Aussage aber heute noch. Denn viele Nutzer rufen ihre E-Mails per POP3 von Servern ab, die primär für IMAP gedacht sind und nur wegen der Kompatibilität POPen.

Für den Admin ist POP prima: uralt, gut erforscht und sehr Ressourcen sparend. Aus Sicht des Users ist das anders: POP zwingt den Nutzer dazu, immer auf demselben Client seine E-Mail zu holen, zu lesen, zu sortieren, zu verschieben und nach Kriterien zu durchsuchen. Als Notnagel haben zwar findige Programmierer eine Option ersonnen, die E-Mails nach dem Abholen auf dem Server nicht löschen. Jedoch sind gute POP-Clients rar, die mit »RETR Nummer« E-Mail selektiv downloaden können. Zum Durchsuchen der Inbox muss der Client deren Inhalt aber auch dann komplett zu sich herholen.

Die Lösung heißt IMAP4 [1]. Das Protokoll bewahrt die E-Mails zentral auf dem Server in einer definierbaren, hierarchischen Ordnerstruktur auf. Ein Client erhält Zeit und Bandbreite sparend zunächst nur eine Liste der E-Mail-Header. Das reicht für die Entscheidung, ob es lohnt, die E-Mail auf den Client zu holen. Wichtiger noch ist es aber, auf dem Server die E-Mails durchforsten und nur die Suchergebnisse versenden zu können. Wie das im Detail abläuft, erklärt der erste Artikel im Schwerpunkt.

IMAP ist übrigens auch erste Wahl, wenn ein Groupware- und ein vorhandener Mailserver zusammenarbeiten sollen. So verschaltet der Provider 1&1 seine Open-Xchange-Implementierung [2] per IMAP mit seinen normalen Mailstores und verhindert damit Inkonsistenzen zwischen den Mail- und Groupware-Accounts seiner Kunden.

Armer Server

Die ganze Angelegenheit ist – wie so oft – ein Tausch. IMAP entlastet den Client zu Ungunsten des Servers. Der muss viel Speicherplatz vorhalten, da alle E-Mails samt Attachments auf ihm liegen. Dass er zudem Flags und Namespaces entsprechend dem recht komplizierten IMAP-Standard und in seiner “Freizeit” Indizes zu verwalten hat, macht sein Dasein auch nicht einfach.

Wie aktuelle Open-Source-IMAP-Server mit dieser Herausforderung umgehen und wann und warum sie an ihre Grenzen kommen, erklärt der Artikel ab Seite 36. Den Testern diente das Benchmarktool Mstone als Mittel, die Server an ihre Leistungsgrenzen zu führen – auch dazu gibt’s einen Artikel.

Die Beiträge auf den Seiten 46 und 50 erforschen, wie gut die Clients IMAP implementieren. So viel sei verraten: eher durchwachsen. Technisch eleganter sind die Möglichkeiten, die Serverskripte bieten. Sieve ist der einzige echte Standard auf diesem Gebiet. Der Artikel ab Seite 54 weiß warum.

Die Rechtskolumne ist diesmal Teil des Schwerpunkts, denn sie befasst sich mit der Aufbewahrungspflicht für elektronische Dokumente und den Problemen, die Admins daraus erwachsen. Und weil IMAP so schön ist, beschäftigt sich selbst Michael Schilli mit dem Thema.