Zum Hauptinhalt springen

8. Beispiel einer IMAP4rev1-Verbindung (Sample IMAP4rev1 Connection)

Ein body-Typ vom Typ TEXT enthält unmittelbar nach den Grundelementen (basic fields) die Größe des Body in Textzeilen. Beachten Sie, dass diese Größe die Größe in deren Content-Transfer- Encoding ist und nicht die resultierende Größe nach einer etwaigen Decodierung.

     Erweiterungsdaten (extension data) folgen auf die Grundelemente und
     die oben aufgeführten typspezifischen Felder. Erweiterungsdaten
     werden bei einem BODY-Fetch niemals zurückgegeben, können aber bei
     einem BODYSTRUCTURE-Fetch zurückgegeben werden. Erweiterungsdaten,
     falls vorhanden, MÜSSEN in der definierten Reihenfolge vorliegen.

     Die Erweiterungsdaten eines nicht mehrteiligen Body-Teils (non-
     multipart body part) liegen in folgender Reihenfolge vor:

     body MD5
        Eine Zeichenkette, die den Body-MD5-Wert gemäß [MD5] angibt.

RFC 3501 IMAPv4 March 2003

     body disposition
        Eine in Klammern gesetzte Liste mit demselben Inhalt und
        derselben Funktion wie die Body-Disposition für einen
        mehrteiligen Body-Teil (multipart body part).

     body language
        Eine Zeichenkette oder in Klammern gesetzte Liste, die den
        Body-Sprachwert gemäß [LANGUAGE-TAGS] angibt.

     body location
        Eine Zeichenkettenliste, die den Body-Inhalts-URI gemäß
        [LOCATION] angibt.

     Alle folgenden Erweiterungsdaten sind in dieser Version des
     Protokolls noch nicht definiert und wären so beschaffen wie oben
     unter Erweiterungsdaten für mehrteilige Bodies beschrieben.

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

     Die Felder der Umschlagstruktur liegen in folgender Reihenfolge
     vor: date, subject, from, sender, reply-to, to, cc, bcc,
     in-reply-to und message-id. Die Felder date, subject, in-reply-to
     und message-id sind Zeichenketten. Die Felder from, sender,
     reply-to, to, cc und bcc sind in Klammern gesetzte Listen von
     Adressstrukturen.

     Eine Adressstruktur ist eine in Klammern gesetzte Liste, die eine
     elektronische Mail-Adresse beschreibt. Die Felder einer
     Adressstruktur liegen in folgender Reihenfolge vor: persönlicher
     Name, [SMTP] at-domain-list (Quellroute/source route), Mailbox-Name
     und Host-Name.

     Die [RFC-2822]-Gruppensyntax wird durch eine Sonderform der
     Adressstruktur angezeigt, bei der das Host-Namen-Feld NIL ist. Ist
     das Mailbox-Namen-Feld ebenfalls NIL, so ist dies eine
     Gruppenendemarke (Semikolon in der RFC-822-Syntax). Ist das
     Mailbox-Namen-Feld nicht NIL, so ist dies eine Gruppenstartmarke,
     und das Mailbox-Namen-Feld enthält die Gruppenname-Phrase.

     Wenn die Header-Zeilen Date, Subject, In-Reply-To und Message-ID im
     [RFC-2822]-Header fehlen, ist das entsprechende Mitglied des
     Umschlags NIL; wenn diese Header-Zeilen vorhanden, aber leer sind,
     ist das entsprechende Mitglied des Umschlags die leere Zeichenkette.

RFC 3501 IMAPv4 March 2003

        Hinweis: Einige Server geben im Fall „vorhanden, aber leer" ein
        NIL-Umschlagmitglied zurück. Clients SOLLTEN NIL und leere
        Zeichenkette als identisch behandeln.

        Hinweis: [RFC-2822] verlangt, dass alle Nachrichten einen
        gültigen Date-Header haben. Daher kann das date-Mitglied im
        Umschlag nicht NIL oder die leere Zeichenkette sein.

        Hinweis: [RFC-2822] verlangt, dass die Header In-Reply-To und
        Message-ID, falls vorhanden, nicht-leeren Inhalt haben. Daher
        können die in-reply-to- und message-id-Mitglieder im Umschlag
        nicht die leere Zeichenkette sein.

     Wenn die Header-Zeilen From, To, cc und bcc im [RFC-2822]-Header
     fehlen oder vorhanden, aber leer sind, ist das entsprechende
     Mitglied des Umschlags NIL.

     Wenn die Zeilen Sender oder Reply-To im [RFC-2822]-Header fehlen
     oder vorhanden, aber leer sind, setzt der Server das entsprechende
     Mitglied des Umschlags auf denselben Wert wie das from-Mitglied
     (vom Client wird nicht erwartet, dass er dies tut).

        Hinweis: [RFC-2822] verlangt, dass alle Nachrichten einen
        gültigen From-Header haben. Daher können die from-, sender- und
        reply-to-Mitglieder im Umschlag nicht NIL sein.

  FLAGS
     Eine in Klammern gesetzte Liste von Flags, die für diese Nachricht
     gesetzt sind.

  INTERNALDATE
     Eine Zeichenkette, die das interne Datum (internal date) der
     Nachricht darstellt.

  RFC822
     Entspricht BODY[].

  RFC822.HEADER
     Entspricht BODY[HEADER]. Beachten Sie, dass dies nicht zur Folge
     hatte, dass \Seen gesetzt wurde, da RFC822.HEADER-Antwortdaten als
     Ergebnis eines FETCH von RFC822.HEADER auftreten. BODY[HEADER]-
     Antwortdaten treten als Ergebnis eines FETCH von BODY[HEADER]
     (welches \Seen setzt) oder BODY.PEEK[HEADER] (welches \Seen nicht
     setzt) auf.

  RFC822.SIZE
     Eine Zahl, die die [RFC-2822]-Größe der Nachricht ausdrückt.

RFC 3501 IMAPv4 March 2003

  RFC822.TEXT
     Entspricht BODY[TEXT].

  UID
     Eine Zahl, die den eindeutigen Bezeichner (unique identifier) der
     Nachricht ausdrückt.

Beispiel: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)

7.5. Serverantworten - Anforderung zur Befehlsfortsetzung (Server Responses - Command Continuation Request)​

Die Antwort zur Befehlsfortsetzung (command continuation request) wird durch ein „+“-Token anstelle eines Tags angezeigt. Diese Antwortform zeigt an, dass der Server bereit ist, die Fortsetzung eines Befehls vom Client zu akzeptieren. Der restliche Teil dieser Antwort ist eine Zeile Text.

Diese Antwort wird im AUTHENTICATE-Befehl verwendet, um Serverdaten an den Client zu übertragen und zusätzliche Clientdaten anzufordern. Diese Antwort wird ebenfalls verwendet, wenn ein Argument eines beliebigen Befehls ein Literal ist.

Dem Client ist es nicht gestattet, die Oktette des Literals zu senden, es sei denn, der Server zeigt an, dass diese erwartet werden. Dies erlaubt es dem Server, Befehle zeilenweise zu verarbeiten und Fehler zeilenweise zurückzuweisen. Der restliche Teil des Befehls, einschließlich des CRLF, das einen Befehl abschließt, folgt auf die Oktette des Literals. Gibt es weitere Befehlsargumente, so folgen auf die Literal-Oktette ein Leerzeichen und jene Argumente.

Beispiel: C: A001 LOGIN \{11\} S: + Ready for additional command text C: FRED FOOBAR \{7\} S: + Ready for additional command text C: fat man S: A001 OK LOGIN completed C: A044 BLURDYBLOOP \{102856\} S: A044 BAD No such command as "BLURDYBLOOP"