Zum Hauptinhalt springen

6.3 Client-Befehle - Authentifizierter Zustand (Client Commands - Authenticated State)

Im authentifizierten Zustand sind Befehle zulässig, die Postfächer als atomare Entitäten manipulieren. Von diesen Befehlen werden SELECT und EXAMINE ein Postfach für den Zugriff auswählen und in den ausgewählten Zustand eintreten.

Zusätzlich zu den universellen Befehlen (CAPABILITY, NOOP und LOGOUT) sind die folgenden Befehle im authentifizierten Zustand gültig: ENABLE, SELECT, EXAMINE, NAMESPACE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, STATUS, APPEND und IDLE.

6.3.1 ENABLE-Befehl​

Argumente: Fähigkeitsnamen

Antworten: keine spezifischen Antworten für diesen Befehl

Ergebnis:

  • OK - Relevante Fähigkeiten aktiviert
  • BAD - Keine Argumente oder Syntaxfehler in einem Argument

Mehrere IMAP-Erweiterungen erlauben es dem Server, unaufgeforderte Antworten spezifisch für diese Erweiterungen unter bestimmten Umständen zurückzugeben. Server können diese unaufgeforderten Antworten jedoch nicht senden (mit Ausnahme von Antwortcodes (siehe Abschnitt 7.1), die in markierten oder nicht markierten OK/NO/BAD-Antworten enthalten sind, die immer gesendet werden können), bis sie wissen, dass die Clients solche Erweiterungen unterstützen und daher in der Lage sein werden, die Erweiterungsantwortdaten korrekt zu analysieren und zu verarbeiten.

Der ENABLE-Befehl bietet eine explizite Angabe vom Client, dass er bestimmte Erweiterungen unterstützt. Er ist so konzipiert, dass der Client eine einfache konstante Zeichenkette mit den von ihm unterstützten Erweiterungen senden kann, und der Server die gemeinsame Teilmenge aktiviert, die beide unterstützen.

Der ENABLE-Befehl nimmt eine Liste von Fähigkeitsnamen entgegen und fordert den Server auf, die genannten Erweiterungen zu aktivieren. Einmal mit ENABLE aktiviert, bleibt jede Erweiterung aktiv, bis die IMAP-Verbindung geschlossen wird. Für jedes Argument tut der Server Folgendes:

  • Wenn das Argument keine dem Server bekannte Erweiterung ist, muss (muss) der Server das Argument ignorieren.

  • Wenn das Argument eine dem Server bekannte Erweiterung ist und es nicht ausdrücklich erlaubt ist, mit ENABLE aktiviert zu werden, muss (muss) der Server das Argument ignorieren. (Beachten Sie, dass das Wissen über eine Erweiterung nicht unbedingt die Unterstützung dieser Erweiterung impliziert.)

  • Wenn das Argument eine vom Server unterstützte Erweiterung ist, die aktiviert werden muss, muss (muss) der Server die Erweiterung für die Dauer der Verbindung aktivieren. Beachten Sie, dass es keine Möglichkeit gibt, eine Erweiterung zu deaktivieren, sobald sie aktiviert ist.

Wenn der ENABLE-Befehl erfolgreich ist, muss (muss) der Server eine nicht markierte ENABLED-Antwort (Abschnitt 7.2.1) senden, die alle aktivierten Erweiterungen wie oben angegeben enthält. Die ENABLED-Antwort wird gesendet, auch wenn keine Erweiterungen aktiviert wurden.

Clients sollten (sollten) nur Erweiterungen einschließen, die vom Server aktiviert werden müssen. Beispielsweise kann ein Client IMAP4rev2-spezifisches Verhalten aktivieren, wenn sowohl IMAP4rev1 als auch IMAP4rev2 in der CAPABILITY-Antwort angekündigt werden. Zukünftige RFCs können dieser Liste hinzufügen.

Der ENABLE-Befehl ist nur im authentifizierten Zustand gültig, bevor ein Postfach ausgewählt wird. Clients dürfen (dürfen) ENABLE nicht ausgeben, sobald sie ein Postfach SELECT/EXAMINE; Server-Implementierungen müssen jedoch nicht überprüfen, ob kein Postfach ausgewählt ist oder während der Dauer einer Verbindung zuvor ausgewählt wurde.

Der ENABLE-Befehl kann in einer Sitzung mehrmals ausgegeben werden. Er ist additiv; das heißt, "ENABLE a b", gefolgt von "ENABLE c", ist dasselbe wie ein einzelner Befehl "ENABLE a b c". Wenn mehrere ENABLE-Befehle ausgegeben werden, sollte (sollte) jede entsprechende ENABLED-Antwort nur Erweiterungen enthalten, die durch den entsprechenden ENABLE-Befehl aktiviert wurden, d. h. für das obige Beispiel sollte die ENABLED-Antwort auf "ENABLE c" nicht "a" oder "b" enthalten.

Es gibt keine Einschränkungen beim Pipelining von ENABLE. Beispielsweise ist es möglich, ENABLE zu senden und dann sofort SELECT, oder ein LOGIN unmittelbar gefolgt von ENABLE.

Der Server darf (darf) die CAPABILITY-Liste nicht als Ergebnis der Ausführung von ENABLE ändern; das heißt, ein CAPABILITY-Befehl, der direkt nach einem ENABLE-Befehl ausgegeben wird, muss (muss) die gleichen Fähigkeiten auflisten wie ein CAPABILITY-Befehl, der vor dem ENABLE-Befehl ausgegeben wurde. Dies wird im folgenden Beispiel demonstriert. Beachten Sie, dass unten "X-GOOD-IDEA" eine fiktive Erweiterungsfähigkeit ist, die ENABLED werden kann.

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
S: t1 OK foo
C: t2 ENABLE CONDSTORE X-GOOD-IDEA
S: * ENABLED X-GOOD-IDEA
S: t2 OK foo
C: t3 CAPABILITY
S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
S: t3 OK foo again

Im folgenden Beispiel aktiviert der Client die Conditional Store (CONDSTORE)-Erweiterung [RFC7162]:

C: a1 ENABLE CONDSTORE
S: * ENABLED CONDSTORE
S: a1 OK Conditional Store enabled

6.3.1.1 Hinweis an Entwickler von Erweiterungen, die den ENABLE-Befehl verwenden können​

Entwickler von IMAP-Erweiterungen werden davon abgeraten, Erweiterungen zu erstellen, die ENABLE erfordern, es sei denn, es gibt kein gutes alternatives Design. Insbesondere Erweiterungen, die potenziell inkompatible Verhaltensänderungen an bereitgestellten Serverantworten verursachen (und daher von ENABLE profitieren), haben höhere Komplexitätskosten als Erweiterungen, die dies nicht tun.

Letztes Update am