7. Server-Antworten (Server Responses)

matches one of the names in the list; similarly, the subset returned by HEADER.FIELDS.NOT contains only the header fields with a non-matching field-name. The field-matching is case-insensitive but otherwise exact. Subsetting does not exclude the [RFC-2822] delimiting blank line between the header and the body; the blank line is included in all header fetches, except in the case of a message which has no body and no blank line.

     The MIME part specifier refers to the [MIME-IMB] header for
     this part.

     The TEXT part specifier refers to the text body of the message,
     omitting the [RFC-2822] header.

        Here is an example of a complex message with some of its
        part specifiers (Hier ist ein Beispiel einer komplexen
        Nachricht mit einigen ihrer Teilbezeichner):

   HEADER     ([RFC-2822] header of the message)
   TEXT       ([RFC-2822] text body of the message) MULTIPART/MIXED
   1          TEXT/PLAIN
   2          APPLICATION/OCTET-STREAM
   3          MESSAGE/RFC822
   3.HEADER   ([RFC-2822] header of the message)
   3.TEXT     ([RFC-2822] text body of the message) MULTIPART/MIXED
   3.1        TEXT/PLAIN
   3.2        APPLICATION/OCTET-STREAM
   4          MULTIPART/IXED
   4.1        IMAGE/GIF
   4.1.MIME   ([MIME-IMB] header for the IMAGE/GIF)
   4.2        MESSAGE/RFC822
   4.2.HEADER ([RFC-2822] header of the message)
   4.2.TEXT   ([RFC-2822] text body of the message) MULTIPART/MIXED
   4.2.1      TEXT/PLAIN
   4.2.2      MULTIPART/ALTERNATIVE
   4.2.2.1    TEXT/PLAIN
   4.2.2.2    TEXT/RICHTEXT


     Es ist möglich, eine Teilzeichenkette des bezeichneten Texts
     abzurufen. Dies geschieht, indem ein öffnender Spitzwinkel
     ("\&lt;"), die Oktett-Position des ersten gewünschten Oktetts, ein
     Punkt, die maximale Anzahl der gewünschten Oktette und ein
     schließender Spitzwinkel (">") an den Teilbezeichner angehängt
     werden. Befindet sich das beginnende Oktett jenseits des Endes
     des Texts, wird eine leere Zeichenkette zurückgegeben.

RFC 3501 IMAPv4 March 2003

     Jeder Teilabruf (partial fetch), der versucht, über das Ende des
     Texts hinaus zu lesen, wird entsprechend abgeschnitten. Ein
     Teilabruf, der bei Oktett 0 beginnt, wird als Teilabruf
     zurückgegeben, selbst wenn dieser Abschnitt stattfand.

        Hinweis: Das bedeutet, dass BODY[]``&lt;0.2048>`` einer 1500-Oktett-
        Nachricht BODY[]\&lt;0> mit einem Literal der Größe 1500 zurückgibt,
        nicht BODY[].

        Hinweis: Ein Teilzeichenketten-Abruf eines HEADER.FIELDS- oder
        HEADER.FIELDS.NOT-Teilbezeichners wird nach dem Teilen des
        Headers berechnet.

     Das \Seen-Flag wird implizit gesetzt; führt dies zu einer
     Änderung der Flags, SOLLTEN diese als Teil der FETCH-Antworten
     enthalten sein.

  BODY.PEEK[\<section>]\&lt;\&lt;partial>>
     Eine alternative Form von BODY[\<section>], die das \Seen-Flag nicht
     implizit setzt.

  BODYSTRUCTURE
     Die [MIME-IMB]-Body-Struktur der Nachricht. Diese wird vom
     Server berechnet, indem die [MIME-IMB]-Headerfelder im
     [RFC-2822]-Header und die [MIME-IMB]-Header geparst werden.

  ENVELOPE
     Die Umschlagstruktur (envelope structure) der Nachricht. Diese
     wird vom Server berechnet, indem der [RFC-2822]-Header in die
     Komponententeile zerlegt wird, wobei verschiedene Felder bei
     Bedarf vorbesetzt werden.

  FLAGS
     Die Flags, die für diese Nachricht gesetzt sind.

  INTERNALDATE
     Das interne Datum (internal date) der Nachricht.

  RFC822
     Funktionell äquivalent zu BODY[], unterscheidet sich in der
     Syntax der resultierenden nicht getaggten FETCH-Daten
     (RFC822 wird zurückgegeben).

  RFC822.HEADER
     Funktionell äquivalent zu BODY.PEEK[HEADER], unterscheidet sich
     in der Syntax der resultierenden nicht getaggten FETCH-Daten
     (RFC822.HEADER wird zurückgegeben).

  RFC822.SIZE
     Die [RFC-2822]-Größe der Nachricht.

RFC 3501 IMAPv4 March 2003

  RFC822.TEXT
     Funktionell äquivalent zu BODY[TEXT], unterscheidet sich in der
     Syntax der resultierenden nicht getaggten FETCH-Daten
     (RFC822.TEXT wird zurückgegeben).

  UID
     Der eindeutige Bezeichner (unique identifier) für die Nachricht.

Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) S: * 2 FETCH .... S: * 3 FETCH .... S: * 4 FETCH .... S: A654 OK FETCH completed

6.4.6. STORE-Befehl (STORE Command)

Arguments: sequence set (Sequenzmenge) message data item name (Nachrichtendaten-Elementname) value for message data item (Wert für Nachrichtendaten-Element)

Responses: untagged responses: FETCH (nicht getaggte Antworten)

Result: OK - store completed (Speichern abgeschlossen) NO - store error: can't store that data (Speicherfehler: jene Daten können nicht gespeichert werden) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)

  Der STORE-Befehl ändert Daten, die mit einer Nachricht in der
  Mailbox verknüpft sind. Normalerweise gibt STORE den aktualisierten
  Wert der Daten mit einer nicht getaggten FETCH-Antwort zurück. Ein
  Suffix ".SILENT" im Daten-Elementnamen verhindert die nicht
  getaggte FETCH-Antwort, und der Server SHOULD davon ausgehen, dass
  der Client den aktualisierten Wert selbst ermittelt hat oder an
  diesem nicht interessiert ist.

       Hinweis: Unabhängig davon, ob das Suffix ".SILENT" verwendet
       wurde, SOLLTE der Server eine nicht getaggte FETCH-Antwort
       senden, falls eine Änderung an den Flags einer Nachricht aus
       einer externen Quelle beobachtet wird. Die Absicht ist, dass
       der Status der Flags ohne Wettlaufbedingung (race condition)
       determiniert ist.

RFC 3501 IMAPv4 March 2003

  Die derzeit definierten Daten-Elemente, die gespeichert werden
  können, sind:

  FLAGS \&lt;flag list>
     Ersetzt die Flags für die Nachricht (außer \Recent) durch das
     Argument. Der neue Wert der Flags wird zurückgegeben, als ob ein
     FETCH jener Flags durchgeführt worden wäre.

  FLAGS.SILENT \&lt;flag list>
     Äquivalent zu FLAGS, aber ohne Rückgabe eines neuen Werts.

  +FLAGS \&lt;flag list>
     Fügt das Argument zu den Flags der Nachricht hinzu. Der neue Wert
     der Flags wird zurückgegeben, als ob ein FETCH jener Flags
     durchgeführt worden wäre.

  +FLAGS.SILENT \&lt;flag list>
     Äquivalent zu +FLAGS, aber ohne Rückgabe eines neuen Werts.

  -FLAGS \&lt;flag list>
     Entfernt das Argument aus den Flags der Nachricht. Der neue Wert
     der Flags wird zurückgegeben, als ob ein FETCH jener Flags
     durchgeführt worden wäre.

  -FLAGS.SILENT \&lt;flag list>
     Äquivalent zu -FLAGS, aber ohne Rückgabe eines neuen Werts.

Example: C: A003 STORE 2:4 +FLAGS (\Deleted) S: * 2 FETCH (FLAGS (\Deleted \Seen)) S: * 3 FETCH (FLAGS (\Deleted)) S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen)) S: A003 OK STORE completed

6.4.7. COPY-Befehl (COPY Command)

Arguments: sequence set (Sequenzmenge) mailbox name (Mailbox-Name)

Responses: no specific responses for this command (keine spezifischen Antworten für diesen Befehl)

Result: OK - copy completed (Kopieren abgeschlossen) NO - copy error: can't copy those messages or to that name (Kopierfehler: jene Nachrichten können nicht kopiert werden oder in jenen Namen) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)

RFC 3501 IMAPv4 March 2003

  Der COPY-Befehl kopiert die angegebenen Nachricht(en) an das Ende
  der angegebenen Ziel-Mailbox. Die Flags und das interne Datum der
  Nachricht(en) SOLLTEN im Kopie beibehalten werden, und das Recent-
  Flag SOLLTE gesetzt werden.

  Wenn die Ziel-Mailbox nicht existiert, SOLLTE ein Server einen
  Fehler zurückgeben. Er SOLLTE die Mailbox nicht automatisch
  erstellen. Sofern er nicht sicher ist, dass die Ziel-Mailbox nicht
  erstellt werden kann, MUSS der Server den Antwortcode
  "[TRYCREATE]" als Präfix des Texts der getaggten NO-Antwort
  senden. Dies gibt dem Client einen Hinweis, dass er einen CREATE-
  Befehl versuchen und den COPY wiederholen kann, falls der CREATE
  erfolgreich war.

  Wenn der COPY-Befehl aus irgendeinem Grund nicht erfolgreich ist,
  MÜSSEN Server-Implementierungen die Ziel-Mailbox in ihren Zustand
  vor dem COPY-Versuch zurückversetzen.

Example: C: A003 COPY 2:4 MEETING S: A003 OK COPY completed

6.4.8. UID-Befehl (UID Command)

Arguments: command name (Befehlsname) command arguments (Befehlsargumente)

Responses: untagged responses: FETCH, SEARCH (nicht getaggte Antworten)

Result: OK - UID command completed (UID-Befehl abgeschlossen) NO - UID command error (UID-Befehlsfehler) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)

  Der UID-Befehl hat zwei Formen. In der ersten Form nimmt er als
  Argumente einen COPY-, FETCH- oder STORE-Befehl mit Argumenten
  entgegen, die für den jeweiligen Befehl geeignet sind. Jedoch sind
  die Zahlen im Sequenzmengen-Argument (sequence set) eindeutige
  Bezeichner (unique identifiers) anstelle von Nachrichten-
  Sequenznummern. Sequenzmengen-Bereiche sind zulässig, es gibt
  jedoch keine Garantie, dass eindeutige Bezeichner zusammenhängend
  sind.

  Ein nicht existierender eindeutiger Bezeichner wird ignoriert,
  ohne dass eine Fehlermeldung erzeugt wird. Daher ist es möglich,
  dass ein UID FETCH-Befehl ein OK ohne Daten zurückgibt oder ein
  UID COPY oder UID STORE ein OK ohne Ausführung von Operationen
  zurückgibt.

  In der zweiten Form nimmt der UID-Befehl einen SEARCH-Befehl mit
  SEARCH-Befehlsargumenten entgegen. Die Auslegung der Argumente ist
  dieselbe wie bei SEARCH; jedoch sind die in einer SEARCH-Antwort
  für einen UID SEARCH-Befehl zurückgegebenen Zahlen eindeutige
  Bezeichner anstelle von Nachrichten-Sequenznummern.

RFC 3501 IMAPv4 March 2003

  of message sequence numbers. Beispielsweise gibt der Befehl
  UID SEARCH 1:100 UID 443:557 die eindeutigen Bezeichner zurück, die
  der Schnittmenge zweier Sequenzmengen entsprechen, des Bereichs der
  Nachrichten-Sequenznummern 1:100 und des UID-Bereichs 443:557.

       Hinweis: Im obigen Beispiel erscheint der UID-Bereich
       443:557. Derselbe Hinweis, dass ein nicht existierender
       eindeutiger Bezeichner ohne Fehlermeldung ignoriert wird,
       trifft auch hier zu. Daher würde dieser Bereich selbst dann,
       wenn weder UID 443 noch 557 existieren, gültig sein und eine
       vorhandene UID 495 einschließen.

       Beachten Sie ebenfalls, dass ein UID-Bereich von 559:* immer
       die UID der letzten Nachricht in der Mailbox einschließt,
       selbst wenn 559 höher ist als jeder zugewiesene UID-Wert. Dies
       liegt daran, dass der Inhalt eines Bereichs unabhängig von der
       Reihenfolge der Bereichsendpunkte ist. Somit schließt jeder
       UID-Bereich mit * als einem der Endpunkte mindestens eine
       Nachricht ein (die Nachricht mit der höchstnummerierten UID),
       es sei denn, die Mailbox ist leer.

  Die Zahl nach dem "*" in einer nicht getaggten FETCH-Antwort ist
  immer eine Nachrichten-Sequenznummer, kein eindeutiger Bezeichner,
  selbst für eine UID-Befehlsantwort. Server-Implementierungen MÜSSEN
  jedoch das UID-Nachrichtendaten-Element implizit als Teil jeder
  FETCH-Antwort einschließen, die durch einen UID-Befehl verursacht
  wurde, unabhängig davon, ob ein UID als Nachrichtendaten-Element
  für den FETCH angegeben wurde.


  Hinweis: Die Regel, das UID-Nachrichtendaten-Element als Teil einer
  FETCH-Antwort einzuschließen, betrifft in erster Linie die Befehle
  UID FETCH und UID STORE, einschließlich eines UID FETCH-Befehls,
  der UID nicht als Nachrichtendaten-Element enthält. Obwohl es
  unwahrscheinlich ist, dass die anderen UID-Befehle eine nicht
  getaggte FETCH-Antwort verursachen, gilt diese Regel auch für diese
  Befehle.

Example: C: A999 UID FETCH 4827313:4828442 FLAGS S: * 23 FETCH (FLAGS (\Seen) UID 4827313) S: * 24 FETCH (FLAGS (\Seen) UID 4827943) S: * 25 FETCH (FLAGS (\Seen) UID 4828442) S: A999 OK UID FETCH completed

RFC 3501 IMAPv4 March 2003

6.5. Client-Befehle - Experimentell/Erweiterung (Client Commands - Experimental/Expansion)

6.5.1. X`<atom>`-Befehl (X`<atom>` Command)

Arguments: implementation defined (implementierungsdefiniert)

Responses: implementation defined (implementierungsdefiniert)

Result: OK - command completed (Befehl abgeschlossen) NO - failure (Fehlschlag) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)

  Jeder Befehl mit dem Präfix X ist ein experimenteller Befehl.
  Befehle, die nicht Teil dieser Spezifikation, einer Standard- oder
  Standards-Track-Überarbeitung dieser Spezifikation oder eines von
  der IESG genehmigten experimentellen Protokolls sind, MÜSSEN das X-
  Präfix verwenden.

  Alle hinzugefügten nicht getaggten Antworten, die von einem
  experimentellen Befehl ausgegeben werden, MÜSSEN ebenfalls mit einem
  X gekennzeichnet sein. Server-Implementierungen DÜRFEN keine solchen
  nicht getaggten Antworten senden, es sei denn, der Client hat sie
  durch Ausgabe des zugehörigen experimentellen Befehls angefordert.

Example: C: a441 CAPABILITY S: * CAPABILITY IMAP4rev1 XPIG-LATIN S: a441 OK CAPABILITY completed C: A442 XPIG-LATIN S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay S: A442 OK XPIG-LATIN ompleted-cay

```
 Server-Antworten (Server Responses)
```
Serverantworten liegen in drei Formen vor: Statusantworten, Serverdaten und Befehlsfortsetzungsanforderung (command continuation request). Die in einer Serverantwort enthaltenen Informationen, die unten in den Antwortbeschreibungen durch „Contents:" gekennzeichnet sind, werden nach Funktion und nicht nach Syntax beschrieben. Die genaue Syntax der Serverantworten wird im Abschnitt „Formale Syntax" beschrieben.

Der Client MUSS darauf vorbereitet sein, jederzeit eine beliebige Antwort zu akzeptieren.

Statusantworten können getagt oder nicht getagt sein. Getaggte Statusantworten geben das Abschlussergebnis (OK-, NO- oder BAD-Status) eines Client-Befehls an und haben ein Tag, das mit dem Befehl übereinstimmt.

Einige Statusantworten und alle Serverdaten sind nicht getagt. Eine nicht getaggte Antwort wird durch das Token "*" anstelle eines Tags angezeigt. Nicht getaggte Statusantworten zeigen Server-Begrüßung oder einen Serverstatus an, der den Abschluss eines Befehls nicht anzeigt (z. B. eine bevorstehende Warnung vor Systemabschaltung).

RFC 3501 IMAPv4 March 2003

Für historische Gründe werden nicht getaggte Serverdaten-Antworten auch als „unsolicited data" (unaufgeforderte Daten) bezeichnet, obwohl streng genommen nur einseitige Serverdaten (unilateral server data) wirklich „unsolicited" sind.

Bestimmte Serverdaten MÜSSEN vom Client aufgezeichnet werden, wenn sie empfangen werden; dies ist in der Beschreibung jener Daten vermerkt. Solche Daten vermitteln kritische Informationen, die die Auslegung aller nachfolgenden Befehle und Antworten beeinflussen (z. B. Aktualisierungen, die die Erstellung oder Vernichtung von Nachrichten widerspiegeln).

Andere Serverdaten SOLLTEN für späteren Bezug aufgezeichnet werden; wenn der Client die Daten nicht aufzeichnen muss oder das Aufzeichnen der Daten keinen offensichtlichen Zweck hat (z. B. eine SEARCH-Antwort, wenn kein SEARCH-Befehl läuft), SOLLTEN die Daten ignoriert werden.

Ein Beispiel für einseitige nicht getaggte Serverdaten tritt auf, wenn die IMAP-Verbindung sich im ausgewählten Zustand (selected state) befindet. Im ausgewählten Zustand prüft der Server die Mailbox auf neue Nachrichten als Teil der Befehlsausführung. Normalerweise ist dies Teil der Ausführung jedes Befehls; daher genügt ein NOOP-Befehl, um auf neue Nachrichten zu prüfen. Werden neue Nachrichten gefunden, sendet der Server nicht getaggte EXISTS- und RECENT-Antworten, die die neue Größe der Mailbox widerspiegeln. Server-Implementierungen, die gleichzeitigen Mehrfachzugriff auf dieselbe Mailbox bieten, SOLLTEN ebenfalls entsprechende einseitige nicht getaggte FETCH- und EXPUNGE-Antworten senden, falls ein anderer Agent den Status von Flags einer beliebigen Nachricht ändert oder Nachrichten entfernt.

Antworten zur Befehlsfortsetzungsanforderung verwenden das Token "+" anstelle eines Tags. Diese Antworten werden vom Server gesendet, um die Annahme eines unvollständigen Client-Befehls und die Bereitschaft für den Rest des Befehls anzuzeigen.

7.1. Server-Antworten - Statusantworten (Server Responses - Status Responses)

Statusantworten sind OK, NO, BAD, PREAUTH und BYE. OK, NO und BAD können getagt oder nicht getagt sein. PREAUTH und BYE sind immer nicht getagt.

Statusantworten KÖNNEN einen OPTIONALEN „response code" (Antwortcode) enthalten. Ein Antwortcode besteht aus Daten innerhalb eckiger Klammern in Form eines Atoms, möglicherweise gefolgt von einem Leerzeichen und Argumenten. Der Antwortcode enthält zusätzliche Informationen oder Statuscodes für Client-Software über die OK/NO/BAD-Bedingung hinaus und wird definiert, wenn eine spezifische Aktion besteht, die ein Client aufgrund der zusätzlichen Informationen ausführen kann.

RFC 3501 IMAPv4 March 2003

Die derzeit definierten Antwortcodes sind:

  ALERT

     Der für Menschen lesbare Text enthält eine besondere Warnung, die
     dem Benutzer in einer Weise präsentiert werden MUSS, die dessen
     Aufmerksamkeit auf die Meldung lenkt.

  BADCHARSET

     Optional gefolgt von einer in Klammern gesetzten Liste von
     Zeichensätzen. Ein SEARCH schlug fehl, weil der angegebene
     Zeichensatz von dieser Implementierung nicht unterstützt wird.
     Falls die optionale Liste von Zeichensätzen angegeben ist, führt
     diese die Zeichensätze auf, die von dieser Implementierung
     unterstützt werden.

  CAPABILITY

     Gefolgt von einer Liste von Fähigkeiten. Dies kann in der
     anfänglichen OK- oder PREAUTH-Antwort erscheinen, um eine
     anfängliche Fähigkeitenliste zu übertragen. Dies macht es für
     einen Client unnötig, einen separaten CAPABILITY-Befehl zu
     senden, wenn er diese Antwort erkennt.

  PARSE

     Der für Menschen lesbare Text stellt einen Fehler beim Parsen des
     [RFC-2822]-Headers oder der [MIME-IMB]-Header einer Nachricht in
     der Mailbox dar.

  PERMANENTFLAGS

     Gefolgt von einer in Klammern gesetzten Liste von Flags, zeigt
     an, welche der bekannten Flags der Client dauerhaft ändern kann.
     Alle Flags, die in der nicht getaggten FLAGS-Antwort, aber nicht
     in der PERMANENTFLAGS-Liste sind, können nicht dauerhaft gesetzt
     werden. Wenn der Client versucht, ein Flag zu speichern, das
     nicht in der PERMANENTFLAGS-Liste ist, wird der Server entweder
     die Änderung ignorieren oder die Zustandsänderung nur für den
     Rest der aktuellen Sitzung speichern. Die PERMANENTFLAGS-Liste
     kann ebenfalls das Sonder-Flag \* enthalten, das angibt, dass es
     möglich ist, neue Schlüsselwörter (keywords) zu erzeugen, indem
     versucht wird, jene Flags in der Mailbox zu speichern.

RFC 3501 IMAPv4 March 2003

  READ-ONLY

     Die Mailbox ist schreibgeschützt ausgewählt, oder ihr Zugriff
     während der Auswahl hat sich von Lese-Schreiben zu Nur-Lesen
     geändert.

  READ-WRITE

     Die Mailbox ist Lese-Schreiben ausgewählt, oder ihr Zugriff
     während der Auswahl hat sich von Nur-Lesen zu Lese-Schreiben
     geändert.

  TRYCREATE

     Ein APPEND- oder COPY-Versuch schlägt fehl, weil die Ziel-Mailbox
     nicht existiert (im Gegensatz zu einem anderen Grund). Dies ist
     ein Hinweis an den Client, dass der Vorgang erfolgreich sein
     kann, wenn die Mailbox zuerst durch den CREATE-Befehl erstellt
     wird.

  UIDNEXT

     Gefolgt von einer Dezimalzahl, gibt den nächsten Wert des
     eindeutigen Bezeichners an. Siehe Abschnitt 2.3.1.1 für weitere
     Informationen.

  UIDVALIDITY

     Gefolgt von einer Dezimalzahl, gibt den Gültigkeitswert des
     eindeutigen Bezeichners an. Siehe Abschnitt 2.3.1.1 für weitere
     Informationen.

  UNSEEN

     Gefolgt von einer Dezimalzahl, gibt die Nummer der ersten
     Nachricht ohne gesetztes \Seen-Flag an.

  Zusätzliche Antwortcodes, die durch bestimmte Client- oder Server-
  Implementierungen definiert sind, SOLLTEN mit einem „X" gekennzeichnet
  sein, bis sie zu einer Überarbeitung dieses Protokolls hinzugefügt
  werden. Client-Implementierungen SOLLTEN Antwortcodes ignorieren,
  die sie nicht erkennen.