Zusammenfassung

  • RFC 2342 standardisierte die Entdeckung der Namenskonventionen für drei Mailboxklassen.
  • Namensgrammatik, LIST-Sichtbarkeit, Existenz, SELECT-Recht, Nachrichtenabruf, Darstellung und menschliche Lektüre blieben getrennte Belege.

Eine vollständige Antwort war erst der Anfang

Ein Server meldet ("" "/") für persönliche Mailboxen, ("~" "/") für andere Benutzer und NIL für gemeinsam genutzte Bereiche. Der Client kann nun ~mark/INBOX bilden. Doch die Antwort sagt weder, dass Mark existiert, noch dass dessen INBOX für die angemeldete Identität sichtbar oder zugänglich ist.

Genau dieses begrenzte Problem löste RFC 2342. Zuvor mussten Benutzer häufig lokale Präfixe manuell eintragen. NAMESPACE lieferte drei geordnete Felder — Personal, Other Users' und Shared — mit NIL oder einer Liste aus Präfix und Trennzeichen.

Mehrere Wurzeln und unterschiedliche Trenner waren erlaubt. Ein Server durfte nur einen Teil seiner Namensräume offenlegen und je Benutzer anders antworten. Die Meldung war daher eine Grammatik dieser Verbindung, kein vollständiger Bestand.

Ein Namensraum gewährte kein Recht auf Aufzählung

Für andere Benutzer schlägt RFC 2342 vor, % an das Präfix anzuhängen und LIST auszuführen. Gleichzeitig sollte der Server Namen ohne list access nicht preisgeben. Er konnte nur autorisierte Benutzer liefern oder eine breite Anfrage mit NO ablehnen und einen konkreten Namen verlangen.

Ein Beispiel lehnt #Users/% ab, beantwortet aber #Users/Mike/% mit INBOX und Foo. Der Namensraum bestand in beiden Fällen. Anfrage und Offenlegungsregel unterschieden sich. Das schützt Kontonamen, die selbst vertrauliche Struktur oder Angriffsfläche verraten können.

RFC 9051 beschreibt LIST ausdrücklich als Teilmenge aller für den Client verfügbaren Mailboxnamen. Null Antworten sind zulässig. Namen können \Noselect oder \NonExistent tragen; eine Abonnementansicht kann sogar einen Namen ohne vorhandene Mailbox enthalten.

Angekündigter Zweig, gelisteter Name, Abonnement, Existenz und aktuelle Auswählbarkeit sind also keine Synonyme.

Sichtbarkeit und Lesen hatten verschiedene Rechte

Nach RFC 4314 steuert l die Sichtbarkeit in LIST/LSUB, r SELECT/STATUS und s die dauerhafte Seen/Unseen-Information. Weitere Rechte regeln Einfügen, Erstellen, Löschen, Expunge und ACL-Verwaltung.

Eine Mailbox kann sichtbar, aber nicht lesbar sein. RFC 9051 behandelt den Fall l ohne r: LIST sieht den Namen, STATUS kann nicht geliefert werden und die Mailbox muss als nicht auswählbar erscheinen. RFC 8440 kann MYRIGHTS an Extended LIST anhängen, doch ein Recht ist weiterhin keine ausgeführte Operation.

Erst ein erfolgreiches SELECT bringt diese Verbindung in den selected state und liefert FLAGS, EXISTS, UIDNEXT und UIDVALIDITY. Auch dann bleiben FETCH, Client-Dekodierung, sichtbare Darstellung und menschliche Aufmerksamkeit unbelegt.

\Seen ist ebenfalls kein Lesebeweis. FETCH, STORE, Vorschau oder Hintergrundsynchronisierung können das Flag verändern. Das Protokoll speichert Nachrichtenstatus, nicht Verständnis.

Die Spezifikation blieb nützlich, weil sie bescheiden blieb

RFC 2342 entfernte eine Vermutung, ohne das Ergebnis späterer Befehle vorwegzunehmen. Ein Präfix ist Eingabe für die nächste ausführbare Prüfung. Erst deren Bewertung unter aktuellen Rechten und aktuellem Zustand erzeugt einen neuen Beleg.

Das Muster gilt allgemein: Ein Schema kann eine Referenz formen, ohne ihr Objekt zu erzeugen. Eine Capability kann einen Befehl ankündigen, ohne Erfolg zu garantieren. Ein grüner Kontrollwert darf den nächsten Test zulassen, aber nicht das Endergebnis zertifizieren.

NAMESPACE erklärte, wie man anklopft. Es öffnete keine Tür.