Flacher Privater Namensraum im IMAP-Protokoll ============================================= 2008-12-03, Bernhard Herzog 2009-01-21, Bernhard Reiter Zusammenfassung --------------- "Flache private Namensräume", also private Ordner ("mailboxen") parallel zu dem besonderen Ordner "INBOX", sind konform to den IMAP-Standard-RFCs. Konzeptuell gibt es nur dann ein Problem, wenn weitere nicht-private Namensräumen bei einer Installation hinzugenommen werden sollen und der entsprechende Präfix bei Nutzern schon als Präfix existiert. Das dürfte in der Praxis irrelevant sein, weil meist exakt zwei andere Namensräume fest stehen und sich nicht mehr ändern: "user/" (andere Nutzer) und "shared/" (kontolose Nutzer). Weitere Schwierigkeiten haben also mit den Implementationen zu tun: Davon bemerkenswert: a) Der Klient sollte auseinanderhalten können, was Ordner anderer Nutzer sind. Damit das geht, darf er das leere Ergebniss des NAMESPACE Kommandos für private Ordner _nicht_ als ersten Präfix prüfen, da auch die anderen Namensräume mit "" beginnen und eventuell nicht mehr erkannt würden. b) Es scheint sinnvoll, dass Server das Anlegen eines privaten Ordners "user" verweigern, wenn "user/" der Präfix eines anderen Namensraums ist. (Der von uns getestete dovecot verhielt sich anders.) c) Bei einem "nicht-flachen" privaten Namensraum könnten Klienten konzeptuell den Präfix "INBOX/" bei der Darstellung weglassen und den gleichen optischen Effekt wie bei einem "flachen Namensraum" erzielen. Der Ordner "INBOX" selbst wird von IMAP besonders behandelt, sollte immer vorhanden sein und wird von Klienten wahrscheinlich übersetzt dargestellt. Es wäre schön, die "flachen Namensräume" in den IMAP-Standards auszuschliessen, da sie für gut implementierte Klienten keine Vorteile bieten, aber komplizierter für Server und Klienten umzusetzen sind. Einordnung ---------- Der "flache" Namensraum kann Implementierungsschwächen in manchen Klienten ausgleichen und zu einer angenehmeren Darstellung führen. Hier eine englische Besprechung des Problems und der Konfigurationsoption des Cyrus IMAPDs: http://blog.fastmail.fm/2008/08/11/alternate-namespace-imap-port-may-help-outlook-ol-express-apple-mail-and-bis-users/ Namespaces in IMAP ------------------ Grundsätzlich ist die Interpretation von Mailboxnamen von der jeweiligen Implementation abhängig. Es gibt nur wenige Ausnahmen. Dazu der RFC zu IMAP4rev1 [RFC3501] in Abschnitt 5.1.: The case-insensitive mailbox name INBOX is a special name reserved to mean "the primary mailbox for this user on this server". The interpretation of all other names is implementation-dependent. Ausserdem gibt es die Konvention, dass ein '#' am Anfang des ersten Teils eines hierarchischen Mailboxnamens einen Namespace anzeigt (Abschnitt 5.1.2.): By convention, the first hierarchical element of any mailbox name which begins with "#" identifies the "namespace" of the remainder of the name. Zusätzlich definiert der IMAP4 Namespace RFC [RFC2342] Mechanismus, wie sich Klienten über die Konventionen des Servers informieren können. Der NAMESPACE-Befehl liefert Informationen über die Namens-Präfixe, die der Server verwendet, um verschiedene Namensräume zu trennen. RFC2342 sagt jedoch nichts darüber, was passiert, wenn es Mailboxnamen gibt, die zu mehreren Präfixen passen, etwa weil es einen Namensraum ohne Präfix gibt. Flacher Privater Namensraum --------------------------- Eine verbreitete Konvention für den privaten Namensraum, ist INBOX/ als Präfix zu verwenden. Dies ist zum Beispiel die Standardkonfiguration beim Cyrus Imapd. Eine Konsequenz dieser Konvention ist, dass alle privaten Mailboxen Unterordner der INBOX sind. Eine Alternative ist, keinen Präfix für den privaten Namensraum zu haben, so dass auch Ordner auf der gleichen Hierarchieebene wie INBOX möglich sind. Diese Alternative nennen wir hier kurz "flach". Namenskonflikte durch Flache Private Namensräume ------------------------------------------------ Bei flachen privaten Namensräumen hat der private Namensraum keinen Präfix. Die anderen Namensräume, z.B. für freigegebene Ordner von Nutzern, können brauchen dann einen Ordnernamen als Kennzeichnung. Der Klient kann diese mit den NAMESPACE-Befehl abfragen. Damit es keine Konflikte gibt, sollten diese Namen nicht als private Ordnernamen verwendet werden. Üblich sind bei Cyrus IMAP die Namen "user/" für die freigegebenen Ordner anderer Nutzer und "shared/" für Ordner ohne zugehöriges IMAP-Konto. Namenskonflikte sind nur zu erwarten, wenn zu einer bestehenden Installation neue Namensräume hinzukommen und Ordner mit diesen Namem bestehen. Sofern die zwei obigen Namen bereits fest sind, läßt sich das in der Praxis vermeiden. Verhalten von Dovecot --------------------- Getestete dovecot Version: 1.2.alpha3 mit Kolab Patches genauer Revision 310ab696497b aus HG kolab_branch In dovecot lässt sich die Situation mit einem präfixlosen privaten Namensraum und einem weiteren Namensraum mit Präfix mit einer Konfiguration wie dieser nachstellen: namespace private { separator = / inbox = yes list = yes subscriptions = yes } namespace shared { separator = / prefix = users/%%u/ location = ... subscriptions = no list = yes hidden = no } Also, ein privater Namespace ohne Präfix, in dem auch die INBOX ist, und ein Namespace mit Präfix "users/" für freigegebene Mailboxen anderer Nutzer. Dovecot lässt es zu, den Ordner "users" zu erzeugen, der dann auch im privaten Namespace sichtbar ist. Unterordner von "users" können aber nicht angelegt werden. Wenn der oben angegebene shared Namespace vorübergehend deaktiviert wird, können auch Unterordner von "users" angelegt werden. Wenn dann der shared Namespace wieder aktiviert wird, werden diese Unterordner zwar aufgelistet, können aber nicht verwendet werden, weil dovecot ihre Namen als Namen im shared Namespace interpretiert. Es wäre wünschenswert, dass dovecot das Anlegen des Ordners "users" gleich ablehnt, da es sonst in der Darstellung und Erkennung der anderen Ordner bei Klienten zu Verwirrungen kommen könnte. Hinweis zur Kolab-Kompatibilität von Namensräumen ------------------ Der Namensraum für die Ordner anderer Nutzer muss als zweites Element den IMAP (bzw. Kolab) Nutzernamen enthalten. Das ist für das Anstossen der Freibelegtlisten-Erstellung notwendig. Referenzen ---------- [RFC3501] IMAP4rev1 http://www.ietf.org/rfc/rfc3501.txt [RFC2342] IMAP4 Namespace http://www.ietf.org/rfc/rfc2342.txt