Zum Hauptinhalt springen

6. Client-Befehle (Client Commands)

IMAP4rev2-Befehle werden in diesem Abschnitt beschrieben. Befehle sind nach dem Zustand organisiert, in dem der Befehl zulässig ist. Befehle, die in mehreren Zuständen zulässig sind, werden im minimal zulässigen Zustand aufgeführt (z. B. werden Befehle, die in authentifizierten und ausgewählten Zuständen gültig sind, in den authentifizierten Zustandsbefehlen aufgeführt).

Befehlsargumente, die in den Befehlsbeschreibungen unten durch "Arguments:" identifiziert werden, werden nach Funktion und nicht nach Syntax beschrieben. Die genaue Syntax der Befehlsargumente wird in "Formale Syntax" (Abschnitt 9) beschrieben.

Einige Befehle verursachen die Rückgabe spezifischer Serverantworten; diese werden in den Befehlsbeschreibungen unten durch "Responses:" identifiziert. Siehe die Antwortbeschreibungen in "Antworten" (Abschnitt 7) für Informationen zu diesen Antworten und in "Formale Syntax" (Abschnitt 9) für die genaue Syntax dieser Antworten. Es ist möglich, dass Serverdaten als Ergebnis eines Befehls übertragen werden. Daher geben Befehle, die nicht speziell Serverdaten erfordern, "keine spezifischen Antworten für diesen Befehl" anstelle von "keine" an.

Das "Result:" in der Befehlsbeschreibung bezieht sich auf die möglichen markierten Statusantworten auf einen Befehl und jede spezielle Interpretation dieser Statusantworten.

Der Zustand einer Verbindung wird nur durch erfolgreiche Befehle geändert, die als zustandsändernd dokumentiert sind. Ein abgelehnter Befehl (BAD-Antwort) ändert niemals den Zustand der Verbindung oder des ausgewählten Postfachs. Ein fehlgeschlagener Befehl (NO-Antwort) ändert im Allgemeinen nicht den Zustand der Verbindung oder des ausgewählten Postfachs, mit Ausnahme der SELECT- und EXAMINE-Befehle.

6.1 Client-Befehle - Beliebiger Zustand (Client Commands - Any State)​

Die folgenden Befehle sind in jedem Zustand gültig: CAPABILITY, NOOP und LOGOUT.

6.1.1 CAPABILITY-Befehl​

Argumente: keine

Antworten: ERFORDERLICHE nicht markierte Antwort: CAPABILITY

Ergebnis:

  • OK - capability abgeschlossen
  • BAD - Argumente ungültig

Der CAPABILITY-Befehl fordert eine Auflistung der Fähigkeiten (z. B. Erweiterungen und/oder Änderungen des Serververhaltens) an, die der Server unterstützt. Der Server muss (muss) eine einzelne nicht markierte CAPABILITY-Antwort mit "IMAP4rev2" als eine der aufgelisteten Fähigkeiten vor der (markierten) OK-Antwort senden.

Ein Fähigkeitsname, der mit "AUTH=" beginnt, zeigt an, dass der Server diesen bestimmten Authentifizierungsmechanismus unterstützt, wie in der einfachen Authentifizierungs- und Sicherheitsschicht (SASL) [SASL] definiert. Alle solchen Namen sind per Definition Teil dieser Spezifikation.

Andere Fähigkeitsnamen beziehen sich auf Erweiterungen, Überarbeitungen oder Änderungen dieser Spezifikation. Siehe die Dokumentation der CAPABILITY-Antwort in Abschnitt 7.2.2 für zusätzliche Informationen. Wenn die IMAP4rev1-Fähigkeit nicht angekündigt wird, werden keine Fähigkeiten über den in dieser Spezifikation definierten IMAP4rev2-Basissatz hinaus ohne explizite Client-Aktion zum Aufrufen der Fähigkeit aktiviert. Wenn sowohl IMAP4rev1- als auch IMAP4rev2-Fähigkeiten angekündigt werden, werden keine Fähigkeiten über den in [RFC3501] spezifizierten IMAP4rev1-Basissatz hinaus ohne explizite Client-Aktion zum Aufrufen der Fähigkeit aktiviert.

Client- und Server-Implementierungen müssen (müssen) die STARTTLS- (Abschnitt 6.2.1) und LOGINDISABLED-Fähigkeiten auf Klartext-Ports implementieren. Client- und Server-Implementierungen müssen (müssen) auch die AUTH=PLAIN-Fähigkeit (beschrieben in [PLAIN]) sowohl auf Klartext- als auch auf impliziten TLS-Ports implementieren. Siehe die Sicherheitsüberlegungen (Abschnitt 11) für wichtige Informationen.

Sofern nicht anders angegeben, sind alle registrierten Erweiterungen zu IMAP4rev1 auch gültige Erweiterungen zu IMAP4rev2.

Beispiel:

C: abcd CAPABILITY
S: * CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI LOGINDISABLED
S: abcd OK CAPABILITY completed
C: efgh STARTTLS
S: efgh OK STARTTLS completed
<TLS-Verhandlung, weitere Befehle unter TLS-Schicht>
C: ijkl CAPABILITY
S: * CAPABILITY IMAP4rev2 AUTH=GSSAPI AUTH=PLAIN
S: ijkl OK CAPABILITY completed

6.1.2 NOOP-Befehl​

Argumente: keine

Antworten: keine spezifischen Antworten für diesen Befehl (aber siehe unten)

Ergebnis:

  • OK - noop abgeschlossen
  • BAD - Befehl unbekannt oder Argumente ungültig

Der NOOP-Befehl ist immer erfolgreich. Er tut nichts.

Da jeder Befehl eine Statusaktualisierung als nicht markierte Daten zurückgeben kann, kann der NOOP-Befehl als periodisches Abfragen nach neuen Nachrichten oder Nachrichtenstatusaktualisierungen während einer Inaktivitätsperiode verwendet werden (der IDLE-Befehl; siehe Abschnitt 6.3.13) sollte anstelle von NOOP verwendet werden, wenn Echtzeit-Aktualisierungen des Postfachzustands wünschenswert sind). Der NOOP-Befehl kann auch verwendet werden, um jeden Inaktivitäts-Automatischen-Abmeldetimer auf dem Server zurückzusetzen.

Beispiel:

C: a002 NOOP
S: a002 OK NOOP completed
   . . .
C: a047 NOOP
S: * 22 EXPUNGE
S: * 23 EXISTS
S: * 14 FETCH (UID 1305 FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed

6.1.3 LOGOUT-Befehl​

Argumente: keine

Antworten: ERFORDERLICHE nicht markierte Antwort: BYE

Ergebnis:

  • OK - logout abgeschlossen
  • BAD - Befehl unbekannt oder Argumente ungültig

Der LOGOUT-Befehl informiert den Server, dass der Client mit der Verbindung fertig ist. Der Server muss (muss) eine BYE-nicht markierte Antwort vor der (markierten) OK-Antwort senden und dann die Netzwerkverbindung schließen.

Beispiel:

C: A023 LOGOUT
S: * BYE IMAP4rev2 Server logging out
S: A023 OK LOGOUT completed
(Server und Client schließen dann die Verbindung)

Hinweis: Kapitel 6 ist umfangreich und enthält mehrere Unterabschnitte. Für die vollständige Befehlsliste siehe die einzelnen Unterabschnitte:

Letztes Update am