IMAP Obsolete Syntax: Internet Message Access Protocol - Obsolete Syntax
The old IMAP4 commands and responses that a server may still meet, and need not support.
Crispin, M., "Internet Message Access Protocol - Obsolete Syntax", RFC 2062, DOI 10.17487/RFC2062, December 1996, <https://www.rfc-editor.org/info/rfc2062>.
@misc{rfc2062,
series = {Request for Comments},
number = 2062,
howpublished = {RFC 2062},
publisher = {RFC Editor},
doi = {10.17487/RFC2062},
url = {https://www.rfc-editor.org/info/rfc2062},
author = {M. Crispin},
title = {{Internet Message Access Protocol - Obsolete Syntax}},
pagetotal = 8,
year = 1996,
month = dec,
} RFC text
Contents
Network Working Group M. Crispin
Request for Comments: 2062 University of Washington
Category: Informational December 1996
Internet Message Access Protocol - Obsolete Syntax
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document describes obsolete syntax which may be encountered by
IMAP4 implementations which deal with older versions of the Internet
Mail Access Protocol. IMAP4 implementations MAY implement this
syntax in order to maximize interoperability with older
implementations.
This document repeats information from earlier documents, most
notably RFC 1176 and RFC 1730.
Obsolete Commands and Fetch Data Items
The following commands are OBSOLETE. It is NOT required to support
any of these commands or fetch data items in new server
implementations. These commands are documented here for the benefit
of implementors who may wish to support them for compatibility with
old client implementations.
The section headings of these commands are intended to correspond
with where they would be located in the main document if they were
not obsoleted.
6.3.OBS.1. FIND ALL.MAILBOXES Command
Arguments: mailbox name with possible wildcards
Data: untagged responses: MAILBOX
Result: OK - find completed
NO - find failure: can't list that name
BAD - command unknown or arguments invalid
The FIND ALL.MAILBOXES command returns a subset of names from the
complete set of all names available to the user. It returns zero
or more untagged MAILBOX replies. The mailbox argument to FIND
ALL.MAILBOXES is similar to that for LIST with an empty reference,
except that the characters "%" and "?" match a single character.
Example: C: A002 FIND ALL.MAILBOXES *
S: * MAILBOX blurdybloop
S: * MAILBOX INBOX
S: A002 OK FIND ALL.MAILBOXES completed
6.3.OBS.2. FIND MAILBOXES Command
Arguments: mailbox name with possible wildcards
Data: untagged responses: MAILBOX
Result: OK - find completed
NO - find failure: can't list that name
BAD - command unknown or arguments invalid
The FIND MAILBOXES command returns a subset of names from the set
of names that the user has declared as being "active" or
"subscribed". It returns zero or more untagged MAILBOX replies.
The mailbox argument to FIND MAILBOXES is similar to that for LSUB
with an empty reference, except that the characters "%" and "?"
match a single character.
Example: C: A002 FIND MAILBOXES *
S: * MAILBOX blurdybloop
S: * MAILBOX INBOX
S: A002 OK FIND MAILBOXES completed
6.3.OBS.3. SUBSCRIBE MAILBOX Command
Arguments: mailbox name
Data: no specific data for this command
Result: OK - subscribe completed
NO - subscribe failure: can't subscribe to that name
BAD - command unknown or arguments invalid
The SUBSCRIBE MAILBOX command is identical in effect to the
SUBSCRIBE command. A server which implements this command must be
able to distinguish between a SUBSCRIBE MAILBOX command and a
SUBSCRIBE command with a mailbox name argument of "MAILBOX".
Example: C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime
S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime
completed
C: A003 SUBSCRIBE MAILBOX
S: A003 OK SUBSCRIBE to MAILBOX completed
6.3.OBS.4. UNSUBSCRIBE MAILBOX Command
Arguments: mailbox name
Data: no specific data for this command
Result: OK - unsubscribe completed
NO - unsubscribe failure: can't unsubscribe that name
BAD - command unknown or arguments invalid
The UNSUBSCRIBE MAILBOX command is identical in effect to the
UNSUBSCRIBE command. A server which implements this command must
be able to distinguish between a UNSUBSCRIBE MAILBOX command and
an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX".
Example: C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime
S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime
completed
C: A003 UNSUBSCRIBE MAILBOX
S: A003 OK UNSUBSCRIBE from MAILBOX completed
6.4.OBS.1 PARTIAL Command
Arguments: message sequence number
message data item name
position of first octet
number of octets
Data: untagged responses: FETCH
Result: OK - partial completed
NO - partial error: can't fetch that data
BAD - command unknown or arguments invalid
The PARTIAL command is equivalent to the associated FETCH command,
with the added functionality that only the specified number of
octets, beginning at the specified starting octet, are returned.
Only a single message can be fetched at a time. The first octet
of a message, and hence the minimum for the starting octet, is
octet 1.
The following FETCH items are valid data for PARTIAL: RFC822,
RFC822.HEADER, RFC822.TEXT, BODY[<section>], as well as any .PEEK
forms of these.
Any partial fetch that attempts to read beyond the end of the text
is truncated as appropriate. If the starting octet is beyond the
end of the text, an empty string is returned.
The data are returned with the FETCH response. There is no
indication of the range of the partial data in this response. It
is not possible to stream multiple PARTIAL commands of the same
data item without processing and synchronizing at each step, since
streamed commands may be executed out of order.
There is no requirement that partial fetches follow any sequence.
For example, if a partial fetch of octets 1 through 10000 breaks
in an awkward place for BASE64 decoding, it is permitted to
continue with a partial fetch of 9987 through 19987, etc.
The handling of the \Seen flag is the same as in the associated
FETCH command.
Example: C: A005 PARTIAL 4 RFC822 1 1024
S: * 1 FETCH (RFC822 {1024}
S: Return-Path: <gray@cac.washington.edu>
S: ...
S: ......... FLAGS (\Seen))
S: A005 OK PARTIAL completed
6.4.5.OBS.1 Obsolete FETCH Data Items
The following FETCH data items are obsolete:
BODY[<...>0] A body part number of 0 is the [RFC-822] header of
the message. BODY[0] is functionally equivalent to
BODY[HEADER], differing in the syntax of the
resulting untagged FETCH data (BODY[0] is
returned).
RFC822.HEADER.LINES <header_list>
Functionally equivalent to BODY.PEEK[HEADER.LINES
<header_list>], differing in the syntax of the
resulting untagged FETCH data (RFC822.HEADER is
returned).
RFC822.HEADER.LINES.NOT <header_list>
Functionally equivalent to
BODY.PEEK[HEADER.LINES.NOT <header_list>],
differing in the syntax of the resulting untagged
FETCH data (RFC822.HEADER is returned).
RFC822.PEEK Functionally equivalent to BODY.PEEK[], except for
the syntax of the resulting untagged FETCH data
(RFC822 is returned).
RFC822.TEXT.PEEK
Functionally equivalent to BODY.PEEK[TEXT], except
for the syntax of the resulting untagged FETCH data
(RFC822.TEXT is returned).
Obsolete Responses
The following responses are OBSOLETE. Except as noted below, these
responses MUST NOT be transmitted by new server implementations.
Client implementations SHOULD accept these responses.
The section headings of these responses are intended to correspond
with where they would be located in the main document if they were
not obsoleted.
7.2.OBS.1. MAILBOX Response
Data: name
The MAILBOX response MUST NOT be transmitted by server
implementations except in response to the obsolete FIND MAILBOXES
and FIND ALL.MAILBOXES commands. Client implementations that do
not use these commands MAY ignore this response. It is documented
here for the benefit of implementors who may wish to support it
for compatibility with old client implementations.
This response occurs as a result of the FIND MAILBOXES and FIND
ALL.MAILBOXES commands. It returns a single name that matches the
FIND specification. There are no attributes or hierarchy
delimiter.
Example: S: * MAILBOX blurdybloop
7.3.OBS.1. COPY Response
Data: none
The COPY response MUST NOT be transmitted by new server
implementations. Client implementations MUST ignore the COPY
response. It is documented here for the benefit of client
implementors who may encounter this response from old server
implementations.
In some experimental versions of this protocol, this response was
returned in response to a COPY command to indicate on a
per-message basis that the message was copied successfully.
Example: S: * 44 COPY
7.3.OBS.2. STORE Response
Data: message data
The STORE response MUST NOT be transmitted by new server
implementations. Client implementations MUST treat the STORE
response as equivalent to the FETCH response. It is documented
here for the benefit of client implementors who may encounter this
response from old server implementations.
In some experimental versions of this protocol, this response was
returned instead of FETCH in response to a STORE command to report
the new value of the flags.
Example: S: * 69 STORE (FLAGS (\Deleted))
Formal Syntax of Obsolete Commands and Responses
Each obsolete syntax rule that is suffixed with "_old" is added to
the corresponding name in the formal syntax. For example,
command_auth_old adds the FIND command to command_auth.
command_auth_old ::= find
command_select_old
::= partial
date_year_old ::= 2digit
;; (year - 1900)
date_time_old ::= <"> date_day_fixed "-" date_month "-" date_year
SPACE time "-" zone_name <">
find ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE
list_mailbox
fetch_att_old ::= "RFC822.HEADER.LINES" [".NOT"] SPACE header_list /
fetch_text_old
fetch_text_old ::= "BODY" [".PEEK"] section_old /
"RFC822" [".HEADER" / ".TEXT" [".PEEK"]]
msg_data_old ::= "COPY" / ("STORE" SPACE msg_att)
partial ::= "PARTIAL" SPACE nz_number SPACE fetch_text_old SPACE
number SPACE number
section_old ::= "[" (number ["." number]) "]"
subscribe_old ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
unsubscribe_old ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
zone_name ::= "UT" / "GMT" / "Z" / ;; +0000
"AST" / "EDT" / ;; -0400
"EST" / "CDT" / ;; -0500
"CST" / "MDT" / ;; -0600
"MST" / "PDT" / ;; -0700
"PST" / "YDT" / ;; -0800
"YST" / "HDT" / ;; -0900
"HST" / "BDT" / ;; -1000
"BST" / ;; -1100
"A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6
"G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12
"N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6
"T" / "U" / "V" / "W" / "X" / "Y" ;; -7 to -12
Security Considerations
Security issues are not discussed in this memo.
Author's Address
Mark R. Crispin
Networks and Distributed Computing
University of Washington
4545 15th Aveneue NE
Seattle, WA 98105-4527
Phone: (206) 543-5762
EMail: MRC@CAC.Washington.EDU
ISO Plain Language
On this page
§1Why the Memo Exists
This document describes obsolete syntax which may be encountered by IMAP4 implementations that deal with older versions of the Internet Message Access Protocol. IMAP4 implementations may implement this syntax in order to maximize interoperability with older implementations. It repeats information from earlier documents, most notably RFC 1176 and RFC 1730.
The memo is a companion to the main IMAP4 document rather than a protocol in its own right. It lists commands, fetch data items and responses that are marked OBSOLETE, and states that it is not required to support any of these commands or fetch data items in new server implementations. They are documented here for the benefit of implementors who may wish to support them for compatibility with old client implementations. The section headings of these commands are intended to correspond with where they would be located in the main document if they were not obsoleted, so the numbering carries gaps and the suffix OBS.
Nothing here is required. The memo exists so that an implementor who chooses to support the old forms knows exactly what they are.
§2The Obsolete Commands
Four commands are listed as obsolete. FIND ALL.MAILBOXES takes a mailbox name with possible wildcards and returns untagged MAILBOX replies. It returns a subset of names from the complete set of all names available to the user, and its mailbox argument is similar to that for LIST with an empty reference, except that the characters % and ? match a single character. The result is OK when the find completed, NO when the find failed because that name cannot be listed, and BAD when the command is unknown or its arguments are invalid.
FIND MAILBOXES works the same way but returns a subset of the names the user has declared as being active or subscribed. Its mailbox argument is similar to that for LSUB with an empty reference, with the same % and ? wildcards, and it also returns untagged MAILBOX replies.
SUBSCRIBE MAILBOX and UNSUBSCRIBE MAILBOX are identical in effect to SUBSCRIBE and UNSUBSCRIBE, and both take a mailbox name as their argument. A server that implements them must be able to distinguish between a SUBSCRIBE MAILBOX command and a SUBSCRIBE command with a mailbox name argument of MAILBOX, and the same distinction is needed for UNSUBSCRIBE. That matters because MAILBOX is itself a possible mailbox name.
The FIND commands list mailboxes by pattern, and the SUBSCRIBE MAILBOX commands are older spellings of SUBSCRIBE and UNSUBSCRIBE. A server that accepts them has to be able to tell them apart from the ordinary commands with a mailbox named MAILBOX.
C: A002 FIND ALL.MAILBOXES *
S: * MAILBOX blurdybloop
S: * MAILBOX INBOX
S: A002 OK FIND ALL.MAILBOXES completed- OKCompleted — The command finished.
- NOFailure — The command failed, for example because that name cannot be listed.
- BADInvalid — The command is unknown or its arguments are invalid.
| Obsolete item | Command it imitates | How it differs |
|---|---|---|
| FIND ALL.MAILBOXES | LIST | Returns untagged MAILBOX replies, not LIST replies |
| FIND MAILBOXES | LSUB | Returns untagged MAILBOX replies, not LSUB replies |
| SUBSCRIBE MAILBOX | SUBSCRIBE | Same effect, but a server must tell the two apart |
| UNSUBSCRIBE MAILBOX | UNSUBSCRIBE | Same effect, but a server must tell the two apart |
| RFC822.PEEK | BODY.PEEK[] | Different syntax in the untagged FETCH data |
§3The PARTIAL Command and the Obsolete Fetch Items
The PARTIAL command takes a message sequence number, a message data item name, the position of the first octet and the number of octets, and returns untagged FETCH responses. It is equivalent to the associated FETCH command with the added functionality that only the specified number of octets, beginning at the specified starting octet, are returned. Only a single message can be fetched at a time, and the first octet of a message is octet 1. The valid data for PARTIAL are RFC822, RFC822.HEADER, RFC822.TEXT and BODY[section], as well as any .PEEK forms of these.
Any partial fetch that attempts to read beyond the end of the text is truncated as appropriate, and if the starting octet is beyond the end of the text an empty string is returned. The data come back in the FETCH response, and there is no indication of the range of the partial data in that response. It is not possible to stream multiple PARTIAL commands of the same data item without processing and synchronizing at each step, since streamed commands may be executed out of order. There is no requirement that partial fetches follow any sequence, so if a partial fetch of octets 1 through 10000 breaks in an awkward place for BASE64 decoding, it is permitted to continue with a partial fetch of 9987 through 19987. The handling of the \Seen flag is the same as in the associated FETCH command.
Five fetch data items are also obsolete. BODY[...]0, a body part number of 0, is the RFC-822 header of the message and is functionally equivalent to BODY[HEADER], differing in the syntax of the resulting untagged FETCH data. RFC822.HEADER.LINES is functionally equivalent to BODY.PEEK[HEADER.LINES], and RFC822.HEADER.LINES.NOT to BODY.PEEK[HEADER.LINES.NOT]. RFC822.PEEK is functionally equivalent to BODY.PEEK[], and RFC822.TEXT.PEEK to BODY.PEEK[TEXT]. In every case the difference is the syntax of the untagged FETCH data that comes back.
PARTIAL fetches a chosen stretch of a message, such as the first thousand bytes, so a client does not have to download the whole thing. The old fetch names do the same job under a different spelling.
§4The Obsolete Responses
Three responses are obsolete. Except as noted below, these responses must not be transmitted by new server implementations, and client implementations should accept them.
The MAILBOX response carries a name. It must not be transmitted by server implementations except in response to the obsolete FIND MAILBOXES and FIND ALL.MAILBOXES commands, and client implementations that do not use those commands may ignore it. It returns a single name that matches the FIND specification, with no attributes and no hierarchy delimiter.
The COPY response carries no data. It must not be transmitted by new server implementations, and client implementations must ignore it. In some experimental versions of the protocol this response was returned in response to a COPY command to indicate, on a per-message basis, that the message was copied successfully.
The STORE response carries message data. It must not be transmitted by new server implementations, and client implementations must treat it as equivalent to the FETCH response. In some experimental versions of the protocol this response was returned instead of FETCH in response to a STORE command, to report the new value of the flags.
The rule for these three is one-sided. A server must not send them, but a client must still cope if an old server does.
§5Formal Syntax
The memo gives the formal syntax rules for the obsolete commands and responses. Each rule suffixed with _old is added to the corresponding name in the formal syntax, so command_auth_old adds the FIND command to command_auth, and command_select_old adds PARTIAL to command_select.
The rules define find as FIND, optionally ALL., then MAILBOXES and a list_mailbox; partial as PARTIAL, a non-zero number, a fetch_text_old and two numbers; subscribe_old and unsubscribe_old as the SUBSCRIBE or UNSUBSCRIBE command followed by MAILBOX and a mailbox; fetch_att_old and fetch_text_old for the old fetch item names; msg_data_old for COPY and for STORE followed by a message attribute; section_old as a bracket containing an optional dotted number; and date_year_old and date_time_old for the date rules.
The zone_name rule lists the time zone names the protocol understands: UT, GMT and Z for plus zero; AST, EDT, EST, CDT, CST, MDT, MST, PDT, PST, YDT, YST, HDT, HST, BDT and BST for the North American offsets from minus four to minus eleven; and the single letters A through Y, skipping J, for offsets of plus one to plus twelve and minus one to minus twelve.
The last part of the memo is the grammar, so that a parser can be written from it. Each old rule is added to the modern one under a name ending in _old.
§6Security Considerations and Status
The Security Considerations section says only that security issues are not discussed in this memo. The status statement says that the memo provides information for the Internet community and does not specify an Internet standard of any kind, and that its distribution is unlimited.
The memo closes with the author's address at the University of Washington, and repeats information from earlier documents, most notably RFC 1176 and RFC 1730.
There is nothing about security here. The memo is a reference for implementors, not a standard to be met.