Skip to main content

8. Sample IMAP4rev1 Connection

A body type of type TEXT contains, immediately after the basic fields, the size of the body in text lines. Note that this size is the size in its content transfer encoding and not the resulting size after any decoding.

     Extension data follows the basic fields and the type-specific
     fields listed above.  Extension data is never returned with the
     BODY fetch, but can be returned with a BODYSTRUCTURE fetch.
     Extension data, if present, MUST be in the defined order.

     The extension data of a non-multipart body part are in the
     following order:

     body MD5
        A string giving the body MD5 value as defined in [MD5].

RFC 3501 IMAPv4 March 2003

     body disposition
        A parenthesized list with the same content and function as
        the body disposition for a multipart body part.

     body language
        A string or parenthesized list giving the body language
        value as defined in [LANGUAGE-TAGS].

     body location
        A string list giving the body content URI as defined in
        [LOCATION].

     Any following extension data are not yet defined in this
     version of the protocol, and would be as described above under
     multipart extension data.

  ENVELOPE
     A parenthesized list that describes the envelope structure of a
     message.  This is computed by the server by parsing the
     [RFC-2822] header into the component parts, defaulting various
     fields as necessary.

     The fields of the envelope structure are in the following
     order: date, subject, from, sender, reply-to, to, cc, bcc,
     in-reply-to, and message-id.  The date, subject, in-reply-to,
     and message-id fields are strings.  The from, sender, reply-to,
     to, cc, and bcc fields are parenthesized lists of address
     structures.

     An address structure is a parenthesized list that describes an
     electronic mail address.  The fields of an address structure
     are in the following order: personal name, [SMTP]
     at-domain-list (source route), mailbox name, and host name.

     [RFC-2822] group syntax is indicated by a special form of
     address structure in which the host name field is NIL.  If the
     mailbox name field is also NIL, this is an end of group marker
     (semi-colon in RFC 822 syntax).  If the mailbox name field is
     non-NIL, this is a start of group marker, and the mailbox name
     field holds the group name phrase.

     If the Date, Subject, In-Reply-To, and Message-ID header lines
     are absent in the [RFC-2822] header, the corresponding member
     of the envelope is NIL; if these header lines are present but
     empty the corresponding member of the envelope is the empty
     string.

RFC 3501 IMAPv4 March 2003

        Note: some servers may return a NIL envelope member in the
        "present but empty" case.  Clients SHOULD treat NIL and
        empty string as identical.

        Note: [RFC-2822] requires that all messages have a valid
        Date header.  Therefore, the date member in the envelope can
        not be NIL or the empty string.

        Note: [RFC-2822] requires that the In-Reply-To and
        Message-ID headers, if present, have non-empty content.
        Therefore, the in-reply-to and message-id members in the
        envelope can not be the empty string.

     If the From, To, cc, and bcc header lines are absent in the
     [RFC-2822] header, or are present but empty, the corresponding
     member of the envelope is NIL.

     If the Sender or Reply-To lines are absent in the [RFC-2822]
     header, or are present but empty, the server sets the
     corresponding member of the envelope to be the same value as
     the from member (the client is not expected to know to do
     this).

        Note: [RFC-2822] requires that all messages have a valid
        From header.  Therefore, the from, sender, and reply-to
        members in the envelope can not be NIL.

  FLAGS
     A parenthesized list of flags that are set for this message.

  INTERNALDATE
     A string representing the internal date of the message.

  RFC822
     Equivalent to BODY[].

  RFC822.HEADER
     Equivalent to BODY[HEADER].  Note that this did not result in
     \Seen being set, because RFC822.HEADER response data occurs as
     a result of a FETCH of RFC822.HEADER.  BODY[HEADER] response
     data occurs as a result of a FETCH of BODY[HEADER] (which sets
     \Seen) or BODY.PEEK[HEADER] (which does not set \Seen).

  RFC822.SIZE
     A number expressing the [RFC-2822] size of the message.

RFC 3501 IMAPv4 March 2003

  RFC822.TEXT
     Equivalent to BODY[TEXT].

  UID
     A number expressing the unique identifier of the message.

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

7.5. Server Responses - Command Continuation Request​

The command continuation request response is indicated by a "+" token instead of a tag. This form of response indicates that the server is ready to accept the continuation of a command from the client. The remainder of this response is a line of text.

This response is used in the AUTHENTICATE command to transmit server data to the client, and request additional client data. This response is also used if an argument to any command is a literal.

The client is not permitted to send the octets of the literal unless the server indicates that it is expected. This permits the server to process commands and reject errors on a line-by-line basis. The remainder of the command, including the CRLF that terminates a command, follows the octets of the literal. If there are any additional command arguments, the literal octets are followed by a space and those arguments.

Example: 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"

Last updated on