Zusammenfassung

  • RFC 6154 definierte im März 2011 optionale Spezialattribute in IMAP-LIST-Antworten. Ein Client kann \Sent, \Drafts oder \Trash finden, auch wenn der sichtbare Ordner anders heißt.
  • \Sent kann bedeuten, dass der Server gesendete Kopien automatisch einträgt; es kann ebenso ein Hinweis an den Client sein, sie dort zu speichern. Ein Ordner kann mehrere Rollen tragen, mehrere Ordner können dieselbe Rolle tragen.
  • Erweiterte LIST-Abfragen können SPECIAL-USE ankündigen. Optionale CREATE- und METADATA-Verfahren erlauben Rollenwünsche, die der Server ablehnen darf. Das IANA-Register koordiniert die Attributnamen.

Der Ordnername war keine zuverlässige Anweisung

Dasselbe Konto wird in zwei Programmen eingerichtet. Das erste speichert gesendete Mails in einem Ordner, dessen Name vertraut aussieht. Das zweite erkennt ihn nicht und erzeugt einen neuen. Nun liegen die Kopien in zwei Geschichten. Es kann auch passieren, dass beide Programme auf den Server warten und der Server auf das Programm. Der Fehler wirkt wie eine Kleinigkeit in den Einstellungen, bis jemand nachsehen will, was er verschickt hat.

Ein IMAP-Implementierungsleitfaden von 1999 behandelte gebräuchliche Namen wie „Sent Mail“ und „Trash“. Solche Gewohnheiten machen Oberflächen lesbar. Sie reichen nicht als Regel für unabhängige Software. Ein Server kann andere Namen wählen, Nutzer können umbenennen, und aus „Gesendet“ lässt sich nicht ablesen, ob der Server die Kopien von selbst einfügt. Der Client musste aus einer Aufschrift einen Arbeitsablauf erraten.

RFC 6154 verschob die Auskunft in die LIST-Antwort. Sie führte \All, \Archive, \Drafts, \Flagged, \Junk, \Sent und \Trash ein. Der Server kann diese Attribute gemeinsam mit den übrigen Eigenschaften der Mailbox melden. Der sichtbare Name darf SentMail, MyDrafts oder eine persönliche Bezeichnung bleiben. Der Client sucht die maschinenlesbare Aufgabe.

Der Server ist dafür der passende Auskunftgeber. Ein frisch verbundenes Programm kennt die Ordnung des Kontos nicht. Der Server kennt die Rollen, die er seinen Mailboxen zugewiesen hat. Er kann sie benennen, ohne den Nutzern vorzuschreiben, wie ihre Ordner heißen müssen. Die Deklaration liefert dem Client Wissen über die Struktur, noch keine Garantie über jede spätere Bewegung einer Nachricht.

Eine Rolle sortiert noch keine Nachricht

Bei \Sent erlaubt der Standard zwei Betriebsarten. Mancher Server legt Kopien ausgehender Nachrichten automatisch dort ab. Anderswo soll der Client die Kopien selbst speichern. Wartet der Client auf einen Server, der das nicht tut, bleibt der Ordner leer. Speichert er selbst, obwohl der Server schon speichert, können Dubletten entstehen. Das Attribut weist auf den vorgesehenen Ort; erst der Nachrichtenlauf zeigt die ausführende Maschine.

Auch die anderen Rollen haben unterschiedliche Mechanismen. \All ist oft eine virtuelle Sicht und kann \Trash und \Junk auslassen. Was \Archive praktisch bedeutet, bestimmt der Server. \Drafts kann eine virtuelle Sammlung markierter Entwürfe sein oder ein Zielordner für die Clientsoftware. \Trash hängt mit dem Löschmodell zusammen und kann einem Client dienen, der das IMAP-Flag \Deleted anders nutzt. Einheitliche Wörter zwingen die Speicher nicht zu identischem Verhalten.

Eine Mailbox kann keine, eine oder mehrere solche Kennzeichnungen tragen. Dieselbe Kennzeichnung kann an mehreren Mailboxen erscheinen. Rollen sind häufig nutzerbezogen: Zwei Personen können eine physische Mailbox teilen, ohne sie beide als ihre gesendete Post zu behandeln. Ein Client, der eine einzige Antwort für jedes Konto voraussetzt, rät weiter, nun mit normiertem Vokabular.

Das IANA-Verzeichnis der IMAP-Mailboxattribute hält Namen und Spezifikationen fest. Es speichert keine Nachrichten und protokolliert nicht, welches Programm eine Kopie eingelegt hat. Die gemeinsame Sprache liegt im Register; die tatsächlichen Briefe liegen im betriebenen Speicher.

Zwischen Bekanntgabe und Einrichtung lag ein Ja oder Nein

RFC 6154 verwendete das erweiterte LIST-Verfahren. Ein Server mit dieser Unterstützung kündigt SPECIAL-USE in CAPABILITY an. Der Client kann nur gekennzeichnete Mailboxen anfordern oder sich die Attribute in der Liste zurückgeben lassen; die Auswahl schließt die Rückgabe ein. Auch eine gewöhnliche LIST-Antwort kann die Attribute bereits enthalten, ohne dass es dafür eine eigene CAPABILITY-Zeichenfolge gibt. Wer eine Verbindung untersucht, muss Befehl und Antwort zusammen lesen.

Zum Entdecken kam ein optionaler Eingriff: Mit USE bei CREATE kann ein Client eine neue Mailbox samt Rolle beantragen, wenn der Server CREATE-SPECIAL-USE anbietet. Der Server kann einen Konflikt ablehnen, eine bisherige Kennzeichnung verschieben oder mehrere gleiche Rollen zulassen. Kann er die gewünschte Mailbox mit dieser Rolle nicht erzeugen, muss er den ganzen Befehl ablehnen und darf die Mailbox nicht halb fertig anlegen. Der Wunsch des Clients ist erst nach einer akzeptierten Antwort wirksam.

Wenn IMAP METADATA unterstützt wird, kann /private/specialuse die Rolle einer vorhandenen Mailbox festhalten und möglicherweise ändern. Der Server muss solche Änderungen prüfen. Ein neuer sichtbarer Name, eine neue Rolle und eine verschobene Nachricht sind getrennte Vorgänge mit getrennten Spuren.

Die Kennzeichnung kann sogar automatische Folgen haben. RFC 6154 beschreibt einen \Junk-Ordner, in den ein Server als unerwünscht bewertete Post schiebt. Wird diese Rolle einer geteilten Mailbox zugeordnet, können fälschlich aussortierte private Nachrichten für andere sichtbar werden. Der Server muss deshalb entscheiden, welche Rollenzuweisung er erlaubt. Ein kleines Attribut kann einen großen Verteilerhebel betätigen.

Die offiziellen Texte erklären, wie Rollen gemeldet, beantragt und geändert werden. Für ein bestimmtes Konto braucht es datierte CAPABILITY- und LIST-Antworten, etwaige CREATE- oder METADATA-Änderungen und den tatsächlichen Ablageort einer gesendeten Kopie. Die Aufschrift am Ordner ist unter diesen Belegen die schwächste.