Inhaltsverzeichnis Stichwortverzeichnis Abstracts
Artikel vom: 23.06.2011

IMAP auf Abwegen

Missbrauch von Mail-Clienten als Dokumentenmanagementsystem

IMAP und eine Verzeichnishierarchie haben viel gemeinsam. Naja, zumindest ein bisschen. IMAP ist explizit zur Verwendung in verteilten Szenarien gedacht. Was laege also naeher, als mal zu versuchen, IMAP als Dateimanagementsystem zu missbrauchen? Zeit fuer Experimente.

• Vorueberlegungen
• Umsetzung

Vorueberlegungen

Wie verteilt man Dateien an viele Nutzer? Man kann verteilte Dateisysteme benutzen, Weboberflaechen oder Replikationssysteme.
Wenn aber hinzukommt, dass die Dokumente niemals geaendert werden sollen, sondern eher den Status einer Bibliothek, eines Nachschlagewerkes bekommen sollen? Dann kann man auch IMAP dafuer missbrauchen. Es bietet eine Handvoll Vorteile:

• Etabliert -- Clients sind vorhanden
  Es gibt mehr als einen brauchbaren E-Mail-Klienten, der IMAP beherrscht. Plattformunabhaengig und im Unterschied zu einem Webinterface in den meisten Faellen auch mit der Option, saemtliche Eintraege fuer Offline-Nutzung zu Synchronisieren.

• Mehrere Dateien als einzelnes Objekt unter einem Namen
  Da die Objekte in einem IMAP nun einmal Mails sind, gelten auch die Spielregeln fuer Mails: Eine davon ist, dass eine Mail mehr als ein Attachment besitzen kann. Damit ist es problemlos moeglich, eine einzelne Hierarchiebene abzubilden, ohne dass die Uebersicht und Durchsuchbarkeit leidet.

• Attribute und Durchsuchbarkeit
  Eine Mail hat einen Absender, Urheber, Verfasser und einen Betreff, Titel, Kurz(!)beschreibung. Diese sind in Mailern ueblicherweise sehr leicht durchsuchbar -- gibt es heute noch Mailer, die nicht schon im Default-Interface ein Eingabefeld zum Durchsuchen der Mails enthalten? Zugegeben, der Vorteil relativiert sich spontan, wenn man Spotlight in Mac OS oder die neue hyperaktive Eingabezeile in modernen Windows-Versionen betrachtet. Dann stellt sich aber stets die Frage, was indiziert ist. Bei einer Mailbox ist das (oder sollte das) gar keine Frage sein. Weitere Dateiattribute koennen einige Systeme zwar auch speichern, aber allzu Netzwerktransparent wird das dann auch nicht. Die Alternative sind Attribute, die direkt am Dokument haengen -- und damit wieder vom Dokumenttyp abhaengig sind. Ach ja, und ein Absendedatum hat so eine Mail ja auch noch ;)

• Noch mehr Flags! Und Verzeichnisse
  Zugegeben, hier wird es duenn -- denn auf viel mehr als auf das "new"-Flag konnten sich die Mailer-Schreiber dann doch nicht einigen. Aber immerhin das funktioniert. Wenn auch nur so lange, bis der erste Mailer es zuruecksetzt.
  Aber immerhin Verzeichnisse werden von IMAP ebenfalls unterstuetzt -- das ermoeglicht noch weitere Hierarchisierungen.

• Relative Einfachheit
  Bevor man einem Geisteswissenschaftler erklaert hat, was ein SVN, ein Repository oder ein verteiltes Dateisystem ist -- oder gar, wie er das auf seinem Mac oder seinem Windows 7 benutzt ist es in den meisten Faellen einfacher, ihm zu sagen, er soll einfach ein Postfach einrichten.

• Vorhandene Serversysteme
  Es ist weder noetig, neue Clientsysteme noch, neue Serversysteme zu entwickeln. In diesem Beispiel wird ein ganz normaler dovecot-Server genutzt werden und die Dokumente werde einfach auf Serverseite in die Maildir-Verzeichnisstruktur eingepflegt.

Das ganze wird -- das soll hier nicht verschwiegen sein -- natuerlich mit ein paar Nachteilen erkauft:

• Erklaeren
  Erklaere einem durchschnittlichen Bueroangestellten, dass das da in seinem E-Mail-Programm keine Mails sind, dass er von dem Account aus keine Mails versenden kann und dass das ganze mit Mails gar nichts zu tun hat.
  Noch dabei?

• "Blinde" Daten
  Die Entwickler von Mail-Programmen moechten die Nutzer vor frustrierenden Erlebnissen bewahren. Postuliere ich. Deshalb pruefen sie saemtliche Eingaben, bevor ein Postfach eingerichtet wird. Und lassen die -- ihrer Meinung nach -- falschen oder unbrauchbaren Angaben nur unter heftigstem Protest durch. Das ist in diesem Szenario misslich, denn, nun ja, es gibt schlicht keine(n)

  • Postausgangs (=SMTP)-Server
  • Gueltige E-Mail-Adresse
  die darf man sich frei ausdenken -- und muss dann damit leben, vom Mailer fuer "inkompetent, aber mach ruhig" erklaert zu werden.

• Selbstdisziplin oder Zeitstrafe
  Gerade, wenn die Dokumente groesser werden, zeigt sich eine haessliche Eigenart der Mailer (die fuer sie nur natuerlich ist): Man klickt eine Mail an und sofort beginnt der (manchmal nicht zu stoppende) Download der Attachments. Je nach Dokumentengroesse kann das unangenehm lange Dauern. Und nein, Text ist keiner in der Mail, es ist ja nur ein Container fuer die Dokumente...

• Aufgeblaehte Datenhaltung
  Das Format, in dem E-Mails gespeichert werden ist rueckstaendig: Es kommt noch aus der Zeit, in der die Existenz von 8-Bit-Zeichensaetzen nicht als sicher galt. Daher werden Anhaenge meist als 7-Bit-Oktett-Stroeme enkodiert. Das kostet natuerlich etwas mehr Speicherplatz -- immerhin wird ein Bit pro Byte verschenkt.

• Read-Only? Not quite!
  Zwar ist es den Nutzern eines Mailers normalerweise nicht moeglich^*, die Mails zu veraendern, aber sie koennen geloescht werden. Das wiederum ist natuerlich hoechst unpraktisch. Daher sollte auf der Serverseite eine Replikation aktiv sein, die ansonsten Dokumente ploetzlich weg sind...

^* ich weiss, mutt erlaubt es.

Umsetzung

Die Umsetzung ist erfreulich schmerzfrei. Man nehme ein FreeBSD und installiere ein dovecot. In der Default-Konfiguration hat jeder Nutzer gleich eine IMAP-Mailbox, die in seinem Home im Verzeichnis ~/Maildir zu liegen kommt und den ueblichen Maildir-Regeln folgt -- vergleiche http://de.wikipedia.org/wiki/Maildir.
Nun braucht es nur noch ein kleines C-Prograemmchen, dass aus einer Dateiliste (und dem, was sonst noch in einer Mail stehen soll) schliesslich eine Mail im von Dovecot verwendeten Format generiert. Dabei steht insbesondere die Konvertierung ins 7-bittige im Vordergrund. Der Ablauf zur "Publikation" von Dateien in einem IMAP-Verzeichnis sieht -- also z.B. so aus:

• Dateien auf den Server bewegen
• Dateien in eine Mail-Datei umformen, dabei
  • Einen Betreff annehmen,
  • ein Datum annehmen,
  • eine Message-ID annehmen oder generieren,
  • Absender und Empfaenger einbetten.
  • Nicht vergessen: Ein- oder mehrere Dateien schliesslich als Attachment encoden und anhaengen.
  Meine Implementation hierzu nimmt alles als Parameter und gibt die komplette Mail nach STDOUT aus, was ja dank konsequenter 7-Bit-Codierung komplett unproblematisch ist.
• Die Ausgabe in eine eindeutig benannte Datei im Verzeichnis ~/Maildir/tmp schreiben und diese dann in ~/Maildir/new verschieben. Schon taucht sie als neue Datei in einem verbundenen E-Mail-Client auf.

Gerade weil die Umsetzung relativ simpel ist (und eine automatische Generierung von Mails mit Text-Inhalten noch einfacher ist, habe ich diese Spielerei fuer einige Anwendungen sehr schnell liebgewonnen. Besonders die oft von den Clienten optimierte Durchsuchbarkeit ist willkommen. Zwei meiner Lieblingsanwendungen:

• Als Vorlesungsarchiv -- mit den Vorlesungsfolien als abgelegte Dateien, Vorlesungstiteln und Zeitstempeln sowie Dozentennamen.
• Als Nachrichtenticker: Diverse Newsfeeds werden abgefragt und Meldungen jeweils in Form einzelner Mails angeboten. Da bei meinen mittlerweile zusammengesammelten Quellen an einem ganz normalen Nachrichtentag um die 3000 Meldungen zusammenkommen, sind noch ein paar Skripte im Hintergrund taetig,um diesen Wust in IMAP-Verzeichnissen zu archivieren. Ansonsten haben einige Mailer leichte Probleme in der Nutzung -- ein Klick auf das Verzeichnis mit den vielen Tausend Mails und der Mailer haengt fuer ein paar Minuten.

Stichworte:

• networking (22)
• office (3)